See also: IRC log
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 Zergaoui
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
AV: XForms have an 'insert'
action, that we should look at to get an idea, perhaps
... Perhaps the different attributes they have would help
<Alessandro> http://www.w3.org/TR/xforms11/#action-insert
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
RT: 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
HST: Looking at the final one, 3.4 set-attributes
RT: I think this just copies attributes from doc elt to doc elt
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
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 to '/' and use '/*/@*'
you get his set-attributes. . .
... Sounds to me like these two both need some more thought,
but there's definitely something 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.
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