[
Lists Home |
Date Index |
Thread Index
]
> From: amyzing@talsever.com [mailto:amyzing@talsever.com]
<snip/>
> This is primarily a problem because it crosses
> boundaries; the
> application normally doesn't expect to have to maintain a stack for
> namespaces--the parser does that. When attributes or elements contain
> structural (even, arguably, lexical) constructs, then the application
> needs access to the internal state of the parser. I think this is not
> good.
I don't get this argument. It seems this could just as easily be used not
simply against QNames in content, but against xml:base, xml:lang, and
xml:space, to name a few other constructs. I think doing any meaningful
processing of content will almost always require some awareness of context.
You need to know what element or attribute you are in, which means you need
access to the "internal state of the parser". The only different with
namespaces in content is that current APIs do not provide access to the
necessary state information, so applications are forced to maintain it
themselves. This is a weakness of the APIs, not an indictment of the use of
QNames. You don't reformulate XML specs to adhere to flawed APIs; you fix
the APIs.
Quite apart from that, just as there is no generic way to "tell whether
QNames are used in values", there is also no generic way to know if an
application needs to know the xml:base, xml:lang, or xml:space that is in
scope to interpret a value, so I don't see how QNames are fundamentally
different in this regard. For instance, xml:base is only going to be
relevant in interpreting URI references. So what generic mechanism is there
for recognizing that an attribute value or element content is intended to be
a URI reference so that an application knows whether it must retain
information for xml:base attributes to know what base URI is in scope?
|
