See also: IRC log
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
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0075.html
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
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
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
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'.