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 25196 - [XSLT30] Availability of the xml-to-json packages
Summary: [XSLT30] Availability of the xml-to-json packages
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows NT
: 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: 25187
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-28 15:32 UTC by Abel Braaksma
Modified: 2014-08-02 13:58 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2014-03-28 15:32:15 UTC
Under [1], the section on XML To JSON, we do not currently mandate that the packages in B.2 have to be made available by implementers. I suggest we add a line something like the following:

An implementation must make the packages under B.2 available through their name, 'http://www.w3.org/2013/XSLT/xml-to-json.xsl', whether or not the package is also physically available (i.e. for editing) is implementation defined.

In addition, I noted the following minor issues:

1) the stylesheet under B.3 [2] uses xsl:import on a package with a relative url. We have decided in the resolution for bug 24310 that packages cannot be imported. 

2) the stylesheet under B.3 is not a package, which limits its usefulness and does not make it readily available.

3) the stylesheet under B.3 does not re-use / redefine $j:start-map.

4) $indent-spaces should probably be $j:indent-spaces

We can solve (1) and (2) easily by embedding the stylesheet under B.3 inside the package under B.2, with a default parameter for $indent-spaces of "0". In addition, we can add a boolean, $j:indent, which, if set, changes the value of other separators to include more whitespace (see for instance template j:start-map).

We can solve (3) by rewriting $j:start-map dependent on the new $j:indent value to include spacing.

Solving all these issues adds usability. We could simplify using the indented version further by adding a function f:xml-to-json-indented, which calls the overridden version of the templates (which will require a bit of redesigning of the global parameters, allowing them to be overridden by function call and/or apply-templates).

See also bug 25187, which mentions a few other (static) bugs in the stylesheets in this section.

[1] http://www.w3.org/TR/xslt-30/#xml-to-json
[2] http://www.w3.org/TR/xslt-30/#xml-to-json-stylesheet-indented
Comment 1 Abel Braaksma 2014-03-28 15:38:15 UTC
I forgot one:
(5) the B.x sections are not marked normative, currently. I believe they should be, or if not, I think we should say so, and why.
Comment 2 Michael Kay 2014-07-31 11:07:05 UTC
From the minutes of 17 July 2014 telcon:

> Re: xml-to-json() function (ACTION 2014-07-10-002) -
> https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Jul/0028.html - MKay

MK walked the group through the state of the proposal.

After some discussion we agreed to make json-to-xml continue producing
a document node, while changing xml-to-json to accept a document node
(and move down to the element).

RESOLVED: The WG agreed with the general approach shown here and
wishes to proceed along the lines laid out.
Comment 3 Michael Kay 2014-07-31 13:05:08 UTC
The WG was generally happy with the text that appears in the current editor's draft. But there was a feeling that the xml-to-json stylesheet should be a package, and that we should require implementations to support xsl:use-package specifying the relevant package name.

This in turn led to a discussion about the use of static variables in packages. This stylesheet uses two static parameters INDENT and VALIDATION, and these parameters need to be supplied at package compile time. As a result, there will be multiple versions of the "compiled package" with different settings for these parameters. One would expect an xsl:use-package declaration to be able to say which of these versions it wants. (Perhaps this is out of scope for the spec and simply implies an indirection between the name of the source package and the name of a compiled package?)

Resolved to close this as resolved, but with an action to look at converting the stylesheet to a package.