Re: XML catalog draft

[Peter Murray-Rust:]

| I am not familiar with the URN process in detail - am I right in
| assuming that it based on DNS?

Yes. See

   draft-ietf-urn-naptr-01.txt
   draft-ietf-urn-http-conv-00.txt

I don't understand the URN proposal completely, but it seems to be
attempting vastly more than what we need.

| > Let's suppose that "-//FOOCORP::FOOAUTH//DOCUMENT sometitle
| > ver1.01//EN" fails to find resolution at the local level.  Postulate
| > the existence of a server (probably mirrored, but let's stay above
| > that level of detail for the nonce) funded by every organization that
| > wishes to use this mechanism.  Let's call this server xmlid.net.  That
| > server does not have a listing for every FPI; all it has is one (and
| > only one) entry for every publisher that has joined the cooperative.
|                             ^^^^^^^^^ Jon, could you expand on this
| word, please?  If it means 'Those large corporations whose business is
| publishing information and who are prepared to pay for a maintained
| site (xmlid.net) to be set up'.  If this is the case then it will lead
| either to a fragmentation of the community, or to a proliferation of
| 'xmlid.net's (e.g. 'xmlid.net.ac.uk', 'xmlid.bio.net')

I mean what you think, but I don't agree that fragmentation follows.

Let's postulate the existence of some organization whose function is
to provide such a service and make just enough to pay for itself and
the salaries of the people it employs.  Take the net operating cost
every year, divide by the number of "publishers", and that's how much
you charge each publisher.  The service provided is pretty simple:
maintain one line in a lookup table and respond to HTTP queries giving
the left hand side by returning the right hand side.  This should cost
no more to provide than the typical DNS entry.  (And we might take
advantage of the fact that this is not DNS by putting in place review
and arbitration procedures that take advantage of what has been
learned from the DNS registration experience.)

I am quite unqualified to make a detailed proposal on how to set this
up, but I believe that something along this line could effectively
solve the FPI resolution problem.  I know that at Sun we are setting
up a collaborative authoring system that automatically assigns FPIs to
every publication and resolves those FPIs in our distributed
publishing system through distributed partial socats which all fall
through, in the worst case, to a single socat that we maintain at
docs.sun.com (not yet publicly visible, but soon to appear).  So for
our purposes, which I believe are commensurate with the needs of the
great majority of publishers, a system that redirected someone trying
to resolve an FPI beginning "-//SUN::SUNSOFT//" to docs.sun.com would
work just fine.

Jon

Received on Sunday, 9 February 1997 20:32:43 UTC