- 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
W3C[1]
- DRAFT -
XML Processing Model WG telcon
Meeting 80, 16 Aug 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Andrew Fang, Paul Grosso, Rui Lopes, Alex Milowski, Jeni Tennison,
Henry S. Thompson, Richard Tobin, Norm Walsh
Regrets
Allesandro Vernet, Mohamed Zergaoui
Chair (pro tem)
Henry S. Thompson
Scribe
Henry S. Thompson
Contents
* Topics
1. Administrivia
2. Namespace binding
3. Comments on August 10 editors' draft
* Summary of Action Items
----------------------------------------------------------------------
Administrivia
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
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0075.html[5]
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
bindings
... 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
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0130.html[6]
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
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0135.html[7]
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
construction?
... 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
bindings
... 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>
element
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
node
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),
Abstain
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
'true|false'
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
'true|false'.
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
log[11])
$Date: 2007/08/16 18:02:09 $
Received on Thursday, 16 August 2007 18:03:43 UTC