Re: Options for dealing with IDs

On Tuesday, January 7, 2003, 7:59:52 PM, Elliotte wrote:

ERH> At 7:27 PM +0100 1/7/03, Chris Lilley wrote:

>>   3) Steal undeclared attributes of name id
>>   In well formed content that does not have a DTD, or that has a
>>   partial DTD used for decoration (declaring ID, declaring attribute
>>   defaults, etc) if an attribute is called id and has not been
>>   declared in the DTD, it is of type ID.

ERH> I'd like to suggest a slight variation of this, which goes along with 
ERH> something Tim Bray said in another message:

ERH> Steal undeclared attributes of name id (and ID). If an attribute is 
ERH> called id, whether or not it is declared in the DTD or schema, and 
ERH> whether or not it's type is DTD, it is treated as an ID for fragment 
ERH> identifiers.

Eew. So its an ID or not an ID depending on who asks? And would that
mean that an IDREF from inside the document and a fragment identifier
pointing to the same element from outside the document might give
different results?

ERH> However, no change is made to the attribute's type. All
ERH> parsers will continue to report the attribute's type as they 
ERH> currently do, whether that's CDATA, ID, 
ERH> my-namespace:social-security-number, etc.

ERH> This moves all the effort into the client application receiving data 
ERH> from the parser. It leaves XML 1.0 untouched.

That is an advantage?

ERH> Since XPointer is still open, that's easy to fix. DOM is the one that 
ERH> will have issues, but they aren't difficult.

That merely sidesteps the issue by giving a parallel and contradictory
declaration mechanism for one possible use of IDs, while leaving the
other uses of IDs stranded - not even as badly off as they are now, but
a little worse off.


-- 
 Chris                            mailto:chris@w3.org

Received on Tuesday, 7 January 2003 15:31:25 UTC