- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 21 Dec 2006 12:14:04 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <871wmtuq77.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/12/21-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 48, 21 Dec 2006
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Henry, Rui, Paul, Richard, Alex, Alessandro, Mohamed,
Andrew, Murray
Regrets
Michael
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 4 Jan 2007?
4. Review of open action items
5. Technical agenda
6. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2006/12/21-agenda.html
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2006/12/14-minutes.html
Accepted.
Next meeting: telcon 4 Jan 2007?
The telcon of 28 Dec 2006 is cancelled.
Accepted.
Review of open action items
A-13-01: continued
A-45-03: continued
A-46-01: completed
-> http://www.w3.org/XML/XProc/docs/alternate/
Technical agenda
Discussion of the nested elements draft
-> http://www.w3.org/XML/XProc/docs/alternate/
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.
Accepted.
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:
<p:when select="xpath">
<p:xpath-context>
<p:pipe>
</p:test>
</p:when>
I think this is what Richard had in mind:
<p:when>
<p:test select="xpath">
<p:pipe>...
</p:test>
</p:when>
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
<p:when test="xpath">
<p:input port="source">
<p:pipe ...>
</p:input>
</p:when>
or,
2. Nested context, with test on p:when
<p:when test="xpath">
<p:xpath-context>
<p:pipe ...>
</p:test>
</p:when>
or,
3. Nested context, with the test on the subordinate element
<p:when>
<p:test test="xpath">
<p:pipe>...
</p:test>
</p:when>
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.
Any other business?
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.
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2006/12/21-agenda.html
[3] http://www.w3.org/2006/12/21-xproc-irc
[8] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[9] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[8] version 1.127 (CVS
log[9])
$Date: 2006/12/21 17:12:44 $
Received on Thursday, 21 December 2006 17:15:08 UTC