Socat issues for XML

david at david at
Mon Sep 21 19:59:38 BST 1998

Paul Grosso writes:

 > >To explicate OVERRIDE: in SGML Socats, OVERRIDE NO means that when
 > >an explicit system id is present, the catalog entries are ignored;
 > >OVERRIDE YES means the catalog entries override an explicit system
 > >id.
 > I'm not understanding why OVERRIDE NO doesn't make sense.  Perhaps
 > I'm missing something about SAX or your implementation.  (Assume I
 > understand TR9401, since I edited it.)

I think that the point is that if OVERRIDE NO were allowed, the public
identifiers in the catalogue would never be used (since all entities,
at least, must have system identifiers in XML).  In SGML, some
entities may not have explicit system IDs, and those can still default 
to the mappings in the catalogue.

I'm not certain that I agree (I'd have to think about the problem
further), but I *am* fairly certain that this is the reasoning behind
the original statement.

 > >2) As another consequence of system ids being always present and
 > >always URLs, a usable Socat implementation must not search the
 > >whole public catalog space for SYSTEM entries.  When should the
 > >search stop?  In some sense "when going offsite", but just when is
 > >that?  Any suggestions?
 > I don't understand what the problem is, and I don't understand
 > how--if there really is a problem--anything about XML makes it a
 > problem that isn't a problem with SGML in general (XML is SGML, you
 > know).

I'd guess that this is a problem of efficiency: when catalogues are on
the other end of relatively slow network connection, you don't want to 
retrieve a dozen catalogues unnecessarily.

All the best,


David Megginson                 david at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list