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

On Fri, Apr 09, 2004 at 06:50:21PM +0200, Eric van der Vlist wrote:
> 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.

  I don't see any conflict between the spec as written and the behaviour
you suggest. Sure those are "like" validity errors, they don't destroy the
Infoset passed, in the worse case you get an error message from the
xml:id layer and no addition to the Infoset.

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

  I think "should" carry the flexibility potential you ask for. Maybe
that can be changed as
   'should at the user option report the error to the application.'
though I prefer the idea that by default such error be reported.

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

  I think I understood your point. You're saying "xml:id can't be applied"
to such document and I'm answering ""xml:id is not defined" for it. That
doesn't mean it can't be applied. Trying to define xml:id without an Infoset
sounds a far more difficult than useful exercise since the semantic of xml:id
for such document can be derived from the semantic in the case of document
with an Infoset.
  Similary XInclude is not formerly defined when such a document is included.
I don't think that prevent implementations from working with them.

Daniel


-- 
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 17:53:02 UTC