<?xml version="1.0"?>
<article
><preamble
><baseloc
>http:<sol
></sol><sol
></sol>www.albany.edu<sol
></sol><tld
></tld>hammond<sol
></sol>gellmu<sol
></sol>mui<sol
></sol></baseloc><date
>October 22, 1999</date><author
>William F. Hammond</author><title
>The Idea of a Markup Interface for <abbr
>XML</abbr></title><surtitle
>Univ at Albany: W. F. Hammond: The <abbr
>GELLMU</abbr> Archive</surtitle><nul
></nul><latexcommand
><bsl
></bsl>setlength<lbr
></lbr><bsl
></bsl>topmargin<rbr
></rbr><lbr
></lbr><hyp
></hyp>30bp<rbr
></rbr></latexcommand><latexcommand
><bsl
></bsl>setlength<lbr
></lbr><bsl
></bsl>textheight<rbr
></rbr><lbr
></lbr>696bp<rbr
></rbr></latexcommand><nobanner
></nobanner><cs0
></cs0><nobaseprint
></nobaseprint><cs0
></cs0><cw0
></cw0></preamble><body
><section
>The Value of a <latex
></latex><hyp
></hyp>Like Markup User Interface
         for <abbr
>XML</abbr></section><parb
>A markup user interface (<abbr
>MUI</abbr>) for an <abbr
>XML</abbr> language
(formally <quophrase
><abbr
>XML</abbr> application</quophrase>) is a markup language
that admits a well<hyp
></hyp>defined translation to the <abbr
>XML</abbr> language<eos
></eos></parb><parb
>Recent discussions in <urlanch
>news:comp.text.tex</urlanch> show that at least
two of us are thinking about <abbr
>MUI</abbr>s for <latex
></latex><hyp
></hyp>like <abbr
>XML</abbr>
languages<eos
></eos>  Jonathan Fine has been working on a <emph
>roff</emph><hyp
></hyp>like
<abbr
>MUI</abbr> that he calls <quophrase
>Active TeX</quophrase>, and I have been
working on a <latex
></latex><hyp
></hyp>like <abbr
>MUI</abbr> that I call <abbr
>GELLMU</abbr><eos
></eos></parb><parb
>As I use the acronym <abbr
>MUI</abbr>, I do intend it to be reminiscent of
the acronym <abbr
>GUI</abbr> for <quophrase
>graphical user interface</quophrase><eos
></eos>  Both
<abbr
>GUI</abbr>s and <abbr
>MUI</abbr>s have the intention of making life easier,
or perhaps at least more familiar, for some authors<eos
></eos>  An <abbr
>MUI</abbr>,
unlike typical <abbr
>GUI</abbr>s, has the possibility of giving the author
full and rigorous control over content<eos
></eos></parb><parb
>Furthermore, an <abbr
>MUI</abbr> in the style of a pre<hyp
></hyp>existing
non<hyp
></hyp><abbr
>XML</abbr> markup offers a convenient avenue for prototyping a new
<abbr
>XML</abbr> language to model the markup practice in the pre<hyp
></hyp>existing
markup<eos
></eos></parb><parb
>Beyond that, it offers a route for conversion of legacy archives in
the pre<hyp
></hyp>existing markup to <abbr
>XML</abbr> languages with minimal human
intervention<eos
></eos></parb><parb
>Please allow me to say a bit more about what I have in mind for
<abbr
>GELLMU</abbr><eos
></eos>
</parb><section
>The Basic <abbr
>GELLMU</abbr> Processing Design</section><parb
>The things that I have on hand, aside from <latex
></latex> are:

<enumerate
><item
>  <abbr
>GNU</abbr> Emacs, version 20<eos
></eos>  (I believe that version 19 is OK.)
</item><item
>  James Clark's <quostr
>nsgmls</quostr>, a part of his <quostr
>SP</quostr><eos
></eos>
</item></enumerate></parb><parb
>My processing set<hyp
></hyp>up is the following:

