XProc Minutes 21 Dec 2006

See http://www.w3.org/XML/XProc/2006/12/21-minutes.html

                                   - DRAFT -

                            XML Processing Model WG

Meeting 48, 21 Dec 2006


   See also: IRC log[3]


           Norm, Henry, Rui, Paul, Richard, Alex, Alessandro, Mohamed,
           Andrew, Murray





     * 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


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2006/12/14-minutes.html


  Next meeting: telcon 4 Jan 2007?

   The telcon of 28 Dec 2006 is cancelled.


  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

   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

   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
   ... 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

   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

   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">





   I think this is what Richard had in mind:


   <p:test select="xpath">




   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

   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
   ... 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

   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

   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
   ... 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

   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

   1. What the current alternate draft says

   <p:when test="xpath">

   <p:input port="source">

   <p:pipe ...>




   2. Nested context, with test on p:when

   <p:when test="xpath">


   <p:pipe ...>




   3. Nested context, with the test on the subordinate element


   <p:test test="xpath">




   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
   ... 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.,
   ... 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

   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
    $Date: 2006/12/21 17:12:44 $

Received on Thursday, 21 December 2006 17:15:08 UTC