IRC log of xproc on 2007-01-11

Timestamps are in UTC.

15:28:37 [RRSAgent]
RRSAgent has joined #xproc
15:28:37 [RRSAgent]
logging to http://www.w3.org/2007/01/11-xproc-irc
15:48:41 [rlopes]
rlopes has joined #xproc
15:56:19 [PGrosso]
PGrosso has joined #xproc
15:57:41 [Alessandro]
Alessandro has joined #xproc
15:58:25 [ht]
Meeting: XProc telcon
15:58:32 [ht]
Chair: Henry S. Thompson (pro tem)
15:58:43 [ht]
Scribe: Henry S. Thompson
15:58:48 [ht]
ScribeNick: ht
15:59:02 [ht]
Agenda: http://www.w3.org/XML/XProc/2007/01/11-agenda.html
15:59:27 [ht]
zakim, please call ht-781
15:59:27 [Zakim]
ok, ht; the call is being made
15:59:28 [Zakim]
XML_PMWG()11:00AM has now started
15:59:28 [Zakim]
+Ht
15:59:47 [Zakim]
+??P24
15:59:48 [Zakim]
-??P24
15:59:49 [Zakim]
+??P24
16:00:28 [richard]
richard has joined #xproc
16:00:35 [Zakim]
-??P24
16:00:37 [Zakim]
+[ArborText]
16:00:38 [Zakim]
+Alessandro_Vernet
16:00:39 [Zakim]
-Alessandro_Vernet
16:00:41 [Zakim]
+Alessandro_Vernet
16:00:56 [Zakim]
+??P24
16:00:58 [richard]
zakim, ? is richard
16:00:58 [Zakim]
+richard; got it
16:01:39 [Zakim]
+??P26
16:01:48 [rlopes]
Zakim, ?? is me
16:01:48 [Zakim]
+rlopes; got it
16:01:59 [AndrewF]
AndrewF has joined #xproc
16:02:48 [Zakim]
+??P22
16:02:51 [AndrewF]
zakim, ? is AndrewF
16:03:04 [Zakim]
+AndrewF; got it
16:03:16 [Zakim]
+MoZ
16:04:36 [ht]
http://www.w3.org/XML/XProc/2007/01/11-agenda.html
16:04:40 [MoZ]
MoZ has changed the topic to: http://www.w3.org/XML/XProc/2007/01/11-agenda.html
16:05:08 [ht]
HST: We will take 2.2 ahead of 2.1
16:05:28 [ht]
HST: Regrets from NDW
16:05:39 [ht]
http://www.w3.org/XML/XProc/2007/01/04-minutes.html
16:05:52 [ht]
HST: Last week's minutes. . .
16:06:11 [ht]
... Approved.
16:06:22 [ht]
HST: Next meeting: 18 January
16:06:44 [ht]
... Regrets from Paul Grosso, Norm Walsh and Richard Tobin
16:07:28 [ht]
... Probably regrets from Mohammed
16:07:40 [MoZ]
s/Mohammed/Mohamed/
16:08:19 [ht]
Topic: Components list
16:08:37 [ht]
http://www.w3.org/XML/XProc/docs/alternate/#std-optional
16:08:48 [ht]
HST: The most recent draft
16:09:14 [ht]
... Micro-operations components
16:11:32 [ht]
... Consider 3.1 Rename
16:11:42 [ht]
RT: Can the 'name' parameter be an XPath as well?
16:12:10 [ht]
HST: Makes sense, but causes the 90% case to have to be quoted twice. . .
16:12:28 [ht]
RT: We could have two distinct parameters, one for constant and one for XPath
16:13:03 [ht]
select='foo' name='bar'
16:13:41 [ht]
RT: or //foo
16:13:47 [ht]
HST: Match or select?
16:14:25 [ht]
... I guess the argument for select is that otherwise you lose the full generality of XPath
16:15:15 [ht]
MZ: Description says attribute, element or pi -- how do you do pi?
16:15:29 [ht]
RT: select='processing-instruction(foo)'
16:16:24 [ht]
HST: Happy with the design of this one?
16:16:57 [ht]
RT: Make this have deletion functionality, or have a separate component?
16:17:18 [ht]
HST: Prefer a separate component
16:17:22 [ht]
MZ: Me too
16:18:04 [ht]
HST: I assume, for the record, that to rename an attribute you say:
16:18:21 [ht]
... select='//*/@foo' name='bar'
16:18:34 [ht]
... name = '@bar'
16:19:01 [ht]
s/name =/NOT name =/
16:19:25 [ht]
RT: There's an overall question about namespace bindings
16:19:48 [ht]
... I presume the XPath finds namespace bindings in the pipeline document
16:20:18 [ht]
... What about the name -- is it a QName and do the default namespace rules apply?
16:20:33 [ht]
HST: Yes it's a QName, and yes they apply
16:21:23 [ht]
RT: I'd say they _don't_ apply, because that would make the 90% case for renaming attributes a problem if there was a default namespace binding in effect
16:23:19 [ht]
AV: I think in XSLT where QNames are used, the default binding doesn't apply, for example in nameing functions
16:23:27 [ht]
... so we can and should do the same here
16:25:28 [ht]
HST: I'm sorry to lose strong typing -- this proposal would mean we can't use xs:QName
16:25:43 [ht]
... Perhaps we should add a namespace parameter
16:26:22 [ht]
RT: Or allow either a name parameter or both local-name and (optional namespace-name) parameters
16:26:29 [ht]
AV: Let's take this to the mailing list
16:27:13 [ht]
HST: OK, agreed -- we like this component, but need to settle this outstanding issue of default NS wrt the 'name' parameter
16:27:30 [ht]
HST: Moving on to 3.2, Wrap
16:28:08 [ht]
... wraps the document element
16:28:14 [ht]
RT: Doesn't seem to useful
16:28:33 [ht]
HST: Agree, I'd like to see a 'select' parameter here as well -- I use that version all the time
16:28:54 [ht]
... A similar operation in other pipeline languages?
16:29:51 [ht]
... What about a 'select' parameter?
16:30:12 [ht]
RT: Yes, but what about recursive operation?
16:30:36 [ht]
HST: Yes, because you can defeat that with a more specialised XPath
16:31:40 [ht]
... although it's not easy to do
16:31:57 [ht]
RT: Yes it is, just write //foo[not(ancestor::foo)]
16:32:16 [ht]
HST: Same issue wrt what the 'name' parameter is arises
16:32:35 [ht]
... should be probably be settled in the same way
16:33:12 [ht]
HST: One more thing to consider -- a 'groupBy' attribute name or XPath parameter
16:34:14 [ht]
... select='//foo' name='bar' groupBy='@fam'
16:34:40 [ht]
... then input of <foo fam='1'/><foo fame='1'/><foo fam='2'/>
16:34:48 [ht]
would give two bars, not three
16:34:58 [ht]
s/fame/fam/
16:35:38 [ht]
RT: What about intervening elements, text, whitespace
16:35:51 [ht]
... and what about matching text?
16:36:02 [ht]
HST: I say it can match text, which I find very useful
16:36:19 [ht]
... select='//foo/text()' name='bar'
16:36:34 [ht]
... turns <foo>text</foo> into <foo><bar>text</bar></foo>
16:37:18 [ht]
RT: That (text) seems reasonable, but the groupBy would need to be carefully specified wrt what's allowed in between
16:37:31 [ht]
... what about comments, etc.
16:37:56 [ht]
HST: Agreed, more care on that front is needed, and email is the right place to do that
16:38:27 [ht]
... I think I here consensus that we want this, but definitely _with_ a select attribute added
16:38:39 [ht]
s/here consensus/hear consensus/
16:39:15 [ht]
RT: What about 'Unwrap' ?
16:39:37 [ht]
HST: Right, we've had suggestions to add Delete and Unwrap operations, we should come to those
16:40:42 [ht]
HST: 3.3 Insert, which takes a whole document and plugs it in just under the document element
16:41:09 [ht]
... typo, should say that it takes the document from the 'insertion' port . . .
16:42:30 [ht]
... Again, I want an XPath to select the parent of the insertion
16:42:55 [ht]
... Useful e.g. for putting a doc inside a soap wrapper
16:43:17 [ht]
RT: That's not fully general, is it -- you can't get it between arbitrary siblings that way
16:43:38 [Alessandro]
http://www.w3.org/TR/xforms11/#action-insert
16:43:46 [ht]
AV: XForms have an 'insert' action, that we should look at to get an idea, perhaps
16:44:03 [ht]
... Perhaps the different attributes they have would help
16:45:05 [ht]
HST: Seems to be consensus to have this, with some extensions, at least a 'select' XPath, and probably some more articulation in the area of 'at-start' to get full(er) control of where the insertion happens under the selected parent
16:45:44 [ht]
HST: Looking at the final one, 3.4 set-attributes
16:46:07 [ht]
RT: I _think_ this just copies attributes from doc elt to doc elt
16:47:10 [ht]
RT: Going back to the Insert one, what about multiple matches?
16:47:38 [ht]
HST: Yes, needs to be decided -- my version says "first match" is where the insertion happens, multiple (or none) are not an error
16:47:51 [ht]
... But we should resolve this after email discussion as well
16:50:03 [ht]
HST: Back to set-attributes -- it's more like copy-attributes, and needs _two_ XPaths, I think -- this suggests Insert could be generalised to CopyChildren with another XPath selecting what to copy in the Insertion document
16:50:41 [ht]
RT: We could combine the two and have a Copy component -- use .../* or .../@* to copy/insert children or attributes respectively
16:51:22 [ht]
HST: I'd like the SOAP insertion case to continue to be simple, but I think that could be accomplished with some sensible defaults
16:52:15 [ht]
... For instance, if both XPaths default to '/', you get Alex's original Insert, and if you default the first and use '/*/@*' you get his set-attributes. . .
16:53:10 [ht]
... Sounds to me like these two both need some more thought, but there's definitely _somethign_ here we want.
16:53:45 [ht]
HST: Can we sketch the two additions we've suggested: Delete and Unwrap
16:54:17 [ht]
... Seems to me Delete just needs a 'select' XPath -- any tricky problems?
16:54:49 [ht]
... Recursion isn't an issue, because you delete the whole matching subtree. . .
16:55:25 [ht]
HST: Unwrap is very similar, but only matching elements makes sense
16:55:55 [ht]
... It's an error to match the doc. elt if it has more than one child or text children, etc.
16:57:35 [Zakim]
-PGrosso
16:57:36 [Zakim]
-rlopes
16:57:36 [Zakim]
-richard
16:57:38 [Zakim]
-Ht
16:57:39 [Zakim]
-AndrewF
16:57:40 [Zakim]
-Alessandro_Vernet
16:57:41 [Zakim]
XML_PMWG()11:00AM has ended
16:57:42 [Zakim]
Attendees were Ht, Alessandro_Vernet, PGrosso, richard, rlopes, AndrewF, MoZ
16:57:52 [AndrewF]
quit
16:58:47 [ht]
HST: We _will_ turn to the question of choose/when next week, but I think the best thing to do is go ahead and officially engage with the defaulting issue at this point, so we can take advantage of the useful thread on this topic which started in December
16:59:08 [ht]
... Please pick up this topic in email and get some discussion started before next time
16:59:13 [ht]
... Adjourned
16:59:21 [ht]
zakim, bye
16:59:21 [Zakim]
Zakim has left #xproc
16:59:30 [ht]
RRSAgent, make logs world-visible
16:59:36 [ht]
RRSAgent, draft minutes
16:59:36 [RRSAgent]
I have made the request to generate http://www.w3.org/2007/01/11-xproc-minutes.html ht
17:03:01 [PGrosso]
PGrosso has left #xproc