See also: IRC log
-> http://www.w3.org/XML/XProc/2007/08/30-agenda
Add: splitting the spec?
Accepted.
-> http://www.w3.org/XML/XProc/2007/08/23-minutes
Accepted.
No regrets given.
Norm: Henry, what do we need to do?
Henry: I'm not sure, but as a tactical matter let's wait until we get to Last Call before we do it.
Norm: We should plan to meet at
the plenary, Th/Fr 8/9 Nov 2007 in Cambridge, MA, US
... I've requested a projector, a whiteboard, and a phone
Norm will be there
Henry will be there in part
Paul will be in the hotel, but at the XSL FO meeting
-> http://www.w3.org/XML/XProc/docs/langspec.html
Henry: Woo hoo! seems appropriate
Norm: Did anyone look at Henry's editorial changes
Mohamed: I did and I think it
addressed many issues.
... I think some of the type stuff isn't in the spec (options
that must be QNames, etc.)
Henry: I think that stuff is in 3.9
Mohamed: Yes, that's ok. But I think some of it is missing in required steps.
Henry: At the moment, the changes in section 7 are only visible in the copy attached to the email that I sent
Mohamed: Ok, maybe I was looking in the wrong place.
Henry: I've been trying to make
the steps more regular (editorially).
... Alex had evolved towards a standard way, but they hadn't
all been updated
Norm regrets Alex's absence.
Henry summarizes his editorial changes.
Norm: I think we should accepted Henry's changes.
Norm and Henry will work together on the draft.
Mohamed: I'm very happy with the styling changes in the tableaus
Norm: Yeah, I think it worked out pretty well too, though I'm open to suggestions for more improvements.
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0080.html
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0101.html
Mohamed: We're only missing a few
things, most of which we can get with options.
... An option on p:count would allow it to return 0, 1, or more
instead of counting all of them
... Adding an option on split-sequence to stop after first
false, that could be an option too.
... And p:pack
... I'm not sure I want all of them, but I was trying to see
what we couldn't do.
... Some of them would require p:input="*" and
p:output="*".
... But the three named above could be done pretty easily.
Norm: I'm sort of inclined leave
these until the next release or as exproc extensions.
... What do folks think of a 0, 1, or more sort of step as an
alternative/option to p:count?
Henry: I'm not sure how central
the requirement for this is?
... I appreciate that there's an in principle need, but what is
the real-world use case?
Norm: I'm not hearing a lot of support
No consensus to add this.
Norm: What about a variation on p:split-sequence to stop after the first false?
Henry: Same question
Norm: I'm not hearing a lot of support for this either
No consensus to add this.
Henry: I think it will be very reasonable during CR to respond to requests of the form "please add a step such as..." with some optional step that we might eventually make required.
Norm: That leaves us with p:pack
Mohamed: The use case for this one is to make a comparison of two sequences of documents.
Norm: I see, so instead of having two sequences, you can just take the first two and then the next two, etc.
Mohamed: You get the two documents in a single wrapper
<MoZ> <A><a/><b/></A>
Norm: Right.
Henry: I'm still not clear; if I have four documents on each input port, how many do I get?
Mohamed: You get four output documents; each of which contains a wrapper that has two documents.
Henry: I think this probably is a
good idea.
... It's the dual of split-sequence to some extent and it
matches a unix utility that I use occasionally
Norm: Anyone object to adding p:pack?
None heard; accepted.
Norm: There's been some discussion in email.
Proposal: Add a type attribute on p:option?
No support heard, at least one object; proposal fails.
Scribe interrupted by FedEx
Henry: At the beginning of 2.2,
we say that it's XML that flows between steps.
... There is no statement here which says that the XML must be
serializable as an XML document.
Richard: I don't think that's what we should be saying.
Henry: As it stands, as an
implementor, I don't think I'd have any obligation to throw an
error if a step produced as output an unserializable document
information item.
... e.g., I am XML 1.0 based implementation and you give me a
document which has two elements with an undeclared
namespace.
<root xmlns="foo"><child xmlns=""/></root>
You can't do that in XML 1.0
(That example doesn't actually work, but hopefully the idea is clear)
Henry: The problem arose in p:add-attribute. Do we require namespace fixup? That is, should we say that the output document contains an in-scope namespace binding for the prefix used in the attribute if there isn't one already.
Richard: It seems that on the individual questions of what steps should do, we should say.
Henry: I think that's a question we should put to the WG.
<MoZ> <p:root xmlns:p="foo"><p:child xmlns:p=""/></p:root> is impossible in XML 1.0 but we just have to change the prefix !
Richard: As to the general
question, we say that the things that flow between the steps
are XML documents. So if you attempt to pass an unserializeable
infoset, that's clearly an error.
... I think this should be partitioned between a general
statement like that statements about the individual steps.
Henry: I think there's a finer
granularity that's worth considering.
... There are at least two senses of serializable:
... Given a fairly close transcription of the infoset, one
possible reading of "serializable" is, if you express every
property in your object model, the result will be a WF XML
document.
... The next step is to say, no, that's too weak, the sensible
meaning is that with the addition of namespace bindings and
possibly additional prefixes, the document could be serialized
successfully.
Richard: I'd say that the
definition is that there's a textual XML document that has the
same infoset.
... If we wished to allow some latitude on that then the
components themselves should say what the latitude is.
Henry: I think that means: in one
case the spec says, if serialization is called for then it must
be possible with namespace bindings synthesized as
necessary.
... The other alternative is to say that that must obtain at
every transition between steps.
Richard: I would be happy to
allow implementations the latitude of not fixing up namespaces
until they actually serialized the output.
... But that should be considered an optimization
... Each step should say that it works as if such a document
was possible at every transition
Henry: So this means describing
namespace fixup for at least all ten of these steps
... I'm happy to do that, but it seems overkill.
Richard: I'd abstract the problem and write a single paragraph that says that.
Norm: Anyone disagree with the strict reading of serialization between steps?
Henry: Yes, I think this is an unbearable burden on implementors.
Richard: Where do errors occur if you don't?
Henry: Given that we have an XSLT
1.0 step, it's clear that this can be done.
... All you have to do is do add attribute and then check the
namespace bindings with XSLT.
... It's definitely detectable.
Richard: I'm not against it being an allowed optimization to do this, the thing that I want is that the spec be written as if every step produced and consumed textual XML and anything else is an optimization.
Some discussion about what 2.2 meant.
Henry: I'm happy to reword this paragraph but I think we need to do it with our eyes open.
Mohamed: I object to the idea that we put this burden on implementors too.
Norm: Let's take this to email
Richard: I think the minimum position is that steps be allowed to serialize between every step and be allowed to produce an error if they can't.
No value in fiddling with the error numbers and non-zero chance of screw up.
None.
Adjourned.