Re: WD-xpath-functions-20030502: casting xs:QName

On Monday, Oct 27, 2003, at 16:11 Europe/Berlin, Kay, Michael wrote:

> > > The terminology we are trying to use is "lexical QName" for the
> > > (prefix, local-name) pair, and "expanded QName" for the (uri,
> > > local-name) pair. I agree that we need to be very careful about the
> > > distinction and this isn't always true of the current drafts.
> >
> > please explain why, in the case of standards which are as central as
> > the further development of xml applications, it is appropriate to use
> > terminilogy which is bound to engeder confusion, instead of
> > terminology
> > which is inherently unambiguous.
> >
> Please explain why you think these terms are likely to engender 
> confusion.

see below.

>
> The term "lexical QName" to my mind creates the clear impression that 
> we are talking about values in the lexical space of the xs:QName data 
> type. The term "expanded QName" relates closely to the familiar term 
> "expanded name" which was used in XPath 1.0, and suggests the result 
> of expanding a lexical QName by replacing prefixes with the 
> corresponding URI.
>
> We have a problem in this area,

yes you do.

let us rephrase the above without "to my mind creates", "clear 
impression", "talking about", "relates closely", "familiar term" (the 
only standardized term to that point was "universal name"), and 
"suggests".

> The term "lexical QName" [refers to] values in the lexical space of 
> the xs:QName data type.

which is by definition. from which it follows that QName suffices.

> The term "expanded QName"[...] [refers to] the result of expanding a 
> lexical QName by replacing prefixes with the corresponding URI.

there is already a standard term for that. the term is universal name. 
the only reference to "expanded" was in the appendix. even then, it was 
used to modify "attribute name" or "element name", not QName.

>  because the Namespaces Rec and the Schema Rec use the word "QName" to 
> mean different things.

yes they do. i note that namespaces 1.1 could improve the situation by 
stipulating the correct use, but does not. (i know, that's not the spec 
for this list, but sometimes an independent implementor wonders if you 
folks ever talk to each other.)

in the problem domain there are two distinct abstract entities:
1. "qualified names" : these are represented as scalar values sequences 
which designate a pair of names which can be interpreted only in the 
context of bindings between one component of the respective pair, the 
prefix, and namespace names. that is the interpretation of the name is 
qualified by the bindings present in its lexical context. there is 
nothing in this definition about "creating a clear impression".
2. "universal names" : these are modeled as the combination of a uri 
and a local part. names which are designated by combinations of two 
respectively equal parts are identical. there is nothing in this which 
"suggests."

furthermore, in contrast to qualified names, lexical expressions for 
universal name are referentially transparent. that is, they are _not_ 
qualified. their semantics resists an attempt to associate them with a 
concept chain name + qualified + expanded. once a qname has been 
expanded it is no longer qualified. in the same sense one would resist 
an approach which required one to always work with --1 when performing 
algebra.

the schema specifications were wrong when the used that term the way 
they did. the passage of time has not made them right. they are still 
wrong now. look at your own explanation, above.

> We therefore decided to use an adjective that makes it clear which 
> kind of QName we are talking about.

to rephrase the original question "why does one want to use a term 
which requires an adjective, and harbors an internal contradiction, 
when there are other standard terms which do neither?" the question 
remains.

...

Received on Monday, 27 October 2003 13:10:12 UTC