W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2002

Re: RDF concepts

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 25 Oct 2002 11:18:43 +0300
Message-ID: <00d401c27bff$21c17a40$6a80720a@NOE.Nokia.com>
To: "ext Jeremy Carroll" <jjc@hpl.hp.com>, <w3c-rdfcore-wg@w3.org>

[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]

>     - lexical form is also a pair (string, language-identifier)
> - datatype mappings (see section 2.4.4) can be from string=>value or from 
> lexical form=>value
> I believe I have slightly overstepped the appropriate editorial freedom, and I 
> am prepared to backpeddle if the WG is unhappy with where I have gone.

Please begin vigorous backpeddaling ;-)

Lexical forms are *not* pairs. That deviates from XML Schema as well
as every datatype model I've ever encountered.

The lang tag is there as a scoping mechanism for selection/filtering
and does not participate in the datatyping interpretation. It is
a qualification of the literal, not of the lexical form.

I'm OK with the other changes.


Specific comments:

[I've not commented on text which reflects the above lexical form
as pair structure]

Section 2.4.3: The statement "Other datatypes are provided by XML Schema 
datatypes [XML-SCHEMA2]." while true is rather suggestive that the *only*
other datatypes are provided by XML Schema. It should be stated clearly
here that any datatype whatsoever which conforms to the minimum 
characteristics as defined in section 2.4.4 may be used, even those
which may not conform to XML Schema specifically.

Section 3.2: I think it is better to define the value space of XML
complex datatypes as the set of XML Infosets to which the lexical
forms (XML Serializations) correspond. Having the value space be
the set of canonical XML serializations is like mapping lexical
forms of xsd:integer to canonical lexical forms but not integer values.
Perhaps you mean infoset when you say document, but that's not clear.

Received on Friday, 25 October 2002 04:18:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:16 UTC