RE: What to do given both SYSTEM and PUBLIC?

Even though repeating oneself doesn't make an argument any better than
the last time, I feel I need to respond to Lee's post.

If we don't have PUBLIC at all, there is no way to build system
independence.

If you want to take control out of the recipient's hands, go ahead and
use SYSTEM, but if the sender's system is different than the recipient's
system then the recipient gets the problems, not the sender.

For those of use who try to _never_ use SYSTEM, the PUBLIC identifier
relieves the sender from the problems (or desires) of the recipient.

You go ahead and only use SYSTEM, I'll go ahead and only use PUBLIC. 
What's the problem?

>----------
>From: 	lee@sq.com[SMTP:lee@sq.com]
>Sent: 	Saturday, February 15, 1997 13:30
>To: 	tbray@textuality.com; w3c-sgml-wg@w3.org
>Subject: 	Re:  What to do given both SYSTEM and PUBLIC?
>
>...
>If we open the can of PUBLIC worms, we have to say:
>* what to do if you are givena PUBLIC Id and no SYSTEM Id

The same thing as if a SYSTEM id points to something that isn't there.

>* what to do if you are given both

See if the recipient (the one in control of the file, having received
it) can satisfy the PUBLIC identifier.  If the recipient cannot, then
rely on the sender's SYSTEM identifier.

>* what to do if you are given both and the resulting files are
>different

Ignore that fact, because if the recipient doesn't want to control the
resolution of the identifier, they need not supply a catalog.

>* give at least one way in which I can put an XML file on the web and
>  someone else 6 months in the future with some new application can
>  use that file, whether or not it has a PUBLIC Identifier.

If the file is marked up with PUBLIC identifiers, then the recipient can
modify their catalog as required for the changed environment 6 months
after the sender created the file.  A lot can change in 6 months.  The
sender may not know that you have taken a copy of the file, so they
cannot tell you how their system has changed, necessitating changes in
the SYSTEM identifier.  The recipient, on the other hand, can tell from
reading the identifier what is required in the catalog to satisfy the
PUBLIC reference, modify the catalog appropriately, and use the (perhaps
read-only) file without touching the file contents.  With only SYSTEM
identifiers, it will be necessary to physically modify the file to point
to changed locations, thus the recipient is not working with an
unmodified file ... how can one guarantee that they haven't otherwise
corrupted the information?  How can one implemented these modifications
if they do not have permissions to change the physical SGML file, when
with PUBLIC all they need do is use their own catalog?

>
>Otherwise...
>
>Some people will implement systms that ignore the PUBLIC ID, as
>David Durand and Paul Prescod suggest, and always require a SYSTEM Id.

Such systems will require recipients to modify the sender's files when
identifier changes are necessary.

>Some people will implement systems in which the SYSTEM Id is ignored,
>as Paul Grosso suggests, when both are given.

I believe this is not quite what Paul suggests, as I believe that the
SYSTEM id is not ignored if the PUBLIC identifier cannot be resolved.  I
believe that this is the most defensable position.

>Some people will implement systems in which the SYSTEM ID is used for
>some things and the PUBLIC for others, as per Panorama today.

This seems difficult to defend.

>Some people will implement systems that require end users to edit local
>configuration files before they can use documents containing PUBLIC
>Ids,
>as per Author/Editor today.

If the sender also sends a catalog that allows the file to be used with
the sender's system dependencies, the recipient can immediately be as
successful as if the sender used SYSTEM identifiers throughout the
document.  The recipient can be more successful with the untouched
document if it only takes a modification to the recipient's catalog to
remove the sender's system dependencies.

>No document will work on all systems.

Documents will gracefully outlive the systems that they are built upon
if PUBLIC identifiers are used.

...
>If we don't have PUBLIC at all, this problem goes away.
>I would rather wait six to twelve months before adding PUBLIC.

I don't think we can wait.

....... Ken


--
G. Ken Holman       mailto:gkholman@microstar.com
Chief Technology Officer  Microstar Software Ltd.
http://www.microstar.com          +1(613)596-2233
3775 Richmond Rd., Nepean, Ontario CANADA K2H-5B7
Personal:   Box 266, Kars, Ontario CANADA K0A-2E0
mailto:gkholman@CanadaMail.com    +1(613)489-2987
PGP:   http://www.cyberus.ca/~holman/gkholman.pgp

Received on Monday, 17 February 1997 11:04:36 UTC