W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > December 1996

Re: FPIs to URNs

From: Murray Altheim <murray@spyglass.com>
Date: Wed, 4 Dec 1996 12:38:15 -0400
Message-Id: <v02140b03aecb532ee181@[]>
To: paul@arbortext.com (Paul Grosso)
Cc: w3c-sgml-wg@w3.org
paul@arbortext.com (Paul Grosso) writes:
> From: bosak@atlantic-83.Eng.Sun.COM (Jon Bosak)
>> 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?
>While it has not been discussed and is therefore not out of the
>question, I suspect SGML Open would have resource problems and
>perhaps jurisdiction problems doing this.  Since the GCA is in
>line to be endorsed as the Owner Identifier Registrar, they may
>be a more obvious choice.
>However, I question why the design requires one "big catalog".  With
>the use of DELEGATE and CATALOG entry types (both of which are *not* in
>the current TR9401:1995, though both of which are extensions currently
>supported by SP and both on the list of things currently being
>considered for the next amendment to TR9401), a hierarchy of smaller
>potentially distributed (and possibly mirrored) catalogs would seem
>feasible, more effective, and more manageable.  Given that "distributed
>processing and distributed resources" is one of the key models of the
>internet, it seems only reasonable to adopt this model for FPI
>resolution too.  (I do admit to lack of experience and expertise in the
>area of web-wide FPI resolution, so I welcome statements of proof that,
>in fact, large monolithic catalogs are required and/or desirable.)

This was my first reaction as well. I didn't know about the Owner
Identifier Registry becoming available online. This being the case, it
seems that rather than a large catalog hosted by GCA, organizations such as
IBM, Sun, Microsoft, W3C, IETF, Davenport, etc. would be responsible for
hosting that portion of the delegated catalog for their public files. The
name resolution would check ownerID and delegate authority to the proper
owner site.

Smaller organizations, individuals, or those not wishing to set up their
own NAPTR-style URN resolution would query a central registry (SGML Open or
GCA), whose potential load would be quite smaller, given that many of the
organizations who create public files would desire canonical ownership of
their namespace. This sounds a great deal like DNS, except that it's on its
head: you want to start at the top of the tree and work down only so far as
necessary, rather than start at the bottom and work up.

One would also have the added advantage of knowing that the downloaded file
was genuine. If you download a DTD from Netscape, you know it's Netscape's
DTD rather than someone's hack. Digital signatures could certainly play a
part here as well.

Another question that comes to mind is that this level of name resolution
is certainly more complex than a simple local catalog resolution on string
comparision of FPIs (I can hear Tim choking in the background). While we
can certainly leave the name resolution mechanism unspecified, if we decide
to include any of this, how far should the XML specification go? If we
don't plan to deal with this in the specification, we probably don't need
to be talking about it here, despite its obvious interest to many of us.
I'm certainly not trying to shut down the discussion, just trying to
understand which portions we can glean for our XML needs.


    Murray Altheim, Program Manager
    Spyglass, Inc., Cambridge, Massachusetts
    email: <mailto:murray@spyglass.com>
    http:  <http://www.cm.spyglass.com/murray/murray.html>
           "Give a monkey the tools and he'll eventually build a typewriter."
Received on Wednesday, 4 December 1996 12:36:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:05 UTC