See also: IRC log
-> http://www.w3.org/XML/XProc/2008/03/27-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2008/03/20-minutes
Accepted.
Henry gives regrets.
Norm observes that we'll all be on Summer Time starting 3 April, so adjust your calendars accordingly
-> http://www.w3.org/XML/XProc/docs/alternate/
Henry summarizes.
Discussion reveals that Henry may have spec'd something other than what we think we intended.
The order of p:with-options has no bearing on the result of the call, irrespective of what the alternate draft currently says.
Richard: What's in scope when you're in the pipeline?
Norm: Only the preceding siblings
Richard: So if you screw up and
refer to something that is defined later, then it might
accidentally be bound.
... An implementation must behave as if it did this
... It evaluates the passed options, in any order
... stores them in a temporary place
... then goes through the options in the pipeline, in order,
and takes their value from the secret place or computes the
default
<ht> I think it is sufficient to remove ", with the addition of variable bindings for all options whose declarations precede its declaration in the surrounding step's signature" from 5.7.3 in the alternate draft
Norm: And crucially it can't see any bindings that come from the ancestors of the call
Richard: So another way would be to check at compile time that the expressions don't refer to variables they aren't allowed to reference and do away with the temporary place
Henry: The way the alternative
draft achieves that is by specifying what the variable bindings
are in the XPath context.
... For with-option, the variable bindings are determined by
the environment of the surrounding step
... For option default, the variable bindings consist only of
bindings for options who's decl.s precede it in the
declaration
Some discussion of dynamic vs. static checking and why we went with dynamic checking.
Richard: This is the same as the case with XSLT parameters?
Norm: Yes, I believe so.
... The one point I'd like to close on is whether we're going
to allow variables mixed into subpipelines.
Norm expresses why he needs the variables to be first.
Richard: I agree
Proposal: accept the alternate draft, amended as necessary, and with the explicit provision that all variable bindings occur at the beginning of the subpipeline.
Accepted.
Henry: I should update the DTD
and the W3C XML Schema
... And Norm should update the RNG schema
Norm: We have a proposal for the
name/media type nexus
... Henry's action on base URIs is still open
... I think that if we came to some conclusion about the base
URI question and we agree on the media type/names question,
that we're done. We should publish a new draft.
... Not a last call, just a regular working draft because we've
changed so much.
... Can anyone think of anything else on the critical path?
Henry made a proposal.
-> http://www.w3.org/mid/f5bd4pg9ymh.fsf@hildegard.inf.ed.ac.uk
Henry summarizes.
PGrosso, can you scribe for a moment or two?
<scribe> scribenick: pgrosso
Henry talks about the fact that, if we go to Rec, we might want to have a media type.
A specific media type would, in theory, allow us to have a fragment identifier syntax that allows us to point into a pipeline.
But it's unlikely that real world clients would really support such a frag id syntax, so registering a media type with such a fragid syntax would be misleading.
So Henry concludes that we shouldn't define our own media type.
Norm wants to simplify, so he tends to agree with Henry's conclusion.
Norm figures people wouldn't be putting xml:id on things, so it might be nice to point to things by name rather than have to rely on tumblers (the element() xpointer scheme).
But on balance he leans toward the simpler (no special media type).
Henry says we could, in the future, define an xpointer scheme called xproc() to allow us to point into pipelines.
We appear to have consensus to go with no special media, so appendix C or D or whatever will be reduced to a statement that we use application/xml for pipelines.
Henry claims there are reasons other that pointing for steps to have names, so he does not proposed to remove secton 2.1.1, but he does suggest a change to the automatic naming mechanism to use tumblers.
Norm is happy to go with tumblers. Paul and Henry prefer tumblers.
<Norm> scribenick: Norm
Richard: We really don't want automatically generated names to ever be able to conflict with a real name
Norm: So: periods or slashes?
Paul: Periods are fine.
Proposed: Tumblers seperated by periods, beginning with a "!"
Accepted.
None heard.
Adjourned.