See also: IRC log
Considering which issues to discuss (apologies again for not providing more notice; I'll try to do better next week): 004 (again) 015, 022, 023, 035.
More possibilities: 017, 021, 025, 026, 027
-> http://www.w3.org/XML/XProc/2009/01/22-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2009/01/08-minutes
Accepted.
Paul gives regrets.
-> Topic: Next meeting: telcon 29 Jan 2009?
-> http://www.w3.org/XML/XProc/2008/11/cr-comments/
Henry: This whole thing is hugely
complicated and it's not made at all easier by the fact that
none of the relevant XML specs are really consistent with one
another.
... It's not the case that it's easy for us to say that we
should do it like everyone else, because they all do it
differently.
... The Infoset says that if you assemble a document out of
multiple general entities, the base URI changes
accordingly.
... But it doesn't have a serialization or any sort of base URI
fixup.
... On the other end of the spectrum, XInclude (V1) said that
you had to insert xml:base attributes and change the
infoset.
... In the middle, we have XSLT which will change the base URI
if you add xml:base attributes, but can't preserve them when
copying.
... So the one observation that Richard made that I point to in
this email:
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2009Jan/0012.html
scribe: is that XML Base is a bit
like character entities or namespace declarations. They're
there in order to effect the infoset, but they're not part of
the document. They're metadata.
... And therefore, there's no guarantee that they're going to
be there when you serialize.
... So it's not completely outrageous to think that you might
loose base URI information when you serialize.
Alex: It seems that if you delete the xml:base attribute, then you get what you deserve if you really wanted to preserve the base URI.
Henry: At the moment, I'm inclined towards the position that we should sort of follow XSLT: if you delete an xml:base attribute, it does not change the base URI attribute of the element.
Alex: But you lose it if you serialize.
Henry: Yes. In the same way that
a parser takes account of general entity structure and the base
URIs, but they won't be preserved when yous serialize.
... What Richard eventually conceded, is that if we leave the
spec the way it is, he can still serialize between steps and
carry the base URI out-of-band.
Straw poll: Removing the xml:base attribute (a) removes the base URI property from the infoset or (b) does not change it.
Results: Five for (b) no change, 1 abstention.
Vojtech: If I really want to remove the base URI information, then I should ... add an xml:base attribute with the value from the parent.
Some discussion of serialization.
Henry: Are we also in agreement that we do have to update the spec everywhere you can do something that can add or change the value of an attribute to say that if the attribute is added/changed is the xml:base attribute, this causes a change to the XML base property.
Norm: Anyone who disagrees?
None heard.
<scribe> ACTION: Norm to edit the spec so that we say that any change to xml:base or adding an xml:base does change the underlying infoset property. [recorded in http://www.w3.org/2009/01/22-xproc-minutes.html#action01]
Vojtech: The question of whether
it generates one UUID or many has been answered: it generates
one UUID.
... The remaining question is whether this step needs
additional options or parameters.
Norm: Do we know what the parameters/options are?
Some discussion of the various types of UUID.
Norm: I think the question is, do we leave other versions implementation-defined, or do we try to add parameters/options to make it interoperable.
Alex: I think we should provide the options.
Vojtech: In Java you can generate
type 3.
... I was thinking maybe it was sufficient to do for p:uuid
what we do for p:hash
Norm: To be honest, I think for V1 we should just make the parameters that are needed for other UUID formats implementation defined.
More discussion about the virtues of parameters instead of extension attributes.
Vojtech: Why don't we just say that the only supported version is version 4.
Alex: I guess I could live with implementation defined.
Proposal: Implementations must support version=4, support for other versions (and how options/parameters are provided for those versions) is implementation-defined.
Accepted.
Norm: If you don't specify a method on p:http-request, do we work it out dynamically or do we make method required?
Alex: I think we should make it a required attribute.
Norm: That's what I thought too, in email following up.
Proposal: The method is required, it is an error to attempt to use p:http-request without a specified method.
Accepted.
Vojtech: I think that's clear now, you can do a post a body.
Norm: Is there any distinction between no c:body and an empty c:body?
Alex: I think if you specify an empty body, you get a content-length: 0, and if you don't specify a body, you don't get any entity body.
Proposal: Yes, you can have a POST with no c:body element.
Accepted.
Norm: I think James is asking for the ability to get the step name without passing it as a separate option. Looks like creeping featurism to me: not in V1?
Proposal: Not in V1.
Accepted.
Vojtech: I thought that in the XQuery step we should have an error for reporting bad XQuery.
Norm: A particular error code for "couldn't understand the query"?
Vojtech: Yes, I think we could put all the possible errors in one error code.
Alex: Could we add an error for
"unable to process input", we could use it for XSLT, XQuery,
XML Formatter. I could use it for a SPARQL step if I had one,
etc.
... These could apply to the validator steps as well.
Proposal: A generic error for "unable to process input/input format wrong/etc." that all steps (including custom steps) can throw when appropriate.
Accepted.
Vojtech: I was wondering what
happens if you replace the document element with an empty
string in p:string-replace.
... Does this call XD0001?
... One of the answers was 'yes'.
Norm: Yep, that works for me.
Vojtech: I was trying to write a test for this.
Norm: We don't require processors to produce exactly the right errors, but it's still good to be clear.
Proposal: Close without action.
Accepted.
Vojtech: You can have a wrapper
element which if you unesacpe the content then you get five
elements inside. The text about unescape-markup talks about a
single document element.
... I think that phrasing should be changed so that it covers
the case where unescaping gives five elements (or no elements)
in the wrapper.
... I think it should be applied to each of the elements in the
wrapper.
Alex: The way I look at this is,
when you provide the default namespace, it's like you're
wrapping the whole thing in a pseudo-element that you can throw
away.
... that's effectively the behavior.
Norm: It sounds like this is mostly editorial, handling the case where there are multiple or no elements.
Vojtech: Issue 080 is related: if
you specify a namespace but the unescaped content already has a
default namespace.
... Or if the element declares other namespaces. Are they
effected?
Alex: If you take the escaped content, treat it as if it was wrapped in an element with a default namespace declaration, and then take it's children. That's what should happen.
Norm: I think the practical upshot is that the answer is that if there are default namespace bindings in the content, those bindings "win" and it has no effect on any other namespace declarations.
Vojtech: The spec currently gives the impression that it overrides the defalut.
Norm: I agree, the spec is confusing.
Proposal: Close 025 with no action, close 080 with an action to the editor to clarify the spec so that any specified namespace clearly does not override any explicit declarations in the escaped content.
Vojtech: Part of my question in 025 was about the case where you have no root elements or more than one.
Norm: Right.
Proposal: Close 025 with an action to the editor to clarify the case where unescaping produces no elements or more than one element, close 080 with an action to the editor to clarify the spec so that any specified namespace clearly does not override any explicit declarations in the escaped content.
Accepted.
<scribe> ACTION: Norm to edit the spec to fix 025 and 080. [recorded in http://www.w3.org/2009/01/22-xproc-minutes.html#action02]
None heard.
Adjourned.