IRC log of xproc on 2007-08-16

Timestamps are in UTC.

14:43:11 [RRSAgent]
RRSAgent has joined #xproc
14:43:11 [RRSAgent]
logging to
14:43:24 [ht]
Zakim, this will be XML Proc
14:43:24 [Zakim]
I do not see a conference matching that name scheduled within the next hour, ht
14:43:31 [ht]
Zakim, this will be XProc
14:43:31 [Zakim]
ok, ht; I see XML_PMWG()11:00AM scheduled to start in 17 minutes
14:43:36 [Norm]
Norm has joined #xproc
14:43:45 [ht]
meeting: XML Processing Model WG telcon
14:43:58 [ht]
Chair: Henry S. Thompson (pro tem)
14:44:07 [ht]
Scribe: Henry S. Thompson
14:44:12 [ht]
ScribeNick: ht
14:45:59 [ht]
14:46:32 [ht]
Agenda+ Administrivia
14:46:47 [ht]
Agenda+ Namespace binding
14:47:02 [ht]
Agenda+ Comments on August 10 editors' draft
14:47:20 [ht]
Agenda+ Discussion of p:pack
14:55:27 [ruilopes]
ruilopes has joined #xproc
14:56:03 [PGrosso]
PGrosso has joined #xproc
14:58:56 [Norm]
zakim, what's the code?
14:58:56 [Zakim]
the conference code is 97762 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), Norm
14:59:09 [Jeni]
Jeni has joined #xproc
14:59:16 [Zakim]
XML_PMWG()11:00AM has now started
14:59:22 [Jeni]
Zakim, please call JeniTennison
14:59:22 [Zakim]
I am sorry, Jeni; I do not know a number for JeniTennison
14:59:23 [Zakim]
+ +1.781.442.aaaa
14:59:35 [ht]
Jeni, it's just Jeni
14:59:45 [Norm]
14:59:46 [Zakim]
14:59:55 [Jeni]
Zakim, please call Jeni
14:59:55 [Zakim]
ok, Jeni; the call is being made
14:59:57 [Zakim]
14:59:59 [Jeni]
Thanks Henry
15:02:16 [Norm]
zakim, who's on the phone?
15:02:16 [Zakim]
On the phone I see Norm, PGrosso, Jeni
15:02:39 [ht]
zakim, please call ht-781
15:02:39 [Zakim]
ok, ht; the call is being made
15:02:40 [Zakim]
15:03:30 [richard]
richard has joined #xproc
15:04:11 [Zakim]
15:04:13 [richard]
zakim, ? is me
15:04:13 [Zakim]
+richard; got it
15:04:19 [Andrew]
Andrew has joined #xproc
15:04:48 [Zakim]
15:04:58 [Zakim]
15:05:07 [ruilopes]
Zakim, ??P1 is me
15:05:07 [Zakim]
+ruilopes; got it
15:05:16 [ht]
Regrets: Allesandro and Mohamed
15:05:18 [Andrew]
zakim, ??P4 is me
15:05:18 [Zakim]
+Andrew; got it
15:05:24 [Norm]
zakim, who's on the call?
15:05:24 [Zakim]
On the phone I see Norm, PGrosso, Jeni, Ht, richard, ruilopes, Andrew
15:06:26 [alexmilowski]
alexmilowski has joined #xproc
15:07:07 [Zakim]
+ +1.415.404.aabb
15:07:26 [ht]
zakim, next agendum
15:07:26 [Zakim]
agendum 1. "Administrivia" taken up [from ht]
15:07:33 [ht]
15:08:12 [ht]
RESOLVED: Minutes of 9 August approved as published
15:08:38 [ht]
Next meeting: 23 August
15:08:44 [ht]
No regrets notified as yet
15:09:10 [ht]
Agenda slightly reordered to put namespace binding first
15:09:18 [ht]
Zakim, next agendum
15:09:18 [Zakim]
agendum 2. "Namespace binding" taken up [from ht]
15:09:30 [ht]
15:10:29 [ht]
HST: AM and JT have maybe reached agreement on this issue
15:10:51 [ht]
AM: Option values are a combination of a string and a set of namespace bindings
15:11:00 [Norm]
q+ to ask if everyone is really happy with the idea that option *values* carry namespace bindings with them
15:11:02 [ht]
... this is for QName [and XPath] interpretation
15:11:36 [ht]
... Where do these nsb come from?
15:11:51 [ht]
... By default, from the option element itself
15:12:21 [ht]
... but you can use a 'namespaces' attribute on p:option to identify a node whose bindings should be used
15:13:02 [ht]
15:13:24 [ht]
AM: Consider selecting a node from a document to get an option value
15:13:27 [Norm]
I don't see any examples that use the new 'namespaces' attribute. Am I blind?
15:13:37 [ht]
... you want to take the nearest ancestor-or-self to get nsb
15:14:25 [ht]
s/selecting a node/constructing a string/
15:15:08 [ht]
AM: The tricky case is when you use an option value to set an option value
15:15:25 [ht]
... In that case you pass the nsb along with
15:15:33 [ht]
q+ to check something
15:16:22 [ht]
AM: The remaining case which my proposal doesn't cover is when you construct a value which e.g. concats another option value
15:16:59 [ht]
JT: I suggest we add a special-purpose step which handles this case
15:17:14 [ht]
15:18:17 [ht]
AM: This approach requires the author to do some extra work
15:18:34 [ht]
NW: Could we see an example which requires this, and how it would work
15:19:00 [ht]
JT: Consider concat('foo:',$delete)
15:20:12 [Jeni]
concat($delete, '/html:p')
15:20:36 [alexmilowski]
e.g. the option value is an element QName that is used in a constructed XPath
15:22:54 [ht]
JT: So the p:to-xml step can be used to unpack an option into an element with the nsb from it and value its value
15:23:14 [ht]
... and then you can do anything you need to
15:24:08 [ht]
... with that document, and then use the result to set an option
15:24:38 [ht]
RT: We couldn't write the p:to-xml step currently
15:24:53 [ht]
... because the connection from the string to the nsb is not available e.g. to XSLT
15:24:55 [ht]
JT: Yes
15:25:35 [ht]
AM: Have we really solved the problem of supporting general XPath construction?
15:25:59 [ht]
... I don't think so, because of possible NS conflicts
15:26:34 [ht]
NW: No way to make it work in principle
15:27:15 [ht]
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
15:27:50 [ht]
... this would work even if there were two a: prefixed names with different bindings
15:28:17 [ht]
HST: I wonder if Alex isn't pointing us in the right direction
15:28:36 [Jeni]
Those are the major cases, but they're not the only cases.
15:29:03 [ht]
HST: We should just support XPath construction and bare QNames
15:31:01 [ht]
HST: What about the following: <p:option name='a' value='concat($delete, '/html:p')' namespaces='$delete'/>
15:32:35 [ht]
JT: As proposed, the namespaces attribute provides the _only_ bindings, so that wouldn't work
15:32:54 [ht]
HST: But couldn't we spec. it to merge in a defined way
15:33:14 [ht]
AM: Yes, but what about conflicts
15:33:44 [ht]
HST: I'm happy for that case to cause an error
15:34:40 [ht]
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
15:35:07 [ht]
AM: I'm inclined towards HST's proposal
15:35:47 [ht]
NW: Why not combine in [scribe missed]
15:36:06 [ht]
RT: Why not allow the namespaces attribute to specify a set of namespaces
15:36:28 [ht]
JT: Then we should go with my original proposal to have a <p:namespace> element
15:36:36 [ht]
15:36:39 [ht]
q- ht
15:36:41 [ht]
q- Norm
15:37:31 [ht]
NW: It seems to me that the p:namespaces element proposal involves a bit less magic. . .
15:37:51 [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.
15:38:58 [alexmilowski]
(in my proposal I mentioned we could allow a node set and just take the first one)
15:39:05 [alexmilowski]
(as an option)
15:40:06 [Norm]
zakim, who's on the call?
15:40:06 [Zakim]
On the phone I see Norm, PGrosso, Jeni, Ht, richard, ruilopes, Andrew, alexmilowski
15:40:41 [ht]
HST: [summarizes the dimension of variation and asks for a round-robin]
15:40:59 [ht]
1: Minimum: option values carry NS bindings with them
15:41:23 [ht]
2: You can override the bindings with one (or more?) XPaths to pick up a node
15:41:46 [ht]
3: Some kind of merger, with error or priority
15:42:01 [ht]
4: Allow many sources of bindings
15:43:27 [ht]
AM: Does (1) get its bindings from the context of the XPath
15:43:47 [ht]
NW: (2) and above include p:to-xml
15:44:35 [ht]
NW: (4) -- others have too much explanatory overhead
15:44:42 [ht]
PG: Concur
15:45:03 [ht]
Jeni: Could live with anything above (1), prefer (4) as per NW
15:45:47 [ht]
HST: I prefer (3) because it covers the 99% case w/o having to use the new step, could live (4)
15:46:15 [ht]
RT: Completely uncertain, not sure I understand implications of (4), Abstain
15:46:23 [ht]
RL: Concur
15:46:36 [ht]
Ax: Abstain
15:46:46 [PGrosso]
15:46:58 [ht]
AM: (3), could perhaps live with (4)
15:47:37 [ht]
NW: I suggest the editor try to write up (4) and we see what it looks like
15:48:05 [ht]
ACTION: Editor to write up (4) and we see what it looks like
15:48:30 [ht]
NW: I think we can go to Last Call if we get agreement on that
15:54:56 [ht]
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
15:55:41 [ht]
... and I'm confident we'll deal with it
15:55:59 [ht]
NW, HST: [discussion about names on p:when etc. issue]
15:56:20 [ht]
zakim, next agendum
15:56:20 [Zakim]
agendum 3. "Comments on August 10 editors' draft" taken up [from ht]
15:56:42 [ht]
[see above]
15:57:00 [ht]
NW: What about 'yes|no' vs. 'true|false'
15:57:30 [ht]
JT: Given that people may use XPaths to generate values, we should go for 'true|false'
15:58:08 [ht]
NW: I'm just not sure how people who expect 'yes|no' will feel
15:58:22 [ht]
HST: I prefer just 'true|false' (and maybe 0|1)
15:58:54 [Zakim]
15:58:55 [Zakim]
15:58:56 [Zakim]
15:58:58 [Zakim]
15:58:59 [Zakim]
15:59:01 [Zakim]
15:59:02 [Zakim]
15:59:05 [Zakim]
15:59:06 [Zakim]
XML_PMWG()11:00AM has ended
15:59:07 [Zakim]
Attendees were +1.781.442.aaaa, PGrosso, Jeni, Norm, Ht, richard, ruilopes, Andrew, +1.415.404.aabb, alexmilowski
15:59:12 [PGrosso]
PGrosso has left #xproc
15:59:17 [ht]
NW: Anyone opposed to restricting all the boolean-type things in the spec to 'true|false'?
15:59:38 [ht]
RESOLVED: To restrict all the boolean-type things in the spec to 'true|false'.
15:59:50 [ht]
RRSAgent, make logs world-visible.
15:59:59 [ht]
RRSAgent, make logs world-visible
16:00:12 [ht]
RRSAgent, draft minutes
16:00:12 [RRSAgent]
I have made the request to generate ht
16:34:48 [Norm]
Norm has joined #xproc