SGML AND BIBLIOGRAPHIC STYLE

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

SGML AND BIBLIOGRAPHIC STYLE

Robin C. Cover
In a recent posting, Christopher Currie (<[hidden email]>)
writes:

>  It's essential that the standard be easy to implement, even
>  if it's flexible enough to cover a wide range of conceivable
>  requirements. Otherwise people simply won't use it, any more
>  than, for example, they follow standards on citation of
>  documents by bibliographical references. Nor will most academics
>  be willing to use a second text editor simply to handle SGML.
>  They will want those which they are alreadly using to be upgraded
>  to be compatible.

Comparing the public acceptance of TEI/SGML markup standards to
bibliogaphic style is a revealing step.  Why do we resent details of
approved bibliogaphic style, when forced to comply, and why do we
resent being "forced to"?  Because we realize that reaching for a
style manual and finding the proper punctuation for an obscure
bibliographic citation is a waste of intellectual effort.  Our minds
should not be cluttered with the rule for whether it's "comma" or
"period" in MLA style for delimiting boundary xxxx in a French
work with three concurrent series-titles, multi-volumes, multiple-
parts, multiple-authors, multiple-editors, reprinted, (etc.).  We
know that in principle, rules can be formed to do this job if we
but enter the bibliogaphic data on a proper template.  (Those who use
BiBTeX or Nota Bene's IBID program have some automatic bibliographic
management done for them, but the style files are never detailed
enough to cover all cases -- the rest of you do it all by hand,
probably, and justifably grumble because it's a waste of time.)

The direct implication of this comparison is that "users" *should* not
have to know about the TEI/SGML standard any more than they *should*
have to know about bibliographic style: software developers and
document-model designers should do this work.  Christopher is thus
correct, but does not go far enough.  It is true that writers using
descriptive markup authoring systems will have to unlearn bad habits:
e.g., they will have to think WHY the text string about to be typed
should be in "italic," and then click on the appropriate element name
rather than clicking "italic-on."  The desire for perspicuity in the
standard is axiomatic, but this applies to primarily to applications
programmers, data-preparation teams, and other designers.  Simplicity in
the standard(s) is also desirable, but as Eric Naggum has reminded us,
we cannot get generality and properly structured documents for zero cost.
It is up the the standards groups to define a robust standard, up to
the applications people to build robust programs that hide the gory
details from the user, and up to the users to be willing to change
bad habits learned from our current software -- software which has
a shortsighted and destructive fixation on paper-appearances, and
debilitating autism in proprietary data formats.

Robin Cover