W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > October 2004

datatypes + in-line plain literals

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Wed, 27 Oct 2004 10:48:26 +0100
Message-ID: <417F6EEA.3060403@hplb.hpl.hp.com>
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
CC: Mark Birbeck <mark.birbeck@x-port.net>, "'public-rdf-in-xhtml task force''" <public-rdf-in-xhtml-tf@w3.org>


1) editorial (move/copy some stuff into section 4)
2) technical: qname vs URI for datatype
3) omitting content attr and using text() descendents?
4) using a special 'datatype' e.g. "plain" for plain literals,
    when combined with 3) allows inline plain literals, as some
    on call desired

1) editorial

A nice feature of the layout of RDF/A is that an implementor
tring to generate triples works exclusively from section 4, with the 
other sections as background.
So far the exceptions to this that I've seen are:
   a) 5.1.2 typed literals adds to the object rules of section 4.4
   b) the xpointer like bnode() scheme in section 5.2 also is
      relevant to such implementors. (I think this scheme is not
      a good idea)

2) qname vs URI for datatype

   In 5.1.2 the datatype attribute is shown with a qname value 
"xsd:integer". I quite like this, but ... an issue is that there are 
likely to be datatypes whose URIs cannot be represented as qnames, and 
for which the two readings of a qname differ (the RDF community's 
reading as an abbreviation for a URIref, and the XML community's reading 
as a local name in a namespace identified by the prefix).

The problem comes from the XML Schema WG's draft
XML Schema: Component Designators

which allows simple types to be referred to using an xpointer scheme


Because these do not end in an NCChar, they cannot be abbreviated as the 
concantenation of two NCNames and hence cannot be abbreviated using the 
RDF convention.

My vote would be to ignore this problem.

3) Typed literals and in-line content

In section 5.1.2

<meta about="http://example.org/foo" property="ex:bar" content="10" 
datatype="xsd:integer" />

The example has a @content attribute for the lexical form.
I suggest that if the @content attribute is omitted then the 
concatenation of all descendent text nodes could be used. So that the 
same triple can be represented as:
<meta about="http://example.org/foo" property="ex:bar" 
datatype="xsd:integer" >10</meta>
<meta about="http://example.org/foo" property="ex:bar" 
datatype="xsd:integer" ><span>10</span></meta>

<meta about="http://example.org/foo" property="ex:bar" 
datatype="xsd:integer" ><b>1<em>0</em></b></meta>

4) Plain literals and in line content

Some participants on Friday (not myself) desired the ability to have 
plain literals as in-line content. Somewhat naff-ly we could have a 
special value of the @datatype attribute e.g. "plain" or "none" that 
indicated a plain literal object. In the absence of a @content then the 
approach taken in 3) above could be used. (Except xml:lang is taken into 
account when forming plain literals)

Received on Wednesday, 27 October 2004 09:49:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:59 GMT