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 spec of json-to-xml() defines a schema for the target namespace http://www.w3.org/2005/xpath-functions/json. The spec states that (a) a particular error occurs "if the processor is not schema-aware" (b) if the processor is schema-aware, then for validation to succeed, the schema does not need to be explicitly imported (c) <quote> If the stylesheet or query does import a schema for the namespace http://www.w3.org/2005/xpath-functions/json, then: * The processor (if it is schema-aware) must recognize an import declaration for this namespace, whether or not a schema location is supplied. * If a schema location is provided, then the schema document at that location must be equivalent to the schema document at C.2 Schema for the result of fn:json-to-xml; the effect if it is not equivalent is ·implementation dependent· It's not clear that any of these statements should properly appear in the F+O spec. (a) Both XSLT and XQuery have some kind of notion that schema-awareness is optional, but the details vary, and they could vary again in other host languages (b) importing a schema is a host language concept It would be better in F+O only to refer to properties of the static and dynamic context. Probably it should say simply that the schema components for this namespace must be present in the in-scope schema definitions for validation to succeed. This isn't ideal, because the in-scope schema definitions are part of the static context, and there's absolutely no reason that these schema definitions need to be available at compile time (they are only needed at evaluation time). But introducing a notion that we can have schema definitions present in the dynamic context that weren't present in the static context is probably overkill. That leaves the question what XQuery, XPath, and XSLT should say about how the static context is populated and whether it should always include components for this namespace. That decision can be made separately for each host language. For XSLT the rule in effect has been that if you want to refer to the schema components explicitly by name, e.g. in "instance of", you have to import the namespace, but if you just want to invoke validation, you don't. That's consistent with the way things like <xsl:element validation="strict"/> work in XSLT, though it can't really be explained fully in terms of the static and dynamic context as currently defined. It also leaves the question about whether and how F+O can make the statement that "a particular error occurs "if the processor is not schema-aware". Perhaps it should say that the error occurs if these schema components are not available in the context, and leave it to the host language specs to make clear that the components will not be in the context if the processor is "not schema-aware".
I was asked to make a proposal to resolve this. The essence of my proposal is: 1. The schema components for the XML results of fn:analyze-string and fn:json-to-xml should NOT be automatically added to the static context; they should be added to the context only if explicitly imported (using import schema in the case of XQuery). 2. In XQuery and XSLT, the processor must accept an import-schema declaration for the relevant namespaces. If such a declaration includes a schema location, the schema location must be ignored (no error occurs if no schema is present at the location, or if the wrong schema is present at the location, etc), and the schema as defined in our specifications is added to the static context. 3. In XPath, mechanisms for adding schema components to the static context are implementation-defined. 4. The XDM trees returned by fn:analyze-string and fn:json-to-xml should be typed (have non-trivial type annotations on element and attribute nodes) if and only if the processor is able to handle typed data (in XQuery this means if the processor implements the typed data feature), unless the user has requested otherwise (in an implementation-defined way). I think point 4 probably belongs in F+O, the other points belong in the host language specs.
At the joint WG teleconference on 2015-05-12, the WG agreed to adopt the proposal in comment 1.
(In reply to Michael Kay from comment #1) > I was asked to make a proposal to resolve this. I'm implementing this right now. Comments below. > 1. The schema components for the XML results of fn:analyze-string and > fn:json-to-xml should NOT be automatically added to the static context; they > should be added to the context only if explicitly imported (using import > schema in the case of XQuery). I don't think this requires anything to be said explicitly in XQuery 3.1 / XPath 3.1. Both specs explicitly state what schema types are predefined. http://www.w3.org/TR/xquery-31/#id-predefined-types http://www.w3.org/TR/xpath-31/#id-predefined-types When adding this, though, I realized I wasn't sure who "they" is in the above statement. In-scope schema types are "augmentable" according to Appendix C. I assume that should not change? > 2. In XQuery and XSLT, the processor must accept an import-schema > declaration for the relevant namespaces. If such a declaration includes a > schema location, the schema location must be ignored (no error occurs if no > schema is present at the location, or if the wrong schema is present at the > location, etc), and the schema as defined in our specifications is added to > the static context. I am adding this to the section on import-schema. > 3. In XPath, mechanisms for adding schema components to the static context > are implementation-defined. I believe this is equally true for all components of C.1 Static Context Components.
We currently have two schemas, and according to the current status, importing importing http://www.w3.org/2005/xpath-functions loads just the schema for fn:analyze-string, and importing http://www.w3.org/2005/xpath-functions/json loads just the schema for fn:json-to-xml. I suggest we modify this so that importing http://www.w3.org/2005/xpath-functions loads both schemas, and the elements returned by fn:json-to-xml are in that namespace. If other schemas are defined in F&O in the future, they would also be in that target namespace.
The Working Group adopted the resolution in Comment #4.
I'm marking this as reopened purely for administrative reasons, to make sure that the implications of the decision to change the namespace on all the specs including XSLT 3.0 are fully worked through when I get back from vacation.
(In reply to Michael Kay from comment #6) > I'm marking this as reopened purely for administrative reasons, to make sure > that the implications of the decision to change the namespace on all the > specs including XSLT 3.0 are fully worked through when I get back from > vacation. I would find it helpful if F&O had an anchor that identifies the schemas it defines. I can enumerate the two we have easily enough, but if new schemas are defined in the future, it would be nice if they were automatically incorporated.
Downgrading to editorial
F&O Appendix C will describe the schema for the fn namespace, which includes the other schemas in that appendix. XQuery / XPath will refer to this appendix.
The change to F+O has been made. Appendix C now defines first an umbrella schema document which simply xs:include's the other two, then the existing schema documents for analyze-string and json-to-xml which are both now in the fn namespace. All three schema documents are reproduced within App C, and also exist as separate referenced documents. There may be changes to the build needed to ensure they are all copied to the right places.
In the editor's draft, it still refers to elements returned by fn:json-to-xml as being in the namespace http://www.w3.org/2005/xpath-functions/json.
The WG agrees this is editorial
The change has been applied.