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