- From: <nobody@w3.org>
- Date: Mon, 03 Aug 2015 16:56:51 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29009 --- Comment #1 from Josh Spiegel <josh.spiegel@oracle.com> --- A few more thoughts on this... If you assume the restriction to xs:untyped instances is removed, the requirement that validation "would succeed" becomes slightly inconsistent with the mappings that are defined in terms of atomization and casting. For example, consider this query: let $input := validate type xs:float { <fn:boolean>0.0</fn:boolean> } return xml-to-json($input) In this case, data(validate { $input }) would fail. However $input cast as xs:boolean would succeed. Assuming the restriction to xs:untyped is removed, I think the definition should then be adjusted in one of the following ways: Option 1: Abandon the requirement on $input that validation "would succeed" and only describe what the function does. In my opinion, this requirement is small burden on the user and the implementor since both have to think about the details of the schema and how validation would work. The intent seems to be that neither the user nor the implementor has to invoke the validator but somehow ensure that it would be possible. If the requirement is removed, I think bullets 1-8 can remain mostly the same and it would just be a matter of explicitly specifying some error conditions (e.g. what to do when an element doesn't match a global element name, what to do when a cast fails, etc.) or Option 2: Align bullets 1-8 more closely with validation. For example, in bullet (3) it says: "An element named boolean results in the output true or false depending on the result of atomizing the element and casting the result to xs:boolean." This would instead say something like: "An element named boolean results in the output true or false depending on the result of validating the element and atomizing the result." Note, the above example (which seems like a corner case) would be allowed under Option 1 and would be an error under Option 2. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 3 August 2015 16:56:54 UTC