\documentstyle[12pt]{article}
\begin{document}
 
\hyphenation{Com-pu-ter-Pro-cess-able}
 
\begin{center}
 
{\small \bf Execution of the Tasks of the Metalanguage Subcommittee\\
of the Text Encoding Initiative}
 
\end{center}
 
\section{Introduction}
 
The Association for Computers and the Humanities, the Association for
Computational Linguistics, and the Association for Literary and
Linguistic Computing have proposed to develop and promote guidelines
for the preparation and interchange of machine-readable texts for
scholarly research.  This project is entitled the Text Encoding
Initiative, or TEI.  Professor S. A. Mamrak has been invited to chair
the committee addressing formal-language issues, now designated the
Metalanguage committee.  Current members of the committee include
Nancy Ide, David Barnard, Eugenio Picchi, Giovanni Varile and Michael
J.  Kaelbling.  Invitations are outstanding to Jacques Dendien and
Jean-Pierre Gaspart of SOBEMAP.
 
The committee has two tasks assigned to it by the TEI.  The first task
is to generate a set of guidelines for using SGML Document Type
Definitions, DTDs \cite{SGM86}, in the TEI.  This task is near
completion.  A draft of the guidelines has been submitted to all
committee members for final approval.  The committee meets on June 5
in Toronto.  After that time it is anticipated that the guidelines
will be formally forwarded to the Advisory Board and Steering
Committee of the TEI and distributed to other working committees in
the project.
 
The second task is the design of an intermediate language, for
representing currently existing encoding schemes, to facilitate
translation into their SGML equivalents.  This task is being
undertaken as a Ph.D dissertation by Julie Barnes at the Ohio State
University.  It is anticipated that in addition to designing the
language, Ms. Barnes will develop a software toolset to aid in
recoding existing, encoded datasets into the intermediate language.
 
In connection with the first task, a set of software tools to aid in
defining DTDs and instances of DTDs has been identified as being
crucial to the TEI.  A DTD is the general, structural description,
defining a class of documents. For example, the DTD for documents of
type article might specify that articles are composed of the elements
frontmatter, body and backmatter.  The specification of frontmatter is
further decomposed into title, author, abstract, and so on.  An {\em
instance} of a DTD is a marked up article.
For example, it might begin:
 
\begin{verbatim}
<article>
<frontmatter>
<title> This is the Title </title>
<author> Jane Doe </author>
etc.
\end{verbatim}
 
In particular, this proposal addresses a software environment to
support the description of DTDs.  This description task is very
complex, and virtually impossible for humans to perform properly
without tools that can aid in avoiding the description of incomplete
or incorrect DTDs.  Below we explain the problems associated with
defining DTDs, describe an ideal support environment that would
alleviate these problems, review existing support systems and propose
to implement a prototype environment.
 
\section{Problem Statement}
 
The description of a DTD is a complex undertaking.  The primary source
of complexity arises because of the large number of elements and the
myriad, often complex, relationships among them.  In order to compare
the complexity of a DTD to a programming language, one DTD
\cite{AAP86c,AAP86} was rewritten using productions containing
terminals and nonterminals.  The grammar has 240 productions, 406
terminals and 230 nonterminals.  Furthermore, a nonrecursive nesting
level to reach a terminal from the root of the grammar can be as deep
as 25.  And some terminals and nonterminals are referenced in as many
as 70 productions.  Comparatively, a grammar for Pascal contains 95
productions, 67 terminals, 49 nonterminals, a nonrecursive nesting
level of 15, and references to some nonterminals and terminals from 21
productions \cite{SCH81}.  Furuta has also recognized and enumerated
similar complexities in \cite{FUR87s}.
 
Complexity in the description task also arises because of the
large number of different DTDs that must typically be described.
For example, a different DTD must be defined for each type of
document, e.g., articles, business letters, books, and theses.
 
