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 14752 - [SER30] The "method" output parameter is NOT enough when it comes to extending the serialization-parameters schema
Summary: [SER30] The "method" output parameter is NOT enough when it comes to extendin...
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Serialization 3.0 (show other bugs)
Version: Working drafts
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: Henry Zongaro
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-10 09:39 UTC by Gabriel Petrovay
Modified: 2011-12-13 19:51 UTC (History)
0 users

See Also:

Attachments

Description Gabriel Petrovay 2011-11-10 09:39:48 UTC 
As one can see, the "method" output parameter in the serialization-parameters schema allows extension for implementations to define their own output method. The most obvious example is the "binary".

But there are plenty other examples where only one output method is not enough. People need to define options for the output method.

See for example:
http://www.zorba-xquery.com/site2/doc/latest/zorba/xqdoc/xhtml/www.zorba-xquery.com_modules_converters_json.html#serialize-2
or
http://www.zorba-xquery.com/site2/doc/latest/zorba/xqdoc/xhtml/www.zorba-xquery.com_modules_converters_csv.html#serialize-2

Extra options are necessary for some output methods. So allowing any implementation defined output method is like giving a kid a transparent candy box that he cannot open.

Moreovert implementers (i.e. BaseX, eXist) have, for example, JSON converters but all work different.
http://docs.basex.org/wiki/JSON_Functions
http://demo.exist-db.org/exist/functions/json
http://www.zorba-xquery.com/site2/doc/latest/zorba/xqdoc/xhtml/www.zorba-xquery.com_modules_converters_json.html

Having in the schema the flexibility to add extra serialization parameters would allow people to start talking (EXPath) about common features in terms of serialization. Envision for example:
method="expath:json"
method="expath:csv"
method="expath:binary"
EXpath could go one step further and define those methods and their parameter.

This way most serialization can go through fn:serialize and will simplify many modules and spare developer brain cycles.


Gabriel
Comment 1 Henry Zongaro 2011-12-13 10:48:56 UTC 
It was the intention that the schema for serialization parameters should be extensible.  The output:serialization-parameters element allows for zero or more output:serialization-parameter-element children.  The output:serialization-parameter-element is declared to be abstract in the schema; the elements for all other serialization parameters are defined to be in the substitution group of output:serialization-parameter-element.

As is described in section 3.1,[1] the "In-scope schema types, In-scope element declarations, Substitution groups, In-scope attribute declarations" components of the static context that is used in evaluating the various queries that extract parameter values from the data model instance may contain "any additional implementation-defined in-scope schema components."  So the implementation can supply any additional schema components it chooses, including, but not limited to, additional elements in the substitution group of output:serialization-parameter-element.

The last paragraph before the final example box of section 3.1 states, "If the instance of the data model contains elements or attributes in the instance of the data model that are in a namespace other than http://www.w3.org/2010/xslt-xquery-serialization, the implementation MAY interpret them to specify the values of implementation-defined serialization parameters in an implementation-defined manner."

So I believe that makes it clear that an implementation is permitted to define additional implementation-specific serialization parameters, and to look for them in a data model instance that was supplied to set the serialization parameters.

To ensure portability of the data model instance to implementations that do not define those same serialization parameters, a user might want to include schema location hints to refer to a schema that defines those additional schema components.  Implementers might want to make a schema that defines the necessary schema components for their implementation-defined serialization parameters freely available.


Of course, the extensibility mechanism might have been handled in a different way - for example, through wildcards in the schema for serialization parameters.

This is a personal response, not on behalf of the XSLT and XQuery working groups.

[1] http://www.w3.org/TR/xslt-xquery-serialization-30/#serparams-in-xdm-instance
Comment 2 Henry Zongaro 2011-12-13 18:59:29 UTC 
At the joint teleconference of the XSLT and XQuery working groups of 13 December 2011,[2] the working groups considered the response in comment #1, and agreed that the requirement stated in comment #0 is already satisfied in the current draft of XSLT and XQuery Serialization 3.0.

If you agree with this assessment, please mark this enhancement request closed.  If you feel that there is some relevant use case that isn't satisfied by the existing extensibility mechanism, please reopen the request.

[2] https://lists.w3.org/Archives/Member/w3c-xsl-query/2011Dec/0052.html (Member-only link)