[RDDL] Nature, Purpose (and XSLT)

[Leigh Dodds <ldodds@ingenta.com>]

The RDDL specification references several XSLT resources.
In each case their natures (xlink:role) are the 
XSLT NS-URI as expected. However there is some 
variation in how the purposes (xlink:arcrole) are defined.

Lets take a look at an example (XHTML stuff removed...)

<rddl:resource
           xlink:title="XSLT API"
           xlink:arcrole="http://www.rddl.org/purposes#implementation"
           xlink:role="http://www.w3.org/1999/XSL/Transform"
           xlink:href="rddlapi.xsl"
           >
...
</rddl:resource>

<rddl:resource
           xlink:title="XSLT Table View"
           xlink:arcrole="http://www.rddl.org/purposes#implementation"
           xlink:role="http://www.w3.org/1999/XSL/Transform"
           xlink:href="rddlview.xsl"
           >
...
</rddl:resource>

<rddl:resource
           xlink:title="RDDL2RSS"
           xlink:arcrole="http://www.rddl.org/purposes#RSS"
           xlink:role="http://www.w3.org/1999/XSL/Transform"
           xlink:href="rddl2rss.xsl"
           >
...
</rddl:resource>

The first two resources are XSLT stylesheets that generate two 
different HTML views of an RDDL document. The last generates 
an RSS view.

My question is: why are the purposes (arcroles) not the NS-URI of 
the output of the transformation?

e.g.

<rddl:resource
           xlink:title="RDDL2RSS"
           xlink:arcrole="http://www.purl.org/rss/1.0/"
           xlink:role="http://www.w3.org/1999/XSL/Transform"
           xlink:href="rddl2rss.xsl"
           >

I see no reason why a 'special' arcrole value should be defined for RSS.
I also think its sets a bad precedent: we may end up with all 
sorts of different values (e.g. http://www.foo.org/purposes#RSS , etc.)
which has obviously detrimental affects.

Can I suggest that the default case should be to use the NS-URI 
(or a URI that can be derived from the mimetype) of the output for
XSLT transforms?

The beneficial side effect to this is that we can use RDDL as a means 
to piece together transformation pipelines: presented with an XML 
document, and the ideal output for a transformation we can inspect 
its RDDL description and determine whether there is a direct transform 
available. If not we can traverse additional RDDL documents until we 
can piece together the appropriate pipeline.

(IOW, if we can't go directly from A->B we may discover that we can 
get from A->C and from C->B)

This seems like a useful side-effect to RDDL, but one that can't 
be realised if the arcroles aren't appropriately specified.

I do realise that the RDDL spec doesn't forbid this kind of usage, but 
neither does it encourage it, nor do the available examples demonstrate 
it.

[The "http://www.rddl.org/purposes#implementation" purpose is also 
very vague, but I'm not sure how to handle this appropriately. For 
example if I have a java library that will produce a custom DOM, and 
one that will (say) produce a Swing based editor, aren't 
these both "#implementation"s?]

Thoughts?

L.

-- 
Leigh Dodds, Systems Architect       | "Pluralitas non est ponenda
http://weblogs.userland.com/eclectic |    sine necessitate"
http://www.xml.com/pub/xmldeviant    |     -- William of Ockham