29602 2016-04-29 14:07:51 +0000 [xslt30] xml-to-json() - inconsistency between XSLT30 and XP31 specs 2016-10-06 18:42:23 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC All CLOSED FIXED P2 normal --- 1 mike mike public-qt-comments oldest_to_newest 126303 0 mike 2016-04-29 14:07:51 +0000 The current XSLT 3.0 version of xml-to-json() has a fallback option; the current XPath 3.1 version does not. 126305 1 mike 2016-04-29 21:10:39 +0000 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. 126421 2 mike 2016-05-12 10:32:18 +0000 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. 126589 3 mike 2016-05-26 16:42:47 +0000 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. 126590 4 mike 2016-05-26 16:45:33 +0000 Further, we resolved to copy the current spec from F+O 3.1 into XSLT (which means, for example, dropping the fallback option) 126591 5 mike 2016-05-26 21:10:25 +0000 The proposal was accepted and the changes have been applied.