[
Lists Home |
Date Index |
Thread Index
]
On Friday, Dec 19, 2003, at 19:52 Europe/Berlin, Eric van der Vlist
wrote:
> ...
> Maybe we should also be clear about what's wrong about using QNames.
yes, it would help if specification writers and implementors recognized
the requirements which the namespaces recommendation established for
document parsers and processors.
>
> For me, it's not that much the use a prefixes which is wrong but the
> fact that they rely on a definition which is part of the markup.
>
> In other words, I think that this is wrong:
>
> <foo xmlns:bar="http://example.com/bar";>bar:baz</foo>
>
> But if an application wants to allow things such as:
>
> <foo prfx="bar http://example.com/bar";>bar:baz</foo>
>
> I don't see any reason to object. That may not be optimal, but that
> doesn't violate any hard rule.
both forms would lead to problems in a mutable document model.
the problem, as apparent from the working draft days, is that the
encoding is no longer referentially transparent. in general, the
problem also applies to attribute mapping and enabling architectures,
but in those cases the extent of the bindings which inform the mappings
are more consciously the responsibility of the application and/or the
subsequent processing, which is no surprise, since the later stage
establishes the, with the consequence that those phases don't try to do
things which are nonsensical. somehow the community expected lexically
scoped prefix bindings would behave the same way. they don't.
they can be relied upon to have dynamic extent only. to expect, allow,
or specify more is an architectural error. has been and will remain so.
given which, perhaps one could stop fretting about how evil qnames are
and specify systems which behave correctly given qnames' inherent
nature.
...
|
