Re: xml:lang and XML infoset: two new datatypes

Patrick Stickler wrote:

> I've tried to make the following point before, and will try again.
> 
> The datatype of a literal is disjunct from any xml:lang 
> attribution, and a literal can be specified for both. E.g.
> 
>    xsd:string"This string is not a valid token."-en
>    xsd:token"moi"-fi


Language-tagged strings in RDF are not subtypes of xsd:strings, and 
aren't subtypes of xsd:tokens either. Is that what you are claiming? In 
mathematical terms, there is no total injective function from 
language-tagged strings to xsd:string...

 
> Thus, it is not always the case that the datatype for language
> qualified literals is xsd:string. It may be some subtype of
> xsd:string or other string type, and the specific datatype
> is of course significant.


No, it cannot be a subtype of string. It can only be a derived type 
defined over a cross-product xsd:string x xsd:string.


> And although the xml:lang does not affect the L2V mapping
> and is ignored by the datatyping machinery, it still is
> relevant to applications.


Of course, therefore language-tagged strings should be a separate 
datatype. I don't see any utility of making the language attribution 
orthogonal to datatyping.

Sergey

 
> It must then be possible to specify both datatype and
> xml:lang for a given literal.
> 
> Patrick
>    
> Patrick
> 
> _____________Original message ____________
> Subject:	xml:lang and XML infoset: two new datatypes
> Sender:	ext Sergey Melnik <melnik@db.stanford.edu>
> Date:		Sat, 21 Sep 2002 11:46:25 +0300
> 
> 
> I'm suggesting to treat strings with xml:lang specifiers as a new 
> datatype (call it "language-tagged string"), disjoint with xsd:string. 
> Similarly, XML infosets should simply be yet another datatype, disjoint 
> with any other XSD datatype.
> 
> These two datatypes were essentially defined as such in the original RDF 
> spec. Now that we have a general-purpose datatyping mechanism, we can 
> make use of it. The two datatypes should get their own URIs.
> 
> If there is enough support for that, I'd like to put the above point for 
> vote at the next telecon.
> 
> The current proposal for representing typed values in the abstract 
> syntax (URI + string) fails for the above datatypes. Therefore, I'm also 
> suggesting that this overspecification is not required. In the abstract 
> syntax, typed literals may be kept as opaque constants, whereas the 
> applications may use their internal representation of choice.
> 
> Sergey
> 
> 
> 
>

Received on Monday, 23 September 2002 11:33:19 UTC