SGML: SGML Extended Facilities

SGML: SGML Extended Facilities (by Steven R. Newcomb)


Subject: Re: Alternatives to Pitting HTML against SGML
Date: Tue, 23 Jul 1996 19:26:27 -0400
From: "Steven R. Newcomb" <srn@techno.com>
Newsgroup: comp.text.sgml
============================================================== Len Bullard <cbullard@HiWAAY.net> wrote: > Every SGML DTD I ever had was being extended > by somebody. DTDs are notorious for this. That is part of the thread > going on here. We need to know if the recent results of the > alignment of DSSSL and HyTime, plus the Technical Corrigendum could > potentially offer some relief to this, and might be a place to > look for future Internet systems capabilities. > > Alternatives wanted: then solutions. Solutions are on the way and will be here any minute now. In fact, James Clark has already implemented, in SP, some extremely significant extensions to SGML defined in ISO 10744, which I will now attempt to summarize. The Technical Corrigendum to the HyTime standard (ISO 10744), when published, will provide, among several other extremely significant "SGML Extended Facilities," the means whereby one DTD can inherit constructs from any number of other DTDs. When a DTD inherits constructs (mostly element types) from other DTDs, we now call the inheriting DTD (the one that will be used in the normal SGML fashion in conjunction with a set of document instances) an "encompassing" SGML architecture. We call each of the meta-DTDs from which the "derived" DTD inherits constructs a "base DTD" or "meta-DTD". There can be a chain of inheritance through any number of meta-DTDs on the way to a given DTD. When an SGML instance conforming to a DTD which inherits from meta-DTDs is parsed, a "grove" of objects, representing the parsed form of the instance, is created. The properties of these objects are fully described in the SGML Property Set, which already is found in clause 9 of the DSSSL standard. (If you can think of a property of an SGML document that isn't in there, I'll be amazed. It is sufficiently comprehensive to please the most demanding SGML purist, but a means is also provided, called a "grove plan", for eliminating from the grove any properties you don't need.) In addition, for each "base architecture", an SGML Extended Facilities parser creates a grove of the objects found in the instance which have significance for that architecture, in terms of that architecture's DTD. In other words, such a grove looks as though the document instance was a different document instance -- one that was parsed according to the meta DTD of that architecture. There is a large number of interesting and profound consequences to these "meta-DTD", "grove", and "property set" ideas. One way of putting it is that object orientation has finally arrived in the world of structured, self-describing information -- both in the form of ISO standards and in free, working source code (of outstanding quality, as it happens). Here are some fascinating and paradigm-warping consequences, as I see them: * Objects with inherited and inheritable characteristics are now representable in an application-neutral fashion, independent of methods, but still encapsulated in semantics. * Meta-DTDs, rather than DTDs, can now form the basis of interoperability. DTDs can be placed under the control of authors, the only requirement being that the instances not violate the constraints imposed by the inherited architecture(s). No more will we have to choose between (a) locking everything down in a single DTD, (b) using the widely-despised CONCUR feature, or (c) not using SGML. * If you don't like HyTime, you can create your own language for universal addressing, strongly typed hyperlinking, measurement expression, scheduling, rendition, etc.; HyTime is just one possible base architecture now. If you do like HyTime, great. You can inherit the large amount of OO design that HyTime is, and, in your software, you can similarly inherit the capabilities of the relevant objects of a HyTime engine. <commercial type=helpful organization=TechnoTeacher>BTW, our company licenses just such an animal; it's called HyMinder(tm).</commercial> * HTML can be a base architecture. An instance can inherit all the characteristics of HTML (pick your HTML DTD), and the HTML aspects of it will appear in the corresponding grove as an HTML document. <suggestion>Somebody should sell an HTML engine.</suggestion> * Java, for example, or any other programming language, can be a base architecture; all you have to do is represent a Java program as an SGML document. For an idea of how that might be done, see MID (http://navycals.dt.navy.mil/mid/mid.html). <question type=rhetorical>Does anybody want to license a Java engine?</question> * Java's GUI, or any other GUI, can be a base architecture; for an idea of how that might be done, see MID (http://navycals.dt.navy.mil/mid/mid.html) (again). <praeteritio>It's too obvious to mention that there are plenty of GUIs and GUI engines out there whose capabilities could be expressed as meta-DTDs.</praeteritio> * A single DTD could inherit the features of a programming language DTD (e.g., Java), a text structure DTD (e.g. HTML), a GUI (e.g. the Java library), and a universal addressing, strongly typed hyperlinking, measurement expression, scheduling, and rendition language (e.g. HyTime). Again, for an idea of how such a thing might look, check out MID, whose working demo will presumably soon be released for the benefit of those who don't believe in anything but working code. MID doesn't mix Java and HTML, but it is a mix of similar stuff. The MID DTD doesn't explicitly inherit from meta-DTDs (it's a two-year-old pioneer, after all), but it could be expressed that way today. <commercial type=helpful organization=GCA>We're going to be discussing these and other very interesting things at the annual HyTime conference in Seattle, Washington, USA, August 20-21 1996. Contact GCA (www.gca.org; Julie Morrison at +1 703 519 8160) for info on "Information Technology Week".</commercial> Best regards, --Steve *************************************************************** * Steven R. Newcomb | President * * direct +1 716 389 0964 | TechnoTeacher, Inc. * * main +1 716 389 0961 | (courier: 3800 Monroe Avenue, * * fax +1 716 389 0960 | Pittsford, NY 14534-1330 USA) * * Internet: srn@techno.com | P.O. Box 23795 * * FTP: ftp.techno.com | Rochester, New York 14692-3795 * * WWW: http://www.techno.com | USA * ***************************************************************