Re: Comments on initial draft of xml:id

(note: distApp list included on this reply)

Elliotte Rusty Harold writes:

> "I'm not sure I agree with the statements "DTD authors should not 
> declare attributes other than xml:id as type ID for interoperability 
> with XML Schema- and non-validating processors. No interoperability 
> guarantees are provided in these cases." and "XML Schema authors 
> should not declare attributes other than xml:id as type xs:ID for 
> interoperability with DTD- and non-validating processors. No 
> interoperability guarantees are provided in these cases." There are 
> just too many existing applications that use ID, Id, and id as 
> ID-type attribute values. XHTML is one."

SOAP is another [1].

There are actually two things going on with SOAP that are worth 
distinguishing.  The name of the attribute in question is soapenc:id [1], 
not xml:id (making the obvious assumptions about prefix associations). 
This distinction is important, as SOAP can be used to encapsulate existing 
document fragments which may have their own uses for xml:id.  We do not 
want any suggestion that a soapenc:ref attribute might be resolved by an 
xml:id in such a fragment.  There are thus potentially two disjoint graphs 
being carried within the same envelope.

For exactly that reason I have always had some personal doubts about our 
XMLP decision to assign a 'type' of xs:ID, as we do.  Then again, the SOAP 
processing model makes clear that schema validation is never required 
anyway. 

Keep in mind that (interestingly enough) use of the xs:ID type itself 
implies no mandatory uniqueness constraint per the datatypes 
recommendation. [2] Uniqueness is enforced only when doing schema 
structures validation [3] (because, I believe, the datatypes rec has no 
notion of a document scope, and the structures recommendation does).  So, 
the xs:ID type assignment in the SOAP recommendation is more suggestive 
than anything else.  In fact, the uniqueness constraint and corresponding 
connection of soapenc:ref to soapenc:id are stated explicitly in the SOAP 
recommendation, and are independent of the type assignment[4].

Noah

[1] http://www.w3.org/TR/soap12-part2/#idattr
[2] http://www.w3.org/TR/xmlschema-2/#ID
[3] http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#cvc-id
[4] http://www.w3.org/TR/soap12-part2/#uniqueidconstraints

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------






Elliotte Rusty Harold <elharo@metalab.unc.edu>
Sent by: public-xml-id-request@w3.org
04/09/2004 08:31 AM

 
        To:     public-xml-id@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Comments on initial draft of xml:id



I'm not sure I agree with the statements "DTD authors should not 
declare attributes other than xml:id as type ID for interoperability 
with XML Schema- and non-validating processors. No interoperability 
guarantees are provided in these cases." and "XML Schema authors 
should not declare attributes other than xml:id as type xs:ID for 
interoperability with DTD- and non-validating processors. No 
interoperability guarantees are provided in these cases." There are 
just too many existing applications that use ID, Id, and id as 
ID-type attribute values. XHTML is one. Is there any way to just note 
the issue of interoperability, without making it as strong as a 
"should"?

Section 4.3 states, "If those conditions are not satisfied then the 
processor should report the error to the application.". Can this be 
made more clear about "error"? In particular is this is a fatal or 
non-fatal error?  Please, please don't let this be another of those 
annoying cases where some parsers go one way and some go another. I 
prefer this to be an explicitly non-fatal error, since that's more 
backwards compatible.

Section 4.3 also states, "The attribute value must be a valid 
NCName." I think this should be "The *normalized* attribute value 
must be a valid NCName."

-- 

   Elliotte Rusty Harold
   elharo@metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml 
   http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA

Received on Friday, 9 April 2004 16:16:35 UTC