W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > November 2006

XProc Minutes 02 Nov 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Fri, 03 Nov 2006 07:04:18 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <87bqnospml.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/11/02-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 42, 2 Nov 2006


   See also: IRC log[3]


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





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 9 Nov 2006
         4. Review of open action items
         5. Technical agenda
         6. Discussion of select vs. match semantics
         7. Any other business
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2006/11/02-agenda.html


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2006/10/26-minutes.html


  Next meeting: telcon 9 Nov 2006

   No regrets given.

  Review of open action items

   A-13-01: continued

   A-41-01: completed

   A-41-02: completed

   A-41-03: completed

   A-41-04: continued

  Technical agenda

   Review of the 27 Oct draft

   -> http://www.w3.org/XML/XProc/docs/ED-xproc-20061027/

   Henry: It needs to be possible to specify if parameters are required or

   <scribe> ACTION: Norm to address optional/required parameters in the next
   draft. [recorded in

  Discussion of select vs. match semantics

   Richard: I certainly want to be able to stream, but I'm not convinced that
   we have to restrict to match patterns because you've got to do some
   analysis anyway. It doesn't seem to be more difficult one way or the
   ... You've got to be able to not stream in general anyway.
   ... An implementation is bound to have to do most of this work anyway.

   Henry: I don't have as much of a concern about that as I do about the
   interpretation of bare names.
   ... I find it odd to write //foo when I want the foo's. I'd have expected
   "foo" to do that.

   Richard: I agree that that's odd, OTOH, there are things that are hard to
   write as match patterns.

   Norm: I think we should use select on input and therefore select

   Richard: That argument seems much less appealing in the viewport case.
   ... It's very much like an XSLT identity transform with a single pattern.

   Henry: I agree, but I also agree that the consistency argument is a good

   Richard: We have to do something special in the viewport case anyway,
   because we can only process the top most match.
   ... We could do something different there.

   Michael: Is the use of match patterns an unquestioned win or only an
   illusory win for streaming.
   ... Some people seemed convinced that mattered for streaming, others
   didn't agree.

   Richard: I agree you have to do a fair amount of analysis to be as
   efficient, but I think you're going to have to do that anyway.
   ... Something I keep meaning to do is write some code to split a general
   XPath expression into streamable and non-streamable parts.
   ... It's just an example of locality of reference.

   Alex: One of the things I'm thinking about here that the conservative
   thing to do is say that it's match patterns.
   ... I'm concerned that people will push a lot of things into expressions
   on inputs that are maybe the wrong way to do things in a pipeline.

   Richard: I'm not quite sure I see this. Even if we have select
   expressions, we can only have select expressions that return node sets and
   probably only elements.
   ... The only difference in practice that I can see is that there are some
   things that are difficult to express with match.
   ... Those are annoying, but maybe they aren't common enough to matter.

   Henry: Example?

   Richard: How would you write the last chapter?

   Michael: //chapter[last()]

   Richard: That works if they are all siblings of the same book

   Michael: Ok then I need ... (scribe missed)

   Richard: To do it as a match //chapter[not(following::chapter)]
   ... That's legal but unbelievably expensive in most implementations
   ... There's a reasonably efficient expression for it, but not as a match

   <richard> (//chapter)[last()]

   Richard: I raise this case because someone really wanted to do that here
   ... It was in a program that only used match patterns.

   Alex: I like match better and I still think it's the conservative thing to

   Murray: I think that what I've heard is that some want to do select and
   others want to do match.
   ... The issue is that we can't do both because it's too much of a burden
   on implementations.

   Richard: No, if you could do select then you don't need match.

   Norm expresses concern that giving users both ways of doing it makes
   everything harder and more confusing.

   <MSM> [MSM silently agrees with Norm: choose one, don't make the user

   Straw poll: for input and for-each, and leaving aside viewport for a
   moment, do you prefer select semantics or match semantics.

   Results: 7 for select, 3 for match, one for allowing users to choose
   either at their discretion

   Norm: Is there anyone who objects to accepting select semantics as the
   consensus view.

   None heard.

   What about viewport?

   Alex: If we have select semantics, I still think that match is the right
   semantic for viewport.

   Norm: Viewport is special because we only want the outer-most subtree.

   Alex: I think the match semantics work really well here.

   Richard: I agree.

   Norm: I suppose I could live with viewport being different, but it's not
   my first choice.
   ... I still prefer to say that it's select with a special rule.

   Alex: But that special rule is really hard to figure out.
   ... Well, I suppose if the ancestor is in the results....

   Richard: I've written numerous programs to do this and it always seems
   natural to have a match pattern and not recurse after you match.
   ... Some programs have had to recurse, but that's not always a clear
   option. But for viewport, it's just impossible.
   ... Sometimes what you want in that case is to recurse on the output of
   the viewport.
   ... I suppose it could work the other way around, do the inner ones first
   and the move outward.

   Norm: Let's not do that one.

   Richard: Right, that's my point. Once you start to consider recursion,
   there are just too many options.

   Henry: I think the core is, how is a bare name interpreted.

   Straw poll: for viewport, do you prefer select semantics or match

   Results: 4 select, 5 for match; Henry asserts Micheal would have voted
   match if he was still here.

   Paul: If we're going to go with select on some things and match on others,
   they better be different attribute names.

   Norm: anyone object to accepting as consensus that viewport will have
   match semantics.

   None heard.

   <scribe> ACTION: Norm to update the draft to reflect the chosen semantics
   for selection on input, for-each, and viewport. [recorded in

   Henry: The interpretation is slightly different in the case of an input
   port on a parameter. Certain things are legal there that aren't legal
   elsewhere and the interpretation is different.

   <ht> concat('a', /foo)

  Any other business

   Norm: When do we publish another public draft?

   Norm proposes December

   Alex/Henry: Let's do it next Friday

   Some discussion of when the publishing blackout period for the AC meeting

   Proposal: new public working draft on 17 November

   Norm wants to answer the declare-* or not question before 17 November,
   expects to devote next meeting to that.

   No objections to a new public WD on 17 November.


Summary of Action Items

   [NEW] ACTION: Norm to address optional/required parameters in the next
   draft. [recorded in
   [NEW] ACTION: Norm to update the draft to reflect the chosen semantics for
   selection on input, for-each, and viewport. [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/11/02-agenda.html
   [3] http://www.w3.org/2006/11/02-xproc-irc
   [7] http://www.w3.org/2006/11/02-xproc-minutes.html#action01
   [8] http://www.w3.org/2006/11/02-xproc-minutes.html#action02
   [9] http://www.w3.org/2006/11/02-xproc-minutes.html#action01
   [10] http://www.w3.org/2006/11/02-xproc-minutes.html#action02
   [11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [12] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[11] version 1.127 (CVS
    $Date: 2006/11/03 12:02:54 $

Received on Friday, 3 November 2006 12:04:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:41 UTC