This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specification of xml-to-json requires the processor to accept a node "whose content is such that validation against the schema given in [json.xsd] would succeed". This provision is designed as a way of specifying what input a non-schema-aware processor should accept, without actually requiring it to perform schema validation. There is one respect in which this provision seems to place excessive burden on a non-schema-aware processor. Validation "would succeed" if the content includes an xsi:type attribute, provided that the xsi:type attribute has an appropriate value. For example the following is allowed: <number xsi:type="xs:short">32</number> while the following is not: <number xsi:type="xs:short">816257</number> It was never intended that a non-schema-aware processor should have to deal with such things, and I don't think we should require it. I therefore propose to change the rule from <old> An element node whose name matches the name of a global element declaration in the schema given in C.2 Schema for the result of fn:json-to-xml, whose type annotation is xs:untyped, and whose content is such that validation against the schema given in C.2 Schema for the result of fn:json-to-xml would succeed. </old> to <new> An element node whose name matches the name of a global element declaration in the schema given in C.2 Schema for the result of fn:json-to-xml, whose type annotation is xs:untyped, and whose content is such that (a) validation against the schema given in C.2 Schema for the result of fn:json-to-xml would succeed, and (b) there is no attribute at any depth whose namespace is http://www.w3.org/2001/Schema-instance </new>
A separate but closely related problem is the fallback option of this function. The specification states that this function is called "When a node is encountered that is not valid against the schema for the XML representation of JSON". What exactly does this mean? If we turn to schema definitions of validity, then if a <map> element contains a <wrong> element that is not permitted by the schema, it is the <map> element that is invalid, not the <wrong> element. But I think the intention here is that the fallback function should be called with the <wrong> element as its argument. Whatever else, this certainly demands a more precise explanation. Also, a map with duplicate keys is invalid against the schema: is it intended that the whole <map> element should be passed to the fallback function in this case? A serious problem with the design is streamability. We don't know whether an element is valid until we reach its end tag, by which time it is too late if the implementation is doing streamed processing. We could attempt a more restricted definition: the function is called when an element is encountered that is not permitted by the content model of its parent element, or in the case of the top level, an element that has no declaration in the schema. Alternatively we could drop the option. It's not clear that it's really useful, in comparison with transforming the XML first to something that conforms with the schema. I would vote for dropping it if only because it's less work than fixing it.
The WG decided on 10 March 2015: (a) the schema should change to allow (and ignore) attributes in "alien" namespaces, that is <xs:anyAttribute namespace="##other" processContents="skip"/> (b) a non-schema-aware processor should ignore all attributes in alien namespaces even where they affect schema validity (e.g. xsi:nil, xsi:type) (c) the fallback option of xml-to-json should be dropped. These changes have been applied.