> and yes, this is an aspect of the namespace proposal (if not xml as a whole)
> which i believe is dented, if not broken: name qualification should apply to
> all values which either are tokens or denote tokens (ie the various attribute
> values and notations). othrwise the whole thing becomes unworkable.
The fact is that the Namespace draft as it is (which is what we have
to work with) doesn't provide for parsers doing colon-ectomies on
attribute values. IMHO it shouldn't; there is no reason to think
a priori that an attribute value that happens to contain a colon
is necessarily a namespace-qualified name. If XML had retained
attributes of type NAME, there might have been some case for them,
but NMTOKENs are just too broad.
[many "should"s deleted]
> it's not messy, it's very simple. don't think strings. think symbols. it
> doesn't matter where they came from, or what prefix they had at the time they
> wre interned, just whether or not they're equal. once they've been parsed, you
> should only ever have too look at the prefix again if you should need to
> serialize. - that's why the parser needs to intern all values which can are,
> or which can denote, tokens.
But just which attribute values are those? Lisp has syntax to distinguish
symbols from strings, but we have only inference: therefore, general
parsers must assume that attribute values are strings.
-- John Cowan cowan@ccil.org e'osai ko sarji la lojban.