QName is ambiguous; aren't datatypes unambiguous? union types total?

Consider:

<aDoc>
  <eltA xmlns:x="http://example/vocab1#"
    aQNameAttr="x:n"/>
  <eltB xmlns:x="http://example/vocab2#"
    aQNameAttr="x:n"/>
</aDoc>

Suppose we look at that document using
a schema that says aQNameAttr has
type QName (in both cases). According to

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#QName

there's a value from eltA; i.e. the pair
 (http://example/vocab1#, "n")
but the value from eltB is the pair
 (http://example/vocab2#, "n")

while their lexical forms are the same
in both cases: x:n.

I thought that a fundamental property of datatypes
was that they're unambiguous; i.e. for
any datatype, there's exactly one value that
corresponds to each item from the lexical space.
The designs that the RDF Core WG is considering
for using XML Schema datatypes in RDF depend
on this property.

But on careful review, I don't see that anywhere
in the spec. I see stuff like
"Each value in the value space of a datatype is denoted by one or more
literals in its ·lexical space·. "

But I don't see "each literal in the lexical
space of a datatype denotes exactly one value."
That should be in there somewhere, no?

I suggest that the lexical form of QNames
should be considered to include the relevant
namespace name; that'll make it unambiguous,
though it won't correspond exactly to
the attribute value.

QName is certainly a special case w.r.t.
using XML Schema datatypes in RDF.

Hmm... but I guess union datatypes are too.
On the other hand, union datatypes don't even
obey the "Each value in the value space of a datatype
is denoted by one or more literals in
its ·lexical space·. " constraint: the union
of (string, decimal) has the decimal 10
in its value space, but nothing in its
lexical space to denote it.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
see you in Montreal in August at Extreme Markup 2002?

Received on Friday, 2 August 2002 01:31:19 UTC