RE: FPIs to URNs

>----------
>From: 	lee@sq.com[SMTP:lee@sq.com]
>Sent: 	Wednesday, December 04, 1996 23:00
>To: 	bosak@atlantic-83.Eng.Sun.COM; lee@sq.com; rdaniel@acl.lanl.gov;
>w3c-sgml-wg@w3.org
>Cc: 	rdaniel@lanl.gov
>Subject: 	Re:  FPIs to URNs
>
....
>
>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.

The supplemental CATALOG, being separate from the markup, is perfect for
this.
>
>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.

I don't think this meets my requirement because of the implication of
location in the URN.

I use FPI's for entity identification and the CATALOG for entity
resolution.  I don't think my needs are met if both are tied up into a
single mechanism.  If I want to use a URN for resolution, I would map
the FPI to the URN in the CATALOG.  To some this seems redundant, but to
me "urn.mitra.org" isn't an identifier, its a location.

>For example, using PUBLIC "urn:urn.mitra.org//Liam
Quin//bailey.dtd;version=3.4":  How would I override an XML processor
from accessing "urn.mitra.org" to give me the entity when I would rather
use a local file? I want to override this without having to get into the
file with my clumsy fingers and risk "breaking" something while I'm in
the file.

>> >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".

Good reasons for me to not include the resolution aspects of any kind of
identifier in the XML specification.  We are defining a meta-language
for document markup that identifies information in a file.  I've always
viewed SGML (and XML) as passive, not active.  CATALOGs are active. 
FPI's are passive.  A local URL is, in my opinion, active.  SYSTEM
identifiers are active.  These two very separate problems need two
separate, distinct but related, solutions, not a single solution that
ties both important concepts inextricably.

The tutorial I've been getting in this maillist about global URLs and
URNs leaves me the impression that these are very "active" things that
"impose" implementation on me, when I'm only responsible for marking up
my information.  I am more than willing to give you supplemental
information to work with my markup, but I do not want to hardwire
environmental client-side-resolution issues in my markup.

>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...

Great flexibility!  Just think, I didn't have to change my markup to
point into my URN cache.
>
>But in that case, perhaps it wouldn't be needed any more.

But it would be needed, because the next day I may not want my catalog
to point into my URN cache (or anybody else's URN cache, or somebody
else pointing into my URN cache (I might be sensitive about that!:{)).

>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?

In my opinion, these are solving two different problems, hence, no URN
scheme would successfully grandfather FPI's.

I want my FPI's to be absolutely permanent if I wish, so my sacrosanct
document remains inviolable, yet I have the flexibility to work with
that document in any environment I have now, or have to work in in the
future.

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 Thursday, 5 December 1996 08:54:06 UTC