Notes on AIW12

17 Jan 90, CMSMcQ

First:  good paper.  I like the formalism pretty well, though I
expect I'll continue to think first in SGML.  I like the discussions
of SGML much less, and found that they distracted me from the paper.
You'll notice in my comments where I become defensive on behalf of
SGML and its designers.  Lord knows they made stupid mistakes, but
I don't think they're guilty of the ones you name.

Need less discussion of why-SGML-won't-work and more discussion of what
is needed for good analysis of the problem domain.  My own view is that
SGML is stronger and better designed than is suggested here, and that in
any case it was designed to work in conjunction with other languages for
semantic specification.  If we add our own formalisms for semantic
specification we are simply working with SGML as it was designed to be
worked with and consequently don't need to argue that SGML is flawed.

It may well be that some things (constraints on element content, scope
and type checking for ID references) ought ideally to be added to SGML
itself in a future iteration of that language.  I am inclined to think
so, and to think that our work with integrity constraints can be very
useful in determining what needs to be added and how.  But we don't need
to decide all that here or now.  All we need to decide is what kinds of
things are useful to specify in designing a markup language.  How we get
from there to an implementation is a separate issue.

Intro.  The distinction made here between "encoding the text itself" and
encoding the linguistics of the text eludes me.  The linguistics are in
the text as surely as are the paragraph breaks.  Do you mean "the
graphetic form of the text"?  In which case you're correct only if you
omit the needs of codicology and analytic bibliography, not to mention
textual criticism.

My notes show no discussion at all of the relative complexity of
linguistic analysis and other markup, and also no decision about the
adequacy of SGML for analytic markup.  The committee decided to work
with an ad hoc formalism to simplify expression of semantic constraints
and (it seemed to me) because no one in the committee felt wholly
comfortable with SGML formalisms.

The only argument we need to make in favor of a specification language
like that presented here is that it simplifies the expression of the
conceptual model.  We needn't claim to be replacing SGML or even talk
particularly about its inadequacies.  If we do, we will make some people
defensive about it (as I have become defensive myself).

1.1 Syntax without semantics

I think this section misrepresents the intention of SGML.  The standard
does without semantics not because the semantics of the graphemic level
of texts are simple but because most attempts at formal semantics turn
out to involve procedural specifications of some sort or another, which
would take away the advantages of generalized descriptive
(non-procedural) markup.  The intention of the developers was and is for
semantic specification languages to be used to specify the semantics of
SGML elements.  That is the function of DSSSL and SPDL (Document Style
and Semantics Specification Language and Standard Page Description
Language) within the realm of document layout and printing.

It may be objected that some types of semantics *are* expressible in
SGML -- inconsistently with the claim that it only aims to provide a
syntax -- and that either more or less is needed.  Attributes have a
(rather eccentric) choice of possible data types, and occurrence counts
are defined (=1) for attributes and definable for elements.  It is
surely true that the SGML developers produced some rather eccentric
dividing lines between what the language does and doesn't do.  I believe
the development of more useful constraints on content or attribute
values could be a useful contribution to the further revision of SGML or
accompanying languages.

'!ELEMENT' -- the '!' is part of the delimiter '<!', not part of the
token.  Suggest 'ELEMENT definitions ...'"

Taken as arguments for being able to specify (1) domain constraints on
element content (2) distinction between semantically significant
linearity and linearity imposed on simultaneous data by the exigencies
of the file structure, and (3) referent-type checking and possible scope
limitations on id references, this section is unassailable.

It would be worthwhile, perhaps, to mention in this section the SGML
mechanisms one might use to express such constraints and link them into
a conformant SGML system.  (1) The NOTATION declaration can be used as a
hook allowing SGML to call a non-SGML processor to process (and
therefore to validate) the content of an element.  Domain constraints on
element content may be expressed, then, as a notation name and a
specification of how content in that notation can be validated.

(2) Significant linearity can be distinguished from simultaneity by
using comma (SEQ) or ampersand (AND) in the content models,
respectively.  Repetitions parsed under plus (PLUS) or star (REP) could
be either way, however, so perhaps some external specification is
desirable.

