See also: IRC log
-> http://www.w3.org/XML/XProc/2015/06/24-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2015/06/10-12-minutes.html
Accepted.
Any regrets for 1 July?
Murray gives regrets.
Jim reports progress on A-265-02; Norm will make sure that's on the agenda for next week.
<jfuller> https://github.com/xproc/specification/issues/136
-> https://ndw.github.io/specification/
<alexmilowski> https://ndw.github.io/specification/langspec/small-fixes/head/xproc20/diff.html
Comments on 2.10 Value Templates
Henry: I think there are a lot of
problems with the terminology. There's overloading of the
attribute/element that might contain something in curly braces
and the strings that contain curly braces.
... They're both called value templates and I don't think
that's helpful.
... I tried to rework it but it wasn't obvious. Introducing
different terms for contexts where value templates are allowed
on the one hand and on the other, the thing that's in there
that gets expanded and so on.
Norm: Entirely fair; I tried to copy what was in the XSLT draft and I don't think it works.
Henry: A few more comments
then.
... The word "alternating" should be removed from the first
paragraph.
... It's just a sequence because {$foo}{$bar} is prefectly
fine.
<alexmilowski> Isn't "{}" just a variable part that returns an empty sequence / empty string ?
Henry: The next to last sentence of that paragraph and the note that follows contradict each other.
<jfuller> its an error
<ht> }{
<alexmilowski> Right, got it.
<alexmilowski> (still drinking my coffee; coffee good)
Henry: The "fixed part of"
following the note has only been removed in one place. That
seems an error.
... In 2.10.1 but not 2.10.2, in the second bullet don't we
need a reference to the process in XPath?
... "converting the value to a string" is non-obvious: you have
to atomize, etc.
... And finally, below the deleted note in 2.10.2, the sentence
that begins "The rules for text value templates..." should be
removed.
<alexmilowski> Are we going to say something about: <x>xyzzy{@y}</x> ?
Henry: We should have a note that
says that.
... Perhaps we could point to something in XQuery that
describes how that construction works.
<alexmilowski> 5.2 ?
Norm: The change in 5 is entirely
editorial, I added new sections.
... In 5.2, I removed @expand-text.
<alexmilowski> 5.51 & 5.5.3 - same change
<alexmilowski> 5.5.1
Norm: The changes in 5.10 are an attempt to get non-XML inlines.
<alexmilowski> Editorial: make the non-XML content subsection first as it is very short.
<alexmilowski> @encoding is separable from this.
Henry: "Interpretation of the content" is wrong; it's "decoding of the content"
Alex: The right way to slice this
is to say you're starting with two things, an encoding
attribute that gives you a sequence of bytes or you have a
sequence of nodes (children of the inline) and you have to
coerce that into a document.
... What happens if you have element nodes in the content.
Henry: I'm happy to special case that. If it's an XML application type, then elements are ok.
Norm: The case of XML that's base64 encoded needs to be considered as well.
Alex: Can't we just make encoding XML an error? This is an inline.
<alexmilowski> We have three categories: text/*, XML media types, everything else
Henry: Are we clear that you can specify a charset on the content type?
<alexmilowski> encoding=base64, content-type=text/xml is an error
Norm: If you base64 encode the text then you have to be able to specify the charset.
encoding=base64, content-type=text/plain; charset=ASCII should work
Alex: Maybe we should just show the matrix: encoding, text, XML, non-XML
Some discussion of media type vs. content type.
Alex: The syntax we're relying on is the value space of content type.
Change MediaType to ContentType
<jfuller> (Internet) Media Type vs Content-Type (the header ?)
Norm mutters on a bit about a primer.
Norm: We thought of you Murray.
<jfuller> to add- as well as editing primer and getting others to contrib
Murray: I'm busy for at least a month but then I might be interested.
Alex: Consensus generally was that we also need someone to think creatively about this.
Murray: Sure.
<jfuller> https://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2015Jun/0012.html
<jfuller> +1 to accepting p:variable everywhere
<jfuller> agree no need to put in atomics
<scribe> ACTION: Norm to draft p:variable everywhere. [recorded in http://www.w3.org/2015/06/24-xproc-minutes.html#action01]
<jfuller> and I've put a comment in https://github.com/xproc/specification/issues/132 that we should probably close (as p:variable in atomic may not mean anything)
Adjourned.