XProc Minutes 7 Dec 2006

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

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

7 Dec 2006

   See also: IRC log[2]

Attendees

   Present
           Paul Grosso, Alex Milowski, Richard Tobin, Rui Lopes, Henry S.
           Thompson, Alessandro Vernet, Andrew Fang, Mohamed Zergaoui, Murray
           Maloney (in part)

   Regrets
           Michael Sperberg-McQueen, Norm Walsh

   Chair pro tem
           Henry S. Thompson

   Scribe
           Henry S. Thompson

Contents

     * Topics
         1. accept previous minutes
         2. next meeting
         3. Subordination
         4. Fallback
         5. Element and attribute names for subordination proposal

     ----------------------------------------------------------------------

  accept previous minutes

   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/0080.html[3]

   AGREED: Minutes of 30 November accepted

  next meeting

   Next meeting will be 14 December, no apologies as yet

  Subordination

   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/0081.html[4]

   MoZ: Main thing of the proposal was to separate source specification into
   three subordinate elements: external, internal and here
   ... Interesting point is that in each case the attributes are required
   ... Also, in the case of external, we could allow fallback to <here>

   RT: Against a fallback mechanism -- we already have conditional processing
   and failure handling
   ... so I'd prefer to consider the proposal w/o that

   HST: We'll separate that -- discussion of the basic subordination
   proposal:

   RT: I like the orthogonality, but it's even more verbose than our current
   verbose proposal
   ... I would have liked <p:step type='xslt' stylesheet='step.port'.../>
   ... We already have one level of nesting, Murray's proposal would move us
   to two
   ... I'm worried we will need pages for even a simple pipeline
   ... XML is just not a good syntax for programming languages

   HST: Verbosity is a problem -- first impressions matter. . .
   ... We don't want people to react as they did to XML Schema. . .
   ... Maybe we should start the defaulting discussion

   AM: I like it, some names aside
   ... It's good for tools, it's good for annotation
   ... We're already verbose, this doesn't make things much worse

   PG: Don't have a strong feeling - some worry about verbosity - if this is
   the right language we'll make it work
   ... If the more verbose solution is cleaner then I'm in favor

   RL: Verbosity is an issue, but not against it as long as it's not too
   verbose

   HST:Concerned about verbosity, but might be okay if we can get shorter via
   defaulting or something.

   HST: Wants the common things to be easy to specify and not too verbose.

   AM: Using subordinate elements allows you to construct a sequence of
   documents, which is a plus: new functionality

   HST: Yes, but not obvious we have any such use cases. . .

   RT: Even a mixture of <here> and <internal> . . .

   AM: I think it's easy to come up with use cases

   AV: Worried about verbosity, thinking about writing this kind of hurts.
   Fine with one level of nesting, but not happy with defaulting.
   ... Worried that we'll be unable to see what the pipeline means just by
   looking at it: where does data come from

   AF: Not against verbosity as such, but worried about the impact on people.
   I'd prefer a simpler syntax in V1

   MoZ: I'm concerned by the verbosity, but

   MoZ: Currently p:input has 4 different models, and it's hard to understand
   the allowed co-occurences for beginners
   ... also hard for tools
   ... This is in tension with the verbosity
   ... I also like the sequence of documents support
   ... Also, easier to add documentation with the extra element
   ... Whereas currently we can't because of confusion with a 'here' document

   <alexmilowski> That's an excellent point... too many attributes cause
   their own verbosity and easy-of-use problems

   AM: Natural conflict between expressiveness and conciseness in the XML
   world
   ... RELAX has a compact syntax to address this issue
   ... Maybe we should consider a non-XML format or a mixture as per XQuery
   ... A well-understood grammar is the right foundation, shouldn't tackle
   verbosity right now

   RT: Verbosity and defaulting aren't mutually exclusive -- even with a
   compact syntax you would want to default the primary connection between
   adjacent steps

   HST: I'm very tempted to take RT's suggestion for secondary inputs, and
   allow you to write
   ... <p:step type='xslt' stylesheet='http://...'/>[5]
   ... Only have to use subordinated elements (one or two) if you were
   computing the secondaries -- quite rare
   ... The subordination story is possible because we moved the magic port
   attribute onto e.g. the <p:for-each>

   RT: Wrong, we gave it a fixed name

   MM: Moz's point can be restated as "Moving to my proposal allows any
   schema language to express our grammar, instead of only one"
   ... Sympathetic to desire for conciseness, but that just means we
   shouldn't be using XML
   ... Ask RT to summarize what the roadblocks are

   RT: No roadblocks, but verbosity is an issue (as well as fallback)

   <alexmilowski> Clarification: I'm not worried about verbosity. We're
   already verbose.

   HST: Straw poll: Shall we ask the editor to draw up a candidate draft
   encorporating MM's proposal?

   In favor: 1111111

   Opposed:

   <PGrosso> I was not asleep--I concur.

   ACTION to NDW: draw up a candidate draft encorporating MM's proposal.

  Fallback

   RT: Worried that it's extending the control structures by stealth
   ... We have mechanisms in the language for handling errors, so you can
   already catch an error in fetching a URI

   MM: This is just an inexpensive (less verbose) way to handle a common
   error
   ... you'd use it as a debugging mechanism

   RT: It's not a bug in your pipeline as such -- you want to see the error

   MM: During development, you may want to test it w/o actually having the
   URLs in place

   RT: Dubious about that. . .
   ... If you're not going to leave it during production, you could just
   start with a <here> and replace it with an <external>
   ... I don't know any programming language that work like this

   HST: Suspend this, take it to email

  Element and attribute names for subordination proposal

   MM: Could accept portref instead of internal

   AM: I don't like 'load', mild preference for 'document' over 'external'

   RT: Would like 'pipe' instead of 'internal'

   AGREED: Leave this to editor's discretion, but all are invited to argue in
   email for their preferred set of names

   HST: Any other business?

   MoZ: What about 'name' vs. 'port' for input?

   MM, RT: Still open, not affected by our decision

   MoZ: I would like to see documentation elements added explicitly at some
   point soon. . .

     ----------------------------------------------------------------------

   [1] http://www.w3.org/
   [2] http://www.w3.org/2006/12/07-xproc-irc
   [3]
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/0080.html
   [4]
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Nov/0081.html
   [5] http://...'/%3E
   [6] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [7] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[6] version 1.127 (CVS
    log[7])
    $Date: 2006/12/12 15:42:35 $