W3C home > Mailing lists > Public > public-xml-id@w3.org > November 2004

Re: 7. Suggested test for space normalisation

From: Daniel Veillard <veillard@redhat.com>
Date: Thu, 18 Nov 2004 17:42:49 -0500
To: Ian Hickson <ian@hixie.ch>
Cc: public-xml-id@w3.org
Message-ID: <20041118224249.GB16882@redhat.com>

On Thu, Nov 18, 2004 at 05:31:33PM -0500, Daniel Veillard wrote:
> 
> On Thu, Nov 18, 2004 at 03:08:46PM +0000, Ian Hickson wrote:
> > On Thu, 18 Nov 2004, Daniel Veillard wrote:
> > > On Thu, Nov 18, 2004 at 02:06:41PM +0000, Ian Hickson wrote:
> > > > 
> > > > Please ensure the test suite contains a test where the following:
> > > > 
> > > >    xml:id=" te  st "
> > > > 
> > > > ...is shown to cause its element to have ID "te st".
> > > 
> > > No, the result is not an NCName, this shoul;d not generate an ID.
> > 
> > That doesn't matter, see xml:id section 4 paragraph 10:
> > 
> > | The xml:id processor performs ID assignment on all xml:id attributes, 
> > | even those that do not satisfy the enumerated constraints.
> 
>   C..p ! I don't remember agreeing with that :-(
> I actually strongly disagree with this. I have seen enough XPointer/XSLT and
> C14N horrors due to the "lax" behaviour of XPath-1.0 IDs ! When you start
> doing digital signatures based on something which should have raised an
> error but that the software didn't even care to report, you're back to 
> the random processing mess we tried to avoid with XML-1.0 :-(

  Previous version
     http://www.w3.org/TR/2004/WD-xml-id-20040407/#non-validating-processor
-------------------
A processor that does neither DTD nor XML Schema validation must report xml:id attributes found in documents using [XML Information Set] properties, assuming the following condition:

    * The attribute value must be a valid NCName.
    * No other xml:id attribute with the same attribute value has been found earlier in the document.

If those conditions are not satisfied then the processor should report the error to the application.

If those conditions are satisfied then the processor must report the xml:id attribute ....
-------------------

  At least it did allow the xml:id processor to reject non NCName values
for xml:id i.e. not report them as ID ...
I think this is a strong regression of the spec.
I really want my implementation to not register as an ID
    <foo xml:id="123"/>
or
    <foo xml:id="te st"/>

  So that I have the right to generate an XPointer failure on a reference to
"#123" or "#te st". I agree too that "" should be banned as you reported in
another mail ! My justification is stronger than just hypertext linking,
it is about being able to be extremely strict when doing digital signatures
which is an area where no flexibility at the implementation level should be
an allowed behaviour.

Daniel
-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Received on Thursday, 18 November 2004 22:43:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:49 UTC