OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] Re: determining ID-ness in XML

># 1 is minimal-impact.  Can it be sold?  I.e., if you
> want the "name" attr to be an ID, then you need the following
> at the top of the file with a line for each element type
> that "name" can appear on:
> <!DOCTYPE rootType [
>  <!ATTLIST element1 name ID #IMPLIED>
>  <!ATTLIST element2 name ID #IMPLIED>
>  ... etc...
> ]>
> I'm not sure it's going to be easy to get the community to
> buy into this.

There are a couple of technical problems with this soluion:

a) Since it relies on XML 1.0 DTDs, it doesn't work properly with namespaces
b) Since it requires all the declarations up front, it doesn't work well 
for streaming output

> The namespace approach(es) have the huge advantage of making
> an important semantic aspect of XML documents self-
> documenting.  In fact, on the Web, I might argue that the
> lack of a clear self-documenting way of establishing the
> semantics of '#whatever' in a URI reference is a nearly
> fatal architectural flaw.

I completely agree this is a serious problem.

> Hm.... the one problem is that if you're dealing with XHTML
> or SVG, which already *have* ID elements defined normatively
> as part of the language, you have to say what happens when
> there's a conflict, e.g. suppose you have
> <html:div id="p3"> ... </div>
> <html:div xml:id="p3"> ... </div>

The problem that xml:id is not completely solving the problem, at least as 
I see it.  A complete solution would allow me to declare in the instance 
that such and such an attribute is an ID attribute, whereas xml:id only 
allows me to say what the ID of an element is.  Just as with default 
attributes, I can normalize my instance to add default attributes and get 
rid of the DTD dependency, so with ID attributes I ought to be able to 
apply some normalization process that makes the ID information in the DTD 
(or maybe schema) explicit in the instance. Overall xml:id is pretty 
intrusive, especially at this stage in the development of XML: it requires 
all the gazillions of existing XML vocabularies that wish to take advantage 
of DTD-less ID's to switch from whatever attribute name they are using at 
the moment to xml:id.  This can be mitigated to some extent by allowing 
both an ID attribute and an xml:id attribute simultaneously provided they 
have the same value.

An alternative would be to have an attribute that declares the name of the 
attribute that is an ID attribute, say xml:idatt. To make this useable, 
xml:idatt would be inherited.  In the typical case where all elements use 
the same attribute name for an ID, this means that a user has only to add 
something like xml:idatt="id" or xml:idatt="rdf:ID" to their root element 
and everything works. You would also need to allow xml:idatt="" to disable