RE: What to do given both SYSTEM and PUBLIC?

----------
From: 	Tim Bray
Sent: 	Tuesday, February 11, 1997 1:33 PM
To: 	w3c-sgml-wg@w3.org
Subject: 	What to do given both SYSTEM and PUBLIC?

At 02:53 PM 2/11/97 CST, Paul Grosso wrote:
>> From: murray@spyglass.com (Murray Altheim)
>> dgd@cs.bu.edu (David Durand) writes:

Hmm, seems I was right - we do *not* have a consensus on this one.

I lean towards giving the public identifier precedence.

The knee-jerk argument is "why bother" with public identifiers if the system IDs take precedence.  If I can't rely on the catalogs that I create, why should I invest the effort to maintain them.  This would be especially true in an organizational setting, where such catalogs are increasingly likely to be managed as shared resources to improve consistency across a collection of documents.  If as a publisher, I don't want the 'standard' component, I should
not code a reference to it.

Another argument is that public identifiers should be given precedence, not just to support server-based catalogs, but to support client-side catalogs. It is these local catalogs, in fact, which should be given highest precedence to allow entities, DTDs, style specifications, etc. to be stored locally 1) to cut down on network traffic and/or 2) to support local customizations.

Expanding the precedence to three layers raises additional issues about managing multiple, possibly conflicting versions of a file, but as long as the rules of precedence are clearly spelled out, I believe that the problem is small, compared to the potential benefits from enhanced flexibility.

This approach would give both publishers and recipients a number of options:

- The simplest system is to use system identifiers with the absolute control that they bring.

- Next would be to use a server-based catalog.  By doing so, the publisher gains the power of a level of indirection, but also assumes additional responsibility.

- Finally, if I decide to create a client-side catalog, I have assumed responsibility for managing it and accept the risks associated with it.

In effect, this approach 'layers' the more powerful methods around the simpler making them (and the risks that they bring) optional.  But for the choices to be meaningful, the system has to enforce these choices through precedence.

From this perspective, the idea that system behavior should be application-dependent scares me.  It means that as a publisher, I can't put confidence in my decision to use catalogs.  Likewise, if I have a concern about mismatched public and system identifiers, I can evaluate and test them as part of the publishing process, using whatever evaluation method I deem appropriate (e.g., location, time and date, byte-level comparisons, logical comparisons, etc.). As a publisher, I am in a much better position to resolve the conflict than a piece of software running on some client.

From the standpoint of a recipient, I could see value in having a way to determine that my local catalog file is 'overriding' the choices of a publisher, but again, the responsibility is mine if I choose to use client-side catalogs.

/s/ kwc 2/11/97 17:06

Received on Wednesday, 12 February 1997 10:16:36 UTC