This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
fn-doc-available-4 is described as a test which checks that a document with an invalid xml:id attribute is flagged. Quoting xml:id version 1.0 (http://www.w3.org/TR/xml-id/#dt-xml-id-error) "An xml:id error is a non-fatal error that occurs when an xml:id processor finds that a document has violated the constraints of this specification." "A violation of the constraints in this specification results in an xml:id error. Such errors are not fatal, but should be reported by the xml:id processor. In the interest of interoperability, it is strongly recommended that xml:id errors not be silently ignored." It seems to me from the above that failing an xml:id constraint will not necessarily cause the document to be considered as not available. That said, a mechanism for catching an xml:id error in XQuery would, I presume, be implementation defined. More generally, is it a requirement that a document loaded with fn:doc (directly, or indirectly via fn:doc-available): 1. Perform xml:id processing? 2. Perform DTD processing if a DOCTYPE is included? 3. Perform XML Schema validation if a schema is referenced?
Starting at the end: More generally, is it a requirement that a document loaded with fn:doc (directly, or indirectly via fn:doc-available): 1. Perform xml:id processing? 2. Perform DTD processing if a DOCTYPE is included? 3. Perform XML Schema validation if a schema is referenced? The answer is emphatically no. The dynamic context defines a mapping from URIs to document nodes, and doc() simply applies that mapping. There are no restrictions on how this mapping is set up. If you want to set it up so that the document <badLuck/> is returned regardless of the URI, then you can. However, XDM defines a mapping from InfoSets to document nodes which processors might wish to provide, and it's reasonable to think of this as the default mapping to use (assuming schema validation is not requested, in which case you would use the PSVI mapping instead). If this mapping is used (Data Model section 6.3.3) the rules are: If the attribute is named xml:id and its [attribute type] property does not have the value ID, then [xml:id] processing is performed. This will assure that the value does have the type ID and that it is properly normalized. If an error is encountered during xml:id processing, an implementation MAY raise a dynamic error. The is-id property is always true for attributes named xml:id.
I note that the expected result has now changed from false to true. Given that it is implementation defined whether xml:id processing occurs for fn:doc (therefore affecting fn:doc-available), I believe that for an XQuery-conformant implementation, fn:doc-available may: 1. return true (because it does not perform xml:id processing with fn:doc) 2. return false (because it does perform xml:id processing with fn:doc, fn:doc would raise an implementation-defined error rather than returning a document node) As such, I think this test is testing implementation-defined functionality, and probably needs to be shuffled out of the "minimal conformance" section.
I actually started factoring out the test into an optional group, but after some thinking I considered this part from the xml:id spec: "[Definition: An xml:id error is a non-fatal error that occurs when an xml:id processor finds that a document has violated the constraints of this specification.]" So, as I interprets it, an xml:id processing implementation and once which isn't, must both be able to perfectly fine load documents. Hence, doc-available() must return true regardless of if xml:id is implemented.
Mike Kay quoted: "If an error is encountered during xml:id processing, an implementation MAY raise a dynamic error. The is-id property is always true for attributes named xml:id." Do you believe that such an error should be swallowed up by fn:doc/fn:doc-available? BTW, it would be helpful to have a test which uses a document which fails xml:id processing so that implementors can check we're handling this case correctly.
I believe that quote applies to node constructors(I think it's from XQuery 1.0, 3.7.1.1 Attributes). So in that case I have the same interpretation: that a implementation may report a dynamic error. However, fn-doc-available-4 doesn't touch node constructors, it's about loading XML documents while supporting xml:id, and that's a different thing, I believe. I think that spec says such errors should be non-fatal(although I personally would have preferred them to be fatal). So yes, I think fn:doc/doc-available should accept xml:id-invalid documents. doc-available-3, fn-doc-30 and fn-doc-31 loads invalid xml:id documents, but unless I'm proven wrong I'll change them to require the documents to be loaded(unfortunately, if you ask me).
The xml:id spec says: A violation of the constraints in this specification results in an xml:id error. Such errors are not fatal, but should be reported by the xml:id processor. In the interest of interoperability, it is strongly recommended that xml:id errors not be silently ignored. The data model spec, for construction of an XDM document from an Infoset or PSVI says: If an error is encountered during xml:id processing, an implementation may raise a dynamic error. So doc() may or may not fail if there are xml:id errors: it's implementation-defined (or -dependent).
Yes, that makes sense, sorry for the noise. Hopefully I've moved CVS in the correct direction now by adding alternative baselines to doc-available-3, doc-available-4, fn-doc-30 and fn-doc-31 such that doc-available()/doc() are allowed to either accept or flag documents that contains xml:id errors.
Thanks.