- 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