- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Wed, 27 Oct 2004 10:48:26 +0100
- 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>
4 comments
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
http://www.w3.org/TR/2004/WD-xmlschema-ref-20040716/
XML Schema: Component Designators
which allows simple types to be referred to using an xpointer scheme
e.g.
schema-URI#xscd(/type(Items)/item/quantity/type())
schema-URI#xscd(/type(SKU))
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
http://www.formsplayer.com/notes/rdf-a.html#div358418640
<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>
or
<meta about="http://example.org/foo" property="ex:bar"
datatype="xsd:integer" ><span>10</span></meta>
or
<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)
Jeremy
Received on Wednesday, 27 October 2004 09:49:11 UTC