Altova Mailing List Archives

"delegate" and "GI" (was RE: Do we need link-catalogs for schemas?)

From: "Rick Jelliffe" <ricko@-------.---.-->
To: <xml-dev@--.--.-->
Date: 10/14/1998 5:50:00 AM
> Peter Murray-Rust wrote:
> > Question in return, what exactly is delegation and can
> > you give an example.  [It's been mentioned both in the
> > context of Java classes and link-catalogs]

James Tauber, who graces this list sometimes, devised an extension to the
(OASIS) SOCAT  catalogs called "delegation". This is one of the main things
markup people often have in mind when they use the term "delegation", as far
as concrete technologies, though of course, it is a ubiquitous idea. A
delegation is a link (i.e. to another catalog) and a policy (i.e. "use these
catalog entries by preferene").

SOCAT catalogs is a (non-XML) format which basically allows you to remap or
override identifiers in a document. This helps resolve public identifiers
and notation identifiers, or correct system identifiers.

The online version is at The SOCAT
delegation system has a nice wrinkle--delegates are declared using a kind of
simple pattern-matching, to exploit the regularities in FPIs:
"The DELEGATE keyword indicates that external identifiers with a public
identifier that has partial public identifier as a prefix should be resolved
using a catalog is specified by the associated storage object identifier."

There was another question "what is a GI". Generic Identifier was the term
used in the SGML standard for the name of an element type; you can see that
the concept of "generic markup" came first, and SGML was developed to
support it. One reason it was also chosen was that, strictly, it was felt
that the "name" of an element was its ID; people find even the basic
distinction between an element and an element type difficult, so it there
was a feeling that it might be better to keep the term GI, which avoided
mention of elements let alone types. As things progressed it became clearer
that the "GI" was really a special attribute, and that it mainly functioned
as a content model and attribute selector, rather than identifying the genus
which processing might be interested in per se (other attributes might have
more useful information, hence the architecture movement). Furthermore that
element type was much more than could be usefully expressed in just one DTD
(hence the architecture movement again, where you can have multiple parallel
DTDs or schemas, but which take other attributes as the "Element Type

Rick Jelliffe

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


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.