W3C home > Mailing lists > Public > www-tag@w3.org > January 2004

Re: RDDL2 Background

From: Eric van der Vlist <vdv@dyomedea.com>
Date: Wed, 28 Jan 2004 18:09:47 +0100
To: www-tag@w3.org
Message-Id: <1075309786.5522.616.camel@delleric>

On Wed, 2004-01-28 at 15:59, Jonathan Borden wrote:
> Eric van der Vlist wrote:

> >But this still doesn't let you define the source of the RDDL link
> >independently of XHTML links like that was possible in RDDL 1.0.
> >  
> >
> Correct. This is one of those 80/20  issues that would be great if we 
> could acheive a rough consensus on. I am just suggesting a possible 
> compromise.

Sorry to hear I stand on the 20% side :-( !

> >The real good thing about RDDL 1.0 is that <rddl:resource/> are
> >fragments that can have a meaning by themselves: they can embed a piece
> >of rich documentation about the resource that they describe and they can
> >be very useful for creating modular vocabularies.
> >  
> >
> That was the original reason to go with a new element rather than 
> overload <html:a>. In RDDL2, the new semantics are identified by the 
> attributes (rddl:nature, rddl:purpose) rather than by the element 
> (rddl:resource). In *practice* almost every <rddl:resource> has a child 
> <html:a>. Is there a problem with using a parent <html:div> to embed the 
> rich documentation about the resource (named using <div id="foo">) and 
> using <html:a> to identify links from that resource local to the 
> namespace and external related resources?

Seems like a miserable hack to me.

First, is not what a <a/> link has been designed to be.

Then, when the doc gets complex (and the documentation of a complex
namespace is likely to get complex), we have embedded <div/>s and it's
not obvious to me that in all the cases the link should refer to its
immediate <div/> parent rather than its <div/> grand parent or other

Also, for RDDL processors, that makes things much more complex to
process. Let's say I want to write a SAX parser to do that job, I'll
need to assume a priori that any <div/> start tag can potentially be the
source of a RDDL statement and won't be able to say that it hasn't been
the case before the end tag. 

Note that we may have to support situations such as:

   <a rddl.../>
  <a rddl.../>

Also, do we allow

  <a rddl/>
  <a rddl/>


If we allow them, the meaning doesn't seem obvious, if not, we have
introduced a risk of error.

I must say I still don't see the benefit of the new proposal.

RDDL's benefit is to allow to publish documentations that are as good
for humans as they are for programs. If we remove the ability to support
complex documents, that means that we will need to publish both an
extensive documentations for human and a RDDL one.

If that's the case, I'd rather drop RDDL and publish a XHTML document
for humans and a RDF one for computers.

The XHTML one will always be easier to write without RDDL and the RDF
one will always be easier to process by computers...

To me RDDL 1.0 is already a compromise between human and machine needs
and the new proposal is just breaking the balance.


> Jonathan
If you have a XML document, you have its schema.
Upcoming XML schema languages tutorial:
 - Santa Clara  -half day- (15/03/2004)        http://masl.to/?J24916E96
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
Received on Wednesday, 28 January 2004 12:10:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:03 UTC