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 29602 - [xslt30] xml-to-json() - inconsistency between XSLT30 and XP31 specs
Summary: [xslt30] xml-to-json() - inconsistency between XSLT30 and XP31 specs
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 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: 2016-04-29 14:07 UTC by Michael Kay
Modified: 2016-10-06 18:42 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2016-04-29 14:07:51 UTC
The current XSLT 3.0 version of xml-to-json() has a fallback option; the current XPath 3.1 version does not.
Comment 1 Michael Kay 2016-04-29 21:10:39 UTC
The fallback option was dropped as a result of the decision (of the Joint WGs) recorded here:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28181

Although this decision was made in March 2015, the changes somehow didn't find their way into the XSLT 3.0 CR. This clearly illustrates the challenge we have given ourselves by replicating material across the F+O 3.1 and XSLT 3.0 specifications.

Getting the two specs back into line for xml-to-json() isn't completely trivial:

(a) the F+O 3.1 spec refers to the "option parameter conventions" which define the common (cross-function) rules for option parameters. Do we replicate these in the XSLT 3.0 specification?

(b) we still provide XSLT stylesheets which we claim are equivalent to the xml-to-json() function specification. However, as the function specification has evolved, the stylesheet has not been updated. There are numerous details where its behaviour differs, although most can be considered edge cases. For example, it does not throw an error if a j:string element has child elements; it treats all values of the "indent" option other than true() as false(), rather than throwing an error; it doesn't accurately follow the escaping rules; it makes no attempt to detect duplicate keys in a map; it reports incorrect error codes if the input is invalid.

My firm preference for resolving these issues would be to specify this and similar functions by means of a normative reference to the F+O 3.1 specification.
Comment 2 Michael Kay 2016-05-12 10:32:18 UTC
The problem with the xml-to-json stylesheets can be solved, I think, by changing text in para 2 of 22.4. Instead of "is functionally identical to the xml-to-json function described in the previous section" we should say 

"has largely similar behavior to the xml-to-json function described in the previous section. (It should not be regarded as a conformant implementation of that function: for example, it does not perform complete validation of the input, and it does not follow the escaping rules precisely.)"

The problem with the option parameter conventions is trickier. Reproducing the OPCs in the XSLT 3.0 spec is overkill and increases the risk of inconsistencies creeping in. I do think we should bite the bullet and reference F+O 3.1 normatively.
Comment 3 Michael Kay 2016-05-26 16:42:47 UTC
We resolved:

(a) to retain a self-standing spec of xml-to-json in the XSLT 3.0 spec without referencing F+O 3.1

(b) this involves copying the section on option parameter conventions even though it could be regarded as overkill for this one function

(c) we retain the stylesheets in the spec but downgrade the claim that they are a conformant implementation of the function as specified.
Comment 4 Michael Kay 2016-05-26 16:45:33 UTC
Further, we resolved to copy the current spec from F+O 3.1 into XSLT (which means, for example, dropping the fallback option)
Comment 5 Michael Kay 2016-05-26 21:10:25 UTC
The proposal was accepted and the changes have been applied.