Wolfgang Hoschek pointed out an inconsistency in how XOM tests xml:id values which I've now traced to an apparent discrepancy between the current xml:id test suite and the xml:id spec, and I was hoping somebody could explain this to me. Section 4 of xml:id states: An xml:id processor must assure that the following constraints hold for all xml:id attributes: * The normalized value of the attribute is an NCName according to the Namespaces in XML Recommendation which has the same version as the document in which this attribute occurs (NCName for XML 1.0, or NCName for XML 1.1). However the very first test case normal_001 uses a non-NCName and apparently expects this test to pass: <doc> <para xml:id=" te st ">MATCH</para> </doc> In the catalog this is listed as <test-case category="normalize" id="normal_001"> <file-path>tests</file-path> <creator>Norman Walsh</creator> <date>2005-01-25</date> <purpose>Check ID normalization</purpose> <spec-citation place="4" type="section" version="1.0" spec="xml:id"/> − <scenario operation="standard"> <input-file>001_normalize.xml</input-file> <id>te st</id> <result>xml:id on para is an ID (te st)</result> <notes>XSLT cannot perform this test.</notes> </scenario> </test-case> However a probably older version of the catalog I find laying around on my hard drive lists this as an error condition. i.e. the value of the operation attribute of the scenario element is error, not standard. Can anyone shed some light on this? What is supposed to happen here? Is the test suite wrong or the spec? Or are they consistent in a way I'm not seeing? -- Elliotte Rusty Harold [hidden email] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim |
> Section 4 of xml:id states: > > An xml:id processor must assure that the following > constraints hold for > all xml:id attributes: > > * The normalized value of the attribute is an NCName > according to > the Namespaces in XML Recommendation which has the same > version as the > document in which this attribute occurs (NCName for XML 1.0, > or NCName > for XML 1.1). > And it then says: An xml:id error occurs for any xml:id attribute that does not satisfy the constraints. Having earlier said: [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.] Section 6 further 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. So: it's clear as mud. The processor must "assure that" (assure whom?) the value is an NCName, and it mustn't fail if it isn't. Michael Kay |
In reply to this post by Elliotte Harold
On Mon, Mar 20, 2006 at 10:45:58AM -0500, Elliotte Harold wrote: > > Wolfgang Hoschek pointed out an inconsistency in how XOM tests xml:id > values which I've now traced to an apparent discrepancy between the > current xml:id test suite and the xml:id spec, and I was hoping somebody > could explain this to me. > > Section 4 of xml:id states: > > An xml:id processor must assure that the following constraints hold for > all xml:id attributes: > > * The normalized value of the attribute is an NCName according to > the Namespaces in XML Recommendation which has the same version as the > document in which this attribute occurs (NCName for XML 1.0, or NCName > for XML 1.1). > > However the very first test case normal_001 uses a non-NCName and > apparently expects this test to pass: > > <doc> > <para xml:id=" te st ">MATCH</para> > </doc> xmllint raises an error about it: paphio:~/XML -> xmllint --noout id_err3.xml id_err3.xml:2: validity error : xml:id : attribute value te st is not an NCName <para xml:id=" te st ">MATCH</para> ^ paphio:~/XML -> > However a probably older version of the catalog I find laying around on > my hard drive lists this as an error condition. i.e. the value of the > operation attribute of the scenario element is error, not standard. that's my recollection too. > Can anyone shed some light on this? What is supposed to happen here? Is > the test suite wrong or the spec? Or are they consistent in a way I'm > not seeing? I tend to think that's an error. Moreover libxml2 does not register an ID in that case, XPath can't find one. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [hidden email] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |
In reply to this post by Michael Kay
On Mon, Mar 20, 2006 at 03:59:49PM -0000, Michael Kay wrote: > So: it's clear as mud. The processor must "assure that" (assure whom?) the > value is an NCName, and it mustn't fail if it isn't. There is no fatal error in xml:id, a fatal error would mean stopping any processing of the XML resource. Failure can only result in reporting the error and not registering the ID. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [hidden email] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |
In reply to this post by Elliotte Harold
Michael Kay wrote: > 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. > > > So: it's clear as mud. The processor must "assure that" (assure whom?) the > value is an NCName, and it mustn't fail if it isn't. > Yes, this sort of non-fatal error is an especial pain for XOM because it has no non-fatal errors. The only thing it does to report an error is throw an exception. There's no ErrorHandler as in SAX, nor does XOM have any other means of talking to the end user. -- Elliotte Rusty Harold [hidden email] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim |
In reply to this post by Daniel Veillard
Daniel Veillard wrote: > On Mon, Mar 20, 2006 at 03:59:49PM -0000, Michael Kay wrote: >> So: it's clear as mud. The processor must "assure that" (assure whom?) the >> value is an NCName, and it mustn't fail if it isn't. > > There is no fatal error in xml:id, a fatal error would mean stopping > any processing of the XML resource. Failure can only result in reporting > the error and not registering the ID. > Even so the test suite suggests the ID should be registered. That still feels like a mistake. -- Elliotte Rusty Harold [hidden email] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim |
On Mon, Mar 20, 2006 at 11:19:04AM -0500, Elliotte Harold wrote: > Daniel Veillard wrote: > >On Mon, Mar 20, 2006 at 03:59:49PM -0000, Michael Kay wrote: > >>So: it's clear as mud. The processor must "assure that" (assure whom?) the > >>value is an NCName, and it mustn't fail if it isn't. > > > > There is no fatal error in xml:id, a fatal error would mean stopping > >any processing of the XML resource. Failure can only result in reporting > >the error and not registering the ID. > > > > Even so the test suite suggests the ID should be registered. That still > feels like a mistake. yeah, sure, I agree with that. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [hidden email] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |
In reply to this post by Elliotte Harold
Elliotte Harold scripsit: > Yes, this sort of non-fatal error is an especial pain for XOM because > it has no non-fatal errors. The only thing it does to report an error > is throw an exception. There's no ErrorHandler as in SAX, nor does > XOM have any other means of talking to the end user. If xml:id errors were marked "fatal", then *every* implementation would have to treat them as fatal. However, there is nothing stopping XOM from (a) treating the errors as fatal in every case, or (b) providing a switch the user can set to "Ignore xml:id errors" or "Treat xml:id errors as fatal", or (c) providing a hook such that elements with xml:id errors are passed to the hook, or .... -- Samuel Johnson on playing the violin: John Cowan "Difficult do you call it, Sir? [hidden email] I wish it were impossible." http://www.ccil.org/~cowan |
In reply to this post by Elliotte Harold
> Even so the test suite suggests the ID should be registered. I'm not sure what you mean by "registered". If you mean recognised as an ID and normalised as one, then yes. This is (by design) the same as for an ID attribute declared in a DTD: validity does not affect normalisation or type assignment. -- Richard |
On Tue, Mar 21, 2006 at 11:40:21PM +0000, Richard Tobin wrote: > > > Even so the test suite suggests the ID should be registered. > > I'm not sure what you mean by "registered". If you mean recognised as > an ID and normalised as one, then yes. This is (by design) the same > as for an ID attribute declared in a DTD: validity does not affect > normalisation or type assignment. And that's how we end up with software expecting id('1234') or id('foo bar') to work in XPath. I still think it's a disaster to let this go though while we had the opportunity to block it and force the cleanup for xml:id Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [hidden email] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |
In reply to this post by Elliotte Harold
> > I'm not sure what you mean by "registered". If you mean recognised as > > an ID and normalised as one, then yes. This is (by design) the same > > as for an ID attribute declared in a DTD: validity does not affect > > normalisation or type assignment. > And that's how we end up with software expecting id('1234') or > id('foo bar') to work in XPath. I still think it's a disaster to > let this go though while we had the opportunity to block it and > force the cleanup for xml:id If it had been changed, it would have been the only case where the type of an attribute depended on its value. -- Richard |
In reply to this post by Richard Tobin-2
I should have also said: the test suite doesn't indicate whether the document has xml:id errors. It just tests whether the correct infoset is produced. -- Richard |
Free forum by Nabble | Edit this page |