XML Processing Model WG

Meeting 30, 27 Jul 2006


See also: IRC log


Alex, Alessandro, Andrew, Mohamed, Norman, Richard, Rui


Accept this agenda?

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


Accept minutes from the previous teleconference?

-> http://www.w3.org/XML/XProc/2006/07/20-minutes.html


Next meeting: Face-to-face: 2-4 Aug 2006

Make sure your arrangements are in order.

Review of open action items

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

<scribe> Withdrawn.

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

<scribe> Continued.

Agenda for the f2f


1. Finish the syntax wrangling

2. Define the core language constructs

3. Make a first pass at identifying a list of required components

4. Make a list of standard but optional components (if any)

5. Review our open issues

Norm will try to draft an agenda this week

XProc syntax

Lots of good discussion on the list, any burning issues?

None suggested.

Alessandro's proposal:

<Alessandro> http://avernet.googlepages.com/xproc-syntax

Alex suggests looking at for-each

Alessandro: On the for-each it looks like we want to reference a sequence of documents that we want to iterate on, we want the option of providing an XPath expression.
... In the for-each we need to be able name the outputs

Norm did something alternate:

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

Alex: If you're iterating over a document and using an XPath expression, you have to specify a replacement
... When you're iterating over a sequence of documents, that's not necessarily true.
... There are way more options when you're iterating over a collection of documents.

Some discussion of whether we're talking about for-each or peephole

Norm tries to outline how for-each and peephole differ. For-each just returns the sequence of things generated, peephole wraps the original document around the replaced matches.

Richard: I think there should be something that does a body for each document in a sequence and something else that does each matched part in a single document.

Norm: We could have for-each and for-each-document, I just didn't think it was necessary.

Richard: The output is a sequence of documents. The peephole mechanism can be build out of that, I think.
... A component that takes the original and an XPath and a sequence of documents, the sequence could be plugged in where the matches occurred.

Alex: It could be done that way, but I'm not sure I want to do it that way.

Norm wonders if there's a practical use for a component that works that way.

Richard proposes that there are some uses, whether they're practical or not...

Some more discussion of how for-each and peephole are similar.

Richard: Do they between them cover all the looping functionality we need?

Alex: Can we add a peephole/viewport element?
... I don't much like "peephole".

Norm: Anyone like peephole better than viewport?

Murray: I don't like either.

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

Norm asks about for-each-output and observes he tried to show how declare-output could be used in each case.

Norm: On the subject of name, I assume we're still sort of evenly divided about how we want to do the naming.

Yeah, pretty much.

Richard: On for-each, the name attribute is used for the binding. Does that make it a variable?

Alessandro: Yes.

Norm: Huh?

Alessandro: No, actually, it's just used when you want to ref= to the output.

Murray: I don't understand why we have ref= and href=

Norm: I think we might be able to combine them.

Some discussion of the direction things flow

Alessandro: In my example, the direction is the same

-> http://avernet.googlepages.com/xproc-syntax-parse-import

Norm: I see, the name is repeated. This really only works in the case where you name individual outputs.
... If you were using the compound naming system, then each when would have to have a *step* with the same name and that step would have to have an output port with the same name, in order to make this work.
... So if we go with #name/port it's much harder to always point from the output to the input in the conditional case
... (Where "much harder" means "impossible", I think)

Richard: When I was thinking about conditionals, I was going to have each of the when's declare their outputs.
... Then the choose referred to those names.

Norm: Yes, that would work as well, but it's pretty verbose to have to declare all the outputs on every branch.

Scribe apologizes for failure to capture several minutes of minutes...

Murray: Can't the p:when's output bubble up?

Norm: Not when there's more than one output from the p:choose

Richard: But when there is only one, we might be able to abbreviate it

Norm: Yes, and it's the idea of abbreviations in the future that makes me have a slight preference for the compound naming choice.

Any other business?



Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/07/27 16:01:04 $