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: Eric van der Vlist <vdv@dyomedea.com>
Date: Fri, 09 Apr 2004 18:50:21 +0200
To: veillard@redhat.com
Cc: public-xml-id@w3.org
Message-Id: <1081529421.15866.182.camel@delleric>

Hi Daniel,

On Fri, 2004-04-09 at 18:30, Daniel Veillard wrote:

> >       * (#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 ?

No, I was referring to this section.

I think that the distinction between well formness and validity is
really important in XML and I really like the fact that with libxml (an
other XML parsers) I can read any well formed document and switch
validation on only when I want.

To me, non respect of the xml:id spec cannot be considered as similar to
a well formness error (you can still understand the basic tree structure
of your document and build an infoset if the xml:id are wrong, and,
furthermore, the notion of well formness is normatively defined in the
XML recs) but more like a validity error.

That this might be clarified in the spec and I do hope that the parsers
will enable to switch this error reporting on and off.

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

That's probably more theoretical than a real world case, but as I read
it, making reference to the XML Infoset as the consequence that xml:id
can't be applied to that perfectly well formed XML document:

  <f:o:o xml:id="bar"/>

Or even that one:

  <my:foo xml:id="bar"/>

because strictly speaking, they don't have XML infosets!

Eric
-- 
If you have a XML document, you have its schema.
                                                  http://examplotron.org
Upcoming XML schema languages tutorial:
 - Amsterdam   -half day- (18/04/2004)        http://masl.to/?P220516D7
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
Received on Friday, 9 April 2004 12:50:25 UTC

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