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

Re: Comments on http://www.w3.org/TR/2004/WD-xml-id-20040407/

From: Daniel Veillard <veillard@redhat.com>
Date: Fri, 9 Apr 2004 12:30:48 -0400
To: Eric van der Vlist <vdv@dyomedea.com>
Cc: public-xml-id@w3.org
Message-ID: <20040409163048.GG1642@redhat.com>

> Hi,

  Hi Eric,

> I have few comments on this WD which I think is meeting a real need.
>       * I think that you should add a definition in your Terminology
>         section stating that unless otherwise qualified, the word
>         "processor" means a XML processor compliant to the xml:id
>         specification (otherwise, people can read that spec as a
>         modification of the XML rec.).

  Good point. For the conformance section 5 we used the term "application"
to avoid any risk of confusion there, but apparently we need to watch 
uses of "processor" too.

>       * You make a reference to XML 1.0 but do not mention XML 1.1. It
>         might be a good idea to mention if it applies to XML 1.1 as well
>         (I don't why it couldn't)

  Hum, right, this should work as well with 1.1

>       * (#id-strictness) I really don't like the idea of non validating
>         parsers having to report errors when a XML document is well
>         formed but the xml:id is mis-used. I'd prefer that you say that
>         non validating parsers may report errors and add a comment
>         suggesting that they add properties to switch this error
>         reporting on and off.

  The problem is that we want as much as possible the xml:id processor 
to report case where using a validating or a non-validating processor
would give different result. This is an extra layer (at least logically)
on top of the processor and if that layer can detect misuse shouldn't it
report them.

  Section 4.3 states:

    "A processor that does neither DTD nor XML Schema validation must
     report xml:id attributes..."

i.e. recognized xml:is must be reported by the processor. But 

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

it's a should so I think the spec already provide some flexibility about
not reporting xml:id problems. Is there a specific part you looked at which
you think contradicts with section 4.3 ?

>       * The fact that xml:id relies on the XML infoset restricts its
>         scope to XML documents that are conform to namespaces in XML. Is
>         that really needed? xml:space and xml:lang on one hand and DTD
>         IDs on the other hand work for any XML document, why couldn't it
>         be the case for xml:id?

   Well, defining the xml:id processing behaviour is far easier to do based
on the XML infoset which is really the best specification to use to
describe the transformation of an xml:id (post-)processor.

  I don't see anything preventing processors not based on the XML infoset
from implementing xml:id but based on their own mechanism to reflect
IDness of an attribute, and in such a context documents for which the 
XML infoset is not defined could still be processed. I actually expect
my own implementation to work that way.


Daniel Veillard      | Red Hat Network https://rhn.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 Friday, 9 April 2004 12:31:17 UTC

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