Re: How could RDDL be distributed ?

[Michael Mealling <michael@bailey.dscga.com>]

On Tue, Jan 16, 2001 at 03:18:38PM +0100, Eric van der Vlist wrote:
> Michael Mealling wrote:
> > On Tue, Jan 16, 2001 at 12:00:54PM +0100, Eric van der Vlist wrote:
> > > Another alternative would be to rely exclusively on the protocol caching
> > > facilities, but I think that they are currently used in a too randomly
> > > fashion to be considered as reliable.
> > 
> > The solution I've been suggesting for a while is using the URI Resolution
> > process (draft-ietf-urn-uri-res-ddds-02.txt) to find a server that can send
> > you information (RDDL in this case) about the URI in question. It still
> > leaves it up to the various XML standards to decide on how to talk about
> > the 'name' of a thing as well as a current 'location' of a thing. As
> > mentioned earlier the actual RDDL (or chunks of it) would be retrieved
> > by something like the RESCAP protocol mentioned yesterday...
> 
> I am not familiar with such URI resolution servers, and I wonder what it
> means when/if I want to process a document on my disconnected laptop
> computer (a common problem with DTD system IDs).

The first step of the algorithm is to "ask any local services".
This means you check your local caches or catalogs first. I could
imagine many different ways of doing this. One common one is
to have a local RESCAP server and use it for all queries. 

> Do I have to setup a server able to return the information and how
> simple is this operation ?

If you are publishing an XML entity that needs this service then yes.
Its a fairly simple protocol and I suspect it would be no more
difficult than something like finger....

> It would be real nice to have a way to tell to the RDDL tools: "get the
> info from this local file instead of fetching it on the web".

That's been a long standing desire. We've always wanted some reliable
way for the network layer to tell the applications that the
machine is not currently on a network. I would suggest that the
RDDL tools come up with a standard API for telling them that
they currently have no network.

> I'll borrow the second use case to W3C XML Schema. If I get a XML
> document from a supplier, I may want to override the location of the
> RDDL document provided in the document itself (because I don't trust
> this supplier or because I have a different way of seeing it even if
> it's still the same namespace).
> 
> How simple would it be to do it through a URI resolution server ?

You really wouldn't do that through the URI resolution. At the
last IETF we had a BOF on something we call Contextualization (c15n).
At first glance it sounds like caching but it isn't. The main
difference is that a c15n server resolves URIs based on some
local context instead of through the normal/authoritative methods.
That local context can be shared between the context server (which
can be on the localhost) and the client since the client can
send resolution parameters to the server. You can use this to
specify whether or not to use a local cache or a catalog, etc.

> A third use case is if I want to use a namespace, but I need to
> associate different resources than the one usually attached.

I would use the c15n stuff. Which doesn't exist yet but that's
what it sounds like. A local c15n server would act as basically
NAT but for URIs. I.e. you hand the URI your trying to resolve
to your local c15n server first. If it returns something then
that is the URI that you use instead. That URI can be to something
on your local machine that is associated with the resources you want.
If it doesn't then you know that the URI in question isn't
being handled locally and you go about using whatever URI resolution
technique you want....

If your curious about what c15n is see this page:
http://lists.research.netsol.com/mailman/listinfo/c15n

There isn't much there but there does seem to be alot of interest...

-MM




-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com