XProc Minutes 11 Jan 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

                              - DRAFT -

                       XML Processing Model WG

                       Meeting 50, 11 Jan 2007

Agenda

See also: IRC log
Attendees

Present
    Andrew Fang, Paul Grosso, Rui Lopes, Henry S. Thompson, Richard
Tobin, Alessandro Vernet, Mohamed Zergaoui
Regrets
    Murray Maloney, Norm Walsh
Absent
    Alex Milowski, C. M. Sperberg-McQueen
Chair
    Henry S. Thompson (pro tem)
Scribe
    Henry S. Thompson

Contents

    * Topics
         1. Components list
         2. Next meeting topic

0. Adminisrivia

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

1. 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

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.

2. Next meeting topic

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

- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFFpnU/kjnJixAXWBoRAgj5AJ9jAmCXxZZWPWzHpSXr9gkKXvigAgCdHGdB
+zwI3yU7sw1xzpWnj/5xKiE=
=bo5F
-----END PGP SIGNATURE-----

Received on Thursday, 11 January 2007 17:35:02 UTC