See also: IRC log
No, since they were never published
Registration is closed. Make sure your arrangements are in order.
A-27-02: Norm to write up some straw syntaxes for some of the use cases
A-23-02: Richard to write a syntax proposal
A-23-03: Norm to write a syntax proposal
A-13-01: MSM to draft a complete table; ETA: 20 July 2006
Alex: I worked through some of my examples.
Alex: Maybe it's easier to look at the large document example
Norm: Is this the one you had in mind?
... 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.
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
... 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?
Alex: Most interesting bit is the p:url step
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.
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?
Scribe apologizes for rather poor minutes this week.