- From: <bugzilla@jessica.w3.org>
- Date: Wed, 09 Sep 2015 10:00:59 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29009 --- Comment #2 from Michael Kay <mike@saxonica.com> --- First: I think that the case let $input := validate type xs:float { <fn:boolean>0.0</fn:boolean> } return xml-to-json($input) fails under the current rules. Although the "validate type" expression succeeds, it produces an instance that does not satisfy the preconditions for xml-to-json, specifically, it is neither: (a) An element node whose name matches the name of a global element declaration in the schema given in [schema] and whose type annotation matches the type of that element declaration; nor (b) An element node whose name matches the name of a global element declaration in the schema given in [schema], whose type annotation is xs:untyped, and whose content after stripping all attributes (at any depth) in namespaces other than http://www.w3.org/2005/xpath-functions is such that validation against the schema given in [schema] would succeed. Changing "xs:untyped" to "xs:anyType" in the second rule would not change this. I think the simplest resolution is (1) to remove the phrase "whose type annotation is xs:untyped, ", and (2) to change rules 3 and 4 in the 8-rule list to 3. An element $E named boolean results in the output true or false depending on the result of xs:boolean(string($E)). 4. An element $E named number results in the output of the string result of xs:string(xs:double(string($E))). This effectively means that the processor does not have to look at the existing type annotations, so long as it validates the values of elements as it goes (though it can use the existing type annotations if it wishes as an optimization to avoid revalidating). -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 9 September 2015 10:01:07 UTC