Lists Home |
Date Index |
> From: Jonathan Borden [mailto:email@example.com]
> Could you provide a short example that demonstates the
> benefits of an extended vs.
> simple XLink, particularly for something like a XAR. Is it
> that an extended XLink
> would represent a tree of subresources rather than a single
> source e.g. the namespace
> URI and multiple leaves e.g. the references resources?
I'm suffering from a bad case of the flu, and am struggling to remain
coherent. Here's a document that conveys what I'm thinking better than I
can, right now: http://www.w3.org/People/cmsmcq/2001/nsrddl.html
Perhaps others have already seen this. I just stumbled across it this
weekend while I was thinking about using an adaptation of RDDL in
extended-link form. The syntax it presents is essentially the same thing I
was thinking of. As you can see, it is not a big conceptual leap from what
is already there in RDDL. But it seems to me that the extended link syntax
enables things that C. M. Sperberg-McQueen does not discuss in this paper.
Note the locator pointing to the XML Schema namespace, and the arcs
establishing links from that locator to other associated resources. That one
extra twist to RDDL means that this document is not limited to simply
existing at the end of a namespace URI. It can be anywhere and still
associate resources with the namespace URI. It could also associate
resources with URIs that cannot possibly have an RDDL resource at the end of
the URI (such as the public id or system id for a DOCTYPE declaration).
You can still place this at the end of a namespace URI and use it as RDDL is
currently used. But you can also package this in a XAR and distribute by
other means, or reference it in a PI and associate resources with a DOCTYPE.
One could even keep the current RDDL syntax (to retain its simplicity) for
the narrow case of having a document at the end of a namespace URI, and have
this extended syntax that can be used in other contexts (including embedding
in a linkbase used by a particular application to provide the equivalent of
a classpath for XML resources).
That's what I'm thinking. I hope I'm explaining it well.