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 28836 - fn:parse-json, fallback function
Summary: fn:parse-json, fallback function
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
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
Depends on:
Reported: 2015-06-22 12:33 UTC by Christian Gruen
Modified: 2016-12-16 19:55 UTC (History)
0 users

See Also:


Description Christian Gruen 2015-06-22 12:33:49 UTC
In the current spec, the fallback function of fn:parse-json is defined to have the function signature "function(xs:string) as xs:string". In the given example, however...

  parse-json('{"x":"\\", "y":"\u0000"}', map{'fallback':function($s){'['||$s||']'}})

...the function is only of type `function(*)` (because the type are not explicitly stated), and it can only be determined at runtime if the passed on and returned item is of type xs:string (or a value that can be promoted to xs:string).

Maybe the correct solution (albeit not so nice to read) would be to specify "function(*)" as type, and require the function to only accept and return strings?
Comment 1 Michael Kay 2015-06-22 18:48:04 UTC
Doesn't function coercion handle this case?
Comment 2 Christian Gruen 2015-06-23 09:21:50 UTC
I see. Yes, sounds absolutely reasonable.

In that case, it could make sense not to return FOJS0005, but the actual error caused by function coercion. Otherwise, it could be difficult for an implementation to decide if an error was caused by the function signature or by the processed data:

Currently, I would expect this expression to yield FOJS0005:

  json-to-xml('"\uFFFF"', map { 'fallback':
    function($s) as xs:integer { 1 }

And I would expect this expression to yield XPTY0004:

  json-to-xml('"\uFFFF"', map { 'fallback':
    function($s) as xs:string { 1 }

Maybe it would be safer to raise XPTY0004 in all cases?
Comment 3 Michael Kay 2015-07-15 17:49:23 UTC
We are thinking that perhaps rule 6 of 1.5 (option parameter conventions) should change from

A dynamic error occurs if the supplied value cannot be converted to the required type, or if the value after conversion is not one of the permitted values for the option in question. 


(a) A type error XPTY0004 occurs if the supplied value cannot be converted to the required type

(b) A dynamic error (error code defined specifically for each function) if the value after conversion is not one of the permitted values for the option in question.
Comment 4 Michael Kay 2015-07-15 17:51:14 UTC
The proposal was accepted.
Comment 5 Michael Kay 2015-07-15 23:52:50 UTC
The change has been applied.
Comment 6 Michael Kay 2015-07-16 01:27:03 UTC
I have applied the change.

I have also sought WG approval for a further change: renaming unescape=false/true to escape=true/false. The reason for this is to reflect the changed semantics introduced by the agreed resolution to this bug, and to avoid the difficulty of understanding the double negative in unescape=false.