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

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

Elliotte Rusty Harold wrote:

> Then we can't fix it for them, and I also mean we can't fix it for
> them by using a processing instruction instead of an attribute either.

The point isn't that we can't fix it, it's that we don't break it.

> I'm willing to believe they can't update their DTD, but if they can't
> update their DTD I don't believe they can update their processing
> software to support a new PI either.

Perhaps not, but if a third party provides them with data that uses the PI
approach, in all likliehood, there will be no impact. They can't make use of the
PI? Fine - at least it's probably benign.

> The DTD is the simplest thing to change in this case.

We disagree on that point.

> In another thread you just wrote:
>
> 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
>
> Your points b and c apply equally to adding a processing instruction.
> The only thing PIs would give instead of an attribute is validity.
> The cost of the changing the software is the same with a PI or an
> attribute. The fear of problems that may arise when this new stuff
> gets dumped into the existing database is the same.

For b), there may not be any change required. If the software is using a DTD, the
users don't care what attribute was considered to be unique at some point in the
history of the document - they only care that it is valid now. For c), it may cause
them some angst to see the PI. (I'm not sure why they would be concerned, but it
does unquestionably change their documents.) Either way, the costs are not the same
- many processors currently ignore PIs, but none ignore or selectively handle
attributes in a way that would result in an equivalent impact.

I really don't understand why we're debating this from the perspective of the
impact on XML systems - if you said that xml:id was a more elegant design, or more
in keeping with the rest of XML or any one of a number of other reasons, you might
convince me that it's a better design. The idea that it will be easy to implement
and will therefore be universally accepted just seems flawed to me. If it's not
going to work for everyone (and the degree of difficulty is proportional to the
size of the implementation), it seems likely that it will end up being benched by
all but a few.

If the impact really was the same, then why wasn't an xml:stylesheet attribute
defined last time an extension was necessary? What will we do next time we need to
extend? Add another attribute? I'd prefer to see a less invasive approach taken
until version 2.0 came out, if that was ever to happen. A new version is the place
to put non-backward compatible changes. If we trade elegance for compatibility in
the interim, so be it.


--
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