Re: FPIs to URNs

> >> This new mini-catalog is then processed by the client. It 
> >> fetches the SunSoft catalog and procedes as usual.
> >
> >So how big would a CATALOG be of every SGML or XML public identifier
> >ever issued at Sun?  Isn't this likely to be more than a kilobyte?
> >I see problems with performance here.
> 
> Right. You don't want to do this sort of thing for on-the-fly
> rendering of pages. You want to use local catalogs for that.
> This sort of thing is only for when you have an FPI that
> can't be resolved by way of the local catalog, and you are
> willing to wait in the hope of getting the resource.

I want to see FPI resolution that works when you *don't* already have
the file and have never seen the FPI before on your local system.

For my part, I would be happy to ditch FPIs and use some other URN scheme
if it scaled better:
<!DOCTYPE Baileys PUBLIC "-//Liam Quin//DTD Bailey's 1736 Dictionary v3.4//EN">
is accessible on the WWW today (using Panorama) if you know how.

But I could use
<!DOCTYPE Baileys PUBLIC "urn:urn.mitra.org//Liam Quin//bailey.dtd;version=3.4">
just as happily.

Note that this meets Debbie's requirement without actually being an
SGML Formal Public Identifier.  I.e., there are other possible solutions.

> >It needs to be a more hierarchical namespace, so that noone needs
> >to manage the whole list.
> 
> That can be accomodated pretty easily. bigcat.sgmlopen.org (or wherever
> the "root" happens to be) could have a catalog with entries of the form:
> DELEGATE -//U.S. Navy//CALS   http://www.navy.mil/foo/cals_catalog.socat
> DELEGATE -//Sun Microsystems  http://www.sun.com/bar/suncat.socat
> DELEGATE -//DOE//OSTI         http://www.osti.doe.gov/baz/ostifpis.socat

The trouble is that there are probably over a million organisations or
individuals who have issued PIs at this point...
This bigcat would hence be the better (worse) part of 50 MBytes, which
won't fit in my Netscape tmp directory, and hence can't be downloaded
by Netscape for use with a helper app.

This is my biggest concern with the (literally) millions of unregistered
public identifiers belonging to tens of thousands or hundreds of
thousands or more of issuing "authorities".

Minor concerns include the way that there are many cases where the
same PI is used by two people to refer to entirely different things,
especially with informal PIs that are often set to be the same as
the file name... and also the way that there are often many PIs for
the same public text, although that doesn't matter as much, if at all.

Really, an SGML OPEN catalog could be thought of as a local entity cache;
although they are often mantained by hand today, if URN resolution were
used, a catalog could point into one's URN cache automatically...

But in that case, perhaps it wouldn't be needed any more.

Then we'd be down to something simpler, with the CATALOG as a possible
implementation optimisation.

So, is there a URN scheme that scales in a way that makes it easier
to implement than grandfathering SGML FPIs?

Lee

Received on Wednesday, 4 December 1996 23:00:54 UTC