28836 2015-06-22 12:33:49 +0000 fn:parse-json, fallback function 2016-12-16 19:55:16 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.1 Candidate Recommendation PC Windows NT CLOSED FIXED P2 normal --- 1 christian.gruen mike public-qt-comments oldest_to_newest 121424 0 christian.gruen 2015-06-22 12:33:49 +0000 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? 121436 1 mike 2015-06-22 18:48:04 +0000 Doesn't function coercion handle this case? 121437 2 christian.gruen 2015-06-23 09:21:50 +0000 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? 122097 3 mike 2015-07-15 17:49:23 +0000 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. 122098 4 mike 2015-07-15 17:51:14 +0000 The proposal was accepted. 122121 5 mike 2015-07-15 23:52:50 +0000 The change has been applied. 122123 6 mike 2015-07-16 01:27:03 +0000 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.