See also: IRC log
Accepted
No comment, silence gives consent, accepted.
MM regrets for 29 June and 6 July
RT regrets for 6 and 13 July
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
HST: No progress on any of the open items
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006May/0087.html
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