Deploying RDDL is dead easy. Unfortunately, there’s a hole in our APIs.
Deploying RDDL is dead easy. There’s a little work left to dot the ı’s and cross the t’s on a spec we can all live with, but the concept is simple. If you’ve got a URI that might reasonably be used to indirectly identify several things, as a namespace name might indirectly identify several schema languages, a stylesheet, reference documentation, and an unbounded number of other things, you put a RDDL document there and that document provides the level of indirection necessary to get what you’re really after.
Unfortunately, there’s a hole in our APIs.
Methods that retreive URIs directly and the various entity and URI resolver APIs all provide a few bits of information about the resource (the URI and the base URI, for example, and perhaps even a relevant public identifier). But what they don’t provide is any indication about why the resource is being requested.
Now, that’s not always unreasonable. Sometimes a URI is just a URI.
But if my application is trying to retreive the URI that it found in an
xsi:schemaLocation hint or a
stylesheet processing instruction, it darned well knows what it wants.
I don’t see any reason why that
information couldn’t be provided to the resolver mechanisms.
My vision is a future where a URI resolver looks like this:
Source resolve(String uri,
uri is the URI as it was found in context,
base is the appropriate base URI from the context, and
purpose identifies the purpose for which the URI is
being requested. The
publicId is an optional public
associated with the resource. Obviously, I’m still a fan of public identifiers.
I’m prepared to lose that battle, but this is my vision, so I get to have my way!
The underlying network libraries can then be intelligent. They can try content negotation, for example, to get the right kind of resource. And if a RDDL file comes back, indirection can be applied to return the right kind of resource transparently.
I was struck by how useful this would be, in particular, when we were discussing fragment identifiers at the face-to-face meeting of the TAG a few days ago.
It seems to me that my vision maximizes the possibility that the resource you get back will be the one you wanted and that, in turn, maximizes the possibility that you’ll have a useful fragment identifier.
What about Catalogs?
Interestingly, I think that XML Catalogs probably still operate at a lower level. Catalog resolution might, for example, return a local RDDL file avoiding a network connection. And after considering the possible indirection defined in the RDDL document, the catalog would be hit again for the indirectly identified URI.