Non NCName IDs

[Elliotte Harold]

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

[Michael Kay]

> 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

[Daniel Veillard]

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/

[Daniel Veillard]

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/

[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

[Elliotte Harold]

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

[Daniel Veillard]

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/

[cowan]

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

[Richard Tobin-2]

> 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

[Daniel Veillard]

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/

[Richard Tobin-2]

> > 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

[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