A third source of complexity arises in the description of DTDs because
SGML allows for {\em adorning} the basic elements that describe the
structure of a document with both {\em attributes} and a variety of
{\em features}.  Attributes allow for the assignment of values to
certain properties associated with elements in the DTD.  For example,
a `column separator' attribute can be associated with a table element,
and it can be assigned the values `blank', `vertical bar', `dashed
vertical bar', and so on.  There are features relating to markup
minimization, to linking two or more different document types, and
others.  The TEI guidelines recommend that neither attributes nor
features (other than CONCUR) be used in TEI DTDs \cite{MAM89a}.  Thus,
this source of complexity is eliminated in our work.
 
Finally, complexity arises in the description of DTDs due to the
unique syntactical requirements of a legal DTD.  SGML defines a
language for specifying DTDs, and the definer must conform to every
syntactic detail of the language in order to generate a valid DTD.
 
Because of these complexities, the typical user describing a
DTD will experience considerable difficulties.  A
software environment designed to explicitly control and manage the
complexities of the description task would aid considerably in
achieving the goal of a complete and correct DTD.  Ideal
features of a support environment for the description task are
discussed in the next section.
 
% Ideal Features
\section{Desirable Features of a Support Environment}
\label{ideal}
 
In order to control the complexity of specifying a DTD, an environment
to support the specification should provide the following functions:
 
\begin{itemize}
 
\item entering DTDs with an abstract syntax, i.e., one less
restrictive syntactically than SGML, but able to be automatically
transformed into legal SGML syntax;
 
\item entering DTDs guided by a syntax-directed editor;
 
\item providing {\em interactive} (as opposed to batch-oriented) feedback
about the legality of the DTD;
 
\item guaranteeing legality, like
reachability and termination, of the underlying context-free grammar;
 
\item providing clues to the definer to aid in assuring that what is
defined is what is intended: generating a syntax-directed editor for
instances of the DTD, for providing clues regarding intended
definitions;
 
\item providing support for the CONCUR feature of SGML;
 
\item providing libraries of previously created elements; and
 
\item outputting legal DTD files, and possibly other specification
forms (e.g. input files to editors for instances of DTDs);
 
\item adding comments to the element definitions.
 
 
 
\end{itemize}
 
% Related Work
\section{Related Work}
\label{work}
 
There are several products that support the creation of instances of
DTDs, e.g., SoftQuad's Author/Editor.  SOBEMAP and Software Exoterica
distribute DTD {\em parsers}.  In each case, the parser expects that a
DTD has already been generated and the parser validates that the DTD
is legal according to SGML rules.  No assistance is provided to create
the DTD initially and no support is provided to check for acceptable
sample strings in instances of the respective DTD.  Currently there
exists only one commercial software environment to support the task of
specifying DTDs themselves: the RulesBuilder package from SoftQuad.
Various other {\em prototype} support environments for specifying DTDs
have been proposed \cite{CAD87,POL88,HUU85}.  However, all of these
efforts fall short of providing the desirable features listed above.
 
RulesBuilder is a macro-based, text editor.  It is a text editor in
the sense that one starts to specify a DTD by facing a blank screen
and entering text strings, as with most text editors.  It is
macro-based in that sense that there exists an expandable macro
library of templates for definitions of various DTD components, like
elements, entities and so on.  The mode of operation is to choose a
macro for a given object, and then to fill in the template shown on
the screen with information specific to the DTD being described.
RulesBuilder is batch-oriented in the sense that the legality of the
DTD is checked only upon request, and not as DTD components are
created.  The output of RulesBuilder is specifically designed to be
input for SoftQuad's Author/Editor.  Author/Editor can be used to
provide clues to the definer.  Of the desirable features listed in the
previous section, RulesBuilder provides only partial support for
guaranteeing that a context-free grammar is legal (it does not check
for termination), and it supports providing clues, libraries and
comments.  It provides none of the other functionality.
 
% Proposed Work
\section{Prototype Design}
\label{pro}
 
We propose to design and implement a prototype software environment to
support all the functions described in Section 3.  By {\em prototype}
we mean that the software will be fully functional and debugged, but
will not necessarily be accompanied by a detailed users manual, be
robust with respect to arbitrary, illegal input, or have elaborate
error-checking and error-reporting capability.  Also, the user
interface may profit from further refinements having to do strictly
with easy access and not with functionality in the underlying system.
The environment will support only those parts of SGML that are
recommended for use in TEI DTDs.  More specifically, it will not
support any features other than CONCUR, it will not support
attributes, and it will not support inclusion and exclusion
exceptions.  The prototype will be implemented in a Unix environment,
using the X11 windowing capability.
 
As a part of the support environment, a syntax-directed editor for
manipulating instances of DTDs will be automatically generated for
each DTD that is defined.  The purpose of this editor is to provide
support for the definer of the DTD in checking intended descriptions
against actual descriptions.  That is, the definer can use the editor
to create sample strings in the document type defined by the DTD and
to verify that these are the strings intended in the DTD
specification.\footnote{The first version of the prototype environment
will not support the CONCUR feature in these editors.}
 
Such an editor is a natural candidate for further elaboration so that
it can support the definer of instances of DTDs.  An example of one
elaboration is software to support markup minimization.  The exact
nature of the desired elaboration, and the design and implementation
of the functionality to provide it, is {\em not} the subject of this
proposal.\footnote{The TEI will investigate developing tools for
elaboration of these editors inhouse, or possibly in cooperation with
vendors.}
 
\section{Timetable and Deliverables}
 
At the end of the funding period we will deliver a prototype software
environment for describing DTDs.  At the end of the funding period we
will also deliver a Technical Report that describes the design and
implementation of the prototype, and experience to date in using it.
At quarterly intervals, we will deliver progress reports.
 
%
\bibliographystyle{plain}
%\bibliography{/n/music/0/chameleon/Bibs/manden}

@manual(AAP86,
   organization="Association of American Publishers",
   title       ="Standard for Electronic Manuscript Preparation and Markup",
   year        ="1986",
   note        ="Electronic Manuscript Series"
)

@manual(AAP86c,
   title       ="Markup of Mathematical Formulas",
   year        ="1986",
   month       ="April",
   organization="Association of American Publishers",
   note        ="Electronic Manuscript Series"
)

@article(BAR88,
   author ="David Barnard and Ron Hayter and Maria Karababa and George
Logan and John McFadden",
   title  ="{SGML}-Based Markup for Literary Texts: Two Problems and
Some Solutions",
   journal="Computers and the Humanities",
   volume ="22",
   year   ="1988",
   pages  ="265-276",
   annote =""
)

@inproceedings(FUR87,
   author   ="Richard Furuta",
   title    ="Complexity in Structured Documents: User Interface Issues",
   booktitle="PROTEXT I{V}: Proceedings of the Fourth
International Conference on Text Processing Systems",
   year     ="1987",
   editor   ="J.J.H. Miller",
   pages    ="7-22",
   publisher="Boole Press",
note="CO",
   annote   =""
)

@inproceedings(HEA88,
   author   ="Jim Heath and Larry Welsch",
   title    ="Difficulties in Parsing {SGML}",
   booktitle="ACM Conference on Document Processing Systems",
   year     ="1988",
   month    ="December",
   pages    ="71-77",
   note     ="Santa Fe, New Mexico",
   annote   =""
)

@phdthesis(KAE87,
   author="Kaelbling, M. J.",
   title="Braced Languages and a Model of Translation for Context-Free
Strings: Theory and Practice",
   note="Available as Univeristy Microfilms International, Inc., No. 8804059",
   school="The Ohio State University",
   year="1987")

@book(SCH81,
   author  ="G. M. Schneider and S. C. Bruell",
   title   ="Advanced Programming and Problem Solving with PASCAL",
   publisher="John Wiley and Sons, Inc.",
   year     ="1981",
   pages    ="484-497",
   annote   ="Used this book to get a CFG from their syntax diagrams,
to get a feel for the numbers of terminals, nonterminals, productions,
etc.  There were 67 terminals (keywords, symbols, digits, and chars),
49 nonterminals, 95 productions, a nesting level of 15 which could go
deeper, and references to IDENTIFIER from 21 locations."
)

@manual(SGM86,
   title           ="Information processing - Text and office systems -
Standard Generalized Markup Language (SGML)",
   year            ="1986",
   month           ="October",
   organization    ="ISO",
   fullorganization="International Organization for Standardization",
   note            ="ISO 8879-1986 (E)",
   annote          ="This document contains the formal definition of the
Standardized General Markup Language.  SGML is a set of rules for
specifying the definition of the structure of a document.  The
specification is given as a formal grammar that is difficult for the
inexperienced reader to follow.  Several appendices are included to
provide examples and further discussion.  This document should be read
by those with a lot of experience with SGML applications who desire or
need to have the complete, unambiguous knowledge of the abstract
syntax that drives these applications."
)

%
 
 
\end{document}
