[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: determining ID-ness in XML
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@a... ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|