[
Lists Home |
Date Index |
Thread Index
]
[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
|
