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

On complexity

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Fri, 29 Oct 2004 15:59:20 +0100
Message-ID: <41825AC8.6040409@hplb.hpl.hp.com>
To: public-rdf-in-xhtml-tf <public-rdf-in-xhtml-tf@w3.org>

I've now finished a faithful implementation of RDF/A (except #bnode() 
Xpointer scheme).

My key worry is the complexity of resolving resouce objects (for @rel 
and @rev properties).

A number of debatable design decisions all come together badly at this 
point. For each of the individual decisions I don't think there is an 
overwhelming case against but when you put it all together it looks like 
much too clever by half.

subject resolution rules differ for <link> and <meta> from other elements.

If no subject is defined on element, and it is a link or meta, try parent.

If no subject is defined on element, and it is a link or meta, and no 
subject on parent, then generate-id() for parent to give bNodeID.

[That's a bit complicated for subjects but not too bad].

1) If no @href object for @rel or @rev then any child that has RDF/A 
attributes can provide an object, by using that child's subject.

For an element with  an @rel no @href a <link> child without a @id 
@about or @nodeID we get very strange behaviour.


<p rel="eg:prop">

generates nothing

<p rel="eg:prop">
     <link rel="eg:p2"/>


_:a eg:prop _:a .

<p rel="eg:prop">
     <a href="http://example.org"/>


_:a eg:prop _:b .
_:b hasReference <http://example.org> .

I think the complexity of the rules will lead to user confusion and 

Received on Friday, 29 October 2004 14:59:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:18 UTC