XProc telcon -- 11 Jan 2007

<scribe> Scribe: Henry S. Thompson

<scribe> ScribeNick: ht

http://www.w3.org/XML/XProc/2007/01/11-agenda.html

HST: We will take 2.2 ahead of 2.1
... Regrets from NDW

http://www.w3.org/XML/XProc/2007/01/04-minutes.html

HST: Last week's minutes. . .
... Approved.
... Next meeting: 18 January
... Regrets from Paul Grosso, Norm Walsh and Richard Tobin
... Probably regrets from Mohamed

Components list

http://www.w3.org/XML/XProc/docs/alternate/#std-optional

HST: The most recent draft
... Micro-operations components
... Consider 3.1 Rename

RT: Can the 'name' parameter be an XPath as well?

HST: Makes sense, but causes the 90% case to have to be quoted twice. . .

RT: We could have two distinct parameters, one for constant and one for XPath

select='foo' name='bar'

RT: or //foo

HST: Match or select?
... I guess the argument for select is that otherwise you lose the full generality of XPath

MZ: Description says attribute, element or pi -- how do you do pi?

RT: select='processing-instruction(foo)'

HST: Happy with the design of this one?

RT: Make this have deletion functionality, or have a separate component?

HST: Prefer a separate component

MZ: Me too

HST: I assume, for the record, that to rename an attribute you say:
... select='//*/@foo' name='bar'
... NOT name = '@bar'

RT: There's an overall question about namespace bindings
... I presume the XPath finds namespace bindings in the pipeline document
... What about the name -- is it a QName and do the default namespace rules apply?

HST: Yes it's a QName, and yes they apply

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

AV: I think in XSLT where QNames are used, the default binding doesn't apply, for example in nameing functions
... so we can and should do the same here

HST: I'm sorry to lose strong typing -- this proposal would mean we can't use xs:QName
... Perhaps we should add a namespace parameter

RT: Or allow either a name parameter or both local-name and (optional namespace-name) parameters

AV: Let's take this to the mailing list

HST: OK, agreed -- we like this component, but need to settle this outstanding issue of default NS wrt the 'name' parameter
... Moving on to 3.2, Wrap
... wraps the document element

RT: Doesn't seem to useful

HST: Agree, I'd like to see a 'select' parameter here as well -- I use that version all the time
... A similar operation in other pipeline languages?
... What about a 'select' parameter?

RT: Yes, but what about recursive operation?

HST: Yes, because you can defeat that with a more specialised XPath
... although it's not easy to do

RT: Yes it is, just write //foo[not(ancestor::foo)]

HST: Same issue wrt what the 'name' parameter is arises
... should be probably be settled in the same way
... One more thing to consider -- a 'groupBy' attribute name or XPath parameter
... select='//foo' name='bar' groupBy='@fam'
... then input of <foo fam='1'/><foo fam='1'/><foo fam='2'/>

would give two bars, not three

RT: What about intervening elements, text, whitespace
... and what about matching text?

HST: I say it can match text, which I find very useful
... select='//foo/text()' name='bar'
... turns <foo>text</foo> into <foo><bar>text</bar></foo>

RT: That (text) seems reasonable, but the groupBy would need to be carefully specified wrt what's allowed in between
... what about comments, etc.

HST: Agreed, more care on that front is needed, and email is the right place to do that
... I think I hear consensus that we want this, but definitely _with_ a select attribute added

RT: What about 'Unwrap' ?

HST: Right, we've had suggestions to add Delete and Unwrap operations, we should come to those
... 3.3 Insert, which takes a whole document and plugs it in just under the document element
... typo, should say that it takes the document from the 'insertion' port . . .
... Again, I want an XPath to select the parent of the insertion
... Useful e.g. for putting a doc inside a soap wrapper

RT: That's not fully general, is it -- you can't get it between arbitrary siblings that way

<Alessandro> http://www.w3.org/TR/xforms11/#action-insert

AV: XForms have an 'insert' action, that we should look at to get an idea, perhaps
... Perhaps the different attributes they have would help

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
... Looking at the final one, 3.4 set-attributes

RT: I _think_ this just copies attributes from doc elt to doc elt
... Going back to the Insert one, what about multiple matches?

HST: Yes, needs to be decided -- my version says "first match" is where the insertion happens, multiple (or none) are not an error
... But we should resolve this after email discussion as well
... 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

RT: We could combine the two and have a Copy component -- use .../* or .../@* to copy/insert children or attributes respectively

HST: I'd like the SOAP insertion case to continue to be simple, but I think that could be accomplished with some sensible defaults
... 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. . .
... Sounds to me like these two both need some more thought, but there's definitely _somethign_ here we want.
... Can we sketch the two additions we've suggested: Delete and Unwrap
... Seems to me Delete just needs a 'select' XPath -- any tricky problems?
... Recursion isn't an issue, because you delete the whole matching subtree. . .
... Unwrap is very similar, but only matching elements makes sense
... It's an error to match the doc. elt if it has more than one child or text children, etc.

<AndrewF> quit

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
... Please pick up this topic in email and get some discussion started before next time
... Adjourned

- DRAFT -

XProc telcon

11 Jan 2007

Attendees

Contents

Components list

Summary of Action Items

Scribe.perl diagnostic output