W3C

XML Processing Model WG

Meeting 105, 27 Mar 2008

Agenda

See also: IRC log

Attendees

Present
Norm, Paul, Richard, Henry, Rui
Regrets
Murray, Andrew
Chair
Norm
Scribe
Norm, pgrosso

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2008/03/27-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/03/20-minutes

Accepted.

Next meeting: telcon 3 April 2008?

Henry gives regrets.

Norm observes that we'll all be on Summer Time starting 3 April, so adjust your calendars accordingly

Henry's alternate proposal

-> 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.

What else do we need to do before we publish a draft.

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?

Names and media types

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.

Any other business?

None heard.

Adjourned.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/04/03 15:57:15 $