- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Fri, 29 Oct 2004 15:59:20 +0100
- 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 UTC