[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use cases [was: How could RDDL be distributed ?]
- From: Michael Mealling <michael@bailey.dscga.com>
- To: Eric van der Vlist <vdv@dyomedea.com>
- Date: Tue, 16 Jan 2001 13:59:43 -0500
On Tue, Jan 16, 2001 at 05:49:47PM +0100, Eric van der Vlist wrote:
> Michael Mealling wrote:
> > On Tue, Jan 16, 2001 at 04:45:12PM +0100, Eric van der Vlist wrote:
> > > 3) Untrusted documents.
> > >
> > > Need to be able to supply alternate locations without modifying a
> > > document in order to process it with our own set of resources.
> > >
> > > Possible solutions:
> > > - setup of specific URI resolution servers
> > > - local xmlcat
> > > - Run time (API) definition of alternate locations
> > > (could rely on xmlcat...)
> >
> > Same c15n solution as #2. Essentially #2 and #3 are the same
> > functionally. The only difference being the actual reason why
> > you would be using some other copy instead of the authoritative one.
>
> Not exactly.
>
> 2) is relying on authorative sources and the best solution for the user
> would be to have a transparent process to replicate these resources on
> his station.
>
> 3) on the other hand is replacing authorative sources with local ones.
Yep. You are correct...
> > > 4) Additional customization of vocabularies.
> > >
> > > Need to supply alternate locations for documents we are authoring to use
> > > a specific set of resources.
> > >
> > > Possible solutions:
> > > - setup of specific URI resolution servers
> > > - local xmlcat
> > > - Definition of alternate locations within instance documents.
> >
> > Hmmm... seems to be the same as 2 and 3 to me. I.e. you end up
> > doing the same thing except that the reason for doing it changes...
>
> It may still be slightly different since if I send such a document to a
> colleague working in another company, I'd like him to use (unless he has
> good reasons to overide this choice) the resources I find appropriate
> for the document.
>
> This isn't the case for 2) or 3).
Same client side function, just different criteria for how
the things get into the databases for what the URIs map to.
It may sound like splitting hairs but its important since
if you standardize the access mechanism you can get a good
deal of interoperability without having to standardize all of
the administrative/policy aspects of how things get into
a particular c15n service....
-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