XML Processing Model WG

Accept this agenda?

-> http://www.w3.org/XML/XProc/2006/07/13-agenda.html

Accepted.

Accept minutes from the previous teleconference?

No, since they were never published

Next meeting: 20 July

Any regrets?

None given.

Face-to-face: 2-4 Aug 2006.

Registration is closed. Make sure your arrangements are in order.

Review of open action items

A-27-01

<scribe> Completed

A-27-02: Norm to write up some straw syntaxes for some of the use cases

<scribe> Continued.

A-23-02: Richard to write a syntax proposal

<scribe> Continued.

A-23-03: Norm to write a syntax proposal

<scribe> Continued

A-13-01: MSM to draft a complete table; ETA: 20 July 2006

<scribe> Continued.

XProc syntax

Alex: I worked through some of my examples.

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0002.html

Alex: Maybe it's easier to look at the large document example

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0016.html

Norm: Is this the one you had in mind?

Alex: Yes
... There's one tweak, the 'from' attribute is wrong in this one.
... The idea is that you are selecting an expression (@select) over an input document (@over)
... The thing you select has to be an element, so that it can be made into a document.
... That's provide as input labeled "iteration" (@to)
... The output of the for-each is the input that's been processed.

<alexmilowski> <p:for-each select="section" over="large-doc" to="iteration" replacement="transformed">

<alexmilowski> <!-- input isn't needed here because this "for-each" has

<alexmilowski> to iterate over elements. The input is identified by

<alexmilowski> the 'over' attribute and the binding for each result

<alexmilowski> element is specified by the 'to' attribute. -->

<alexmilowski> <p:output name="final" from="large-document"/>

Alex: So in this example, the output is a little funny

Some discussion which the scribe couldn't follow

Norm attempts to summarize

Alex: The way I've been using the output element is that there's a name for it and a from that refers to whatever you're labelling
... So what is the from?
... In the case of a normal step, it'd be something the component defined.

Norm and Alex attempt to come to an understanding...

Alex: The p:output can't be from 'transformed' because that's just the inner result. And it can't be 'large-doc' because it's not large-doc, it's large-doc after modification.

<alexmilowski> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0028.html

Norm: This suggestion makes p:for-each something like a p:output in the sense that it defines a label for its output

Alex: I think an issue we should raise for later is whether there's some grand unification of this and iterating over documents. We should make sure we come back to that.
... It would be unfortunate if we couldn't extend this to the concept of iterating over sequences of documents

Norm: This example has multiple steps
... You've used the explicit naming of each input and output as opposed to the alternative which was naming though the step name.

Alex: I said no defaults, no magic, no prefixing.

Norm: Ok, so that was a significant part of your proposal.

Alex: In the end, I think it might be very confusing to users.

Norm: I'm inclined to agree.

<MoZ> Alex, are steps systematicaly anonymous ?

Norm: Anything else we should spend time discussing?

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0017.html

Alex: Most interesting bit is the p:url step

<alexmilowski> http://www.smallx.com/tideinfo/

<alexmilowski> http://www.smallx.com/tideinfo-service/

Alex: The url step performs an http action and possibly massages the result (based on content-type) to produce a well-formed XML result
... The following steps cleanup and filter the result data.
... There's nothing earth shattering here except for the retrieval step.
... I could have done this through XSLT using document() calls, but that would require XSLT to be able to handle HTML documents

Alessandro: the only thing I see are purely syntactic. What's the best name for these attributes, for example?

Naming is hard.

Alex: The naming issues and not having defaults haven't really been an issue for me. That makes me pretty comfortable with a first-round story that doesn't have any defaults.

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0019.html

Alex: The biggest thing to not here are the parameters.
... There's one input that contains two elements. I'm going to need those lots of times.
... So I grab them right at the beginning.
... There's a whole question of if you use parameters, where are they available. Is it implicit or explicit? Etc.
... This is a straight-through pipe. In fact it has to stream because the output of the last two steps can blow up to millions of elements.

Norm: Are you making parameters copies or pointers to a document?

Alex: I'm making copies.
... There are two interesting things: I have a bunch of custom steps, how do we deal with those, and I have a need to reuse the inputs to the pipeline at a later part, what's the right way to do that? With parameters? Or an input dependency? And how would that work?

Any other business?

None.

Scribe apologizes for rather poor minutes this week.