[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: repercussions

• To: xml-dev@l...
• Subject: Re: repercussions
• From: james anderson <james.anderson@s...>
• Date: Fri, 19 Dec 2003 20:39:38 +0100
• In-reply-to: <1071859947.30296.592.camel@delleric>

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.

...

• References:
  • Re: repercussions
    • From: Eric van der Vlist <vdv@d...>

• Prev by Date: RE: repercussions
• Next by Date: RE: repercussions
• Previous by thread: Re: repercussions
• Next by thread: Re: repercussions
• Index(es):
  • Date
  • Thread