Cart
[Home] [By Thread] [By Date] [Recent Entries]
[sorry if this is a re-send] Michael Brennan wrote: > I still think it doesn't make sense to have one mechanism for attribute > values and another for element and attribute names. I think > consistency for > this is going to be less complicated and less confusing than having one > mechanism for element and attribute names, and another for values. I completely disagree. As Mike Kay pointed out, there's no way for an XML processor to tell whether QNames are used in values. Consequently, all scope information, i.e. exactly where every xmlns declaration is and what prefix it uses, must always be passed to the application, regardless of whether it's needed or not. It's hard to believe that this was ever the intent of the XML Names recommendation. This practice blurs the distinction between the XML processor and the XML application, forcing the processor to pass a bunch of redundant information to the application when that information is only actually needed a fraction of the time. If each layer had its own namespace declaration mechanism (one for element/attribute names, and one for application-specific content), then it would always be possible to throw away scope information as purely lexical detail. The point of a namespace declaration is to enable the resolution of QNames. Currently, it is forced to do a lot more than that. I think there are still many people in the XML world (including members of W3C working groups) who happily use namespaces and who are oblivious to the fact that other specs are forcing [in-scope namespaces] on XML applications everywhere. These people are in for a harsh wake-up call. I could easily be persuaded that we have to stick with the status quo, that it will cause more damage to remove the knife than to leave it in. But I don't anticipate being convinced that inflicting the wound was the right thing to do in the first place. Evan
|
