[
Lists Home |
Date Index |
Thread Index
]
> From: Jonathan Borden [mailto:jborden@mediaone.net]
<snip/>
> From an architectural point of view, using extended XLinks within RDDL
> should be relatively straightforward. The question is whether
> the increased
> complexity is worth the tradeoff for increased expressive
> power. Personally,
> I would like to see some real use cases and software
> implementations that
> justify this. In the meantime, there is nothing preventing one from
> referencing an external linkbase in a RDDL document.
>
> Currently, in order to describe a namespace that you do not
> own, you would
> use an XML Catalog to redirect where the RDDL document is
> obtained from
> (i.e. shortcircuit the URI resolution process).
>
> That said, if a real need for extended XLinks could be
> demonstrated, then
> this would be a natural extension of RDDL.
I'm working on an implementation to try these ideas out. Hopefully I'll have
something to share soon.
One clarification I should make, though. I originally thought of the XML
Catalog approach. But that still assumes that there will be one and only one
such resource I will consult to find links to other resources. I'm
envisioning an approach like Java where I can add libraries to the "resource
path" (for lack of a better term) of an application, and the resource links
from different libraries get merged into a global namespace. I could have 2
different libraries associating resources with the same namespace, and
within the application, these get merged into one namespace. It provides a
mechanism by which users can extend an RDDL resource and define further
resources to associate with that namespace. They could then package this as
a library and exchange it with other users.
RDDL is fine for the case of a single resource at the end of a URI which
associates resources with that URI. It does not permit such links to be
merged from multiple sources without explicit references to those multiple
sources in the primary resource or in another resource referenced through a
path that starts at the primary resource. It also does not permit the
association of links with any resource that cannot be RDDL (such as the DTD
for a DOCTYPE).
I'd be inclined to keep RDDL as is for the simple case of a container of
links at the end of a namespace URI. It's simplicity is an advantage that
should not be discarded lightly. The extended-links proposal was really an
attempt to address use cases that RDDL cannot address, but do so in a manner
that is consistent with the RDDL approach and philosophy.
I'd also toss in the notion of a PI that could associate an RDDL resource
(or extended-link variant) with a document instance to override default
resolution based on namespace or doctype. I may be reinventing architectural
forms with XLink, here. I need to study up on architectural forms; I haven't
had a chance to digest that whole XAF thread, yet. But this approach could
do sophisticated things like identify an XSLT document that uses the literal
result as stylesheet approach as having a "nature" that has nothing to do
with its root element. The extended-links in the resource addressed by the
PI could associate completely different schemas or other resources with the
root element then those associated by the RDDL resource at the end of the
namespace URI.
I'm still refining these ideas as I experiment with implementation. I'm also
probably operating at a handicap, here, since I don't have the experience
and theoretical grounding that others on this list have. I'm giving it a
shot, though, and this is where I'm headed with my implementation at
present.
|
