See also: IRC log
Norm gives regrets, Henry has agreed to chair.
Alex and Norm, get to work!
Norm summarizes Richard's mail.
Alex: The use case is things like RSS and things that have escaped markup in them.
Norm: I think we should say that the XML declaration if it appears is ignored, and any DOCTYPE declarations are ignored.
Alex: The algorithm that I use to
do this that you wrap the text descendants in some kind of
pseudo document element.
... So you can just run it through a parser.
Norm: I don't care if we make it an error or if we ignore it, but I think we should be consistent.
Alex: We could add an option to specify "treat like document
Norm: Isn't that making things more complicated?
Alex: You could get escaped
markup from http-requests.
... You might really, truely get an HTML document.
... which would be escaped because text/html is not XML.
... I think we should say look, either treat the text as a document or treat it as a text entity.
... If you treat it as a document, then the default-namespace option is superflous.
... But any doctype declaration should do the right thing.
Norm: SO your idea is make the user decide, and then the only thing that's difficult is a XML declaration at the top of something that you're not treating as a document.
Vojtech: Why can't we just do the opposite of escape markup, just make it an error if the unescaped isn't an XML document.
Alex: Because RSS often contains
sibling escaped elements, not a valid document.
... The example in p:unescape-markup is wrong, the description element can't have the declaration.
<scribe> ACTION: Alex to fix the example in p:unescape-markup so the namespace declarations are percolated through [recorded in http://www.w3.org/2008/07/17-xproc-minutes.html#action01]
Norm: So I still see just two possibilities: add a new option, or declare that XML decls and DTDs are ignored.
Alex: What about the HTML case
Norm: You'd get the document, it just wouldn't be validated.
Alex: So no attribute defaulting?
Vojtech: I sort of don't like
that there's no symmetry between escape-markup and
... In one we insert a wrapper, in the other we don't remove it.
Alex: They are symmetrical, escape-markup escapes the children.
Norm: Let's take this to email. We don't seem to be making any more progress today.
Vojtech: It seems to me that
there are two cases. If you use escape markup, you'll never
produce something that contains an XML decl or doctype. So the
only problem is text that comes from the outside.
... Maybe in that case we could provide an option to remove the containing element, so that we can handle doctypes or XML declarations.
Alex: I think that was my idea for a "treat as document" element.
Vojtech: So unescape-markup could remove the c:body wrapper and return the content.
Norm: Can we take this to email?
Norm: Let's start with Andrew's comments first.
Alex: I'm a little confused about invocation of XQuery and someone would want both a context node and a sequence of documents.
Norm: Yes, Andrew wants to be able to distinguish the source document from the default collection.
Alex: I don't understand from an
XQuery context if it's comment to have a default collection and
a context item?
... In XSLT, we say that the first node in the sequence is the context node.
Norm: Let's try making that explicit in the XQuery step and be consistent.
Proposal: Make XQuery consistent with XSLT wrt context node and default collection
Alex: Can we do a simple one, let's just adopt his description fo static and dynamic context.
Norm: Don't we already?
Norm: Ok, right, we have it for XProc but not for XQuery.
Alex: We should do it for both XSLT and XQuery
<scribe> ACTION: Norm to update the XSLT and XQuery steps to include static and dynamic context information [recorded in http://www.w3.org/2008/07/17-xproc-minutes.html#action02]
Norm: Now let's look at making a reference to an XQuery file
Norm: You can't load an external query now, which I think we need to fix.
Alex: I could read it with
... You can do it with http-request, but input can't, and I don't see why.
Norm outlines his email
Alex: I can see two additions
that would make this straightforward. We could make c:body the
... And I think it would be appropriate to say that you can do the conversion to base64 instead.
... Based on media-type, it should be able to do something better.
... But a pipeline could still fail if it got back media types it couldn't process.
Mohamed: I'm opposed to changing
p:document; I think we should do this with a step.
... I think we need a different p:load that's able to do this.
Norm: What about putting something else in p:input as an alternative to p:document
Mohamed: That would be ok to me.
Alex: There are other things out there, there's SPARQL, etc.
Mohamed: We have the same issue for RELAX NG compact syntax, and other places.
Norm: We need uri and wrapper
Mohamed: I think you also need encoding
Norm: What about binary vs. text?
Alex: We already have this language in http-request.
Norm: Ok, I see what you mean.
Alex: Having an option to tweak
the charsets would also be handy.
... I think the default is, if it's not an XML media type, if it's not something you know is text, then you get base64.
... And then we have to decide about attributes on the wrapper.
... Basically, translation of the conversion we do on c:body, basically.
<scribe> ACTION: Norm/Alex to write up a proposal to add this. [recorded in http://www.w3.org/2008/07/17-xproc-minutes.html#action03]