Cart
[Home] [By Thread] [By Date] [Recent Entries]
> From: Jonathan Borden [mailto:jborden@m...] <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.
|
