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

[Marcus Carr <mrc@allette.com.au>]

"Simon St.Laurent" wrote:

> No, I should have been clearer about that.  Documents using existing
> DTD-style ID attributes would continue to use their IDs.  I'd encourage
> developers creating new specs to use xml:id as it would work with or
> without DTD processing, but I wouldn't declare xml:id the ONLY way to
> mark an ID.

If XML was being designed now, I'd agree that the attribute approach is better.
The problem is that because of the limitation of one ID per element, your
solution doesn't provide a migration path for existing documents - owners can't
declare both attributes to allow both the new and old documents to be valid.

As the legacy set grows, so does the conversion required, if the DTD owner was to
decide to upgrade the DTD to allow xml:id. The result of this is that we end up
with a division between systems that use xml:id and those that don't. The schism
then becomes between DTDs that are _able_ to evolve to use xml:id and those that
are not - contrary to what has been suggested, that it is in fact a matter of
simple choice.

The example of a bank was used earlier - here are three reasons that they would
refuse to add the attribute to their DTD:

  a)  it invalidates all of my existing data

  b)  I will need to upgrade the software that [insert number here] people are
using

  c)  I have no easy way of guaging the impact on the transition into my backend
database

Using an attribute is not offering those people a choice. It's telling them that
it's their bad luck for starting their implementation before we'd designed the
tidier mechanism. On top of that, despite the fact that we will then have two
classes of documents, we don't have a mechanism that identifies whether the use
of xml:id attributes is compatible with the DTD. If the use of xml:id catches on,
the bank's system is left behind, despite the fact that they developed it in good
faith and in total accordance with XML v1.0.

It's too late to start invalidating implementations. We should to toe the line
and commit to compatible changes until v2.0 (should that ever come).


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein