The following report was obtained from the Exeter SGML Project FTP server as Report No. 9, in UNIX "tar" and "compress" (.Z) format. It is unchanged here except for the conversion of SGML markup characters into entity references, in support of HTML. The document contains two appendices: (1) Yuri's "Year in Review", and (2) Michael Sperberg-McQueen's closing address
THE SGML PROJECT SGML/R16
CONFERENCE REPORT
SGML '92
DANVERS, MA, USA OCTOBER 25TH-29TH 1992 Issued by
Michael G Popham
2nd December 1992
-----------------------------------------------------------------
NOTE: Thanks to Yuri Rubinsky and Michael Sperberg-McQueen, for
posting the texts of their speeches to comp.text.sgml, which have been
reproduced in the Appendices to this report. Initially, Yuri and
Michael's postings were reproduced without their permission -- so as
well as a huge debt, I also owe them my profound apologies. Copyright
and permission to re-use these texts remain with Yuri and Michael.
BACKGROUND
This was the tenth in a series of annual SGML conferences
organized by the Graphic Communications Association (GCA). This
was the most well attended conference to date, with 270 attendees
drawn from a wide range of backgrounds.
SESSIONS ATTENDED
1. SGML: The Year in Review -- Yuri Rubinsky (SoftQuad,
Canada) (Full text of this presentation is given in Appendix I
attached)
2. I have seen the Future of SGML and It is ... -- Dr Charles Goldfarb
(IBM USA)
3. Lessons Learned from the Text Encoding Initiative --
Susan Hockey (CETH USA)
4. The Marks that Monks Make: Tagging Irish Manuscripts
-- Peter Flynn (University College, Cork, Ireland)
5. Using SGML in Non-SGML Environments -- Ludo van Vooren
and Eric Severson (Avalanche Development Company, USA)
6. SGML and Braille -- George Kerscher (Recording for the
Blind, USA), Yuri Rubinsky (SoftQuad, Canada)
7. Standards Activity and News Briefing -- Various Speakers
8. The Novice's Guide to HyTime -- Lloyd Rutledge
(University of Massachusetts, USA)
9. One Doc - Five Ways: Comparative DTD Session -- Various
Speakers
10. The OSF DTD Recommendations: Lessons We Learned --
Jeanne El Andaloussi (Bull SA), Eve Maler (Digital Equipment
Corporation)
11. Guidelines for Document Analysis reports and a Tool for
Maintaining Many, Varied DTDs -- Dennis O'Connor (Bureau of National
Affairs Inc, USA)
12. Sharing the Lessons of the CALS SGML Activity -- Beth
Micksh, Robin Tomlin (Intergraph, USA)
13. SGML: Extending and Confirming Object-Based Software --
Don Davis (Interleaf, USA)
14. Poster Session -- Various speakers
15. International SGML Users' Group Meeting
16. The Society of Automotive Engineers J2008 Task Force --
Jim Harvey (Volt, USA)
17. The Air Transport Association/Aerospace Industries
Association, rev 100 -- Diane Kennedy (Datalogics, USA)
18. The Davenport Group for On-line Documentation -- Various
Speakers
19. Implementing a HyTime System in a Research Environment --
Lloyd Rutledg (University of Massachusettes, USA)
20. Poster Session -- Various Speakers
21. The User SGML at the Boston Computer Society -- Sam
Hunting and Irina Golfman
22. Document Management in Production Publishing Environments --
William Trippe (Xyvision, USA)
23. An SGML Pilot Project: The OSTI Reports Received List --
Norman Smith (Science Application International Corporation, USA)
24. Frame-Based SGML -- Len Bullard (Paramax, USA)
25. SGML as Foundation for a Post-Relational Database Model --
Tim Bray (Open Text Corporation, Canada)
26. The SGML View of a Database -- Bob Barlow, Fritz Eberle
(AGFA, CAPS)
27. SGML Queries -- Paula Angerstein (Texcel, USA)
27.1 Comparative Implementation of the SGML/Search
Query Language Francois Chahuneau (AIS/Berger Levault, France)
27.2 Structured Queries and Location Models: DSSSL
Paul Grosso (ArborText, USA)
27.3 Structured Queries and Location Models: HyQ
Steve DeRose (Electronic Book Technologies, USA)
27.4 Structured Queries and Location Models: SFQL
Neil Shapior (Scilab Inc, USA
28. Structured Queries and Location Models, Part II --
Various Speakers
29. Transforming Airworthiness Directives from Paper to CD-
ROM -- Hally Ahearn (Oster & Associates Inc, USA)
30. The Development of a Technical Support Database for On-
Line Access and for Publication on CD-ROM -- Elizabeth Jackson
(K.E.B. Jackson Consulting)
31. The Making of Microsoft Cinemania: SGML in a Multimedia
Environment -- John McFadden (Exoterica Corporation, Canada)
32. Process of Converting from Paper Documentation to SGML
Based CD-Rom -- Ken Kershner (Silicon Graphics, USA)
33. Converting 180+ Million Pieces of Paper -- Eric Freese
(Mead Data Central, USA)
34. Poster Session Conversion -- Various Speakers
35 Back to the Frontiers and Edges -- Michael Sperberg-
McQueen (University of Chicago, USA) (Full text of this
presentation is given in Appendix II attached).
1. SGML: The Year in Review -- Yuri Rubinsky (SoftQuad, Canada)
Yuri Rubinsky (YR) offered his now traditional rapid run-through
of the past year's main SGML events and activities. The full
text of his presentation will be published in both <TAG> and The
International SGML User's Group Newsletter (it also appears in
Appendix A of this report). However, some of the highlights in
the areas identified by YR include:
* Standards activity HyTime, the Conformance Testing
Initiative, the SGML review, and work on query languages.
* User Groups new groups in Australia, United Kingdom,
Washington DC., South Ontario, Seattle, Colorado
* Major public initiatives European Community projects
promoting information access access for the blind.
Work of the Davenport Group. Work on ISO TR 9573 at the ISO.
Work of the EWS (European Workgroup on SGML) on DTD for
journal articles.
* Major Corporate and government initiatives Use of SGML by
Canadian Standards Association, Australian Parliament, US Navy,
Fokker aircraft, Wolters Kluwer, Boeing,
US Air, US Dept. of Energy, Silicon Graphics and Novelle (for
delivering hardware and software documentation on CD-ROM)
* Publications -- a new book by Joan Smith. 2nd print-run of
The SGML Handbook. An electronic version of Practical SGML
to be produced.
* Vendors -- (In addition to those that would be documented
later) YR mentioned WordPerfect's "Markup", Adobe's "Carousel"
(2nd release to have SGML `smarts'),
Quarkexpress (will be able to export SGML) and the future
release of TechnoTeacher's "HyMinder" (HyTime engine).
* Miscellaneous December '92 release of Exoterica
Corporations "Compleat SGML" text suite etc. on CD-ROM.
Work of CURIA (The Irish Manuscript Project). Proposed
SGML-aware extension to LaTex3. Release of the ICA's
software for building translators.
2. I have seen the Future of SGML and It Is .... -- Dr Charles
Goldfarb (IBM, USA)
Dr Goldfarb (CG) began be expressing his personal disappointment
at the continuing appearance of proprietary "standards" which
users are still buying. He urged all attendees to promote the
advantages of using SGML (and other non-proprietary standards) as
widely as possible. He then began his talk proper.
The world of the isolated single document is dead. Now there is
hypertext and multimedia the future lies in documents that
conform to SGML and HyTime (which is both an application of SGML
and a conceptual extension to it).
CG showed some slides of pages taken from the Winchester Bible
a highly ornate, illustrated twelfth century manuscript. He
proposed that these were, in fact, multimedia documents
showing that readers have been using the techniques to access
such texts for several centuries. CG also remarked that time
dependencies represent a central feature of using hypertext and
multimedia -- but again argued that readers have been familiar
with such concepts for years, in the form of music manuscripts
and scores. In the same way that music notation represents the
relative duration of notes, HyTime extends the concept of
addressing into "finite co-ordinate addressing", where location
and time co-ordinates are expressed in terms of their relative
position to a known address. This enables HyTime to express
almost any kind of relationship, just as SGML can express any
ordered structure. Co-ordinate space can have any number of
dimensions and these, plus the units of measurement, are
definable by the HyTime system developer.
CG concluded by encouraging all new and prospective users of
HyTime (and SGML) with the thought that we are all experts in the
use of hypertext and multimedia already!
3. Lessons Learned from the Text Encoding Initiative -- Susan
Hockey (CETH, USA)
Susan Hockey (SH) summarized the organisational structure and
work of the TEI. I refer readers who are not familiar with the
TEI to the account of Lou Burnard's paper at SGML '91, given in
the conference report produced by the SGML Project (SGML/R9).
The latest TEI news from SH is summarized below:
* TEI P2 is due by July '93, with a "final report" (P3) due
soon after.
* the TEI is actively seeking additional funding to
continue its work.
* users need to be educated to realize they will not
need to adopt everything that is in the TEIs "Guidelines"
in order to use them
* libraries are taking an increasing interest in handling
electronic texts. Much of their attention focuses on work
to create a standard TEI document header (and the
software to process these automatically).
* the TEI is also seeking to establish guidelines for
testing TEI conformance, and how best to maintain and develop
the "Guidelines"
4. The Marks that Monks Make: Tagging Irish Manuscripts -- Peter
Flynn (University College, Cork, Ireland.
Peter Flynn (PF) described the activities of the CURIA project,
which is funded for ten years to make machine-readable copies of
Irish manuscripts texts from the sixth century to the sixteenth
century. Most of these texts are illuminated, and written in
either Irish and/or Latin. PF said they anticipated multiple
uses for the electronic text archives, and that it was less
important to record formatting information because the electronic
texts would not be used to recreate printed or displayed copies
of the original manuscripts. However they had to provide
electronic texts which were acceptable to the increasing number
of scholars who wished to analyse them.
CURIA's aim is to make the archive widely accessible -- via
anonymous ftp, telnet, WWW browsers (also Gopher and WAIS), on
CD-ROM and via interactive Bitnet messages. PF showed how the
electronic texts were derived; rather than using an original
manuscript, they scan a book version (usually nineteenth century)
of the text -- which takes about two minutes per page with 99%
accuracy to get an ASCII file. The file is hand-tagged using
"Author/Editor" (using Latin tag names, to satisfy the lingua
franca of mediaeval scholars), to produce a TEI-conformant SGML
file which can also be printed or displayed with user-defined
options.
5. Using SGML in Non-SGML Environments -- Ludo van Vooren and
Eric Severson (Avalanche Development Company, USA)
Van Vooren and Severson (V&S) gave a highly entertaining
dramatised dialogue to present a discussion of how best to
implement SGML in a real-world, non-SGML environment. They
suggested that it would be unacceptable to try and impose the use
of SGML and/or structured editors in many traditional working
environments.
V&S urged systems implementors to make SGML appear as simple and
friendly as possible through the adoption of minimally rigid
DTDs, and "verifiers" which can be incorporated into familiar
word processing environments, so that users can be guided to
produce acceptable structured documents before the files
converted into SGML. They argued that to be truly successful and
widely adopted, SGML must offer solutions to the problem of
managing the "infoglut" -- and that it must always appear simple,
even if an implementation is, in fact, highly complicated behind
the scenes.
6. SGML and Braille -- George Kerscher (Recording for the Blind,
USA), Yuri Rubinsky (SoftQuad, Canada)
George Kerscher (GK) spoke of the Texas State law which has
recently been passed to mandate that all school texts must be
made available to the blind and other "print disabled" groups.
Similar laws have subsequently been passed in eight other states.
Under the Texas law, conventional publishers are required to
provide braille publishers with the electronic files they use to
format their printed textbooks. Braille publishers are able to
strip out the formatting codes to produce a plain ASCII file
which they can then mark up using SGML. However, as electronic
text/manuscript standards, such as the one developed by the AAP
become widely adopted amongst publishers, the braille publishers
will need to find a way of mapping from say, the AAP DTD to one
which provides sufficient structural information for their needs.
Yuri Rubinsky described the tag set which has been developed for
this second target DTD and discussed some of the problems that
the translation process has identified -- ie the need to change
tag names, recognise contexts , and so on. This work was being
carried out in conjunction with the activities of the
International Committee for Accessible Document Design (ICADD).
7. Standards Activity and News Briefing -- Various Speakers
Sharon Adler (Electronic Book Technologies, USA) described the
latest developments affecting SGML Registration Procedures and
Authority. After several years delay following the appearance of
ISO 9070, it now seems almost certain that the GCA will become
the controlling authority for issuing Public Owner Identifiers
etc.
Marion Elledge (GCA, USA) described activities in the sphere of
conformance testing. Harmonized test suites will be developed by
the end of 1992, and in the first quarter of 1993 an SGML
conformance testing laboratory will be established at the NCC in
Manchester (UK). The laboratory will test parsers for
conformance to the core of ISO 8879, test features (such as
minimization), and test applications (such as the MIL 28001 DTDs,
ATA DTDs etc.)
Anders Berglund summarized moves towards developing an harmonized
SGML math. He characterized the existing difference as follows:
* ISO 9573 and AAP DTD offer meaningful element names, and
aim to represent first year university math (including basic
semantics)
* Euromath DTD offers a layout-oriented approach
* ISO TR 9573 and AAP DTD have more in common than they
have differences.
He suggested that the work of the AAP math revision subcommittee
will be closely based on the latest version of ISO TR 9573, which
offers a three layer approach to math encoding. He argued that
this approach offered opportunities for semantic and layout-
oriented markup and was highly user-extensible. Work on the AAP
math DTD would continue at the conference.
Sharon Adler (Electronic Book Technologies, USA) gave an update
on the status of DSSSL (ISO/IEC DIS 10179 -- Document Style
Semantics and Specification Language (DSSSL). The second DIS
is scheduled for ballot during April 1993, and it is hoped that
it will be available as a full International Standard within the
following six months. A number of issues and features
surrounding DSSSL still remain to be resolved and Adler welcomed
any input from users through their national standards bodies.
8. The Novice's Guide to HyTime -- Lloyd Rutledge (University of
Massachusetts, USA)
Lloyd Rutledge offered a very detailed introduction to the main
concepts of the HyTime standard (ISO 10744). Much of the value
of the session came from extensive question and answer periods.
The content of the slides was too extensive to reproduce here,
and interested readers are recommended to contact Rutlege
directly (his address can be obtained from the GCA or The SGML
Project).
9. One Doc - Five Ways: Comparative DTD Session -- Various
Speakers
This session was Chaired by Tommie Usdin (ATLIS Consulting Group,
USA), who began by expressing her belief that DTD development is
an art form, not a science. Five experienced DTD designers had
been asked to produce a DTD for "The New Yorker" magazine. Each
of the five was asked to keep a particular application or purpose
in mind when writing their DTD.
Usdin remarked that the five DTD designs had thrown up a number
of interesting similarities and differences.
Similarities included:
* Similar tag names chosen
* influence of the AAP model
* layout of the DTDs (they all looked physically similar)
* oriented towards content modelling (even when the
* designers had been asked to focus on formatting issues)
* all the authors had identified themselves in comments
near the start of the DTD.
Differences:
* only one DTD expressly accommodates document management
* inclusion/omission of the SGML declaration
level of detail
* only one DTD design was modularized
* only one contained "code comments"
* several different types of graphics had been identified
* documentation: internal, external, both or none
* great variation in the extent of use of attributes
Debbie Lapeyre had been asked to produce a design based on the
AAP standard. She changed the AAP DTD model by stripping out a
number of tags and content models -- and tried to add as few new
tags/models as possible. She modularized her DTD to reflect the
split between the magazine's editorial and authorial production
roles. All the base level elements were therefore included at
the "article" module level (ie. the authorship level), but were
accessible from the "magazine" (editorial) level module.
Yuri Rubinsky's design illustrated the use of content tags and
tagging techniques. He felt that content could only be modelled
in consultation with end users of the DTD, and so had "cheated"
by actually phoning the staff of "The New Yorker" magazine! Some
content was fixed, but some was surprisingly varied -- for
example, titles in the table of content were not always the same
as those actually used in the articles themselves. Rubinsky
discussed how he had identified separate pieces of content and
justified his design decisions in terms of how they modelled the
end users' perception of the magazine content.
Halcyon Ahearn produced a DTD that took advantage of the markup
minimization features of SGML. She had scanned pages of "The New
Yorker", then used regular expressions to enable an SGML parser
to recognise certain character combinations in the file as being
DTD tags -- ie that two successive carriage returns indicated the
end of one paragraph and the start of the next. She altered the
SGML declaration to permit the use of long, descriptive tag
names, but used parameter entities to simplify the content models
used in the DTD. She had also taken advantage of SGML's SHORTREF
and LINK features to further minmize markup without losing any
functionality.
Dennis O'Connor had written a DTD to support print publication.
Although he was concerned with formatting issues, he had found it
necessary to use a surprising number of content-oriented tags.
He used an empty <font> element to signify changes to the current
font when printing. Dimensions of figures and graphics were
expressed in terms of the number of whole column widths they were
intended to span.
David Durand and Steve DeRose had produced a DTD to support
hypermedia applications. They stated that their design had been
based on the creation of a traditional (non-hypermedia) DTD
design, with additional "milestone" tags incorporated to aid
navigation and reference within the document. Some of the
hypermedia links would have to be hand-coded into a Hypermedia
document that conformed to their DTD, whilst other links could be
derived from database versions or indexes of the document. The
practical issues involved, such as dealing with different graphic
types, would take a long time to resolve (and they had not
tackled them in their design). Putting IDs on every tag seemed
the simplest way to allow hypertext linking/searching/navigation;
they suggested the IDs are the basic pointing mechanism within
SGML. Their envisaged application would use an "authority list"
of document object IDs to control hypermedia linking and
retrieval. They remarked that the more a DTD facilitated content
tagging, the easier it would be to convert a document conforming
to such a DTD into some sort of hypermedia form.
10. The OSF DTD Recommendations: Lessons We Learned -- Jeanne El
Andaloussi (Bull SA), Eve Maler (Digital Equipment Corporation)
Andaloussi and Maler (A&M) gave an account of their experiences
developing the OSF's DTD recommendations. They had developed a
DTD design methodology as part of the project, and went on to
describe its benefits -- namely that it was a rigorous process
enabling high quality DTD design with clear rationale; it also
produced very thorough and understandable documentation to
accompany the DTD.
In order to produce the guidelines, the OSF had asked its members
to send DTDs so that they could be analyzed by a design team.
The bulk of A&M's presentation focussed on the development and
use of a tree-based diagram notation to reflect a DTDs overall
design, element hierarchy and so forth. Making DTD designs
explicit in this way had enabled them to compare and better
justify DTD designs decisions. Each stage of the DTD design
process was also thoroughly documented through the use of
standardized forms.
A&M felt that their design methodology and accompanying tools
bore close similarities to current software development
practices. The itterative design process had proved to be very
thorough, and encouraged designers to work for and justify the
functionality they really wanted. The use of the tree-diagram
notation approach, and standard documentation forms had enabled
non-SGML experts to contribute effectively to the design process.
A&M are hoping to produce a more generally applicable and
formalized DTD design methodology. They repeatedly identified
the benefits to be gained from agreeing and documenting clearly-
defined design axioms and principles throughout the design
process. The creation and maintenance of a glossary of key terms
played a major part in ensuring that all those involved in the
design process used the same terms in the same way -- thereby
minimizing any ambiguities and misunderstandings between members
of the DTD design and maintenance teams.
11. Guidelines for Document Analysis Reports and a Tool for
Maintaining many, varied DTDs -- Dennis O'Connor (Bureau of
National Affairs Inc, USA)
Dennis O'Connor (DC) described his work to develop guidelines for
writing Document Analysis reports -- which provide a means for
maintaining many, varied DTDs. The reports facilitate inter-
departmental communications, permit control over the growing
volume of document types, and enhance the quality of available
documentation.
DC's guidelines define the structure and content of Document
Analysis reports, and are written in plain, non-technical
English. The Guidelines require a Document Analysis report to
include background information -- such as "Who did the document
analysis?". "Which documents were looked at?", "When was the
analysis done?", "Why was the analysis done?"
The bulk of the guidelines require the author of a Document
Analysis report to define the document type, what a document is
made up of (elements, attributes, character sets, special
characters and other entities). The guidelines also require the
recording of the history of the Document Analysis report -- when
was it written? What, when, why were changes made?
A well written Document Analysis report provides a means for
those who know about documents to communicate with those who know
about SGML. The report effectively provides some of the
documentation which ought to accompany a DTD.
12. Sharing the Lessons of the CALS SGML Activity -- Beth Micksh,
Robin Tomlin (Intergraph, USA).
The CALS (Computer-Aided Acquisition and Logistics Support)
initiative, which started in 1985, aims to improve the timeliness
of documentation and improve the quality of weapon systems.
Micksh and Tomlin (M&T) felt that users in other industries could
learn from the experiences of those involved in CALS -- and
perhaps adopt similar terminology, or methodology in their own
areas.
The presentation took the form of a mock news cast, with CALS
celebrities being given brief interviews. The areas covered and
interviewees' remarks are summarized below:
* MIL-28001 the SGML part of CALS. Work was initially
industry/committee driven but now there is a need for a
single central body (such as the Dept of Defense) to
take over and unify the administrative functions.
* Output Specifications -- a standard way of exchanging
formatting information (an appendix of MIL-28001 currently
under revision). Other industries would probably
benefit from producing their own output specifications.
* Electronic Review -- a machine-readable way of handling
structured comments on electronic texts. ie comments are
inserted in a standard way (using SGML tags and
attributes) -- so that they can be easily searched,
retrieved etc. Structured comments are quite easy to use
and are vital to any complex review project which requires
careful monitoring and control of comments.
* Declaration Subsets -- declarations in addition to the
external declaration subset (DTD). Users can include things
in the declaration subset which can override parts
of the DTD. This effectively makes a DTD
modifiable/modularized -- so it would
be possible, for example, to take a DTD and add
electronic review functionality without affecting the main DTD.
* CALS SGML Registry and Library -- registration/evaluation
process for all the elements etc. going into CALS DTDs, FOSIs etc.
The aim of the library is to allow DTD designers/users to login
and download example DTDs, entity sets and so on.
13. SGML: Extending and Confirming Object-Based Software -- Don
Davis (Interleaf, USA)
Much of Don Davis' (DD) presentation looked at the particular
Object-Oriented approach to SGML adopted within the Interleaf
range of products. Such details are omitted here, and interested
readers should contact either DD or their nearest Interleaf
agent.
DD suggested that it is useful to think of an SGML encoded data
stream as a set of objects, where the element structure provides
object "handles", and element-in-context details add more
information. Treating SGML encoded data in this manner, enables
the use of Object-Oriented programming languages and techniques
to support the mapping of SGML files to/from proprietary, object-
based editing/processing systems. DD proposed that an Object-
Oriented approach provides significant benefits when developing
and deploying SGML-based applications.
14. Poster Session -- Various Speakers
This poster session offered software vendors and developers the
opportunity to demonstrate and discuss their products. The
companies present were as follows:
Agfa CAPS, ArborText, Avalanche, Data Conversion Laboratory,
Datalogics, Exoterica, Frame Technology Corporation, Interleaf,
Open Text Corporation, Recording for the Blind, Silicon Graphics,
SoftQuad, TMS Incorporated, US Lynx, Xerox, Zandar.
15. International SGML Users Group Meeting
Considering the number of people at the conference, this meeting
was (surprisingly) poorly attended, only about 25 people came.
The meeting was chaired by Steve Downie (Secretary of the
International SGML Users' Group).
Brief reports were heard from representatives of the following
Chapters:
SGML Forum of New York
Canadian SGML Users' Group
Mid-Atlantic SGML Users' Group
Mid-West SGML Forum
SGML UK
SGML France
There was a limited discussion on what the various Chapters did
(and should do), how much they charged etc.
Steve Downie reported that the Canadian Chapter will be making a
proposal to the International SGML Users' Group to launch an
initiative to produce reports on issues of typical concern to
SGML systems implementors (ie human, contractual and technical
issues). These reports would be distributed through the Users'
Group membership to facilitate their work.
Yet again, calls were made for the publication of conference
papers -- either by the GCA or the Users' group. A
recommendation to this effect will be put to the Users' Group
Committee.
16. The Society of Automotive Engineers J2008 Task Force -- Jim
Harvey (Volt, USA)
J2008 is a standard for the automotive industry which resulted
from the passing of the Clean Air Act. J2008 will shortly appear
as a published document.
Producing J2008 involved setting up a number of committees to
look at: data modelling (ie what data should be brought
together?), DTD development, Administration, Orientation,
Communication and Graphics (TIFF, CGM). Bringing the DTD and
Data Model together had revealed some problems however two
manufacturers are now testing the DTD, and their comments will be
taken into account when it is revised for publication.
Manufacturers aim to use a database of J2008-conforming documents
for publication; third party information provider will be able
to take J2008-conforming data and re-use the information to
supply to independent service providers.
J2008 makes no recommendations about the hardware or software
anyone should use but all adherents to the standard will want
to re-use their data as much as possible. A draft version of the
DTD will soon be publicly available for comment.
17. The Air Transport Association/Aerospace Industries
Association, Rev 100 -- Diane Kennedy (Datalogics, USA)
ATA is a written specification (cf CALS), first issued in 1956
and currently undergoing its thirty-first revision. In the 1988,
revision of ATA 100, it was decided that SGML should be the
standard for the interchange of electronic data (with graphics
conforming to CCITT 4 and CGM).
Revision 31 of ATA 100 (approved two weeks ago) includes six DTDs
for Aircraft Maintenance Manuals, Aircraft illustrated Parts
Catalogues, Engine Shop Manuals, Engine Illustrated Parts
Catalogues, Service Bulletins, and Master Minimum Equipment
Lists. ATA's first attempts to develop a DTD had relied on a
single small group which had proved to be very slow.
Consequently, a set of controls were specified to speed up DTD
development -- including the setting up a strong committee
structure to handle DTD development and approval, and the
production of a DTD requirements document and an industry
glossary. All six current DTDs have been harmonized for revision
31.
The DTD working groups have a majority membership of subject
matter experts (with little/no SGML experience), with the bulk of
SGML work being done by SGML experts working in conjunction with
the groups. SGML DTD modelling is done using structure charts.
Conformance to the ATA DTD recommendations is voluntary -- so
they have introduced four levels of DTD to allow for options
based on manufacturers' needs.
* Level 1 DTDs (DTD is precisely defined; no options; all
tags in glossary)
* Level 2 DTDs (DTD is precisely defined; options allowed,
all tags in glossary)
* Level 3 DTDs (DTD defined by document producer following
ATA framework; all tags in glossary; used where there is
minimal agreement between a group of manufacturers).
* Level 4 DTDs (DTD defined by document producer; all tags
in glossary; used for unique documents - ie where one manufacturer
produces a unique product).
All document revisions are strictly controlled and recorded. The
have adopted the CALS approach to tables.
In 1993, the number of DTDs within the ATA is expected to more
than double. Many airlines are automating to take advantage of
such new publication/information standards.
18. The Davenport Group for On-line Documentation -- Various
Speakers
Fred Dalyrymple (FD) summarized the reasons for the formation of
the Davenport Group. Manufacturers, vendors and users had all
experienced the frustrations of working with proprietary
solutions, and wanted to take advantage of emerging standards
such as SGML and HyTime. Standardizing information would enable
generalized, shareable help systems, on-line documentation,
virtual libraries, information webs etc. The Davenport group had
established four working groups, dealing with
* architectural forms (producing DASH and SOFABED
standards)
* the Committee for the Common Man
* SGML Query Language
* SGML Resources (cf. the CALS Registry and Library)
In January 1992 a Davenport workshop on Architectural Forms was
held, in the hope that this would enable the unification of
several manufacturers DTDs. At that time, not many people knew
about HyTime, which was still a Draft International Standard.
General aims included
* unifying DTD linking specifications (via HyTime's
Architectural Forms)
* enabling equal access to diverse technical documents
* separating link descriptions from access methods
* enabling the assembly of several documents into compound
documents
* enabling document publication in a variety of media from
a single source document.
So far, they have produced the Davenport Advisory Standard for
Hypermedia (DASH) document -- which includes specifications
relating to producing indexes, glossaries, bibliographies, tables
of contents and cross references. Participants have also gained
a working knowledge of HyTime. The workgroup responsible for
producing the DASH has been very productive, and once they have
published a final version of the document (due soon), the group
will be disbanded.
Lar Kaufman spoke about the work of the Committee for the Common
Man (where "man" alludes to the Unix command to request on-line
documentation, and the set of macros used to produce such
documentation). Originally a separate endeavour, the CftCM had
soon decided to work within the Davenport Group.
The CftCM had emerged following a discussion on the USENET
newsgroup comp.text.sgml, and had worked largely through email
correspondence between expert volunteers. To their surprise,
they had found "man" papers to be less consistent, structured and
uniform than they had first imagined. The results of their work
will be posted to comp.text.smgl as a "White Paper", with a
request for comments. It should be noted that the CftCM envisage
completely portable "man" pages, -- ie across all systems (not
just UNIX). Although they have defined a tag set, they have not
yet agreed a heirarchical structure for the tags -- they also
still need to consider how to convert the `legacy data' of
existing "man " pages, and how best to take advantage of the
existing tools for viewing/manipulating "man" pages.
19. Implementing a HyTime System in a Research Environment --
Lloyd Rutledge (University of Massachusettes, USA)
It is very difficult to report the content of Lloyd Rutledge's
(LR) presentation -- since it relied very heavily on complex
schematic diagrams showing a number of models. LR showed a model
for his HyTime Hypermedia Presentation System and also one for
the data layers in the system.
Much of his presentation focussed on a diagram showing a model of
his Hyperdocument Processing System being developed at the
University of Massachusettes. Built around a shared database,
the model included a conventional SGML parser, through which all
SGML/HyTime input to the system had to pass. The results of
passing files through the parser are stored in the database.
Next, a HyTime Engine takes in the output of the SGML parser and
checks the HyTime-specific markup; it can query the SGML
document stored in the database, if necessary, The output of the
HyTime Engine is also stored in the database.
The output from the HyTime Engine is also passed to a HyTime DTD
(HDTD) processor (which can also query the HyTime Engine's output
to the DTD). The HDTD processor outputs to the hypermedia
presentation system (ie the application), and takes queries from
it which the HDTD processor in turn uses to query the database.
In the case of large documents and/or interactive processing,
some outputs of the HDTD processor may have to be passed back to
the SGML parser -- eg if the processor needs to open a particular
file (which will have to go through the SGML parser and HyTime
Engine as usual, before it can be used by the HDTD processor).
20. Poster Session -- Various Speakers
This poster session looked at the problems of handling tables
within SGML. There were ten presenters, covering many of the
concerns about tables. Since poster sessions thrive upon ad lib
discussions, I have not reported them here.
21. The User SGML at the Boston Computer Society -- Sam Hunting
and Irina Golfman
Sam Hunting (SH) gave some of the background to the Boston
Computing Society -- which is the world's largest user group
(c.25,000 members), is organized by volunteers, and publishes
around 25 newsletters, maintains bulletin boards and help lines
(each of which represent document content).
SH identified the typical problems of maintaining information in
conventional print or electronic form. Document content cannot
be easily retrieved, repackaged, or delivered in a number of
different media from a single source. Presentation of such
information is enforceable only by editorial staff working to
strictguidelines, and conventional page markup is difficult to
automate.
SGML allows information content to be retrieved, repackaged and
so forth; it can also permit the enforcement of house-style
structures (thereby permitting automated page makeup). The
Boston Computer Society has the same difficulties implementing
SGML as many other organizations have experienced -- resistance
from staff, lack of SGML expertise, no easy to use, attractive,
interactive SGML applications, no "shrink-wrapped" tools to
process SGML etc.
Irina Golfman (IG) described how they had tried to overcome the
problems of implementing SGML. Volunteers had had to be educated
so that they could develop some enthusiasm for SGML. Vendors of
SGML-aware products had been invited to give presentations. The
Hypertext-subgroup sponsors the "SGML Panel", to discuss the
practical implementation issues of using SGML. A growing number
of BCS print publications would be produced from SGML source
files (at present four newsletters are done in this way).
Several other projects and activities were also envisaged.
22. Document Management in Production Publishing Environments --
William Trippe (Xyvision, USA)
Xyvision sells UNIX-based production publishing systems. William
Trippe (WT) reported that they are encountering a growing
interest in the use of SGML within traditional publishing
organizations. Xyvision's experiences have shown that there are
great production benefits to be gained from using SGML -- and
that one of the keys to successful SGML system implementation and
acceptance is satisfying the concerns of editorial personnel.
However, WT remarked that it is important to remember that large
SGML applications require lots of computing "horsepower" (eg
large CPU, memory disk storage, fast backup devices etc.)
In order to ensure its success, WT recommended that SGML needs:
* more of an infrastructure
* standard data modelling techniques
* standard training and documentation tools
* a more helpful and obvious vocabulary
* more helpful tools
23. An SGML Pilot Project: The OSTI Reports Received List --
Norman Smith (Science Application International Corporation, USA)
The Office of Science and Technical Information (OSTI) maintains
a large energy science and technical database (2 GB of data, with
a 14 month maintenance window). The database can be used to
generate bibliographies, reports etc.
The Reports Received List is a paper document produced to
accompany the microfiches of all the reports received at OSTI
each week. Norman Smith's (NS) pilot project aimed to produce
the Reports Received list as an SGML document. Since it was
already highly structured, it was quite straightforward to alter
their existing structured production process to output an SGML
document. They also wrote an electronic document viewer (as a
stand-alone application) -- which adds value to the SGML document
and offers potential benefits for other SGML applications that
might be developed at OSTI.
NS summarized the lessons that they learned from their
experiences during the pilot project
* Document analysts and application programmers must work
closely together
* Treat DTD development as a software development project
* SGML applications are easier to develop when approached
from a database-oriented perspective.
* use selective parsing
* add value to distributed documents (by producing tools
etc) for non-SGML users.
NS also offered the following hints for anyone about to embark on
an SGML pilot project:
* pick something do-able but not trivial
* keep it simple and non-critical. (If it succeeds
good. If it fails - it can be thrown away).
* approach from a database perspective
* involve the whole organization
* work within the h/w s/w framework provided
* provide adequate resources for the project
* don't be afraid to try unconventional approaches
24. Frame-Based SGML -- Len Bullard (Paramax, USA)
Len Bullard demonstrated the Interactive Authoring and Display
System (IADS) that Paramax had developed to create and deliver
frame-based SGML. The demonstration content discussed the nature
of frame-based SGML. IADS was running under MS-Windows, taking
raw SGML frames and displaying them interactively.
A "frame" is an addressable SGML node in a map of SGML nodes.
The map of frames is a flat file web of frame nodes connected by
links. Len Bullard showed the element declarations for the
frames, buttons, hotspots etc that are hard-coded into the SGML
file(s) which underlie IADS.
25. SGML as Foundation for a Post-Relational Database Model --
Tim Bray (Open Text Corporation, Canada)
Tim Bray (TB) discussed how current attitudes to text processing
limited the usefulness of the entire process. For example,
current opinion tends to reflect such statements as:
* files belong to applications
* good printout = good application
* data sharing = data conversion
* no ad hoc access to information
* intolerable application backlog
He proposed that the field of MIS had been a comparable mess
prior to the adoption of a number of techniques -- which could
also be usefully employed in the text processing arena. These
techniques included:-
* data centering via database management
* data modelling for system and language
* using a database access language
* indexing for performance
* using 4GLs and GUIs
* using administration features (eg concurrency control,
transaction model, an audit trail etc).
However, unlike MIS, TB argued that the field of text processing
could not adopt a relational approach to implementation (cf the
success of Relational Databases within MIS).
TB argued that text processing could not follow a relational
model because:
* text is tabular and not normalized
* in text, nothing above the character level is atomic
-- so entity-relationship modelling is hard
* neither the relational algebra nor calculus are an
effective Data Access Language for text.
* it is possible to decompose a DTD into a relational
schema, but it is a bad idea (except in cases where
documents are of an identical, tabular structure eg insurance
claim forms.
With regard to the techniques mentioned earlier, TB proposed that
SGML represented the data modelling system and language. A
database language is under development (eg DSSSL). We are
already able to index for performance use 4GLs and GUIs and make
use of database administration features. All that is now
required is an SGML-based, post-Relational implementation.
26. The SGML View of a Database -- Bob Barlow, Fritz Eberle
(AGFA, CAPS)
Bob Barlow (BB) began by stating that when people are considering
implementing an SGML database, they are confronted by a number of
questions "To what level of granularity should I store my
data?", "How do I identify the stored objects?", "How do I
accomplish revision control?" Granularity issues will affect
the pieces of data that are available for use/re-use, location in
the database etc. Identifying objects involves considering if
there is a relationship between SGML element IDs and database
IDs, how to link to SGML objects, what information is stored in
the database, and what is stored in SGML attributes. Revision
control could be carried out within the SGML document or within
the database environment.
Fritz Eberle offered some general approaches for resolving the
sorts of questions raised by BB. For example, when considering
approaches to SGML document management, it is possible to exploit
structure at the element, entity or content level -- or a
combination of any of these. One of the interesting cases raised
in Fritz Eberle's presentation was an example where two
hyperdocuments share the same entity; whilst the entity is the
same, the links that each uses to retrieve the entity may have
different names.
27. SGML Queries -- Paula Angerstein (Texcel, USA)
Paula Angerstein (PA) as Chair of the panel dealing with the
afternoon's topic of SGML and Databases, took this opportunity to
say something about SGML queries. Essentially a query is a
question about what is in an SGML document or documents. As far
as users are concerned, they want access to all the information
in the document which will resolve their query. However, PA
pointed out that developing an SGML query language raises a
number of issues, namely:
* whether to query parsed or unparsed data
* whether to query the ESIS and beyond
* applying queries to classes vs instances
* allowed "root" of a query
* user interfaces to the query language
PA had asked all of the panel speakers (who had developed query
languages) to discuss their approaches to resolving a number of
test queries.
27.1. Comparative Implementation of the SGML/Search Query
Language -- Francois Chahuneau (AIS/Berger Levault, France
SGML/Search is the name of both a query language, and a system
implementing this language developed by AIS (running on top of
PAT/Lector from OpenText). SGML/Search considers the document
(or documents), if all conform to single DTD) as a database. It
uses some of the structural information given in the ESIS, it
loads SGML documents and extracts SGML fragments, and it returns
SGML fragments in response to queries.
SGML/Search can user numerous filtering conditions to refine its
queries -- ie element type, element hierarchical position,
structural or lexical distance (from a known point), attribute
constraints, logical connectives to combine queries, set
operations etc.
Francois Chahuneau (FC) showed how SGML/Search would handle the
sample queries proposed by Paula Augerstein, then went on to
discuss some queries, which would be "impossible" within the
syntax of SGML/Search (though the queries could be resolved in
other ways).
FC compared SGML/Search queries to DSSSL queries -- pointing out
that SGML/Search is oriented towards fragment retrieval rather
than processing and that an SGML/Search query target can only be
an SGML element. He claimed that any valid SGML document can be
imported into SGML/Search -- giving full access to the SGML
structure and text content, as well as high indexing and search
performance via PAT's full-text engine. SGML/Search is an open
tool for systems integrators -- offering a forms-based GUI and a
complete API accessible to C/C ++ programmers.
27.2 Structured Queries and Location Models: DSSSL -- Paul
Grosso (ArborText, USA)
Paul Grosso stated that DSSSL queries are useful for locating
objects within a tree that are going to be acted upon. He also
reminded everyone that the DSSSL query language is only one
component of the whole DSSSL standard.
The DSSSL query grammar is based upon several premise, namely
that:
* a query works on a tree of digits
* objects have object attributes
* a query uses relationships based on pre-order traversal
of the tree
* a query uses information from both structure and
"content"
* a query can "start" from the tree root, or any object, or
set of objects
PG went rapidly through a series a slides describing the DSSSL
query language in more detail, then showed how DSSSL queries
would be written to satisfy the text cases supplied by Paula
Angerstein. Readers who wish to know more about DSSSL might
try contacting PG through the conference organizers.
Alternatively they could contact the committee of their national
standards body assigned to consider DSSSL.
27.3 Structured Queries and Location Models: HyQ -- Steve
DeRose (Electronic Book Technologies, USA)
HyQ is the portion of HyTime concerned with querying. Querying
is a central part of hypertext, and developers require systems to
have both authored linking and dynamic querying. Steve DeRose
(SD) characterized a query as a mechanism for specifying sets of
things -- where a set of things is a "node list" (HyTime-speak
for an ordered list of locations in the information world,
locations can be spread across any number of documents and can be
at any level from characters to the world!)
HyQ provides a number of functions for operating on node lists
set operations, list processing, filtering/selection operations
etc. SD did not have the time to cover the features of HyQ in
any real detail, and interested readers should try retrieving
information from another source (ie see remarks at the end of the
previous section, or contact SGML SIGhyper). SD summarized the
design principles that underlie the HyQ query language:
* must be adept, not just capable, in order to deal with
complex trees
* must handle multilingual data and different SGML syntaxes
* must provide natural access to all SGML phenomena
* it is not designed for end-users to type in (it will be
hidden behind 4GLs and GUIs)
* it has a macro mechanism to make it manageable
SD then talked through the HyQ solutions to the sample queries
distributed by Paula Angerstein.
27.4. Structured Queries and Location Models: SFQL -- Neil
Shapiro (Scilab Inc, USA)
Neil Shapiro (NS) reported on the ATA's experiences of querying
with SQL (the precursor to SFQL). SFQL is being developed in
response to the drive to produce Interactive Electronic Technical
Manuals (IETMs) -- which consist of both data and applications,
requiring quick and intelligent access to the information they
contain. Typical IETMs are distributed on CD-ROMs and involve
using very large files. Current problems arose from the fact
that proprietary access software (requiring proprietary indexes)
lead to software dependence. A typical airline will receive
several IETMs from different manufacturers, and each will
necessitate the use of different user interfaces (which is
clearly unsatisfactory).
The ATA solution is to work towards software independence,
dividing the search engine (server) from the user interface
(client). This means the server can represent data in a
proprietary format, but the user will only see a single user
interface. NS put up the following model diagram
User interface (client)
^ |
| |
| |
--------|-------|------- can standardize this
| | | | area (the server
| | | | request language
--------|-------|-------
| |
| |
| v
Search engine (server)
Possible standards available to the ATA for the server request
language are SQL (structured Query Language) and Leverage SQL.
SQL has been extended to give better support for text-based
queries; the new version will be called SFQL (Structured Full-
text Query Language). SFQL will support such things as:
* fielded searches
* advanced searches (using fuzzy matches)
* retrieval control (relevance ranking, projection)
* extended data types (SGML, CGM, TIFF CCITT etc).
SFQL is an abstract access model, which conceals all index and
storage design differences whilst the SFQL conceptual model
enables views of data without saying how it should be stored.
After reminding everyone that users should look for software
independence, and not just data portability, NS went on to show
how SFQL would resolve Paula Angerstein's sample query.
28. Structured Queries and Location Models, Part II -- Various
The idea of this session was to build on the query language
presentations given earlier. Initial comments revealed that
DSSSL will only work with SGML documents, whilst HyQ needs to be
able to support both SGML and other types of document. HyQ does
not have the higher level constructs of some query languages, but
this is intentional and can be circumvented by developing HyQ
macros.
Unfortunately the discussion degenerated into little more than a
series of accusations and counter-accusations about what the
various query languages could do and how efficiently they
achieved this. It was mostly impossible to distinguish facts
from opinions -- and perhaps the point most clearly demonstrated
during the session was that the ISO standards developers held
SFQL in low esteem.
29. Transforming Airworthiness Directives from Paper to CD-ROM --
Hally Ahearn (Oster & Associates Inc., USA)
The first half of Hally Ahearn's (HA) talk was a conventional
overview of SGML theory -- looking at such issues as the SGML
processing model, the SGML Document, SGML as metalanguage, the
role of the parser, the process of document analysis, and when to
use private or public entities.
In the second half of her presentation, HA demonstrated how ASCII
output from a word-processing system could be successively marked
up and parsed to give ever greater levels of structural encoding.
The file could then be edited using SGML-aware structure editing
tools so as to fully prepare it for processing for storage in a
database and/or display via a presentation system.
30. The Development of a Technical Support Database for On-Line
Access and for Publication on CD-ROM -- Elizabeth Jackson (K.E.B.
Jackson Consulting)
Elizabeth Jackson gave a high-level overview of the work she had
done towards producing HelpdisQ -- a database of multi-vendor
technical support for PC hardware and software products
(published as a CD-ROM in May 1992). Regrettably, this
presentation lacked detailed information, which was only
available in a handout available at the conference.
31. The Making of Microsoft Cinemania: SGML in a Multimedia
Environment -- John McFadden (Exoterica Corporation, Canada)
Throughout this presentation John McFadden (JM) was able to
demonstrate the main features and capabilities of MicroSoft's
"Cinemania" CD-ROM. The disk has only been available for about
three weeks and costs $79 -- although Microsoft had spend nearly
$5m to produce it.
Running under MS Windows, the user interface is a typical mix of
windows, buttons and icons to access the Cinemania data. As well
as selecting particular films, the user can call up glossary
definitions, film-star biographies, academy awards lists, sound
clips and video stills. The Cinemania database contains five
traditional publications converted into a single SGML document
database. The CD-ROM contains 22Mb of markup and text (the DTD
is 64kb) -- and a total of 220Mb of data and software (so the
disk is still less than half full!). The Cinemania database
also contains 1.6 million identified SGML elementa, with typical
element granularity of ten characters per element (cpe) whilst
name elements typically have a granularity of 2cpe. The database
stores 19000 movie listings, 300 biographies, 500 articles, 745
reviews, a glossary, 175 still video clips etc.
The original paper documents were re-keyed to give an electronic
form, which was automatically tagged, marked-up, and quality
controlled using Exoterica's "OmniMark" product. Exoterica's
internal "CheckMark" product was used for any final structural
editing, and to handle exceptional cases which had not been
tagged automatically. The resulting SGML was stored in an SGML
Knowledge Base. Microsoft then took the SGML Knowledge Base,
used OmniMark to control linking, flow and formatting (and some
presentation design experience), to get the SGML data into the
Microsoft Multimedia Viewer -- which is the front-end
presentation system used to create the "Cinemania" product that
users actually see.
Looking at some instances of conventional SGML encoding JM showed
how OmniMark could greatly simplify the markup which has to be
added to a document. This markup stood in for conventional raw
SGML encoding -- which made it much easier for authors with
little SGML experience to edit the document.
Exoterica worked hard to ensure that the resulting SGML Knowledge
Base was completely independent of its intended use (eg it would
now be a simple matter to create new electronic/paper books based
on selected extractions from the Knowledge Base). There are no
explicit links in the markup; these are generated when the data
is translated for the Multimedia Viewer -- which makes updating
or amending the data in the Knowledge Base, or even adding new
categories, very much easier.
Approaching the development in this way had proved to be very
fast and economical. They have produced an extremely
maintainable and adaptable information resource with guaranteed
quality levels. OmniMark had been used to expedite things at
almost every major point in the development of the system. JM
also reserved high praise for MicroSoft's MultiMedia Viewer,
which only costs $495.
32. Process of Converting from Paper Documentation to SGML Based
CD-Rom -- Ken Kershner (Silicon Graphics, USA)
Ken Kershner (KK) stated that the reason behind Silicon Graphics
decision to adopt SGML had come from their wish to enable the
company, its developers and customers to deliver technical
reference information (in electronic form, for publishing on
paper or on-line). This was a very visual demonstration, with
the results of Silicon Graphic's effort being displayed and
discussed throughout.
The benefits of using SGML included:
* reduced printing and freight costs (=money saved)
* reduced hot line calls (=money saved)
* quick information retrieval (=money+time saved)
* creating allies in manufacturing and Customer Support
The SGML-based electronic technical reference information system
produced is called IRIS InSight. It provides "one-stop-shopping"
for on-line documentation, support information, and tightly
integrated digital media. Although all the source files are in
SGML, these are compiled into books for DynaText (Electronic Book
Technologies browser) to display to the user.
Usability tests of the pre-alpha release of IRIS InSight using 16
novice users, had tested link behaviour and task times. Results
showed that users preferred scrolling within books to
conventional methods of displaying on-line technical information.
Task times averaged 10.2 minutes.
Taking what they had learned from the first session, Silicon
Graphics conducted a second usability test at the pre-beta
release stage of development, also using 16 novice users. They
tested user preferences to on-line vs paper documentation; they
were a little surprised (based on previous research) to find that
task performance using on-line documentation was equal to that
using paper. Task times averaged only 4.3 minutes. The
researchers believe that as users become more accustomed to using
on-line documentation, their efficiency will improve, as will the
users' learning curve.
KK identified a number of traps to avoid when developing such
projects:
* there can be conflicts during development between
sticking strictly to the standards and guidelines that
have been adopted, and getting a working product.
* beware of underestimating the effort involved in
converting data beware of underpowered hardware
* avoid making any dependency changes when development is
nearing a milestone point.
* start licencing discussions early
KK then identified the things Silicon Graphics would do again on
a similar project:
* get together a committed engineering team
* use outside experts
* survey customers
* build a multi-functional team (including authors,
editors, trainers, customer support, software engineers etc.
* pick the pilot project very carefully
* document the entire development process.
33. Converting 180+ Million Pieces of Paper -- Eric Freese (Mead
Data Central, USA)
Mead Data Central maintain a number of massive, very diverse
databases of textual information. Their holdings currently
represent the equivalent of 180 million pieces of paper, to which
another 40 million are added annually.
Erice Freese (EF) gave some of the reasons why Mead had decided
to convert all their electronic data to SGML form -- primarily to
take advantage of SGML's device, application and language
independence, and to use related standards such as HyTime and
DSSSL. The more structural information they can capture in their
encoding scheme, the easier it will be to provide satisfactory
responses to users' queries and requests. For the SGML data they
already process, they have adopted the FOSI approach (from CALS)
to get formatted output, but they will certainly adopt DSSSL once
a stable standard and software tools have appeared. EF claimed
that because of the huge range of document types stored in Mead's
Databases, they will ultimately need to develop between 4,00-
7,000 DTDs (and 8,000-14,000 FOSI's to allow for paper and on-
line formatting).
The conversion process will need to be almost entirely automated,
as it would be unrealistic, if not impossible to do it by hand.
The conversion process is due to start in 1994 and will need to
handle 1.5 million documents a day. The production of database
definitions, DTDs and FOSIs is expected to take only 5 months
whilst the actual conversion of the documents themselves is
scheduled to take only 6 months. The result will be one of the
largest SGML applications in the world.
EF believes that standards such as HyTime will become ever more
important to them over time. The sort of search and retrieval
systems he envisages for the future at Mead include:
* distributed environment (possibly world wide)
* GUI
* Multimedia - hypertext, graphics, video, audio
* international sources and delivery (10+ source languages,
multilingual documents, and possibly even automatic language
translations)
34. Poster Session: Conversion -- Various Speakers
This session considered various approaches to, and experiences of
converting to and from SGML documents.
35. Back to the Frontiers and Edges -- Michael Sperberg-McQueen
(University of Chicago, USA)
This was the closing keynote speech, in which Michael Sperberg-
McQueen speculated on some of the SGML-related developments he
expected and/or hoped to see over the coming years. Amongst a
long list of various issues that he raised were such points as
"Will we find a way to encode semantics?", "Will a methodology
for developing DTDs evolve?" and a number of similar questions.
The full text of this presentation is given in Appendix II)
For further details of any of the speakers or presentations,
please contact the conference organizers are:
Graphic Communications Association
100 Daingerfield Road, 4th Fl.
Alexandria VA 22314-2888
United States of America
Phone: (703) 519-8157 Fax: (703) 548-2867
=================================================================
You are free to distribute this material in any form, provided
that you acknowledge the source and provide details of how to
contact The SGML Project. None of the remarks in this report
should necessarily be taken as an accurate reflection of the
speaker's opinions, or in any way representative of their
employers' policies. Before citing from this report, please
confirm that the original speaker has no objections and has given
permission.
==================================================================
Michael Popham
SGML Project - Computing Development Officer
Computer Unit - Laver Building
North Park Road, University of Exeter
Exeter EX4 4QE, United Kingdom
Email: sgml@exeter.ac.uk M.G.Popham@exeter.ac.uk (INTERNET)
Phone: +44 392 263946 Fax: +44 392 211630
APPENDIX 1
THE SGML YEAR IN REVIEW 1992
by Yuri Rubinsky, SoftQuad Inc
STANDARDS ACTIVITY
1. The highlight of the SGML year, I think most people would
agree, was the adoption of HyTime as an international standard.
Sort of like a child born already having been accepted into a
good university, HyTime has been considered for some time a
necessary component of many initiatives, including the grand old
US DoD CALS. I think we're going to see an outburst of activity
and creativity revolving around HyTime over the next year.
The standard will be published shortly by ISO in Geneva. Copies
will be available from national standards bodies like ANSI and
BSI; there will probably be a few authorized redistributors like
GCA and TechnoTeacher.
2. Conformance Testing Initiative: Spearheaded by the GCA in the
US and the National Computing Centre in the UK, the SGML
conformance testing initiative slowly but surely attempts to
gather the momentum (and money) it needs to proceed. There seems
to be general agreement that independent testing of SGML
capabilities is needed (with some vocal exceptions citing
examples of the market deciding what conformance means) but no
agreement whatsoever on where the money should come from.
Nonetheless, the GCA GenCode Committee continues to explore the
possibilities.
3. The SGML Review: ISO regulations call for a review of each
standard around the time of its 5th birthday. That review will
continue over the next few months; Dr. Goldfarb is chairing the
Special Working Group on SGML and invites comments and
suggestions.
4. From Jim Mason, Convenor of WG8, comes the following news
clip:
"There are two query languages for SGML documents being developed
in ISO/IEC JTC1/SC18/WG8: HyQ, as part of HyTime, ISO 10744; and
an unnamed language as part of DSSSL, ISO/DIS 10179. We are
developing two languages because these two standards, while they
both manipulate SGML documents, are partially complementary in
scope and functionality. DSSSL deals with pure SGML files.
Although HyTime requires the `hub document' to be in SGML,
subsidiary documents may be in any format, including binary
digitized audio or graphics. DSSSL and HyQ both operate on
property sets defined in SGML. DSSSL's location model is entirely
in terms of SGML structures (where an element is in the tree, its
relationships to its siblings, and so on). HyTime also needs to
deal with finite coordinate spaces (this happens three seconds
after that). As of the September meeting of WG8, we feel that in
areas of simultaneous interest, there should be simple mappings
between the languages."
5. DSSSL, which I hope will be the highlight of next year's Year
in Review, is expected to go out for a second draft ballot about
April, 1993.
USER GROUP ACTIVITY
1. Here's a good piece of "you heard it here first" news: Today,
[Oct. 26, day one of SGML '92] on the other side of the planet,
that is, about 12 hours from now, the Australian National SGML
User Group is being formally incorporated under the name SGML OZ.
Chaired by Carlyle Nagel, the group's inaugural sponsor is Xerox
Australia, who, in Carlyle's words, "provide the tea and
biscuits". Congratulations to that group on this exciting and co-
incidental day
2. A Mid-Atlantic SGML Users' Group has been formed, catering to
SGML Users' living in Atlantis. Well, the Washington D.C. area
actually.
3. With the International SGML Users' Group having started in
the United Kingdom, it was often easy for everyone to think of
the International group as meeting the needs of a local chapter,
but of course local chapters have a separate role to fulfill, and
accordingly those big islands finally have their own U.K. SGML
Users' Group with Nigel Bray as Chairman.
4. The Southern Ontario User Group (covering a broad sweep of
area more or less centered on World-Series-winning Toronto,
Canada) recently held a successful vendor day and continues to
publish its newsletter.
5. A Seattle User Group has begun, under the sponsership of DEC.
6. Meanwhile in Colorado, what I mentioned last year as the
planned Boulder SGML User Group finally got off the ground last
month with its first meeting and a working name of The Rocky
Mountain SGML Entity.
7. The Dutch Chapter of the SGML Users Group reports that it had
a difficult year, due to the resignation of Dieke Van Wijnen as
secretary of the Group. In September the group found a new
secretary and now activities are resuming, including on November
25th, a one day conference on the managerial implications of the
introduction of SGML applications. On December 9th, the annual
meeting of the group will be held.
MAJOR PUBLIC INITIATIVES
1. The Air Transport Association/Aerospace Industries
Association subcommittee responsible for text standards has just
released Revision 31 of Specification 100. This standard includes
six DTDs covering a range of technical maintenance publications
(including Aircraft Maintenance Manuals, Engine Ship Manuals and
Service Bulletins). The new spec also includes a DTD Requirements
Document and an SGML Data Dictionary (an industry-wide list of
reusable elements and attributes).
2. Latest news on the CALS front is that MIL-M-28001B is
expected to be released about March. Revision B will include
significant changes in the Appendix B Output Specification, a
tagging scheme for partial document delivery requirements, and a
tagging scheme meeting the requirements for electronic annotation
and review requirements.
MIL-STD-1840B availability will be announced at CALS Expo '92. It
is expected to provide more flexibility in data delivery such as
accomodating other data types, device-independence, and tape
medium.
3. The Commission of the European Communities (CEC) is funding
the TIDE (Technology Initiative for Disabled and Elderly people)
Pilot Action.
Within TIDE, the Communication and Access to Information for
Persons with Special Needs (CAPS) project started in December
1991, and will last until the end of March 1993.
This project's main objective is to provide broader access to
digitally distributed documents (especially newspapers, books and
public information) to a significant group of handicapped and
elderly persons who have difficulty in accessing the printed word
and/or electronic information. The print disabled group includes
the blind, the deaf blind, the visually impaired, the dyslexic
and those with motor impairments that make it difficult to
physically control paper documents or to use traditional methods
for computer access.
Working with the CAPS committee, Manfred Kruger of MID has
written a DTD for electronic delivery of newspapers including
such interesting and once-you-think-about-it-perfectly-sensible
constructs as an entity for an "invisible blank". This is the
character that tells a voice synthesizer to break the current
word into parts which are pronounced separately.
4. In a related item, a related committee with some overlapping
membership, a working sub-committee of the International
Committee for Accessible Document Design, has completed a draft
DTD to support the formatting of braille from SGML. This DTD was
accepted by the full committee last week and will now go forth to
the Texas legislature to become part of state law regarding
accessible electronic versions of all textbooks approved for use
in the state educational system. Anyone interested in learning
how to make new or existing DTDs "braille-ready" should contact
the author at SoftQuad. (+1 416 239-4801)
5. In a single year, the Davenport Group, as part of its
"Davenport Advisory Standard for Hypermedia (DASH)" activity,
started (in January) and by December will have completed the
design and publication of a set of HyTime-based SGML
architectural forms, tentatively dubbed the "Standard Open Formal
Architecture for Browsing Electrical Documents," for the standard
representation of indexes, tables of contents, glossaries, and
cross references, for use with online documentation on Unix and
Unix-like Open Systems. Unix International, the Open Software
Foundation, Novell and others participated in this development,
and the Open Software Foundation is probably going to implement
the SOFABED architectural forms immediately.
6. X Consortium, the people who brought you X-Windows, has been
presented with a protocol, proposed by Kent Summers of EJV and
Jeff Vogel of EBT, for online help servers. The proposal puts
forward a scheme which takes advantage of the hierarchical
tendencies of SGML models but also can support anything else that
has a notion of unique identifiers.
7. As evidenced by the turnout from the drug industry at SGML
'92, there is strong interest in SGML from the point of view of
the manufacturers and of the US Federal Drug Administration.
Simultaneous with the first two days of this conference is a
CANDA (Computed-Assisted New Drug Applications) conference in
Washington, at which they are discussing SGML. The FDA has said
it wants electronic submissions of New Drug Applications by 1995
and is interested in experimenting with SGML. The Pharmaceutical
Manufacturers Association Task Force has suggested an SGML pilot
project.
8. The CAD Framework Initiative (CFI a good example of a
nested acronym) has a task force to develop a semiconductor
industry SGML application for use in transferring component
documentation within the industry. This group deserves special
mention for its formal name:
CAD Framework Initiative Design Information Technical Committee
Components Information Representation Technical Subcommittee
Electronic Data Book Working Group Technical Documentation
Interchange Standard Task Force.
9. The US Congress' 1990 Clean Air Act requires that by 1996 car
manufacturers provide all emissions system documentation to
anyone who requests it. That will be done in SGML, in an
application known as J2008 and created by a subcommittee of the
Society of Automotive Engineers.
10. Formatting images for CD-ROM publishing and other electronic
image management systems can be made easier if there is an
organized scheme to follow. The Association for Information and
Image Management C15.9 standards committee members are developing
a scheme for generating image tags, based on Standard Generalized
Markup Language (SGML), that will be compatible with numerous
image indexing and retrieval products. The objective of the
project is to assist users by providing a versatile path for
converting image files into other publishing systems' proprietary
formats or database files. The project is entitled Compact Disk
Read Only Memory (CD-ROM) Application Profile For Electronic
Image Management (EIM).
11. A healthy collection of standards bodies, including AFNOR,
BSI, DIN and the IEEE are all looking at using (and modifying as
necessary) the DTD in the "ISO Technical Report 9573: Techniques
for Using SGML" for standards creation and production.
The Canadian Standards Association is developing, with
InfoDesign, a new SGML-based information and publishing system,
currently in pilot test phase, to encompass all facets of the
standards development process at CSA. When complete, the
information and publishing system will allow all data relevant to
a document to be created directly in SGML allowing its retrieval
in both view-only format and editable SGML text, and publishing
to both hardcopy and CD-ROM directly from SGML.
12. The Text Encoding Initiative is nearing completion of the
second version, much after the hoped-for date, but
correspondingly more thorough and well thought out. A number of
major commercial publishers are encoding considerable volumes of
material in TEI (Chadwyck-Healey and Oxford University Press,
among others).
13. The European Workgroup on SGML is working on a DTD for
scientific journal articles, the so called MAJOUR Article DTD
(Modular Application for JOURnals). This DTD is based on the AAP
Article DTD and is intended as an exchange format between
scientific publishers, typesetter and printers, and database
hosts. Since last year, when the MAJOUR Header DTD was presented
at the International Markup Conference 1991 in Lugano, the EWS
has been working on the Article DTD, particularly body, tables,
figures, math, and back matter. The first draft version was
finished in February '92. Work on individual parts and the
documentation is still going on. The MAJOUR Article DTD is
scheduled to be finished by the end of the year and will be
presented at International Markup 1993. The EWS is trying to take
into account and harmonize its own work as far as possible with
the work and the results of other initiatives in the field such
as the AAP Tables/Math Update Committee and the AAP Article DTD
Update.
14. In April, Pam Gennusa of Database Publishing made a
presentation on SGML to the Text Working Party of the
International Press Telecommunications Council in London. In May,
the Associated Press hosted a seminar to introduce SGML to North
American print and broadcast media and vendors. At the June
meeting of the IPTC working parties and Standards Committee in
Toronto, the AP presented an initial draft of NIML, a News
Industry Markup Language, intended as a first step towards a full
SGML implementation for news text.
The NIML draft has since been republished in SGML News in
Australia, and been added to the libraries on CompuServe's
Journalism Forum. The IPTC has formed a joint SGML working party
with the Newspaper Association of America and the Radio-
Television News Directors Association.
MAJOR CORPORATIONS & GOVERNMENT INITIATIVES
1. The US Department of Energy has adopted SGML as its standard
for electronic exchange of scientific and technical information
and the Office of Scientific and Technical Information in Oak
Ridge, Tennessee has been selected as the facilitating
organization. Various DOE organizations and contracters are
already participating in this effort and proposals have been
submitted for the backbone system.
2. The Australian Parliament has just completed a review of its
publishing needs and has recommended SGML for the daily
publication of Hansard and supporting documentation. The
Australian Attorney General's Office is ramping up its use of
SGML, and the Australian Tax Office has an SGML pilot project
going which, if successful, will spread across the department.
The Australian Defense Publishing Group (DPUBS) has installed a
CD-ROM manufacturing facility, which is migrating to SGML.
3. The U.S. Navy Defense Printing Service purchased an SGML-
based publishing system to be deployed at all printing service
sites, DoD-wide under the ADMAPS (Automated Document Management
and Publishing System) program.
Under the EDRADS (Electronic Document Retrieval and Distribution
System) program, the Navy is populating a document database of
all Military Specifications and Standards by scanning and
applying SGML tagging.
The U.S. Navy has begun a study on conversion of logistics
support analysis material directly to Interactive Electronic
Technical Manuals.
4. Agfa won the 910S award to develop DTDs and FOSIs for US Air
Force Administrative material (and conversion of 10,000 pages).
With Agfa's recent re-organization announcements, the fate of
this award is, so to speak, up in the air.
5. JCALS the US DoD publishing system architecture contract
was awarded this year to a project team headed by Computer
Sciences Corporation. With an estimated value over 10 years of
$750 million, JCALS is intended to provide systems which will
then be duplicated thoughout the DoD to receive contractor data
encoded to CALS standards. When complete, the system will be the
world's largest integrated information retrieval, document
database, editing and publishing system, consisting of hundreds
of sites with tens of thousands of users.
6. In Holland, Fokker Aircraft is working on a CALS-like SGML
implementation.
7. The Dutch Petroleum Company (NAM) owned by Shell and Exxon
has begun implementing an SGML application.
8. Wolters Kluwer Law, has completed conversion of the entire
Law Database of Dutch legislation into SGML and is now converting
its looseleaf operation.
9. Sumitomo Bank Capital Markets of New York City reports that
it would not be capable of maintaining its current volume of
business without the links between its structured database data
and its unstructured data that SGML provides. Frank Deutschmann
writes:
"Over the course of the year ... we have moved ALL wordprocessing
activities into the SGML environment (currently ArborText's
Publisher). Our business (trading derivative financial products)
involves detailed legal documentation for each trade (dozens a
day), and all documentation is now generated and stored in SGML
format. I believe that we are one of the first serious users of
SGML ... literally our whole business is based on SGML."
10. In New York City and London, MarketScope, Standard & Poor's
electronic market analysis service, is being launched
simultaneously through three on-line distribution services with
three different formatting requirements all from a common SGML
source (created in SoftQuad Author/Editor).
11. In France, Bull is creating its user documentation in SGML
using an editorial system centered an Ingres database, and geared
to producing both paper and a CD-ROM.
12. Aerospatiale, with the help of AIS, has built a ground based
ELS (Electronic Library System) to take maintenance manuals and
transform them both automatically and manually into documents
needed by Air Inter, the national airline owned by Air France.
Aerospatiale is to deliver the final system within the next
month. The system will also be available to other airlines.
13. Delta's TOPS System is up and running, producing native SGML
job cards. The system takes Boeing data into Datalogics' tagger,
using an older version of ATA Spec 100 DTD.
14. USAir is building a native SGML application for Service
Bulletins and other internal documents using IBM's TextWrite.
15. Boeing will be producing Service Bulletins in SGML and has
provided a complete maintenance manual as test data to the
airlines.
16. At the ATA Digital Maintenance Conference last month, 160
people from 60 airlines saw Digital Service Bulletins on SGI
computers with Arbortext's SGML Editor and MS Windows and
Macintosh versions of SoftQuad Author/Editor. All computer
platforms demonstrated the same business process: Service
Bulletin content being edited and re-ordered to become
Engineering Orders.
17. The Laboratory for Library and Information Science at
Linkoping University in Sweden is working with the Swedish
Defense Research Establishment in using HyTime to model dynamic
structures in crisis management systems incorporating, for
instance, information from geographical information systems.
18. John Duke of Virginia Commonwealth University, and consultant
George Alexander, a member of the original AAP committee, are
working on a project to convert the second edition of the Anglo-
American Cataloguing Rules. (AACR2) to an SGML file. AACR2 is
maintained by an international committee and codifies the rules
that librarians throughout the world use to describe materials in
their collections. The electronic version of AACR2 will be used
not only to produce future print versions of the constantly
changing rules, but to develop software for online versions
linked to other cataloguing tools, for tutorial programs, and for
other research tools. Value-added developers of AACR2-e may
develop linkages to other products, such as the LC Rule
Interpretations or the MARC format documents.
19. The Department of Statistics at North Carolina State
University will be publishing The Journal of Statistics
Education, a newly organized electronic journal that will
maintain journal materials using SGML. Some assistance to authors
will be provided in producing the SGML documents, at least in the
short-term. The first issue of the JSE is targeted for July 1993.
The editors plan on using a modified version of the AAP journal
DTD.
20. SRC, the Semiconductor Research Corporation funds university
research and "pre-publishes" the results to its member sponsors.
It has said it will start delivering those findings
electronically in SGML by the end of this academic year. The DTDs
are done.
21. The Caterpillar Service Information System (SIM) project is
based on 11 DTDs and includes file system management software
developed by InfoDesign. To date, the system has received,
verified and catalogued more than 350,000 pages of converted SGML
text and graphics.
A second project, the Caterpillar File Management System (FMS)
built with Computer Sciences Corporation, a distributed, SGML-
based information management system, is now being implemented.
22. Microstar Software of Ottawa has received funding for a two
year research project in the area of SGML tools from the Canadian
Department of National Defense.
23. This year Microsoft released a CD-ROM multimedia package,
entitled "Cinemania" integrating several books about movies into
one complex reference source. Microsoft and Exoterica's
consulting group used SGML as an enabling technology in the
preparation of text data.
24. Mead Data Central has begun work on what may be the largest
non-government SGML application in the world. Over the next 2
years, they will be converting between 200 and 250 million
documents into SGML using 4,000 or more DTDs and 8,000 or more
FOSIs.
25. SunSoft, the Sun software subsidiary, is using SGML in its
online publishing tools. Documents in several popular electronic
publishing formats will be converted into online information
similar to SunSoft's AnswerBook online documentation product.
26. A company called FLUKE reports that it has built a filter for
its "Standard Input File Format" where it attempts to keep a
writer's file as close to ASCII text as possible and then implies
the markup to take it into an Agfa CAPS System.
27. The Cooperative Extension System, which includes the U.S.
Department of Agriculture Extension Service, 77 land-grant
universities and 3100 county offices, has appointed a working
group to develop a standard for encoding publications using SGML.
Extension publications include technical reports, fact sheets,
and pamphlets on agriculture, horticulture, home economics, youth
development many of which incorporate images, tables, charts
and graphs.
In addition, USDA Extension Service is supplementing its paper
distribution system with electronic distribution over the
Internet. Documents will be encoded with SGML and formatted on
request for a variety of display technologies.
PUBLICATIONS
1. Joan Smith, leader of the CALS in Europe Special Interest
Group and one of the founding fathers and mothers of SGML, has a
new book just out, called SGML and Related Standards published in
the UK by Ellis Horwood and distributed in North America by Simon
& Schuster.
2. Oxford University Press has indicated to Charles Goldfarb
that The SGML Handbook has gone back to press for a second
edition.
3. Eric von Hervijnen's book Practical SGML has sold 3000
copies. The Japanese edition of the book was published this year
by the Japanese SGML Forum. Eric is now working on a second
edition which will also be available electronically in Dynatext,
incorporating the ARCSGML parser with buttons that will allow you
to parse the book's examples. A wonderful case of using available
SGML technology technology beyond simply representing pages.
4. SGML Inc., the editorial team behind <TAG>, the SGML
Newsletter, entered into an agreement whereby the GCA publishes
the newsletter. Another sign of SGML's continued growth is the
fact that <TAG> is now published monthly.
5. The CALS Journal, a glossy colour magazine devoted to the
world-wide CALS initiative and with continuous coverage of SGML
in CALS, is now completing its first year of publication.
6. Interesting and exciting SGML coverage in the mainstream:
BYTE magazine's June issue had a cover section on "Infoglut"
which included articles devoted to SGML by Steve DeRose and Lou
Reynolds of Electronic Book Technologies and Chris Locke and
Haviland Wright of Avalanche. The November '92 issue of Unix
World includes that magazine's first major mention of SGML in its
Standards column.
7. The Seybold Report's coverage of SGML activities continues to
grow, recently with Mark Walter's long piece on September 7th
describing both Silicon Graphic's and Novell's committment to
SGML:
"If we've been writing a lot about the Standard Generalized
Markup Language (SGML) lately, it's because a lot is happening.
The latest ringing endorsement of the standard: Silicon Graphics
and Novell will be converting their hardware and software
documentation into SGML for delivering the manuals on CD-ROM.
The adoption of SGML by two big-name computer gear suppliers
both of whom had ready access to vendor-based solutions
reflects a growing awareness of the intellectual and business
advantages to putting critical information in a rich, portable
form. Adoption of SGML by the computer industry could spur more
widespread use and change the face of electronic delivery
software development."
8. The November 18th Management Edition of Newsweek which is
sent to 3/4 million management subscribers includes an article
by Chris Locke placing SGML in perspective for managers. Locke
describes reasons why computer automation "has largely failed to
increase productivity" and goes on to say:
"A solution to both problems universal document interchange
and the explicit encoding of document structure is rapidly
arriving from a largely unheard of quarter. The Standard
Generalized Markup Language (SGML) is being adopted with
surprising speed by companies such as WordPerfect, Novell Frame
Technologies, Interleaf, Silicon Graphics, Digital Equipment, and
Sony. The reason that this open, non-proprietary international
standard is situated at the heart of so many development efforts
is its ability to represent a rich set of document structures and
relate them to a humanly meaningful whole."
VENDOR ANNOUNCEMENTS
A couple of announcements this year suggest activity among
vendors that signal, I think, SGML's movement into the
mainstream:
1. The WordPerfect Corporation, market leaders in the
wordprocessing world, demonstrated their SGML-conforming version
of UNIX WordPerfect, both at TechDoc and the recent Seybold
Conference. The product is in its beta test period now and will
be ported to MS-DOS next year.
2. Adobe Systems has launched its Carousel product, which
accurately displays PostScript fonts and pages irrespective of
the computing platform they're sent to. Although there have been
no formal announcements, statements made at the Seybold
Conference by John Warnock and Adobe Vice President, Bill
Spaller, indicate that sometime next year a new version of
Carousel will be released with some SGML smarts.
3. TechnoTeacher, Inc. demonstrated a prototype of its
"HyMinder" Hytime engine at TechDoc Winter 1992 last February.
TechnoTeacher expects to release the "HyMinder" product along
with its SGML document object library (called "MarkMinder")
during the first quarter of 1993.
4. Quark, maker of Quark Express, has produced an alpha version
of a filter that exports Quark files in SGML-encoded form in
conformance with the ICADD Minimal DTD (for Braille).
Other vendors who have made announcements this year include: AIS,
Arbortext, Avalanche, Datalogics, EBT, Exoterica, Frame,
Intergraph, Interleaf, Oster & Associates, SoftQuad, Unifilt,
Zandar, and Westinghouse.
MISCELLANEOUS
1. One sign of a growing market is the appearance of market
analysis: InterConsult has released an "SGML Software Market
Report" which divides the SGML market into useful sectors and
attempts to gauge both current and future sales levels. The data
is available both as a published document and with InterConsult-
developed software called Intuition, which allows one to build
one's own assumptions into a sophisticated analytical model.
2. The next item is a reprise of one of last year's. I ended
this talk in 1991 by describing Michel Bielzinski's talk at the
International Markup Conference. Well, a recent issue of <TAG>
includes a very interesting piece by Michel on the same theme: a
comparison of space and time in HyTime and Einstein's General
Theory of Relativity.
3. In December 1992 Exoterica will be releasing a CD-ROM
entitled "The Compleat SGML" containing the full text of ISO8879
integrating the 1988 amendment in online hypertext form.
Accompanying this electronic reference will be thousands of
sample SGML documents, comprising Exoterica's SGML conformance
test suite. Several enormous documents will also be provided for
benchmarking purposes.
4. CURIA, the ancient manuscript project of the Royal Irish
Academy, has 6MB of text scanned and now being encoded from
printed editions of annuals, sagas, poems and prose works in
Irish Latin and Old Norse.
5. Dynatext is being used in a math course (differential
geometry) at Brown University with interactive 3D graphics and a
whole on-line text book.
6. This is surely one of the great tidbits of miscellaneous SGML
news: At the recent mid-Atlantlic SGML User's Group meeting, the
U.S. Central Intelligence Agency announced that SGML is a
strategic direction for the Agency.
7. Reaction was so good at the SGML '91 Conference to Tommie
Usdin's paper cut-out dolls for modelling SGML content, that the
GCA is now offering the package for sale.
8. An SGML and LaTex volunteer group managed by Chris Rowley,
Ramer Schopf and Frank Mittelbach reports:
"On top of this low level typesetting engine [LaTeX] we are
building a high-level language `for specifying the formatting
requirements of a class of structured documents' (i.e. for
prescribing how to format a document which conforms to a
particular DTD) and also implementing a `formatting engine' which
uses the specified formatting to convert an input document into a
PDL (primarily in TeX's DVI language, but this can be translated
directly into quite `low-level' Post Script or PCL or ...) This
will be, like the current LaTeX, a public domain system."
9. The Integrated Chameleon Architecture, a software system for
generating translators to and from SGML DTDs, was made available
for public release in March 1992. A user's guide is also
available. Scheduled enhancements include the addition of a
capability to import already existing DTDs and to specify
attributes in DTDs.
10. CITRI, the Collaborative Information Technology Research
Institute, a joint research arm of the University of Melbourne
and the Royal Melbourne Institute of Technology, has been
researching in the area of document retrieval. A group has
developed an SGML based hypertext information retrieval system
which uses tools such as Lector (University of Waterloo) and XGML
(Exoterica) plus their own database engine, Atlas, to provide a
platform for researching the retrieval of large, structured
documents.
11. The SGML Project, based at Exeter University in the U.K., has
continued to successfully promote the use of SGML within the
U.K.'s academic and research community. During this last year,
the members have given presentations on SGML to several
universities, businesses and conferences, established a major
electronic archive for SGML resources, and recently set-up an
email discussion list for the U.K. community. They are actively
seeking additional funding, and over the coming year intend to
establish workgroups to define criteria for evaluating SGML
software, to assess the software currently available, and to
write the DTDs and translators required by the academic
community.
12. The Jet Propulsion Laboratory (a division of Caltech
contracted to NASA) began a project in 1985 called Planetary Data
System a project to catalog and archive planetary data. Thus
far the project has only archived the plain ASCII text of
accompanying documentation, but is now looking into determining
the best way of archiving for the long term while making the
documents associated with planetary data available in multiple
output forms. SGML is being put forward as a possibility.
Finally, with JPL involved, SGML has the opportunity to become a
truly universal standard. Or at least galactic.
APPENDIX II
Back to the Frontiers and Edges:
Closing Remarks at SGML '92: the quiet revolution
Graphic Communications Association (GCA)
C. M. Sperberg-McQueen
29th October 1992
Note: This is a lightly revised version of the notes from which
the closing address of the SGML '92 conference was given. Some
paragraphs omitted in the oral presentation are included here;
some extemporaneous additions may be missing. For the sake of
non-attendees who may see this, I have added some minimal biblio-
graphic information about SGML '92 talks referred to. I have not
added bibliographic references for HyTime, DSSSL, etc. If you
are reading this, I assume you already know about them, or know
where to find out. (MSM)
Section I
INTRODUCTION
What a great conference this has been! We began with a vision of
the future from Charles Goldfarb,(1) and since then have had a
detailed tour of a lot that is going on in the present. I want
to turn your attention forward again, and outward, back to the
fringes and the edges of our current knowledge. We've been hearing
about a lot of projects in which the gains of SGML are being
consolidated, implemented, put into practice. I want to talk
about some areas in which I think there may still be gains to be
made.
Not surprisingly, some of those gains are at the periphery of our
current concerns with SGML, in fringe applications, pushing the
edge of the envelope. Not surprisingly, Yuri asked an academic
to talk about them, because academics are by nature fringe
people, and our business is to meddle with things that are
already pretty good, and try to make them better.
In identifying some areas as promising new results, and inviting
more work, there is always the danger of shifting from "inviting
more work" to "needing more work" and giving the impression of
dissatisfaction with the work that has been accomplished. I want
to avoid giving that impression, because it is not true, so I
want to make very clear: the questions I am posing are not
criticisms of SGML. On the contrary, they are its children:
without ISO 8879, these questions would be very much harder to
pose: harder to conceive of, and almost impossible to formulate
intelligibly. SGML, that is, has created the environment
within which these problems can be posed for the first time, and
I think part of its accomplishment is that by solving one set of
problems, it has exposed a whole new set of problems. Notation
is a tool of thought, and one of my main concerns is to find ways
in which markup languages can improve our thought by making it
easier to find formulations for thoughts we could not otherwise
easily have.
I start with the simple question: what will happen to SGML and
to electronic markup in the future? Charles Goldfarb told us
Monday: the future of SGML is HyTime. And this is true. HyTime
is certain to touch most of us and affect our use of SGML in the
coming years. But HyTime is already an international standard:
it's part of the present. What will happen next? What should
happen next?
What I will offer is just my personal view, it has no official
stand- ing and should be taken for what it's worth. It's an
attempt to provide a slightly fractured view, a view slightly
distorted in order to provoke disagreement and, I hope, some
useful thought.
If you want to know what is going to happen with SGML and markup
languages in the next few years, all you have to do is think about what
happened in programming languages after the introduction of Cobol or
Algol, and what happened in database management systems after the
development of the Codasyl data model.
Section II
THE MODEL OF THE PAST
The introduction of Cobol made possible vast improvements in
program- mer productivity and made thousands of people familiar
with the notion of abstraction from the concrete machine. It is
no accident that SGML is often compared to Cobol: it is having a
similarly revolutionary effect.
More suggestive to me however is the parallel between SGML and
Algol. Apart from the skill with which its designers chose their
basic concepts, one of Algol's most important contributions was
its clean, simply designed syntax. By its definition of its
syntax, Algol made possible the formal validation of the program
text, and thus rendered whole classes of programmer error (mostly
typos) mechanically detectable, thus effectively eliminating them
from debugging problems. Similarly SGML renders whole classes of
markup error and data entry mechanically detectable and thus
eliminates them as serious problems. The notion of formal
validity is tremendously important.
What happened after the introduction of Algol? Over a period of
time, the intense interest in parsing and parser construction
gave way to interest in the meaning of programs, and work on
proofs of their correctness -- which I interpret as essentially
an attempt to extend formal validation beyond the syntax of the
language and allow it to detect logic or semantic errors as
well, and thus eliminate further classes of programmer error by
making them mechanically visible. Formal reasoning about objects
requires a clean formal specification of those objects and their
characteristics, so time brought serious work on the formal
specification of programming language semantics.
In particular, work on type systems occupied a great deal of
attention, because Algol had demonstrated that type errors can
be mechanically detected for simple types. So a lot of people
worked on extending those simple types and creating stronger,
subtler, more flexible, more useful type schemes; from this work
our current trend of object-oriented programming takes some of
its strength.
All of these same issues arose in connection with database
management systems after Codasyl. (No matter what Tim Bray said
yesterday, this did happen well before 1978.) The work of
Codasyl in defining formally the characteristics of databases led
to a generation of improved database systems, and eventually
the increasing complexity of those systems led to the introduction
of the relational model, whose simple concepts had a clean
formal model firmly grounded in mathematics, which simplified
reasoning about databases and their correctness and which led to
substantial progress in database work, as Tim Bray described
yesterday.(2)
The database work confirmed, fueled, and strengthened the conviction
that formal validity and a rational set of data types are a useful
investment. Equally important for our purposes, database work showed
the importance of placing as much as possible of the burden of
validation in the database schema definition and not in the application
software that works with the data. If you have a logical constraint in
your data, for example that the sum of columns DIRECT COST and INDIRECT
COST not exceed the column PRICE TO CUSTOMER, or that the only colors
you offer are GREEN and BLUE, it is better to define that constraint
into the database schema, so it will be consistently enforced by the db
server. You may be tempted to leave it out of the schema on the
grounds that your application programs can enforce this constraint just
as well as the server. And you are right -- in theory. In practice,
as surely as the day is long, before the end of the year you and the
two other people who were there are transferred to new duties, your
replacements will overlook the note in the documentation, the first
thing they will do is write a new application which does not enforce
this rule, and before another year is gone your database will be full
of dirty data.
In other words, to paraphrase an old Chicago election adage, constrain
your data early and often.
As hardware costs declined and programmer costs increased,
portability became an increasingly prominent issue, and the
semantic specification of languages, abstracting away from the
specifics of individual machines, proved to be an invaluable tool
in helping achieve it where possible and limit the costs where
device-specific code was necessary.
Since the progress on formal semantics, though promising, did not
yield mechanistic logic checkers as reliable as mechanistic
syntax checkers, the years after Algol and Codasyl also saw the
development of the notion of programming style, and attempts to
define what constitutes a good program. At least some of these
discussions appealed as much to aesthetic judgments as to empirical
measures, which is as it should be, since aesthetics is a fairly
reliable measure of formal simplicity and power.
Section III
SGML PROBLEMS AND CHALLENGES
All of these problems are also visible in SGML and electronic text
markup today, and my prediction, for what it is worth, is that they
will occupy us a fair amount in the coming years. What is more, as you
will have noticed in the course of the conference they are already
occupying us now. That is, the future is closer than you might think.
What problems will occupy us in this uncomfortably near future?
The same ones that we saw in programming languages and database
management:
* style
* portability
* a large complex problem I'll call "semantics", which
includes problems of validation and type checking
III.1 Style
We saw the other day in Tommie Usdin's session One DTD Five Ways(3) how
close we already are to developing consensus on DTD style. As for
external, presentational details, Tommie remarked that there is already
an implicit consensus. For details of construction and approach, she
remarked, rightly I think, that there is no one answer, no context-free
notion of "a good DTD". Our work in coming years is to work on
clarifying a context-sensitive notion of "a good DTD".
When is it better to tag a profile of Miles Davis as a
<NewYorkerProfile> and when is it better to tag it <article> or even
<div>? The answer is not, I suggest to you, as some were proposing the
other day: namely that it's always better to tag it <NewYorkerProfile>,
but you may not always be able to afford it and so you may have to
settle for <article> or <section>. For production of the New Yorker,
or for a retrieval system built specifically around the New Yorker, I
personally would certainly use the more specific tag. For a production
system to be used by all Conde Nast or Newhouse magazines, however, I
think the elements <goings>, <TalkOfTheTown>, and so on would be
problematic. Let's face it, Psychology Today and Field and Stream just
do not have those as regular departments. In building a 100-million
word corpus of modern American English, it would similarly be a
needless complication of the needed retrieval to provide specialized
tags for each magazine and newspaper included in the corpus. One of
the points of this whole exercise (i.e. SGML) is to reduce irrelevant
variation in our data -- and relevance is context-dependent.
Judging by the talks we have heard, those in this community will
be building and customizing an awful lot of distinct DTDs in the
coming years. One of our major challenges is to learn, and then
to teach each other, what constitutes good style in them: what
makes a DTD maintainable, clear, useful.
III.2 Portability
Our second major challenge is, I think, portability. I can hear you
asking "What?! SGML is portable. That's why we are all here." And you
are right. Certainly, if SGML did not offer better portability of data
than any of the alternatives, I for one would not be here.
But if data portability is good, application portability is better. If
we are to make good on the promises we have made on behalf of SGML to
our superiors, our users, and our colleagues, about how helpful SGML
can be to them, we need application portability. And for application
portability, alas, so far SGML and the world around it provide very
little help.
Application portability is achieved if you can move an application from
one platform to another and have it process the data in "the same
way". A crucial first step in this process is to define what that way
is, so that the claim that Platform X and Platform Y do the same thing
can be discussed and tested. But SGML provides no mechanism for
defining processing semantics, so we have no vocabulary for doing so.
DSSSL (ISO 10179, the Document Semantics and Style Specification
Language) does provide at least the beginnings of that vocabulary. So
DSSSL will definitely be a major concern in our future. We have seen
another bit of the future, and it is DSSSL.
Section IV
THE BIG PROBLEM
But the biggest problem we face, I think, is that we need a clear
formulation of a formal model for SGML. If we get such a formal
model, we will be able to improve the strength of SGML in several
ways.
IV.1 SGML's Strengths
SGML does provide a good, clean informal model of document structure.
Like all good qualitative laws, it provides a framework within which to
address and solve a whole host of otherwise insoluble problems.
For the record, my personal list of the crucial SGML ideas is:
* explicitly marked or explicitly determinable boundaries
of all text elements
* hierarchical arrangement/nesting of text elements
* type definitions constraining the legal contents of
elements
* provision, through CONCUR and the ID/IDREF mechanism, for
asynchronous spanning text features which do not nest properly
-- and here I want to issue a plea to the software vendors:
Make my life easier. Support CONCUR!
* use of entity references to ensure device independence of
character sets
Obviously there are a number of other features important to making SGML
a practical system, which I haven't listed here. What I've listed are
what seem to me the crucial elements in the logical model provided by
SGML.
It seems to me that a properly defined subset of SGML focusing on these
ideas and ruthlessly eliminating everything else, could go far in
helping spread the use of SGML in the technical community, which is
frequently a bit put off by the complexity of the syntax
specification. I don't think a subset would pose any serious threat to
the standard itself: use of a subset in practice leads to realizations
of why features were added to the standard in the first place, and with
a subset, the growth path to full use of the standard language is
clearly given. Spreading the use of SGML among the technical community
would in turn help ensure that we get the help we will need in
addressing some of the challenges we face.
IV.2 Semantics
We commonly think of SGML documents as data objects, to be processed by
our programs. I ask you now to participate for a moment in a thought
experiment: what would the world be like, if our SGML documents were
not documents, but programs? Our current programs for processing SGML
documents would be compilers or interpreters for executing SGML
programs.
What else?
Well, first of all, we discover a tremendous gap: we have lost
everything we used to know about programming language semantics,
and we have no serious way of talking about the meanings of these
SGML programs. And for that matter, we have no serious way of
talking about what happens when we compile or execute them. In
other words, we have made our programs reusable (we can run the
same program / document with different compilers) and so we can
use just one programming language instead of many, and this is
good, but it would be nice to have a clue about the semantics of
the interpretations our compilers make of the language we are
using.
The clearest analogy I can think of to our situation is that in SGML we
are using a language like Prolog, in which each program (document) has
both a declarative interpretation and an imperative or procedural
interpretation. If you ignore the procedural aspects of Prolog
programs, you can reason about them as declarative structures; if you
attend to the procedural aspects, you can see what is going to happen
when you run the program.
The difference between Prolog and SGML is that Prolog has very
straightforward semantics for both the declarative and the procedural
interpretations, for which formal specifications are possible. In
SGML, we have a very clear informal idea of the declarative meaning of
the document, but not a very formal one. And we have no vocabulary
except natural languages for talking about processing them.
Ironically, it is not easy to say exactly what ought to be meant by the
term semantics. Different people use it in different ways, and if it
does have a specific, consistently used meaning in formal language
studies, then the practitioners have kept it a pretty well guarded
secret. So I can't tell you what semantics means; I can only tell you
what I mean by it today.
Imagine I am about to send you an SGML document. Included in this
document are two elements I suspect you may not have encountered
before: <blort> and <vuggy>. When I say I'd like to have a good
specification of their semantics, I mean I would like to be able to
tell you, in a useful way, what <blort> and <vuggy> mean, and what
formal constraints are implied by that meaning.
But we don't seem to know how to do that.
The prose documentation, if there is any and if I remember to send it,
may say what a <blort> is, or it may not. It may tell you what <vuggy>
means, but if it does it may say only "full of vugs; the attribute TRUE
takes the values YES, NO, or UNDETERMINED". Unless you are a geologist
you probably don't know what a vug is, and if you are a geologist you
may harbor some justifiable skepticism as to whether I know and am
using the term correctly.
Even if my prose documentation does explain that a vug is an air-hole
in volcanic rock, and you know how to decide how many vugs make a rock
vuggy, I have probably not succeeded in specifying what follows
logically from that meaning in any useful way -- probably not, that is,
in a way that a human reader will understand and almost certainly not
in a way that a validating application can understand and act upon.
For example, how many people here realize, given our definition of
<vuggy>, that the tag <vuggy true=yes> is incompatible with the tag
<rock type=metamorphic> -- since the definition of a vug is that it's
an airhole in volcanic, i.e. igneous, rock. If you noticed that,
congratulations. Are you right? I don't know: if some vuggy igneous
rock is metamorphosed and the airholes are still there, is it still
vuggy? I don't know: I'm not a geologist, I'm just a programmer. Is
there a geologist in the house?(4)
It would be nice to be able to infer, from the formal definition
of <vuggy>, whether or not <vuggy true=yes> is incompatible with
<rock type=metamorphic>, just as we can infer, from the DTD, that
<vuggy true='76.93%'> is not valid, since the attribute true can
only take the values YES, NO, and UNDETERMINED. Prose is not a
guaranteed way of being able to do that.
So what can we manage to do by way of specifying the "semantics"
of <blort> and <vuggy>? We don't seem to know how to specify
meaning in any completely satisfactory way. What do we know how
to do? Well, we can fake it. Or to put it in a more positive
light, we can attempt to get closer to a satisfactory specification
of meaning in several ways:
IV.2.1 Prose Specification
First, we can attempt to specify the meaning in prose.
Specifications in prose are of course what most of our manuals provide
in practice. It is handy to formalize this as far as possible, to
ensure consistent documentation of all the characteristics of the
markup that we are documenting. We've heard obliquely about a number
of systems people use to generate structured documentation of SGML tag
sets: Yuri Rubinsky mentioned one used internally by SoftQuad; Debby
Lapeyre mentioned one; the Text Encoding Initiative (TEI) uses one; I
am sure others exist too. This is already a live issue. And it will
continue to occupy our attention in the coming years.
Natural-language prose is, at present, the only method I know of for
specifying "what something means" in a way that is intuitive to human
readers. Until our colleagues in artificial intelligence make more
progress, however, prose specifications cannot be processed
automatically in useful ways.
IV.2.2 Synonymy
Second, we can define synonymic relationships, which specify that if
one synonym is substituted for another, the meaning of the element,
whatever that meaning is, remains unchanged. If we didn't know in
advance what <blort> and <farble type=green> meant, we probably still
don't know after being told they are synonyms. But knowing we can
substitute one for the other while retaining the meaning unchanged is
nevertheless comforting.
IV.2.3 Class Relationships
Third, we can define class relationships, with inheritance of class
properties. It doesn't tell us everything we might need to know, but
if we know that a <blort> is a kind of glossary list, or a kind of
marginal note, we would have some useful information, which among other
things would allow us to specify fall-back processing rules for
applications which haven't heard of <blort>s but do know how to process
marginal notes.
The fact that HyTime found it useful to invent the notion of
architectural form, the fact that the TEI has found it useful to invent
a simple class system for inheritance of attribute definitions and
content-model properties, both suggest that a class-based inheritance
mechanism is an important topic of further work.
IV.2.4 License or Forbid Operations
Fourth, we can define rules that license or forbid particular
rela- tions upon particular objects or types of objects. We may
not know what a <blort> is, but we can know that it stands in
relation X to the element <granfalloon>, and we can know that
no <blort> can ever stand in relation Y to any element of type
<vuggy>.
In addition to relations, we can specify what operations can be
applied to something: knowing that INTEGER objects can be added
while DATE objects cannot, especially if one of the DATE objects
is "in the reign of Nero", is part of what we mean when we say we
understand integers and dates.
An ability to define legal operations for SGML objects is a key
requirement for using SGML in data modeling.
The definition of a data type involves both the specification of the
domain of values it can take on and the spec of operations which can
apply to it. Because SGML has no procedural vocabulary it is very
difficult to imagine how to specify, in SGML, the operations applicable
to a data type. It would be useful to explore some methods of formal
specification for legal operations upon SGML objects.
But note that "what it can do" and "what can be done to it" are
not, really, specifications of "what it means".
Moreover, object-oriented specifications cannot be exhaustive. In an
application program, if an operation P is not defined for objects of
type Q, it counts as a claim that operation P is illegal for such
objects. Even if it's not illegal, you aren't going to get anywhere by
trying to call it, so it might as well be illegal. In SGML, with our
commitment to application independence, that isn't the case. If no
definition of addition for DATE objects is provided, that could mean
that it is semantically invalid: dates can never be added. Or it
could mean that we just haven't got around to it yet, or haven't
thought about it yet. So the absence of a method for performing an
operation doesn't tell us whether the operation is or should be legal
upon a particular type of object. Obviously, instead of leaving
operations undefined, we could specify explicitly that certain
operations are illegal for objects of a certain class. But it is not
feasible to make an list of all the things that cannot be done to
DATES, or BLORTS, or GRANFALLOONS, because the list is likely to be
infinite.
Nevertheless, as a way of approaching the formal description of
applications, object oriented work is very promising. It's
fairly obvious that in the future we need to work together with
those people developing the object-oriented programming
paradigm.
IV.2.5 Axiomatic Semantics
Fifth, we can specify in some logical notation what claims about the
universe of our document we can make, given that it is marked up in a
certain way, and we can define what inferences can be made from those
claims. The synonymic relations I was talking about a moment ago are
just a special case of this.
Formal logic (i.e. first-order predicate calculus) certainly makes
possible the kinds of inference I've been talking about, but even
predicate calculus makes some concessions to the difficulty of the
problem. I can infer that this value for this attribute and that value
for the other one are consistent, inconsistent, etc. But since Frege
and Russell and Whitehead, logic has treated itself as a purely formal
game divorced from meaning; the only relation to the real world is by
way of models which involve assigning meanings to the entities of the
logical system and seeing which sentences of the logical system are
true under these interpretations. The problem is that "assign a
meaning in the real world to an entity or operation of the logical
system" is taken as a primitive operation and thus effectively
undefined. We all know how to do this, right? We can't define
semantics, but we know it when we see it.
In work on declarative semantics, we can learn a lot from recent
experience with logic constraint programming and declarative
programming. The declarative approach to SGML semantics has a certain
appeal, both because it fits so well with the perceived declarative
nature of SGML as it is, and because declarative information is
useful. As John McCarthy said in his Turing Award lecture, "The
advantage of declarative information is one of generality. The fact
that when two objects collide they make a noise can be used in a
particular situation to make a noise, to avoid making a noise, to
explain a noise, or to explain the absence of noise. (I guess those
cars didn't collide, because while I heard the squeal of brakes, I
didn't hear a crash.)"
One worry about declarative semantics is that it might prove difficult
to define processing procedures in a declarative way. But in fact it
is possible to specify procedures declaratively as Prolog, and logic
constraint languages, and the specification language Z show us.
So I think a formal, axiomatic approach of some kind is very
promising.
But let's be real: it is very unlikely from a description of the
tag set in first-order predicate calculus that you or I, let
alone the authors we are working with, will understand what a
<blort> is, or even what a <vug> is.
IV.2.6 Reduction Semantics
Finally, I should mention one further method of formal semantic
specification: reduction semantics. Reduction works the way
high-school algebra works. One expression (e.g. "(1 + 2) + 5" is
semantically equivalent to that expression ("3 + 5"), that one to this
other one("8"), and so on. If you work consistently toward simpler
expres- sions, you can solve for the value of X. There has been
substantial work done on reduction semantics in programming languages,
including LISP and more purely functional languages like ML.
Moreover, reduction semantics doesn't have to be defined in terms
of string expressions: it is entirely possible to define reduction
semantics in terms of trees and operations upon trees.
Take a simple example: if we have an element <A> whose content
model is "B+", does the order of <B>s matter? In SGML there is
no way of saying yes or no. Reduction semantics allows you to
say that this tree (gesture)
<a><b>Apples ... </b><b>Oranges ... </b></a>
is the same as that tree (gesture)
<a><b>Oranges ... </b><b>Apples ... </b></a>
so sequence is not important. Or that they are not the same, so
sequence is significant.
We have a good example of this type of work in the paper "Mind Your
Grammar" and the grammar-based DB work at the university of Waterloo by
Frank Tompa and Gaston Gonnet.(5) I think this is a very important
field for further work.
In summary: we have at least six areas to explore in trying to work on
better semantic specification for SGML: structured documentation (the
kind of thing SGML itself is good at), synonymy, classes, operation
definitions, axiomatic semantics, and reduction semantics.
I don't know whether these activities would constitute the
specification of a semantics for SGML and for our applications, or only
a substitute for such a specification, in the face of the fact that we
don't really know how to say what things mean. Certainly no
lexicographer, no historical linguist, would feel they constituted an
adequate account of the meaning of anything. And yet I suspect that
these activities all represent promising fields of activity.
IV.3 Validation and Integrity Checking
A formal model would make it possible to formulate cleanly many
of the kinds of constraints not presently expressible in SGML.
This is by no means an exhaustive or even a systematic list, but
at least all the problems are real:
* If an attribute SCREEN-TYPE has the value BLACK-AND-
WHITE, the attribute COLOR-METHOD almost certainly should
have the value DOES-NOT-APPLY.
But this kind of constraint on sets of attribute values
is impossible to specify for SGML attributes. It would certainly
be useful sometimes to be able to define co
occurrence constraints between attribute values.
* Similarly, there are cases where one would like to constrain
element content in a way I don't know how to do with
content models. We have heard repeatedly in this
conference about revision and version control systems
which allow multiple versions of a document to be encoded in
a single SGML document. For example, one might
have a <revision> element which contains a series of
<version> elements. The TEI defines just such a tag pair.
At the moment our <version> element can contain only
character and phrase elements. It would be nice to allow
it to operate as well upon the kind of SGML-element-based deltas
that Diane Kennedy described the other day
for revision info, in which the unit of a revision was
always an SGML element. If a change is made within a paragraph,
the entire paragraph is treated as having been
changed, and versioning consists in choosing the right
copy of the paragraph.(6) But one would like to be able to
specify that if the first <version> element contains a <p>
element, the second had better contain one as well, and
not a whole new subsection or just a phrase. Otherwise, the
SGML document produced as output from a version
-selection processor would not be parsable.
* It would be nice to be able to require that an element be
a valid Gregorian date, or a valid ISO date, or a valid part
number, etc., etc.
* It would be nice to be able to require character data to
appear within a required element: i.e. to have a variant on
PCDATA whose meaning is "character+" and not
"character*" -- or even to require a minimum length, as
for social security numbers, phone numbers, or zip codes.
* The SGML IDREF is frequently used as a generic pointer.
Many people wish they could do in SGML what we can do in
programming languages, and require a given
pointers to point at a particular type of object. (The
pointer in a <figref> had better be pointing at a figure,
or the formatter is going to be very unhappy.)
* Similarly, it would be nice to have a type system that
understood classes and subclasses. The only reason we face
this nasty choice between using the tag
<goings> and using the tag <section> for the New Yorker's
"Goings on Around Town" section is that we have no way to
make a processor understand that <goings>
and <TalkOfTheTown> and so on are just specialized
versions of <section> or <article>. If we use the specialized
tags, and want to specify an operation upon all
sections of all magazines, we must make an exhaustive
list of all the element types which are specializations of
<section>. To be sure, our application systems can
handle this. But we want to constrain early and often.
And never constrain in your application what you could
constrain in the DTD.
Section V
CONCLUSION: WHY BOTHER?
I suppose you can sum up my entire talk today this way. We want to
constrain our data early and often. To do this, we need better
validation methods. To express the validation we need, we need a clean
formal model and a vocabulary for expressing it. The query languages
described yesterday are not the final word but they are a crucial first
step.
Why do we want to do all these things? Why bother with formal
specification? Because formal specification and formal validation
are SGML's great strengths.
Why is it, as Charles Goldfarb said on Monday, that SGML allows us to
define better solutions than the ad hoc solutions built around a
specific technology? It is because SGML provides a logical view of
problems, not an ad hoc view based on a specific technology.
Naturally, it seems to suit the technology less well than the ad hoc
approach. But when the underlying technology changes, ad hoc solutions
begin to fit less well, and look less like ad hoc solutions, and more
like odd hack solutions.(7) But we can improve SGML's ability to
specify the logical level of our data and our applications. And so we
should.
A logical view is better than a technology-specific view. And so we
should welcome every effort to improve the tools available to use in
defining our logical view. In this connection I could mention again
the work by Gonnet and Tompa on large textual databases, and the work
of Anne Brggemann-Klein which is occasionally reported on the Netnews
forum comp.text.sgml.
Success in improving our logical view of the data is what will
enable the quiet revolution called SGML to succeed.
And now I hope you'll join me in thanking Yuri Rubinsky, for organizing
this conference and for allowing all of us co-conspirators in the
revolution to get together and plot.
-----------------------------------------------------
(1) Charles Goldfarb, "I Have Seen the Future of SGML, and It Is
..." (Keynote, SGML '92), 26 October 1992.
(2) Tim Bray, "SGML as Foundation for a Post-Relational Database
Model," talk at SGML '92, 28 October 1992.
(3) B. Tommie Usdin (et al.), "One Doc -- Five Ways: A Comparative
DTD Session," (panel discussion of five sample DTDs for
the New Yorker magazine), SGML '92, 27 October 1992.
(4) There was; metamorphic rock can be vuggy too, so the initial
definition was too narrow. - MSM
(5) Gaston H. Gonnet and Frank Wm. Tompa, "Mind Your Grammar: a
New Approach to Modelling Text," in Proceedings of the 13th
Very Large Data Base Conference, Brighton, 1987.
(6) Diane Kennedy, "The Air Transport Association / Aerospace
Industries Association, Rev 100", talk at SGML '92, 28
October 1992.
(7) I owe this pun to John Schulien of UIC.