See also: IRC log
Introductions all around.
No regrets given.
Norm updated the draft to include Henry's comments, the tumblers, and a first pitiful stab at an appendix on parallel processing.
Alex observes that the parallel processing section is currently section 8, probably should be an appendix.
Norm: Yes, you're probably right, I'll move it.
Norm: No, I don't think so, it's just for explanation.
Vojtech: The issue I had was a
simple pipeline that transformas an XML document. What wasn't
clear was what the resulting documents base URIs were.
... Can I manipulate the base URI and assign it?
... If I process document.xml, I want to get document.fo, for example.
... Later I thought if I have a pipeline that validates a document, does the result have the same base URI.
<alexmilowski> XSLT 2.0 says: "The base URI of the new element is copied from the base URI of the literal result element in the stylesheet, unless the content of the new element includes an xml:base attribute, in which case the base URI of the new element is the value of that attribute, resolved (if it is a relative URI) against the base URI of the literal result element in the stylesheet."
<alexmilowski> In section 11.1
Norm: I think steps don't change the base URI unless they explicitly say that they do.
Vojtech: So even viewport and split don't change the base URI?
Alex: I had always imagined that
a lot of the steps we have are identity++; and so if you think
of it from that perspective, it's just like changing parts of
the infoset, leaving the base URI alone.
... Maybe one of the things we have to do is explain this more carefully.
... We're probably underspecified.
Norm: Yes, I think that definitely needs to be added.
Some discussion of XPath 1.0/2.0 functions for updating base URI.
Norm outlines his proposal for p:set-base-uri
Some discussion of what has a base URI.
Richard: I think we should say that the individual documents produced by p:viewport have the base URI of their document elements.
<scribe> ACTION: Alex to update the spec so it says this. [recorded in http://www.w3.org/2008/04/03-xproc-minutes.html#action01]
Alex: It seems to me that it
isn't string manipulation isn't right, what you want is
relative URI resolution.
... It seems to me that set-base-uri should also handle the case of relative URI resolution.
Norm: That seems reasonable to me.
Alex: If we wanted to roll this up so that implementors that don't have XPath 2.0 have a step to do this, we need to think about this a little bit more.
Norm: I'd be very happy if we continued to expand this proposal in email.
Some discussion of whether we want variables or functions.
Richard: For finding base-uri, I
don't think it makes any sense to have a variable.
... I think it should be a function that returns the base URI of an element.
... Maybe it just makes sense for us to provide a suite of extension functions in XProc.
... get the base URI, resolve it to an absolute URI, relativize it against a base URI, etc.
Norm: Maybe my step idea was ill-conceived. Perhaps we should just make extension functions; that resolves the XPath version issue.
Vojtech: I agree with this, but I think we also need to say how the base URI is passed between steps.
Richard: You can't say the base URI is the same, you have to say something like: the base URI of the primary output is teh same as the base URI of the primary input unless otherwise stated.
<scribe> ACTION: Norm to review the steps to clarify which ones change base URIs and how. [recorded in http://www.w3.org/2008/04/03-xproc-minutes.html#action02]
Norm: I'm inclined to agree with Richard and say we should persue this with extension functions.
Alex reports that it's label-elements that has a magic variable, but that change isn't reflected int he spec.
<scribe> ACTION: Alex to update label-elements in the spec [recorded in http://www.w3.org/2008/04/03-xproc-minutes.html#action03]
<scribe> ACTION: Richard to draft a proposal for the new functions [recorded in http://www.w3.org/2008/04/03-xproc-minutes.html#action04]
Norm: Are these decisions sufficient to cover issue #83?
Vojtech: I think so.
1. We need to implement the decision of today, clearer prose and new extension functions
2. We need to review the parallelism appendix
3. We need to update the label-elements step, check other steps
Vojtech: I have a question about
... You can insert only a single document or element, should we allow a sequence?
Norm: Indeed, I don't see why
insertion couldn't be a sequence
... Anyone think we shouldn't?
Alex: We have the same rules for detecting errors as anywhere else, so I think that's fine.
Proposed: Change insertion port to be a sequence