Public Identifiers

[W. Eliot Kimber]

At 02:50 PM 9/18/98 -0400, Deborah Aleyne Lapeyre wrote:
>John Coan wrote:
>
>>Coming soon: an SAX EntityResolver that processes Socats.
>
>Thank you!
>
>From someone to whom fpis are still incredibly useful, and to
>whom socats (on admittedly brain-dead but very common operating
>systems) provide a real service.

But note that with the second edition of the SOCAT spec, you can remap
system IDs just as you can public IDs. So even there, FPIs provide no
unique facility, although the SOCAT mechanism itself does (redirection).

Formal public identifiers have value because they are intended to be human
meaningful and, when using registered owner names, guaranteed unique--but
not because they are indirect.  They are indirect only because, as far as I
know, SGML formal public IDs are not valid file names in any common
operating system. If they were, then you could use them as direct system
IDs.  It wouldn't matter whether their invocation was preceded by the
keyword PUBLIC or SYSTEM.  But note that, for example, within the scope of
dedicated repositories, I would expect to be able to use FPIs as the
primary name for resources, knowing that the redirection to the real
resource name, the private repository ID, is transparent, just as the
redirection of filenames to internal storage locations (e.g, i-nodes in
Unix) is transparent in operating systems.

The real issue is one of generally-available name redirection services ala
DNS. We take DNS for granted because the Internet would be really
inconvenient to use without it.  We could have a similar system for
resource names if the Internet community was willing to step up to funding
the development and maintenance of it. Unfortunately, because the Internet
is a distributed resource with no central management and largely hidden
shared costs, it's difficult to get a general resource in place if people
can get along with out it. You can't get along without DNS, so we have it.
You can get along without generalized resource name redirection, so we
don't have it.  

Note that things like PURLs, while useful, don't really solve the problem
because they are really nothing more than server-side redirects, which
we've always had and which anyone can provide unilaterally.  The problem
isn't really solved until we have a general service that everyone can take
for granted.  It may be, in the spirit of 80/20 solutions, that using
server-side redirection is all we will ever really need or have. Providing
a generalized resource name redirection service poses some difficult
technical and social challenges that might prove more expensive to solve
than the benefit provided can justify.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)