XML Processing model telcon

22 Jun 2006

See also: IRC log


Rui Lopes, Murray Maloney, Alex Milowski, Henry S. Thompson, Richard Tobin, Alessandro Vernet, Mohamed Zergaoui
Michael Sperberg-McQueen, Norm Walsh
Chair (pro-tem)
Henry S Thompson
Henry S Thompson





Minutes of 2006-06-15

No comment, silence gives consent, accepted.

Call next week

MM regrets for 29 June and 6 July

RT regrets for 6 and 13 July

F2F 2--4 August

MM: Accommodation is going fast, if you're not booked, do so ASAP!

MM: Rocklin Inn is closest to the meeting venue at MM's
... Estimating 9 participants

Review of open action items

HST: No progress on any of the open items

Syntax of the pipeline language


HST: Three levels for names:
1) The pipeline itself ;
2) Components may declare required parameters
3) Authors may need variables to park things in

HST: AM's email directly addresses (3)

HST: Does AM's proposal also address (2)?

RT: 4th category has been discussed -- XSLT parameters -- not required by component or pipeline, but used in a particular stylesheet, for example

HST: Yes, that's a separate use case, and AM's mechanism addresses it

MM: Late binding on the table? E.g. bind 'foo' to date, at pipeline invocation or only as referenced

AM: Been discussed. . .dynamic binding at a particular point, but not re-evaluated thereafter
... but lazy values not as such

<MoZ> for me only functions can give different results

RT: User needs to do that explicitly, with e.g. a small component which produces the current date/time in an small XML document

<MoZ> date() for date and current() for current node for example

AM: I think we agreed no iteration of a 'while (condition) ...' variety for v1, so, no
... My email, and HST's simple pipeline -- let+params+vars makes simple progress from that

RT: While working on conditional for my simple syntax proposal, same problems come up

AM: This topic actually involves the larger question of flow vs. sequence semantics. . .
... If there's a primary input, my proposal works as written
... If that can't be assumed, then things get more complicated

<richard> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jun/0029.html

HST: Two kinds of named values: constants, or simple values pulled via XPath from documents on the one hand, and (sequences of) infosets on the other
... Should these both use the same kind of binding mechanism? They don't in the sum of the proposals on the table at the moment

RT: The first thing to note about this example, somewhat irritatingly, is that the conditional itself has to declare a name for its output
... Assumes as have others that default context for XPaths is the primary input
... A bit verbose as it stands, but if we allow the default rule that w/o an explicit input, you get the primary output of the previous step, etc.
... So here we have a name being 'bound' by the conditional -- e.g. the 'result' of the conditional
... So last week we observed that we have components defining names, and steps binding those names
... But pipelines themselves do both
... Conditional is similar -- it both names the output and binds something to it in each branch
... Perhaps we should separate out the idea of scopes within which names exist, and binding of values to names

AM: Several issues -- two-part names, or full hierarchical
... We could go all the way to a path-like name which lets you address any step by navigating to it, or we could just use the ordinary ID/IDREF story
... What I don't like is having to use paths for names depending on what the pipeline looks like

RT: Well, I didn't want to have to make up names for every output of every step

HST, RT: Steps are instances of components

scribe: The XSLT component has a 'member' called 'stylesheet'
... So every XSLT step gives us a name [step-name].stylesheet, for the stylesheet for the named step

HST: It's always only a two-part name, never a richer path. . .

AM: I think of steps using components, which doesn't seem to be consistent with what you have above, but that's actually a distraction at this point
... I also don't like the '.' separator
... Worried that once we start including pipelines inside pipelines, etc., we'll need a general reference mechanism

RT: Don't think we should allow that -- if you want to get at an input or output of a sub-pipe, the sub-pipe itself has to expose that at the sub-pipe surface

AM: You're missing the lesson from XML Schema -- you need to be able to refer to every part of the complex structure, for example for debugging, documenting, labelling intermediate results, etc.

RT: I see what you're saying, so yes, the naming approach I've proposed could generalize to pipe.step.port, etc.
... There's some potential for confusion between step names and port names, in that case . . .

AM: I also want names for inputs, even if the pipeline language doesn't need them

RT: Yes, again, can do, as long as we're careful wrt namespaces

AM: So we need to step back and generalize -- carefully consider what we want to be able to name, in general
... and build it in from the beginning

RT: Indeed, and that's an argument for scoped names, and against ID/IDREF, otherwise composition might produce conflict

MM: Multiple dots?

RT: Only one in the language itself, but multiple for addressing 'from outside' as it were

MM: Public vs. private? You're proposing inputs and outputs are public, what about variable?

RT: In the language, as I'm proposing, only outputs are 'public' in that sense

AM: I agree with MM, referring to vars and params still need ways to point to them, so you can ask about them

MM: [book example which the scribe didn't catch -- please put in email!]

RT: You seem to be adding dependency on values, as well as documents

MM: ... I'm going to record something in a set of variables, each with a different, but related, name, one per chapter

HST: I think this sounds like something we've already discussed, namely a resource manager in which components can post arbitrary information so that other components can access it, and that we decided not to go there, but I may have misunderstood.

MM has responded to RT's component example by email, please have a look

Summary of Action Items

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/06/22 16:15:36 $