Re: RDDL2 Background

After thinking about this for a few days, I can see both sides of these 
issues. RDDL1 has pros and cons, RDDL2 has pros and cons, and I think we 
can devise an acceptable solution with either. Let me explain:

Tim Bray wrote:

>
> I've been seeing the grumbling about RDDL2, and in fact it's kind of 
> unfair to ask people to react to it without a bit of the rationale 
> behind it.  So let me provide that.  I'll post a pointer to this 
> message to xml-dev too.
>
> Here's the original idea for RDDL: "We want a namespace document 
> that's human-readable (to explain what the namespace is all about) and 
> contains a machine-readable directory of related resources, like 
> schemas and stylesheets and renderers and so on.  We'll identify the 
> related resources by "Nature" (mime type or namespace name) and 
> "Purpose" an extensible list of things you might use them for.
>
> The community, including everyone from solo hackers to the Microsoft 
> Office group, reacted well to this premise, and Jonathan (mostly) and 
> I cooked up RDDL.  There were some problems with RDDL, though.
>
> 1. the "Nature" attribute was labeled role= and the "Purpose" 
> attribute was
>    labeled arcrole=; or maybe I have that backward, I never could 
> remember.
>    Reasonable people kept asking why nature wasn't called "nature" and 
> purpose
>    wasn't called "purpose".

As I recall, we started with "role" and "arcrole" and came up with 
"nature" and "purpose" as better names for these. Indeed it could be 
argued that XLink itself would be better off with these names ... on the 
other hand "href" makes no sense to me in isolation i.e. "arcrole" is no 
worse a name for "purpose" than "href" is for "resource pointed to".

> 2. If you read the semantics of the XLink spec, RDDL1 was arguably 
> abusing
>    them pretty severely.  XLink's design is highly optimized for 
> support of
>    human-facing apps, whereas the linkage in RDDL was designed from 
> the start
>    for machine-readability.  Also the choice of role= and arcrole= for 
> nature
>    and purpose was really hard to defend, you could have switched them 
> and
>    defended it just as easily

My approach to RDDL *semantics* is to define it via an XSLT to RDF -- 
i.e. I agree entirely with DanC on this issue. As far as I am concerned 
I can see an XSLT for RDDL1 *or* RDDL2 that would give identical RDF 
semantics.

> 3. RDDL1 also included a bunch of other stuff that was duplicated by 
> markup
>    already present in HTML, in which it was designed to be embedded.

Agreed. As it turns out almost every <rddl:resource> embeds an <a 
href="">. That is an empiric fact. Also many of the XLink attributes are 
#FIXED.

>
> So I cooked up RDDL2, which used the existing mechanisms in XHTML and 
> had a whole lot less markup, and I thought did a lot better job of 
> hitting the 80/20 point.
>
> The one thing it loses that RDDL1 gave you, as Eric points out, is the 
> ability to have a bunch of marked-up descriptive text *inside* your 
> related-resource link.  I'm having trouble getting upset about that, 
> since it seems that the marked-up text is aimed at humans, while the 
> nature/purpose link is aimed at machine-readability.  -Tim
>
I have a solution for this issue.

First, some people have asserted that a "problem" with RDDL is that it 
doesn't allow one to say anything about *names* in a namespace. This is 
untrue. In RDDL1, <rddl:resource id="foo"> allows one to "say something" 
about the "foo" name in the namespace being described. In RDDL2 one can say:

<a id="foo" rddl:nature="...">

and consequently say something about the "foo" name. On the other hand 
<rddl:resource id="foo"> allows embedded <rddl:resource> elements, 
allowing one to say *many things* about the "foo" name.

This is how we could do this in RDDL2:
(assume namespace = http://example.org/namespace#)
<div id="foo">
    <a rddl:nature="http://example.org/n1" 
rddl:purpose="http://example.org/p1" href="..."> ...</a>
    <a rddl:nature="http://example.org/n2" 
rddl:purpose="http://example.org/p2" href="..."> ... </a>
    <a rddl:nature="http://example.org/n3" 
rddl:purpose="http://example.org/p3" href="...">... </a>
</div>

which using the ancestor-or-self::*[@id] XSLT pattern could be used to 
create the following subject URU: <http://example.org/namespace#foo>.

This fits along the general practice of using id="foo" as a way of 
specifying what a fragment identifier identifies (in HTML)

Jonathan

Received on Friday, 23 January 2004 12:08:47 UTC