Lists Home |
Date Index |
Michael Brennan wrote:
> My proposal [jb: for extended XLink in RDDL], though, did put forth a
syntax that could be embedded in
> human readable documentation or not. Either way works. (In the latter
> case, it would just be a linkbase. But I personally very much like the
> idea of keeping human readable documentation at the end of a namespace
> Which is why I think a packaging approach like I suggested is important.
> Ultimately, the end user has to be in control and should make the
> decision of what resources to use and where to obtain them. And they
> should have a convenient mechanism by which they can share resources
> with others that relate to namespaces and/or doctypes they do not own.
> Maybe it's time to give this a rest. (Or maybe I just need a rest.) I'll
> let others have the last word on this at this point if they wish.
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.