This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22122 - [F+O] Serialization parameters in fn:serialize()
Summary: [F+O] Serialization parameters in fn:serialize()
Status: RESOLVED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-21 15:20 UTC by Michael Kay
Modified: 2013-06-01 02:48 UTC (History)
2 users (show)

See Also:


Attachments

Description Michael Kay 2013-05-21 15:20:53 UTC
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
Comment 1 Liam R E Quin 2013-06-01 00:11:44 UTC
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!
Comment 2 Erik Bruchez 2013-06-01 00:43:22 UTC
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.
Comment 3 Liam R E Quin 2013-06-01 02:48:34 UTC
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.