<defnlist
><term
>Syntactic translation from <latex
></latex><hyp
></hyp>like markup to <abbr
>SGML</abbr></term><desc
> My Elisp processor, which can
be run interactively in <abbr
>GNU</abbr> Emacs or in batch mode, performs
syntactic translation to convert <latex
></latex><hyp
></hyp>like markup to an <abbr
>SGML</abbr>
language (formally, application)<eos
></eos>  The syntactic translator is largely
ignorant of command names<eos
></eos>  Whatever command names are used become the
names of <abbr
>SGML</abbr> elements<eos
></eos>  There is a standard way to convert
multiple argument<sol
></sol>option sequences<eos
></eos>
<parb
>This processing stage traps syntax errors<eos
></eos>  (It will fail to detect an
even number of missing <quochar
><dol
></dol></quochar> characters; but this error will
show in the next stage.)
</parb></desc><term
>Validating parse of the <abbr
>SGML</abbr> language</term><desc
> At the
validation stage the difference between <abbr
>SGML</abbr> and <abbr
>XML</abbr> is
significant if one wants to have <quophrase
>math mode</quophrase> be a global
toggle since that may be modeled robustly only using <abbr
>SGML</abbr>
exclusions<eos
></eos>
<parb
>A validating parse is made using <quostr
>nsgmls</quostr><eos
></eos>
Of course, the language definition, i.e., <abbr
>SGML</abbr> application
definition, is crucial<eos
></eos>  It is contained in an <abbr
>SGML</abbr> declaration
and in an <abbr
>SGML</abbr> document type definition (<abbr
>DTD</abbr>)<eos
></eos></parb><parb
>The language definition that I am using is the heart of my personal
production system<eos
></eos>  But I regard it only as didactic in the larger
scheme of things<eos
></eos>  Others will certainly want things that I do not
want<eos
></eos></parb><parb
>As far as it goes, it models <latex
></latex> rather closely in some ways and
rather loosely in other ways<eos
></eos>  Where it departs from close modeling,
the reason is usually related to having a document structure that is
not print<hyp
></hyp>centric<eos
></eos></parb><parb
>The validating parse traps errors in language use<eos
></eos>
</parb></desc><term
>Down<hyp
></hyp>translation to XML</term><desc
> This is done with the program
called <quostr
>sx</quostr> in the family of <quostr
>SP</quostr> processors<eos
></eos>
<parb
>While it is possible to recover an equivalent <abbr
>SGML</abbr> document
from the down<hyp
></hyp>translated <abbr
>XML</abbr>, it is not possible under the
<abbr
>XML</abbr> umbrella to have as precise a language definition as
under the wider <abbr
>SGML</abbr> umbrella<eos
></eos>  That said, either form may
be run through a processor that serves to enforce a tighter language
definition<eos
></eos>
</parb></desc><term
><abbr
>SGML</abbr> processing</term><desc
> This can go anywhere that is sane for the language definition<eos
></eos>
One can use any programming language, but it helps to have a basic
<abbr
>SGML</abbr> library on hand<eos
></eos>  I am using David Megginson's
<quostr
>SGMLS.pm</quostr>, a Perl 5 library, and its interface
<quostr
>sgmlspl</quostr><eos
></eos>
<parb
>In my personal production system I routinely format <abbr
>GELLMU</abbr>
<quophrase
>articles</quophrase> for both <latex
></latex> and <abbr
>HTML</abbr><eos
></eos>  Invalid
<abbr
>HTML</abbr> and error messages from <latex
></latex> represent bugs in my
processors, which I always repair as soon as possible<eos
></eos>  There may be
box size complaints from <tex
></tex>; they represent authoring content
errors<eos
></eos>  These two formatters work either on the <abbr
>SGML</abbr> or the
<abbr
>XML</abbr> version of an article<eos
></eos></parb><parb
>At present my personal production language definition is not fully
up<hyp
></hyp>to<hyp
></hyp>speed for journal articles nor for translation to
XHTML<hyp
></hyp>with<hyp
></hyp>MathML, but it is serving me well for my classes<eos
></eos>  It gives
me a sane way to have course handouts and web offerings in a
bullet<hyp
></hyp>proof way from a single source<eos
></eos>  At this time I simply cannot
assume that more than about a third of my students have easy access to
<abbr
>PDF</abbr> readers<eos
></eos>  So I feel constrained to give them simple
<abbr
>HTML</abbr> with very limited pseudo<hyp
></hyp>TeX for math<eos
></eos></parb><parb
>Other formattings for <abbr
>GELLMU</abbr> article that should be possible
include translations to (1) DocBook, (2) TEI, and (3) Texinfo, though
suboptimally so long as math is not available<eos
></eos>  These are not small
jobs, and I may never undertake any of them<eos
></eos>  (Any project that
undertakes to format an <abbr
>XML</abbr> language in Texinfo should give
serious consideration first to modeling Texinfo as an <abbr
>XML</abbr><eos
></eos>
It would also be desirable to minimize Info<sol
></sol><tex
></tex> bifurcation in
XTexinfo and to provide math for XTexinfo.)</parb><parb
>If a time arrives when I can assume that three<hyp
></hyp>fourths of my students
have out<hyp
></hyp>of<hyp
></hyp>the<hyp
></hyp>box browsers for XHTML<hyp
></hyp>with<hyp
></hyp>MathML, then I should be
able to format the original <abbr
>GELLMU</abbr> source directly for that <pdash
></pdash>
if by that time I am not able to squeeze it out of carefully<hyp
></hyp>set
LaTeX<hyp
></hyp>4<eos
></eos>  (I exaggerate somewhat<eos
></eos>  In principle, I need to provide
some math symbol declarations in the sources, and math symbol
declaration handling is not yet present in my set<hyp
></hyp>up.)
</parb></desc></defnlist>
</parb><section
>About this document</section><parb
>This document was prepared as a <abbr
>GELLMU</abbr> <quophrase
>article</quophrase><eos
></eos>
A copy of the <abbr
>HTML</abbr> version of this document is available
on the web at
<display
><urlanch
>http:<sol
></sol><sol
></sol>www.albany.edu<sol
></sol><tld
></tld>hammond<sol
></sol>gellmu<sol
></sol>mui<sol
></sol></urlanch></display>
along with a full list of anchored versions as follows:
<menu
><item
> <abbr
>GELLMU</abbr> source: <urlanch
>mui.glm</urlanch><eos
></eos></item><item
> <abbr
>SGML</abbr> under <quophrase
>article</quophrase>: <urlanch
>mui.sgml</urlanch><eos
></eos></item><item
> formatting in <latex
></latex>: <urlanch
>mui.ltx</urlanch><eos
></eos></item><item
> <abbr
>DVI</abbr> made from <latex
></latex>: <urlanch
>mui.dvi</urlanch><eos
></eos></item><item
> formatting in <abbr
>HTML</abbr>: <urlanch
>mui.html</urlanch><eos
></eos></item><item
> down<hyp
></hyp>translation to <abbr
>XML</abbr> <quophrase
>article</quophrase>:
      <urlanch
>mui<hyp
></hyp>xml</urlanch><eos
></eos></item><item
> formatting from <abbr
>XML</abbr> in <latex
></latex>: <urlanch
>muix.ltx</urlanch><eos
></eos></item><item
> <abbr
>DVI</abbr> made from second <latex
></latex>: <urlanch
>muix.dvi</urlanch><eos
></eos></item><item
> formatting from <abbr
>XML</abbr> in <abbr
>HTML</abbr>: <urlanch
>muix.html</urlanch><eos
></eos></item></menu>
</parb></body></article>
