hmm..., i agree, but for a different reason. in some respects, it's not broad enough.
what happens, for example when/if xpointers come to pass. an xpointer library
(that is, an "application") will need to identify elements and attributes on
the basis of universal identifiers. that is, there are attribute value
domains, other than names, components of which (eg
"http://abcd.html|child(1,my:element)") will be interpreted in (or as if they
were in) the dynamic scope of the prefix bindings.
which means that, while the "decoder" cannot make this decision on a syntactic
basis, it must realise a machanism which among other things, takes the
encoding for an universal name and transforms it - whether based on syntactic
rules or upon request - into an universal identifer. [one should changed to
must :-]
note please, that i use the term "decoder" here, since if i were to use
"parser" i would mean something else than most people on the list would expect
it to mean.
>
> [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.
as noted above, syntax would not be sufficient. in any case, a name encoded as
a string must, at some point, become a universal identifier. it makes no sense
to delay this operation, since, as a prefix binding is valid during the
dynamic context of the document parse only, the intended result will never
change. once the transformation has been performed it makes no sense to expose
the internals of an identifier. which means anywhere outside of the
en/decoding layer.
which means that, by the time the "processing" part of an xschema processor
gets its hands on the namespace element, all the symbols should already have
been interned, the prefix attribute has no meaning and can be ignored, and the
element's is strictly documentary.
a declarative means to control this mechanism would be nice. i don't know what
it would be.
in particular, with regard to xpointers, i've taken to interning element
attribute values during element initialization. which happens in the
document's dynamic context and thereby permits one to intern constituent names
with respect to the correct prefix bindings.
it's not a general solution, since this is controlled in class declarations
specific to the implementation language and i don't see how one would declare
this in a dtd.