Client-side-resolved Indirection

From: RE: Simple solution? Pub. Idents. vs URN.

[Len Bullard]
>What I hear Debbie, Jon, Ken and others saying is that the 
>FPI provides functionality they need, some of which, depends 
>on formal registry practices and SGML Open standards for 
>catalogs.  Does this undo the URL?  Does this preclude 
>the use of the URL?  Do the URN and the FPI/catalog conflict?

Speaking for myself, I need "client-side-resolved indirection", which
SGML's established PUBLIC mechanism, with "some kind of resolution",
provides.

The benefits I described earlier of identifer uniqueness, persistence,
management and portability are all aspects of successfully implemented
and utilized client-side-resolved indirection.

I'm concerned that the (I hope useful) discussion of the use of ISBNs
and Jon's observation of trademark lawyers' habits has distracted the
readers in this group from the essence of the service provided by PUBLIC
identifiers.  BTW, I too was not charged anything to obtain an ISBN
Publisher's Prefix, and I perceive the two-level hierarchy to be the
Publisher's Prefix followed by the publisher's own management of their
number space (the two-component value of the prefix is a mixture of both
regional and language issues).  We have since established internal
publishing (manuals, diskettes, etc.) on the ISBN system.

In short, is see no benefit difference _to the end user_ between our
"+//ISBN 1-55160" and Jon's "-//SUN::SUNSOFT" because in both cases the
end user has the opportunity to implement their client-side indirection
however they need to without impacting on the (assumed) sacrosanct SGML
files.

If this client-side-resolved indirection dereferences PUBLIC values to
URLs or internet-resolved URN/URIs or absolute filename specifications
or relative filename specifications or SQL queries or DMS copy-out
procedures or JCL tape mount directives or even some future
yet-to-be-determined-or-standardized query mechanism, the SGML files
remain inviolable.

Isn't this inviolability critically important to people who want to
invest in their data for the long term?

Certainly the SGML Open scheme has its benefits and features, but I
agreed with Debbie that the minimum is a simple string comparison.  If I
choose to go beyond that with an SGML Open catalog, I can choose to do
so without impacting on my marked up source.

Then again, need XML establish the "environment" in which XML PUBLIC
identifers are dereferenced?  Is it in the scope of XML to go outside
the syntax of the markup to specify any obligatory mechanism by which
information in the markup is handled?

Users of XML who wish to hardwire SYSTEM identifiers can still choose to
do so; hopefully the XML exercize will teach people more about the
benefits they can build into their markup, one of which could be the
implementation of client-side-resolution of indirect PUBLIC identifiers.

>James says the FPI is hard to implement.  So, it is something 
>not everyone should be required to implement.  But this seems 
>to be a system implementation restriction and I don't think 
>we are here to restrict implementors.

Agreed.

......... Ken

--
G. Ken Holman            Tel:  +1 613 596-CADE(2233)    /\ /\
Chief Technology Officer Fax:  +1 613 596-5934          \/ \/   Computer
Microstar Software Ltd.  WATS:  1 800 267-9975        /\     /\ Aided
3775 Richmond Road       Mail: gkholman@microstar.com \/     \/ Document
Nepean Ontario           Info: cade@microstar.com       /\ /\  
Engineering
CANADA K2H-5B7           Web:  http://www.microstar.com \/ \/
--
1605 Mardick Court, Box 266    Phone:  +1 613 489-2987
Kars, Ontario CANADA K0A-2E0   E-mail: gkholman@CanadaMail.com
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6

mQCNAjHOimAAAAEEAK47HbDtZZB8hJBk+r9Zh7m7QxdFHTaz/m200QQ7J9XX4QYs
h6hsuP6ZqBJXyLdmIVMEwR6Ry6oxjKMd6BRJ8OGScD89eIghgbrpMX+900NxM0x2
v3yWO9ki2gKRPrn4vlCXznnmcmsyke0G02T2LefXbgZHyVSqDSOLy8nwuN7dAAUR
tClHLiBLZW4gSG9sbWFuIDxhYjk0NUBmcmVlbmV0LmNhcmxldG9uLmNhPg==
=IN3T
-----END PGP PUBLIC KEY BLOCK-----

Received on Monday, 2 December 1996 09:44:14 UTC