RE: Finding News Taxonomies [was: RE: Towards a TAG consideration of CURIEs]

> From: John Cowan [mailto:cowan@ccil.org] 
> 
> Booth, David (HP Software - Boston) scripsit:
> 
> > I'm confused by your point #3 below, as it seems to be 
> > implying that a document without a DTD could legitimately 
> > have an attribute of type ID with value "123456", and 
> > after looking at the specs I don't see how it
> > can.  Did I miss something?  
> 
> An xml:id processor will report a constraint violation when it sees
> "xml:id='123456'" in an element, but it will perform ID type 
> assignment anyway, as noted in Section 4 of the xml:id Recommendation.

Oh yes, now I see:
http://www.w3.org/TR/xml-id/#processing
[[
The xml:id processor performs ID type assignment on all xml:id
attributes, even those that do not satisfy the constraints.
]]

> 
> In addition, a conformant XML processor must report an 
> attribute declared
> to be of type ID as having that type, no matter what the value may be.
> For example, the document:
> 
>         <!DOCTYPE items [
>                 <!ATTLIST item id ID #IMPLIED>
>                 ]>
>         <items>
>                 <item id="123456">...</item>
>                 ...
>         </items>
> 
> is not valid, but the id attribute of the item element is of type ID.
> So you can use either xml:id or a (possibly partial) DTD to force
> an attribute to be of type ID, and ignore any xml:id or 
> validation errors.

And I see that a processor SHOULD report those errors:
http://www.w3.org/TR/xml-id/#errors
[[
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.
]]

I guess an approach that depends on routinely ignoring xml:id processing
errors and not validating the XML does not seem to me like a wise design
choice, because it severely limits future processing options, and a key
consideration in any standardization effort should be the facilitation
of future processing that may be slightly different than it is today.

David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software 

Received on Wednesday, 11 April 2007 21:00:20 UTC