Cart
[Home] [By Thread] [By Date] [Recent Entries]
> I think that part of Gavin's point is that from an application writer's
> point of view, disambiguating the names is a tiny little part of the
> much harder problem of making applications where random namespaces
> appear together and "just work." If I add a Corel:P to my Office 2000
> document, Word isn't going to do anything useful with it. Getting Word
> to do something useful with invented tags is the really hard part.
Exactly. In addition, there are two other things:
1) There are any number of ways of associating processing with
an element, and I don't *need* namespaces for any of them.
2) Most applications don't have to handle "random namespaces" and
"just work".
> On the other hand, if I have solved the harder problems and am left only
> with the problem of disambiguating names, there is a simple, tried and
> true approach.
Yes. Again though, point (2) is important here.
At the end of the day, naming is *not* something you can control.
Languages evolve and cannot be controlled by any centralized
authority. The fallacy of a "single namespace" is roughly equivalent
to the fallacy of a "single dtd does everything".
Again, a document combined with it's XSL stylesheet obviates the
need for most namespace usages (the XSL stylesheet is the trusted
mediator that transforms a desire into action).
|
