[
Lists Home |
Date Index |
Thread Index
]
Jim Fuller writes:
> This example was attempting to say that local names, not just their
> values are meta data too; some sort of common local name
> analysis......
And I'm saying that I'm not willing to work with specs that going into
meta-meta-meta-meta. XML 1.0 left it to us to do the meta-work, and
namespaces added an extra layer which appears to be composed of endless
layers.
> What you are saying is that a world with no namespaced xml in
> general, is not a world that you want ? Which changes the focus from
> attributes ( and all the silly nuances ) to something more generic
> like namespaced xml versus no namespaced xml. Yes I'm slow on the
> uptake or maybe wrong......
No, I'm saying that Namespaces in XML is grossly underspecified for a
number of reasons, and that in practice we need to constrain how
namespaces are used if we have any interest in sharing documents which
use them.
> There may be perfectly valid reasons for generating a no namespaced
> element ( and/or attribute )...tried representing the intersection of
> many namespaced elements and attributes with no namespaced elements
> and attributes, for example.
XML without namespaces is fine. XML that mixes qualified and
unqualified is a horrible mash. I think I'd better make that clearer in
the piece. While I have no qualms about using namespace-unqualified
XML, I don't think it's something a document can be halfway about. Use
them or don't use them.
> The example is admittedly reaching, but in a real sense, no
> namespaced xml is out there ( in fact it may be useful to represent
> data this way )....and as I said I think its inane to start off with
> something like <test:jim hat="" test:hat=""/> but with a little
> imagination I can easily see it as a result of some complicated
> process that generically handles unknown elements and attributes.
I see it as the result of a process created by people who didn't know
enough about namespaces to avoid harming themselves or others.
> In your world of fully qualified namespace attributes and elements
> you would never have to change the spec, because you would never
> encounter the situation. Be it a defect or a design aspect, best
> practice takes care of the problem ( by using namespaces ), I see no
> need to change the spec until it is proven that 'it is broken'.
I think we've been around the namespaces specification long enough that
I can say without difficulty that the specification is in fact broken.
Tim Bray, one of the spec's editors and perpetual defenders,
acknowledged that "this is a design error in the namespace rec".
The question is whether best practices are enough to contain the mess.
My feeling is that they are not enough, but as the spec developers still
haven't acknowledged that these are problems worth fixing ("we're
probably stuck with it" -TB), this is the only approach that I have to
offer.
> We
> may lose a powerful idiom...without even knowing how to use it ! Or
> we may never use it and never miss it.
Sorry, but some idioms, especially in computing, are just dead ends.
This one's a cul-de-sac at best.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