(3) I don't know an SGML trick that hooks in here, so perhaps what we
need is simply a rethinking about the concept of pointers in SGML in
general.  Typing them and giving them scope both seem to be in line with
good practice in other languages.  In practice, of course, one can use a
type-name string as the prefix for every ID of a certain type, so all
IDREFs can be checked for type without following the reference.  Since
periods are legal in SGML entity names, that is, we can require all ID
names for sentences to begin with 'sent.' and so on.  I'm not sure that
a simple type system suffices for all linguistic constraints, however.
What type constraint expresses the phrase type to which the ANTECEDENT
attribute of a pronoun can point?  (Will we need something like Pascal
variant records to express our type constraints?  If so, then I begin
to understand why the developers didn't type IDs!)

(I told you it was making me defensive!)

1.3 From syntactic modeling to conceptual modeling

For paragraphs 1 and 2 ("The basic premise..." and "To make markup ...")
I'd suggest:

    Specification of semantic integrity constraints on document
    elements and their attributes and the creation of many-to-many
    links among document elements may benefit from work on
    conceptual modeling in database management, programming language
    theory, and artificial intelligence.

This avoids the potentially divisive rhetoric of the draft text and
heads off arguments about who knows how much about dbms and language
theory.  Semantic specification is not a new idea in text encoding,
either in the TEI or in the standards organizations (ISO SC22 WG8 has
spent the last several years working on the Document Style and Semantics
Specification Language, DSSSL) and suggesting that it is would be a sure
way of raising some people's tempers quite needlessly.  It sure raised
mine.

2.1 Element class definitions

I like the semantic constraints.  It seems to me you have lost the
distinction between attribute and constituent which appeals to me
in SGML's use of both attributes and contained elements.  (But I
recognize this is not a universal view.)  This elision of the distinction
does have the advantage that one can work on the conceptual analysis
without having to decide whether to represent things as contained
elements or as attributes and thus can focus more intently on the
information structure.

2.2 Value set definitions

If we are seriously going to use date format specifications, we need to
use a broader range of possible legal forms and need to specify the
legal calendar.  The historical dbms KLEIO has probably the most
adequate account of date formats, but now that I've written out the
description below I wonder if this isn't a reductio ad absurdum of our
entire plan.

KLEIO allows for dates to be specified:
    (a) in styles labeled
        German (nn.nn.nnnn, year of the common era),
        English (nn mmm nnnn, year of the common era),
        Islamic (nn Arabic-month nnnn, year since the Hegira),
        Revolutionary (nn rev-name nn, year 1-14 of the Revolution),
        Byzantine (nn monthname nn, year since the creation),
        Mosaic (nn Hebrew-name nnnn, year since creation), or
        Latin (nn (calends | nones | ides)? latin-month nn, year of the
            common era)
    (b) in any yy-mm-dd / dd mm yy / etc.  sequence,
    (c) with year end computed by
        Circumcision (1 Jan),
        Roman style (1 Mar),
        Annunciation (25 Mar),
        Easter (but no provision made for days before/after Easter in
            years with two occurrences of, say, 2 April)
        Byzantine style (1 Sept), or
        Nativity (25 Dec).
    (d) One may specify one's own list of month names, if desired.
    (e) Interval dates (terminus post quem + terminus ante quem) are
        handled.
    (f) Questionable segments (marked with '?') and unknown segments
        (replaced by '0') are allowed.
    (g) The suffixes 'NS' and 'AS' may be used to force
        interpretation as a Gregorian or Julian ('alter Stil') date --
        by default, a database knows the date when the Gregorian
        calendar was introduced in the region described by the data, and
        assigns dates to either style automatically.

If we specify dates as a primitive type, we need to have this much
apparatus, I think.  (Not, perhaps, for the linguists, but certainly
elsewhere.)

Are boolean constraints and enumerated sets really parallel, or ought
they to be orthogonal?  (i.e. ought the syntax to allow FROM and WHERE
clauses to coexist?)  If we can say a value ought to be a counting
number less than 7, ought we similarly to be able to say that a value
ought to be a month-name less than July, or a set of case-names whose
intersection with the case names on the head-noun tag is non-empty?

Should value-set defs be able to call other value-set defs?  (An
alternative would be to allow WHERE clauses on the attribute definition,
but I'd prefer to allow recursive value sets.)

2.3 Enhancements

Allow elimination of attributes, as well as addition of attributes, in
class inheritance?

4.1 general encoding rules

Not clear what happens when an attribute is defined as "instance of" a
class.  By rule 1 its tag is the class name with angle brackets around
it; by rule 3 (it's an attribute) it's tag is the class name prefixed by
'%' and enclosed in angle brackets.

Since you've defined a global name space for your class and value set
names I don't understand how different attribute names can represent
entirely different things depending on their immediate parent tag.  That
is, I grasp the idea but can't see how it could be done in the
formalism.

For aesthetic reasons I wouldn't suggest the formal translation of
these specifications into a DTD be taken too seriously.  I'm a
partisan of SGML attributes, and believe they should be used wherever
appropriate, since they are much much cleaner to read than
multi-layer nested tags tend to be, and since they
automatically implement the un-sequenced nature of some types
of information.