Re: Socat issues for XML

Paul Grosso (paul@arbortext.com)
Tue, 22 Sep 1998 10:34:35 -0500

At 22:40 1998 09 21 -0400, John Cowan wrote:
>Paul Grosso scripsit:
>> I'm not sure I follow. Are you saying that, even if you set the initial
>> default of OVERRIDE to YES and a catalog writer explicitly puts in an
>> OVERRIDE NO entry, you think it is more "useful" to assume they didn't
>> mean it and ignore it? That there is, in fact, no way to say "please
>> really use the system ids in my document" (which is, of course, precisely
>> what the "real" browsers will do until and unless they actually implement
>> a catalog, which I don't expect from MS&NS in the near term)?
>
>If you really want to use the system ids, why make use of a catalog at all?
>In SGML, you may want it for standalone public ids, but not in XML.

You omitted my compatibility argument which is summarized by:

>users will get unexpected results when they use existing [TR9410]
>catalogs.

I have not heard a convincing argument for not including OVERRIDE
in your subset of TR9401. There are many TR9401 catalogs in use,
implementing OVERRIDE is trivial, and users are used to using it.
If you don't include it, then the existing catalogs--and users
who write new catalogs based on their understanding of TR9401
catalogs as they exist--will get subtlely different results with
no warning because you would be ignoring the OVERRIDE NO entries.

>> Perhaps you need (and maybe this is what you meant above) some
>> sort of entry like CATALOG but that ignores SYSTEM entries in
>> the catalog-to-be-read.
>
>That is what I meant.
>. . .
>Your example is compelling. But I think there is still a need,
>for efficiency's sake, to add CATALOG entries that are marked
>"do not search this catalog if *not* looking for a public id".

I see your point. You want something like a PUBLIC-CATALOG entry
type with the same semantics as the CATALOG entry type except
additionally with the semantic "ignore if the external identifier
has no public identifier." Note that the referenced catalog entry
file could still have SYSTEM (and ENTITY and other) entry types, and
if the catalog is ever processed, all those entry types are significant,
it's just that no catalog referenced by a PUBLIC-CATALOG entry would
be processed if the current external identifier being resolved has
no public id.

Note, you can't say "looking for" (or "not looking for") a public
id, because you are never looking for a match to a public id per se.
You are always looking for a match for the set of info that you have
for the current external identifier, and that set of info includes
one or more of (1) public id, (2) system id, (3) entity name. In
particular, for XML, you always (except for notations) have both a
system id and an entity name and sometimes you also have a public id.

I think you'd also want the standard CATALOG entry type, therefore
PUBLIC-CATALOG would be a new entry type. The standard CATALOG
entry would address my "compelling example" as well as give
compatibility with TR9401 catalogs.