Re: FPIs to URNs
Thanks for posting that, Jon -- It's very informative.
A couple of questions...
> The HTTP daemon at bigcat.sgmlopen.org fires up the N2C
> CGI script. The script looks at the Accept: header, and
> realizing it is speaking to a SOCAT-savvy client it starts to
> build a custom SOCAT on-the-fly by trolling through its huge
> catalog and only returning entries that match.
If matching entries are based only on ownr identifier, N2C would
need to have a list of every ISBN used in an FPI, with corresponding
URLs, and also every registered owner. This isn't the same as every
ISBN ever issued, if you don't mind it failing on obscure ones that
the owner had not registered with the orgnisation running N2C.
> This response might look like:
> Content-type: application/socat
> DELEGATE -//Sun Microsystems::SunSoft//
> DELEGATE -//Sun Microsystems
> 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.
> Actually making this into a reality would require commitment
> from some SGML-affiliated organization, such as SGML
> Open or GCA, to try and maintain a big catalog of registered
> and unregistered FPIs, and agree to serve that up for the
> advancement of the community. I think doing such a thing on
> an experimental basis might not be too hard, but committing to
> doing so on an ongoing basis is another story. Anyone want to
> comment on the liklihood of this scenario?
Zero. :-) I wonder how many FPIs have been used so far?
A million? Ten million? That's a major management problem.
It needs to be a more hierarchical namespace, so that noone needs
to manage the whole list. Or, better, charge $5,000 to register
an FPI, and store only the new ones.
> Case 2: SOCAT-savvy, URN-unaware client
> It might be desirable to have a SOCAT version 2 proposal that
> allows the magic characters "%!uri" in the URL of a
> DELEGATE entry to mean "substitute the full FPI here". The
> SOCAT-2 client would then have a catalog entry of
> DELEGATE -//
If I am not mistaken (I might well be) I think that CATALOG is only
processed once -- the DELEGATE entry (Panorama actually uses the
keyword CATALOG for that) isn't read multiple times, so this
These schemes are interesting, and I think if the difficulty of a
previously flat namespace for informal public identifiers is
surmounted they can probably work. I also think that it would be
well worth reopening the CATALOG spec (sorry, Paul!) to include
such information in it, once it is shown to be workable.