Minimal RDDL [NamespaceDocument-8]

I have an action item, working with Paul Cotton, to produce a draft of 
RDDL based on the discussion we've had around the TAG.  I reviewed the 
input, talked to Paul, and co-author Jonathan Borden, and got to

Here's how.  The original RDDL draft from Borden and me was XHTML plus a 
new element <rddl:resource> with a bunch of ordinary attributes like 
title and description, plus two special ones "nature" (namespace name or 
mime type) and "purpose" (what you want to use this for).  Both nature 
and purpose were going to be URIs; RDDL was going to provide a bunch of 
useful pre-cooked purposes.

People coming from the Semantic Web direction (including co-author 
Jonathan Borden) argued in favor of several different RDF 
representations, but they all had significant overhead, and furthermore 
IMHO failed to achieve their semantic-web objective while simultaneously 
making RDDL uglier less useful in terms of its original goal.  I just 
don't think the community will buy into any of those alternatives.

Next, Sandro Hawke suggested just using the existing <xhtml:a> element, 
which has little-used attributes rel= and type= which fit pretty well 
perfectly onto "nature" and "purpose".  See  Turns 
out there are two problems with this.  First of all, how do you know 
that some particular <html:a> is pointing to related-resources, rather 
than just being a human-oriented hyperlink right there in the text? 
Second, it turns out that rel= and type= come preloaded with a bunch of 
fuzzy semantics,  I've appended a private email from Sandro.  Having 
read it, it seemed likely impossible to cleanly reuse rel= and type=.

So, in conclusion, the above is a RDDL proposal using <html:a> elements, 
  not trying to re-use the "rel" and "rev" attributes, but rather 
introducing just two new attributes, rddl:nature and rddl:purpose.  The 
<html:a> element has tons of other useful attributes like "title" and 
"longdesc" and so on already, people can use those if they want to and 
occasionally browsers will even do something useful with them.

Bear in mind that *all* these RDDL proposals are more or less isomorphic 
in that you could turn pretty well any of them into pretty well any of 
the others with an XSLT script.  -Tim

Sandro's note ==============================================

 >> 1. The TAG seems to have consensus that we should move forward toward
 >> something to fill the RDDL hole, and I have part of the job of producing
 >> a first-cut WD.  I would like to base it on your suggestion using the
 >> existing attributes of <html:a (described at
 >>, just
 >> because it seems like the simplest possible way to proceed.  Someone
 >> piped up and said that your proposal was invalid per some HTML rule or
 >> another but I never took the trouble to figure out whether this was
 >> right or not.  Is there a problem and does your proposal need
 >> modification to work around this?

I discussed the problem in a followup [1] and then offered an amended
proposal [2] which should be valid in all HTMLs.  It's a vaguely
unpleasant situation with XHTML 1.1.  The document linked in [2]
contains the amended rddl challenge text, or see [3].  One could also
do the imports using LINK in the HEAD, I suppose, if one wanted them
to be invisible.

 >> Also, another question... does the profile= attribute in the <html:head
 >> element mean that for all <html:a attributes, the rel= and type= have
 >> the RDDL semantics?  Or is there a case to be made for some other
 >> syntactic mechanism to distinguish <html:a's which are RDDL pointers as
 >> opposed to generic links?

I think profiles allow you to define additional link types (values for
rel=), but not change existing ones [4].  I'm thinking these RDDL
semantics for type are the same as the existing semantics (a hint as
to what Content-Type you'll get if you do a GET), so there's no issue
there.   This kind of relies on the TAG view that Content-Type values
should be viewed as URIs.

It's hard to find an example of profile= which doesn't have Dan
Connolly's name on it.   :-)



Received on Friday, 14 February 2003 17:33:37 UTC