RDDL proposal from Sandro Hawke

Let's just use the existing "rel" and "type" attributes on a-href
elements.  New values for rel are allowed if you specify an HTML
profile [1] detailing the syntax and semantics of new link types [2].
It seems to me that that rel corresponds exactly to both RDDL purpose
and RDF predicates, while type corresponds exactly to RDDL nature and
(URI-style) media type.

Here's the example:

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
  <head profile="http://www.w3.org/2002/12/RelRDF">
  <title>The "L" Namespace</title>
  </head><body>
  
  <h1>The Example-L Namespace</h1>
  
  <p>This document addresses the <a 
  href="http://lists.w3.org/Archives/Public/www-tag/2002Nov/0147">RDDL 
  Challenge</a></p>
  
  <p>If you are using the Example-L namespace, you may be interested in
    <a rel="http://www.rddl.org/purposes#validation" 
       type="http://relaxng.org/ns/structure/1.0"
       href="http://example.com/schemas/L.rng">a RelaxNG schema</a>
  and
    <a rel="http://www.rddl.org/purposes#render" 
       type="text/css"
       href="http://example.org/style/L.css">a very terse style sheet</a>
  </p>
  </body></html>
  
Which is also at http://www.w3.org/2002/12/RelRDF-extra/rddl-challenge

Pros:

   - valid in HTML and XHTML

   - in the spirit of HTML; existing HTML works for namespace
     documents, but without REL= values, the information
     will be a little vague.  (We're left with something like
     rdfs:seeAlso: an untyped link.)   (Missing TYPE= values just mean
     you need to use the web to find out the type, as usual.)

   - machine parsing (eg conversion to RDF triples) is fairly easy.
     (But that's probably true of all candidates.) 

   - can be served in parallel (via content negotiation) with an
     RDF/XML version giving the same information with more of it
     machine-readable.    (But that's also probably true of all
     candidates.) 

Cons:

   - too Simple and Obvious?   :-)

   - I decided to consider the "nature" information a media-type,
     because that's what it seems like to me.  This means we need to
     handle URIs for media-types, which I think the TAG supports
     anyway.   If someone can explain how nature is criticially
     different from media type, I have some ideas how to handle that.

   - raises some hard questions about httpRange-14 [4] and RDF
     identifiers.   Or is that a "Pro", since it forced me to solve
     them (to my own satisfaction at least!) [5].

Thoughts?

    -- sandro                      http://www.w3.org/People/Sandro/

[1] http://www.w3.org/TR/html401/struct/global.html#adef-profile
[2] http://www.w3.org/TR/html401/types.html#type-links
[4] http://www.w3.org/2001/tag/ilist#httpRange-14
[5] http://lists.w3.org/Archives/Public/www-rdf-interest/2002Dec/0125

Received on Tuesday, 24 December 2002 13:14:04 UTC