RE: FPIs

[Tim Bray]
>Which is a long-winded way of saying that I just haven't seen any
>evidence in the field that FPI's have any *practical* utility other
>than serving as a rather lengthy and awkward lookup key in a catalog.
>I think the problem that FPI's purport to try to solve is in fact
>a real problem, and in fact as soon as there is working technology
>out there that demonstrably uses FPI's (or some other mechanism)
>to solve it, we should adopt the proper attitude of gratefulness
>and steal it.
>
>The kind of argument on the WG that would succeed in swinging me
>(and I suspect a lot of others) toward including FPI's would be a war 
>story along the lines of "here's how we used FPI's to solve important
>problem X, 

1) Identifier Uniqueness

An FPI is made up of an owner name and an object name.  When owner names
are unique, the uniqueness of object names is the responsibility of the
owner in the owner's object name space.

FPI's that begin "-//" are unregisterable and can _never_ be guaranteed
to be unique.  FPI's that begin "+//" or "ISO" are _obliged_ to have
been assigned by a _recognized_ ISO authority: the ISO publication
authority, the ISO registration authority, an ISO member body authority
or an ISO identified organisation authority.  

I was very surprised to see that some people at SGML'96 were incorrectly
using FPI's that were prefixed "+//" in direct contravention of this
rule ... if you see "+//" without a recognized registration authority,
do not assume that the identifier is guaranteed to be unique as it has
been improperly formed.

Two available registered owner name spaces that guarantee uniqueness are
ISBN (recognized as an authorized organisation for a long time) and the
ISO registration authority (available real soon now!).

Microstar's 2 registered owner names begin:

  +//ISBN 1-55160

and (real soon now) 

  +//ISO/IEC 9070/RA::A00004

In both cases we use additional owner-name components to further
identify us and our project, customer, application, whatever.  For
example:

  +//ISBN 1-55160::MSL//DTD Presentation Slide Show//EN
  +//ISBN 1-55160::MSL::CUST-A//DTD Book Test//EN
  +//ISBN 1-55160::MSL::CUST-B//DTD Book Test//EN

Each project can then manage their own object name space as they wish,
knowing that whatever they choose they will not interfere with any other
project's object name space, nor with any other company's use of public
identifiers.  I am guaranteed that no other organisation in the world
will be legally authorized to use our owner-name, unless we give them
part of our extended name space.

BTW, we obtained our ISBN Publisher's Prefix by a simple application to
our country's ISBN Registration Authority, the National Library of
Canada (who were assigned sets of numbers by the International Standard
Book Numbering Agency in Berlin).  Contact your government for the name
of the authority in your country.

2) Identifier Persistence

I'm not sure that this is the correct word, as it might be overloaded by
now ... but the idea is that given the uniqueness guaranteed in (1), it
is now up to the owner to ensure that the object's name lasts forever
and is not made ambiguous by identifying something else with the same
identifier.

3) Identifier Management

When we deliver a project to a customer, the _only_ change required to
locate _all_ objects (we try to _never_ use SYSTEM identifiers
_anywhere_) is to modify the catalog (and even that can be mitigated as
noted below).  None of our SGML instances change one iota, and can be
marked read-only when delivered (this is so that the customer cannot
accidentally change something else when attempting to change only SYSTEM
identifiers if the SGML files contained SYSTEM identifiers).

Also, how would the customer know where all of the SYSTEM identifiers
were in a set of SGML instances?  By delivering a system based
_entirely_ on PUBLIC identifiers, all external identifiers can be
summarized in catalogs.

FPI's make an excellent management tool for the delivery of a suite of
interconnected SGML files.

4) Identifier Portability

If, after delivery with our catalogs, the customer wishes to move the
suite of SGML files elsewhere within their system, or change the source
of any file of the system, only the catalogs need be changed.  The
customer need not know how many files share a common resource in order
for all references to that resource to be changed.

Think of how quickly aged, broken or incompatible HTTP links can be
repaired if all links in a suite of files are FPI's, thus fixable with a
single change to a catalog.

>and here's where you can go and look at the software that
>does it."  Of course, the software function would have to be something
>that you could do in a lightweight, compact implementation.

[Debbie Lapeyre]
>I would be content if they could be viewed as
>one long silly-looking string that we use in a character for character 
>match.

Sounds good enough for me, though there are some very nice aspects of
the SGML Open catalog specification to make life easier.

The SGML Open catalog convention of resolving relative file path named
SYSTEM identifiers as being relative to the location of the SGML Open
catalog provides further independence and can reduce the amount of
"customisation" required when delivering, or moving, a suite of SGML
files.

Please add my voice (LOUDLY) to the clamour for supporting FPIs in XML.

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

--
G. Ken Holman            Phone:  +1 613 489-2987
P.O. Box 266             Street: 1605 Mardick Court
Kars, Ontario            E-mail: gkholman@CanadaMail.com
CANADA  KOA-2E0          E-mail: ab945@freenet.carleton.ca

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6

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

Received on Wednesday, 27 November 1996 10:15:55 UTC