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.

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

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

3)
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.

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


e.g.

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

generates nothing

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

generates

_:a eg:prop _:a .

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

generates

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

I think the complexity of the rules will lead to user confusion and 
non-interoperability.

Jeremy
Received on Friday, 29 October 2004 14:59:47 GMT

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