This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
Doesn't function coercion handle this case?
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?
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. to (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.
The proposal was accepted.
The change has been applied.
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.