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

XProc Minutes 16 Aug 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 16 Aug 2007 14:04:55 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2d4xn1hko.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/08/16-minutes


                                   - DRAFT -

                         XML Processing Model WG telcon

Meeting 80, 16 Aug 2007


   See also: IRC log[3]


           Andrew Fang, Paul Grosso, Rui Lopes, Alex Milowski, Jeni Tennison,
           Henry S. Thompson, Richard Tobin, Norm Walsh

           Allesandro Vernet, Mohamed Zergaoui

   Chair (pro tem)
           Henry S. Thompson

           Henry S. Thompson


     * Topics
         1. Administrivia
         2. Namespace binding
         3. Comments on August 10 editors' draft
     * Summary of Action Items



   RESOLUTION: Minutes of 9 August[4] approved as published

   Next meeting: 23 August

   No regrets notified as yet

   Agenda slightly reordered to put namespace binding first

  Namespace binding


   HST: AM and JT have maybe reached agreement on this issue

   AM: Option values are a combination of a string and a set of namespace
   ... this is for QName [and XPath] interpretation
   ... Where do these namespace bindings come from?
   ... By default, from the option element itself
   ... but you can use a 'namespaces' attribute on p:option to identify a
   node whose bindings should be used


   AM: Consider constructing a string from a document to get an option value

   <Norm> I don't see any examples that use the new 'namespaces' attribute.
   Am I blind?

   AM: you want to take the nearest ancestor-or-self to get nsb
   ... The tricky case is when you use an option value to set an option value
   ... In that case you pass the namespace bindings along with
   ... The remaining case which my proposal doesn't cover is when you
   construct a value which e.g. concats another option value

   JT: I suggest we add a special-purpose step which handles this case


   AM: This approach requires the author to do some extra work

   NW: Could we see an example which requires this, and how it would work

   <Jeni> concat($delete, '/html:p')

   <alexmilowski> e.g. the option value is an element QName that is used in a
   constructed XPath

   JT: So the p:to-xml step can be used to unpack an option into an element
   with the namespace bindings from it and value its value
   ... and then you can do anything you need to
   ... with that document, and then use the result to set an option

   RT: We couldn't write the p:to-xml step currently
   ... because the connection from the string to the namespace bindings is
   not available e.g. to XSLT

   JT: Yes

   AM: Have we really solved the problem of supporting general XPath
   ... I don't think so, because of possible NS conflicts

   NW: No way to make it work in principle

   RT: Yes there is -- there's always an XPath that does the right thing, if
   you know all the QNames anywhere in the string, and all the prefix
   ... this would work even if there were two a: prefixed names with
   different bindings

   HST: I wonder if Alex isn't pointing us in the right direction

   HST: We should just support XPath construction and bare QNames

   <Jeni> Those are the major cases, but they're not the only cases.

   HST: What about the following: <p:option name='a' value='concat($delete,
   '/html:p')' namespaces='$delete'/>

   JT: As proposed, the namespaces attribute provides the only bindings, so
   that wouldn't work

   HST: But couldn't we spec. it to merge in a defined way

   AM: Yes, but what about conflicts

   HST: I'm happy for that case to cause an error

   RT: What about a component for generating a QName with a guaranteed-unique
   prefix bound to a specified namespace, so there couldn't be a complex

   AM: I'm inclined towards HST's proposal

   NW: Why not combine in [scribe missed]

   RT: Why not allow the namespaces attribute to specify a set of namespaces

   JT: Then we should go with my original proposal to have a <p:namespaces>

   NW: It seems to me that the p:namespaces element proposal involves a bit
   less magic. . .

   <Norm> I had been queued to ask if everyone was happy with $option values
   carrying namespaces, but since I don't see any alternative...I'm going to
   let it go.

   <alexmilowski> (in my proposal I mentioned we could allow a node set and
   just take the first one)

   <alexmilowski> (as an option)

   HST:[Summarizes the dimension of variation and asks for a round-robin]

   1: Minimum: option values carry NS bindings with them

   2: You can override the bindings with one (or more?) XPaths to pick up a

   3: Some kind of merger, with error or priority

   4: Allow many sources of bindings

   AM: Does (1) get its bindings from the context of the XPath

   HST: Yes.

   NW: (2) and above include p:to-xml

   NW: (4) -- others have too much explanatory overhead

   PG: Concur

   Jeni: Could live with anything above (1), prefer (4) as per NW

   HST: I prefer (3) because it covers the 99% case w/o having to use the new
   step, could live (4)

   RT: Completely uncertain, not sure I understand implications of (4),

   RL: Concur

   AF: Abstain

   AM: (3), could perhaps live with (4)

   NW: I suggest the editor try to write up (4) and we see what it looks like

   <scribe> ACTION: Editor to write up (4) and we see what it looks like
   [recorded in http://www.w3.org/2007/08/16-xproc-minutes.html#action01[8]]

   NW: I think we can go to Last Call if we get agreement on that

  Comments on August 10 editors' draft

   HST: I'm still in the middle of a careful readthrough, and so far one
   point has arisen which could be considered as a real issue
   ... and I'm confident we'll deal with it

   NW, HST: [discussion about names on p:when etc. issue]

   NW: What about 'yes|no' vs. 'true|false'

   JT: Given that people may use XPaths to generate values, we should go for

   NW: I'm just not sure how people who expect 'yes|no' will feel

   HST: I prefer just 'true|false' (and maybe 0|1)

   NW: Anyone opposed to restricting all the boolean-type things in the spec
   to 'true|false'?

   RESOLUTION: To restrict all the boolean-type things in the spec to

Summary of Action Items

   [NEW] ACTION: Editor to write up (4) and we see what it looks like
   [recorded in http://www.w3.org/2007/08/16-xproc-minutes.html#action01[9]]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/08/16-agenda.html
   [3] http://www.w3.org/2007/08/16-xproc-irc
   [4] http://www.w3.org/XML/XProc/2007/08/09-minutes.html
   [5] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0075.html
   [6] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0130.html
   [7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0135.html
   [8] http://www.w3.org/2007/08/16-xproc-minutes.html#action01
   [9] http://www.w3.org/2007/08/16-xproc-minutes.html#action01
   [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [11] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[10] version 1.128 (CVS
    $Date: 2007/08/16 18:02:09 $

Received on Thursday, 16 August 2007 18:03:43 UTC

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