This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Taken from: http://lists.w3.org/Archives/Public/public-qt-comments/2013May/0101.html All, The XForms Working Group is looking into providing a `serialize()` function similar or identical to the XPath 3 function [1], and to make it available, for practical reasons, to XPath 2 implementations. Ideally, the XForms Working Group would like to use the exact same function signature as XPath 3. But while considering the XPath 3 function, it has come to our attention that the format to pass serialization attributes appears to be extremely heavy (via the output:serialization-parameters), to the point that we are thinking of using an alternative way to pass such parameters. I have provided my understanding of this in the following public email to the XForms Working Group: http://lists.w3.org/Archives/Public/public-forms/2013May/0003.html Our questions to the group are: 1. Is our understanding, as expressed in the email above, correct? Namely, that `use-character-maps` is the main reason behind the chosen format (although we do understand that future extensibility could be a factor as well), and that there is no other way to pass serialization parameters? 2. If so, could the group be convinced of using instead a lighter syntax, such as a simple sequence of tokens in an attribute value? The main driver behind this thinking is that lighter is usually better, and having to provide a complete XML document to provide a few serialization parameters, while clearly maximizing flexibility, is definitely on the heavier side of what is possible. This is true especially since character maps are likely to be used rarely, certainly more rarely than some other serialization parameters. Optimizing for the common cases seems like good practice. (As a side note, if maps were a core feature of XPath 3, then using a map parameter could be a possibility for XPath 3 (although not for XPath 2).) Thanks, -Erik [1] http://www.w3.org/TR/xpath-functions-30/#func-serialize
Thank you for writing to us. The XSLT and XQuery WGs discussed this. In XPath 3.1 there will be (as you note) a new data structure, the map, which might well provide an alternative in the future. However, some of the parameters have intrnal sructure, so that XML elements seems not unreasonable. I will close this as WONFIX; we'd obviously be happy to revisit it for XPath 3.1, or to discuss options with you in more detail; reopen this bug if this resolution is not satifactory. On a personal note I'd be interested to know the practical reasons for not moving to XPath 3, but that's outside the scope of this issue ;-) Thanks!
Thanks for the response. We have decided to use the XPath 3 serialize() function nonetheless to facilitate future compatibility with XPath 3. The practical reason not to require XPath 3 is the lack of implementations at this time, in particular open source implementations. Most XForms implementations do not implement their own XPath engine but use an existing one. Also, a number of XForms implementations are open source and require an open source XPath implementation as well. Requiring XPath 3 would mean that no conformant XForms 2 implementation could be realistically produced in a reasonable amount of time (this year). Note that with XForms 2, the expression language is defined in a separate module, which currently defines support for XPath 2 and XPath 1 in compatibility mode. This includes an xpath-version attribute, and an implementation can choose to support XPath 3 if it chooses so.
Thank you for the respose! Note that you could supply a function that took a simpler format and converted it to a form suitable for serialize(), and the impelemntation could optimize away the conversion. THis isn't possible in all cases of course.