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

Some minor quibbles


> I think we have to admit that the lexical space for QName is context 
> dependent, for better or worse.

I'd say rather that the mapping from lexical to value space is
context-dependent.  We've already agreed that specifying that mapping
for each simple type is a goal for 1.1.


> My preferred resolution would be different than yours, I think.  I think 
> we should workb backwards from the validation rules, make clear that order 
> matters, and that in your example the decimal 10 is NOT in the value space 
> of the union.   So the value space of a union would be the values 
> corresponding to lexical forms that validate per the order sensitive rule. 
>  Thus, neither the value spaces nor the lexical spaces can be a union. 
> Actually, I think it's clear that the lexical spaces can't be a union, 
> since the form "10" would appear twice, which seems wrong to me.

That can't be right, since the following is allowed, given a
definition of my:u as union(xs:string,xs:decimal) and foo declared to
have my:u as its type:

<foo xsi:type="xs:decimal">10</foo>

I agree that this just makes the interpretation of "Each value in the
value space of a datatype is denoted by one or more literals in its
*lexical space*" even more unclear. . .

  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2002, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail:
 [mail really from me _always_ has this .sig -- mail without it is forged spam]

Received on Friday, 16 August 2002 06:13:53 UTC