text: Agenda
  See also: IRC log
  ->
  Accepted.
  ->
  Accepted.
  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]
  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
  unescape-markup.
  ... 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?
  No objections
  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
  Accepted.
  Alex: Can we do a simple one, let's just adopt his description fo static and dynamic context.
  Norm: Don't we already?
  Alex: No
  Norm: Ok, right, we have it for XProc but not for XQuery.
  Alex: We should do it for both XSLT and XQuery
  Norm: Yes.
  <scribe> ACTION: Norm to update the XSLT and XQuery steps to include static and dynamic context information [recorded in]
  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.
  <alexmilowski>
  Alex: I could read it with
  http-request
  ... 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
  default wrapper.
  ... 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]
  None heard.
  Adjourned.