This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The current XSLT 3.0 version of xml-to-json() has a fallback option; the current XPath 3.1 version does not.
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.
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.
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.
Further, we resolved to copy the current spec from F+O 3.1 into XSLT (which means, for example, dropping the fallback option)
The proposal was accepted and the changes have been applied.