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 http://www.w3.org/2007/08/16-xproc-irc

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]

Agenda: http://www.w3.org/XML/XProc/2007/08/16-agenda.html

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:+33.4.89.06.34.99 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]

Welcome!

14:59:46 [Zakim]

+[ArborText]

14:59:55 [Jeni]

Zakim, please call Jeni

14:59:55 [Zakim]

ok, Jeni; the call is being made

14:59:57 [Zakim]

+Jeni

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]

+Ht

15:03:30 [richard]

richard has joined #xproc

15:04:11 [Zakim]

+??P0

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]

+??P1

15:04:58 [Zakim]

+??P4

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]

http://www.w3.org/XML/XProc/2007/08/09-minutes.html

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]

http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0075.html

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]

http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0130.html

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]

http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Aug/0135.html

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]

q?

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]

s/Ax/AF/

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]

-Ht

15:58:55 [Zakim]

-Norm

15:58:56 [Zakim]

-richard

15:58:58 [Zakim]

-ruilopes

15:58:59 [Zakim]

-PGrosso

15:59:01 [Zakim]

-alexmilowski

15:59:02 [Zakim]

-Andrew

15:59:05 [Zakim]

-Jeni

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 http://www.w3.org/2007/08/16-xproc-minutes.html ht

16:34:48 [Norm]

Norm has joined #xproc