W3C home > Mailing lists > Public > www-tag@w3.org > August 2003

Re: Which QName?

From: james anderson <james.anderson@setf.de>
Date: Sun, 17 Aug 2003 17:57:35 +0200
Cc: www-tag <www-tag@w3.org>
To: Robin Berjon <robin.berjon@expway.fr>
Message-Id: <84CB6C4C-D0CB-11D7-9068-000393BB8814@setf.de>


On Friday, Aug 15, 2003, at 15:23 Europe/Berlin, Robin Berjon wrote:

> ...
> The qnameAsId-18 states that "using the in-scope namespace bindings 
> has the advantage that it theoretically allows a generic processor to 
> interpret QNames in content without having to be aware of any 
> application-specific mechanisms".
>
> That, unfortunately, is very theoretical.

it may be insufficiently specified, but it is neither theoretical nor 
hypothetical. the namespaces recommendation specifies two scoping 
rules, those referred to below as the  "attributes rule" and the 
"element rule". there is no need for a decision as to which is the best 
option. each standard should specify which rule should apply -  if need 
be, in which context. then "parsers" should be expected to either apply 
the rules as specified by the caller, or delegate the resolution back 
to the application. there have been several xml-dev posts [1,2,3] to 
this point over the years. [2], in particular.

> There is dissent on which of the QName resolving rule applies to 
> QNames in content: for XML Schema's xs:QName, the "element rules" 
> apply so that no prefix means the default namespace applies; for XSLT, 
> the "attribute rules" apply, and no prefix means no namespace.
>
> I haven't found a document explaining which of those is the best 
> option, or even putting the emphasis on clearly defining which one is 
> to be chosen.
>

why does one mode need to be "the" mode?

> This has caused a certain amount of confusion in a number of 
> discussions here and there, notably the xml:id discussion that took 
> place here a few months back.

a useful contribution would be a collection of clear use-cases which 
purport to demonstrate that this issue cannot be readily resolved 
either directly in terms of the existing modes or in terms of some 
tractable combination of those modes.

...

[1] http://lists.xml.org/archives/xml-dev/199901/msg00532.html
[2]http://lists.xml.org/archives/xml-dev/200201/msg01867.html
[3]http://lists.xml.org/archives/xml-dev/200201/msg01924.html
Received on Sunday, 17 August 2003 11:58:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:00 UTC