See also: IRC log
The telcon of 28 Dec 2006 is cancelled.
Discussion of the nested elements draft
Norm: Murray, what do you think?
Murray: I would have kept document and inline together, but that's ok.
Richard: I'm very ambivalent. Its main advantage is that it separates things, so I'm in favor of 3 instead of 2.
Alex: Are we going to allow construction of sequences?
Norm: I don't think we've decided that question.
Alex: I really like nested elements.
Henry: So do I.
... I'm not fussed about the syntax because the defaults are going to make it all go away.
Norm: I'm ambivalent too. It's cleaner in some senses, but it sure obfuscates the written out version to my mind.
Alessandro: it looks nice from the perspective of someone who reads the specification or writes it, but I have the feeling that it's going to be different for people who have to read or write pipelines. It's a very heavy syntax.
... I'm not sure that what we gain is really worth the cost.
Mohamed: In fact, I like this proposal because it's better, I think, looking forward to a V2 or something later.
... When we agree the defaulting story, maybe the point about the syntax will go away.
... But we need a good proposal around the defaulting story.
... Also, I wanted to say that this proposal maybe we can make some things clearer. The fact that we now see the name "pipe" is something very interesting for catching the big picture.
Paul: I think it reads better in the spec, but I haven't tried to write pipelines. So I thought Alessandro's point was an interesting one.
... On the whole, I'm leaning toward this implementation of Murray's ideas. But that's only a gut feeling.
Rui: I feel the same way that Mohamed does. We need a strong defaulting story.
Paul: What's the downside of this proposal, other than verbosity.
Norm: I think the downside is only the verbosity.
Murray: But it does have the advantage that you can explicitly make a sequence.
Mohamed: This proposal makes it easier to document inputs and outputs, I think that's an advantage.
Henry: I think it's also easier to write authoring tools that allow you to do the right thing because it's easier to write simple document definitions.
... I mean document definitions without co-constraints.
Murray: I have a potential modification that might make things easier.
... The input and/or the output element could have the step and port attributes on them, if they're used on that element then they would refer to the step and port. Then you could write anything in the one element.
... However, you could use the subordinate elements if you wanted to.
Norm: I agree we could do that, but I'm strongly opposed. I'd much prefer to have one way to do it.
Straw poll: do you prefer the attribute syntax or the nested element syntax?
Results: 9-to-1 in favor of nested elements.
Proposal: We will adopt the nested element syntax going forward.
Mohamed: In the alternate draft, you've named an input for choose/when
... Now there's something to choose between. If we name, we have to default all the names, or we have to skip the surrounding input and just put the pipe or document.
Norm summarizes the situation with respect to choose/when
Norm: If I understand Mohamed's proposal correctly, he's saying that the p:input is unnecessary.
... I agree that syntactically it's unnecessary, but I'd prefer to keep the p:input.
Richard: if you put the inputs on the whens, do you not need one on the choose?
Norm: That's right.
Richard: Maybe there should be a test subelement that has something in it
... The test is like the input element in that it requires a source.
... It would be natural to make the test a subelement as well.
Norm: So instead of having p:input, we could have p:xpath-context?
Henry: I think I like that better.
Richard: I'm proposing that p:when would have no attributes and an optional p:test element with an attribute that was the test.
I think this is what Henry (and I) had in mind:
I think this is what Richard had in mind:
Murray: If there's a when element and it has a subordinate test element, then I can move them around with cut-and-paste.
Mohamed: That's what I proposed in email.
Murray: I think you really do want a p:input on p:choose.
... On p:input there's a select attribute, and I might want that for testing.
Richard: So you can factor the conditional.
... If you put a select on the choose, then it means that the tests in the whens will operate on the selected part of the document.
<Zakim> MoZ, you wanted to add that adding p:input in top of choose or when with a name would permits the big mistake to refer to it
Mohamed: Putting a input on the top of the choose/when will make it a mistake to refer to this name inside the when.
... I think giving an input with a name, is something which we have to take care about.
Henry: I want things to be as simple as possible when they're fully defaulted.
... I think the primary input will often be what you want for both the test and the input. I really want the test attribute on the when elements.
Norm: I agree that that's what users will expect.
Richard: I think this argues in favor of what Murray suggested earlier, allowing the attributes to be hoisted up.
... Then this would just be analagous to that.
Henry: What is the argument in favor of a nested test element, aside from cut and paste?
Richard: I didn't like the nested input element because the test amounts to being a combination of an attribute and a subelement which seems a bad idea.
Henry: I guess I think familiarity is more important than that locality.
Richard: I'm not saying I agree with Murray's suggestion, I just pointed to an advantage of it.
Norm: With my chair's hat off, I am really strongly in favor of having exactly one way to do something. Having more than one way just complicates things.
Murray: I disagree with that assertion.
Richard: I think if we had a consistent story about what kinds of abbreviations you could do that that might not be the case.
... It would be a simple enough story that it would not be confusing.
Henry: I agree with Norm and I disagree with Richard. Trying to explain the circumstances under which hoisting is or is not allowed will be much more confusing and have benefit only in marginal cases.
Murray: Not that I want to push this idea, but if I understand this, then the vast majority of people will. What we're talking about here is SGML's conref.
... One of the difficulties I had with the p:input element before was that we had co-constraints and optional input. I'm suggesting here that we give primacy to the p:pipe attributes. Don't allow an href up there, only allow for pipes.
Norm: I think putting source/port up there but not href would be very strange.
Henry: What about a straw poll?
... I think the question is between what the current alternate draft and the two variations Norm typed in earlier.
... There's a separate question about what kind of promotions are possible.
1. What the current alternate draft says
2. Nested context, with test on p:when
3. Nested context, with the test on the subordinate element
Henry: Current proposal says, there's a distinguished port called 'source' for p:when elements and you use that port to establish the context for testing.
... I proposed a slight change which says, "let's not confuse things by using the port named source, let's have a distinguished element, e.g., p:xpath-context"
... The third proposal is to say, take the test attribute off the p:when and put it on the subordinate element which still would wrap p:inline|p:document|p:pipe
Results: 6-to-2 for the status quo with one abstention.
Norm: Let's do this on the list so we can reach a decision on 4 Jan 2007.
Murray: We've been hanging fire on the core components list, it'd be nice if we could make progress.
Norm: I suggest that we try to do some of that in email too.
Murray: Review of the current draft and suggestions for any changes.
Norm: I suggest that we aim for another public WD on 26 Jan.