- From: <bugzilla@jessica.w3.org>
- Date: Mon, 10 Feb 2014 11:14:18 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24207 C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cmsmcq@blackmesatech.com --- Comment #3 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> --- The WG discussed this during the ftf meeting in Prague. We agree that this is a possible path for growth of XPath, though it is a path the WG is not inclined to take at this time. In the discussion, a few technical points were made which may be worth recording. - Functions to construct nodes will feel most convenient to many users if they can be chained (so one could write an expression like element('x').att('id', 'x0001').att('code',3) to produce <x id='x0001' code="3"/>). (The alternative of element('x', (att('id', 'x0001'), att('code'3))) was also mentioned; the function library of SQL/XML. Or the set of attributes can be defined by a map from names to values.) - Having the same expression language in XSLT and XQuery might be another approach. - Since the F and O function library already has crossed the boundary line of including functions which return nodes (doc()), it is conceivable that functions for constructing elements and attributes could be specified and prototyped in EXPath. Strictly speaking, this issue seems to involve XPath, not XSLT; should it be reassigned to XPath 3.0 or 3.1? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 10 February 2014 11:14:25 UTC