See also: IRC log
Make sure your arrangements are in order.
A-23-02: Richard to write a syntax proposal
A-13-01: MSM to draft a complete table; ETA: 20 July 2006
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
Lots of good discussion on the list, any burning issues?
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
... In the for-each we need to be able name the outputs
Norm did something alternate:
Alex: If you're iterating over a
document and using an XPath expression, you have to specify a
... 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,
... 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
... I don't much like "peephole".
Norm: Anyone like peephole better than viewport?
Murray: I don't like either.
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: 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
Norm: I see, the name is
repeated. This really only works in the case where you name
... 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.