XML Processing Model WG telcon

Meeting 80, 16 Aug 2007


See also: IRC log


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



RESOLUTION: Minutes of 9 August 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 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


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

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]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/08/23 16:10:12 $