W F Hammond: LaTeX Profiles as Objects in the
Category of Markup Languages<latex
/> Profiles as Objects in the Category of Markup LanguagesWilliam F. Hammond Dept. of Mathematics Statistics University at Albany Albany, New York12222(USA) http:www.albany.eduhammondTeX User Group (TUG) San Francisco, June 2010setlengthtopmargin36bpsetlengthtextheight690bpThe mathematical notion of category in the context of markup
languages raises the idea of widespread use of reliable automatic
translations between markup languages profiles, which are dialects of with a fixed
command vocabulary where all macro expansions must be effective in
that vocabulary, are suitable domains for defining translations to
other profiles and, where sensible, to other markup languagesThe construction of reliable translators from several journalneutral
profiles to many journalspecific profiles would
eliminate the need for technical editing in the production flow
for academic journalsProfiled Usage of We now have 15 years of experience with various efforts to translate
into HTML, the language of the World Wide Web We know that
the task is more difficult than it appeared to be to many of us in the
mid 1990s Part of what makes difficult to translate is that
, contrary to the impression one might gain from an initial
reading of Leslie Lamports book lamport, has never been
entirely formalized as a language unto itself independent of any
implementation for processing the language Indeed, the only implementation
of is that originating with Lamport and maintained by
The Project (http:www.latexproject.org) as a
very large macro package under As slidepretext says, success with such translation
requires profiled usage of pSlidepretext:Translation of vspace24bpp{0.03}p{0.65}p{0.03}p{1}Question:What works well with translation softwareAnswer:Profiled usage of Carefully limited command vocabularyTuned translation softwareSlidethistalk provides a succinct statement of what I wish to
suggestpSlidethistalk:Todays Suggestionvspace18bpformalizeprofiledusage ProfilesWhat might be involved in formalizing profiled usage First, I am
suggesting the notion of profile as the framework for
multipurpose documents Slidelatexprofile specifies
what is meant by profilepSlidelatexprofile:The Notion of Profilevspace24bpp{0.03}p{0.65}p{0.03}A dialect of LaTeX with a fixed command vocabulary where all macro
expansions must be effective in that vocabularyA language essentially equivalent to an SGML document type with
a canonical XML shadowMy project on Generalized Extensible Like MarkUp (GELLMU),
http:www.albany.eduhammondgellmu,
begun in 1998, underlies what I am suggesting today The GELLMU
didactic production system provides, in particular, a fairly elaborate
example of what might be regarded as a profile although some names
in its command vocabulary are not part of current standard usage
Slidetinymathsource shows the source markup for a minimal document
instance under this profilepSlidetinymathsource:A Simple Examplevspace24bpp{0.03}p{0.65}p{0.03}documenttypearticlesurtitleLaTeXProfilestitlelatexprofilesAnExamplebegindocumentItseasiertolearntowriteinalatexprofilethantolearntowritelatexThenumberspiisqrt1andefuncexp1arerelatedbytheequationeipi1enddocumentSlide tinymathrendered shows a typeset rendition of this
minimal document instancepSlidetinymathrendered: profiles: An Examplevspace24bpp{0.03}p{0.65}p{0.03}Its easier to learn to write in a
profile than to learn to write
The numbers , i 1, and
e exp(1) are related by the
equation
ei1 . pSlidegellmu:The GELLMU Projectvspace24bpp{0.03}p{0.65}p{0.03}Demonstrates that the ideas in this presentation can be implemented
Provides a didactic document type which may be viewed as close
enough to being a profile that it can serve as a base for
constructing profilesFrom the outset I should make clear that:
The totality of standard usage of classical , as we have it,
is not suitable for modeling as a profileThere should be many profilesHTML Translation HistoryA close examination of our 15 years of experience with the most successful
projects for the automatic translation of to HTML will suggest
that such translations should take place in two stages: (a) first capture
the document as an XML document under a document type that closely
models , and (b) second translate from that document type to HTML
This is, in fact, the design in the GELLMU Project (see bridge,
dual, and multipurpose) except that GELLMU source, though
like, is not nor a dialect of present The two stage design is also integral to the remarkably successful
translator LaTeXMLhttp:http:dlmf.nist.govLaTeXML,
initiated around 2001 at the U.S. National Institute of Standards and Technology
(NIST) under the very capable leadership of Bruce Miller for the purpose of
providing a translation route to HTML (actually XHTML MathML) for the
NIST Handbook of Mathematical Functions As time passed LaTeXML
became the translation engine for the ambitious project arXMLivhttp:kwarc.infoprojectsarXMLiv,
led by Michael Kohlhase of Jacobs University in Bremen,
for translation to XHTMLMathML of Paul Ginspargs large eprint
archivehttp:www.arxiv.org,
originally housed at Los Alamos and now located at CornellAn older very successful project for translation from to HTML (including,
as desired, XHTMLMathML) is tex4hthttp:www.cse.ohiostate.edugurariTeX4ht,
developed by the late Eitan Gurari of the Ohio State University, in the years
after 1995 While its core technique is the use of specialloading in DVI
files generated by with tex4ht macros, since the time that the
projects scope was extended to generate a number of XML formats other
than HTML, it has seemed clear to me that the tex4ht design would be
improved by generating XML under a document type modeling the supported parts of
and then using standard XML libraries for translation to HTML and
the various other XML document typesThe Advantage of Using a ProfileThe crux of the problem in translating documents to HTML is
that , as a whole, is not welldefined as a language unto
itself In the community there is a wellknown newbie
question: How can I know if my document is correct? A
commonly heard answer is that a document is correct if it runs
seamlessly through , the program.A tougher standard,
probably unreasonably tough, might be that a document is correct if
it runs through and also through the tex4ht driver script
mzlatex for generating XHTMLMathML.The whole of , with maximally sane mixing and matching of
packages and arbitrary legal (see Lamport lamport,
Appendix E) excursions into the world of plain , is suitable for
translation to printer languages (either specific printer languages
or, more commonly DVI and PDF) but not suitable for reliable
automatic translation to HTML or to common authorlevel document
formatsLanguage specificationWhen a list of commands, perhaps 500 to 1500 in numberImagine culling these commands from the core and from ones
favorite packages; but note that one is just assembling a list of commands
and is not in any way thereby adopting segments of packages., is
fixed, and when rules for usage of those commands in relation to each
other, i.e., what commands are allowed to appear in a given context,
are given, then one has something that is essentially equivalent to
an SGMLStandard Generalized Markup Language, an ISO
standard See Goldfarbs Handbook goldfarb for a copy
of the standard, and see http:www.sgmlsource.com for amendments
to the standard.
document type It is straightforward to construct an XMLExtensible Markup Language, a World Wide Web Consortium (W3C)
standard w3cxml.
shadow The reason for the dual track is that dialects of classical
can be more closely modeled with SGML than with XML, which is
SGML dumbed down for use on the World Wide Web The difference here
between SGML and XML is a question of convenience for authors For
example, if we want blank lines to begin new paragraphs without the
tediously redundant explicit closing of previous paragraphs, then we
want the umbrella of SGML inhouse for the formal structuring of a
profile rather than the XML umbrellaWhen a document language is implemented under the SGML umbrella, then
It is possible to know with varying degrees of precision, as
required, when a document instance is technically correctCorrect document instances can be translated automatically to
other suitable formats with a very high degree of reliabilitySoftware libraries are available for most computer languages to
facilitate automated translation and other forms of automatic
processing such as, for example, automatic extraction of metadataCategories: A MetaphorAt this point it is relevant to mention the mathematical notion of
categorypSlidecategories:Notion of Categoryvspace24bpp{0.03}p{0.65}p{0.03}A category consists of:
Objects
Arrows between objects
Rule: An arrow followed by a second is also an arrowRelevance: to suggest a way of thinking about markup(No plans for actually using category theory)My reason for introducing the concept of category here is
not for the purpose of applying category theory but for the purpose
of suggesting different ways of thinking about how the community
handles its documents In particular, Im trying to suggest a way
of thinking about how the systematic use of translations between
document formats can improve the way we operate with our documents
The largest relevant category here is the category of all markup
languages:pSlidemarkupcat:The Category of Markup Languagesvspace24bpp{0.03}p{0.65}p{0.03}Markup languages are the objectsTranslations are the arrowsSlide glmarrows shows the principal objects and arrows in
the category of markup languages associated with the GELLMU
didactic production systemcSlideglmarrows:Objects and Arrows in GELLMUlcrmp{.14}p{.07}p{.12}p{.07}p{.06}mcGELLMUsourcemp{0.7}ArrowsrightarrowmcSGMLmp{0.7}ArrowsdownarrowmcOutsideSGMLsourcemp{0.7}ArrowsrightarrowmcAuthorlevelXMLmp{0.7}Arrowsswarrowmp{0.7}ArrowssearrowmcPDFmcHTMLClassical is, more or less, a markup language While many
useful arrows can point toward , few useful arrows point
from toward markup languages other than printer languagespSlideclassicallatex:Classical : an object in the categoryvspace24bpp{0.03}p{0.65}p{0.03}(to the extent that classical is a welldefined language) is a reasonable translation target (for authorlevel
markup languages) is a poor domain for translation to languages other
than printer languagesClassical is does not fall under the umbrella of SGML, but
classical HTML does While classical HTML is not under the umbrella
of XML, there is a variant of HTML called XHTML that isSGML and XMLpSlidesgmlxml:SGML XMLvspace24bpp{0.03}p{0.65}p{0.03}SGML is a subcategory of the category of all markup languagesXML is a subcategory of SGMLXML is SGML made suitable for the World Wide WebSGML is designed so as to facilitate the construction of arrows
emanating from an SGML document typepSlidegooddomains:Good domains for translationvspace24bpp{0.03}p{0.65}p{0.03}Authorlevel SGML and XML document types are, by design, good
domains for translation, i.e., arrows can flow from these
document typesArrows can be chained; these pipelines work wellLet me suggest that in a properly designed system the chaining of
arrows, i.e., translations, should take place at the command line
This makes it possible for the user to switch components (translators)
from time to time, and it provides the opportunity for the user to run
correctness tests at intermediate stagesWhile the use of translations between document formats has not been
part of regular practice, the use of translations has not been
far awayExample: TexinfoTexinfo, the language of the GNU Documentation System, was originally a
vehicle for the simultaneous generation from a single source
of (1) print output (via DVI) and (2) Info, an
early form of hypertext predating HTML Historically, Texinfo
had been processed by the engine with Texinfo macros for print and
either by the GNU Emacs Lisp engine or by a freestanding C program, called
info, for Info hypertext When HTML came along, it became
easily possible for the program info to generate HTML as
well as Info It has been obvious from the beginning to anyone
asking the question that Texinfo, which has a careful
language definition, is equivalent to an SGML document type This
was formalized in the year 2000 with Daniele Giacominis
Sgmltexihttp:www.archive.orgdetailssgmltexi,
and a few years later an independent XML version of Texinfo was incorporated
in the Texinfo distributionBecause of its different markup syntax and command vocabulary relative
to , it is not sensible to think of Texinfo as a
profile But aside from those differences, it is a longstanding example
of something that is the same type of object as a profileAs an object in the category of markup languages Texinfo can serve usefully
as both origin and target for arrows This is often the case with
authorlevel SGML and XML document typesExample: the tdsguide document classAnother instance of the use of format translations lies in the
production during the late 1990s of the specification document for
the Directory System (TDS),
http:mirror.ctan.orgtds.zip Ulrik Vieth, the editor,
devised a setup under which the TDS specification could be written in
and processed either as a document or as a Texinfo document
(for Info and HTML outputs) Of course, there was a finite list of
commands (and environments) associated with the TDS
source In effect, this system can be said to
amount to the ad hoc construction not formalized of (1) a
profile and (2) a program for translating that profile
to TexinfocSlidetdsroutes:tdsguide: Two Routes to PDFlcrmp{.11}p{.06}p{.11}p{.06}p{.08}mcTDSsourcemp{0.7}ArrowsrightarrowmcTexinfomp{0.7}Arrowssearrowmp{0.7}ArrowsswarrowmcPDFNote that although the source tds.tex is very nicely
structured, there are two reasons why a directtohtml translation
program might be expected to have trouble with it First, it is
written under the documentclass tdsguide; I am not aware of any
directtohtml translator with knowledge of that documentclass
Second, the document uses manmac syntax, which is part of plain
rather than Moreover, inasmuch as it is reasonable to think about constructing a
translation to regular from any authorlevel XML document
type, it is, in particular, reasonable to imagine the possibility of
someone constructing a translation from (the XML guise of) Texinfo
to That would offer a third (and different) route to PDF for
tdsguide documents Beyond that it is reasonable to think about
constructing a translation from Texinfo to GELLMU article, and,
following that with the translation to provided for GELLMU
article would provide a fourth route to PDF for tdsguide
documentsHow Profiles Might be DeployedThere are many advantagesTraditional authorsWe know that a very substantial portion of the community of
authors is interested in being able to pull HTML from
documents There are frequent questions in the UseNet newsgroup
comp.text.tex about using translation programs There is a
recurring theme in discussions there where the participants are
seeking a authoring interface a better form of
markup that is robust for translation to other formats,
particularly HTML Another recurring theme that is sometimes
intertwined with the former theme is that of having a version of
that enables an author to focus on content Of course, there
is some irony in this latter theme in that Lamport in his book
lamportexplicitly states that this is the purpose of
as is indeed the case, when is used well Thus, the latter
theme may be interpreted to be about somehow enforcing the use
of as Lamport intendedOne or more profiles sponsored by the Project could
meet these requests for BeginnersWith a suitably literate system for constructing profiles
it should be a relatively simple matter to produce a command glossary
for a given profileCombine the availability of a definitive command glossary with the
enforcement of sane markup provided by routine structural validation
in the process of running on a document instance under a
profile, and it is not difficult to see why it should be easier for
a beginner to learn a profile than to learn classical s interface with established SGML document typesAlthough provision for typesetting SGML and XML has been a stated
goal of the 3 Project, almost all of the Projects work so far
has been focused on developing the infrastructure for writing
document classes and packages The community is just beginning to
harvest the results of that workAnother aspect of the situation with SGML and XML in relation to
is that while is used by a very large community of
authors, it does not seem to be the case that large crowds of original
authors have migrated to wellknown document types such as that of
the Text Encoding Initiative (TEI),
http:www.teic.org, which provides a vehicle for capturing
electronic versions of classical printed texts, and the
DocBookhttp:www.oasisopen.orgdocbook
document type, of the Organization for the Advancement of Structured
Information Standards (OASIS), oriented (like Texinfo) toward
documentation of technical workWell supported SGML and XML document types such as these typically
are accompanied by formatting code for reaching both HTML for online
presentation and PDF for print presentationSome tentative and rather incomplete experimentsThese involved
using sgmlspl, about which there is a section in The
Web Companion lwc, and which is the staged translation workhorse
in the GELLMU Project, to begin building a translator from DocBook
to GELLMU article, sufficient for handling four particular document
instances.
I have undertaken, with the GELLMU didactic document type playing the
role of a profile, suggest to me that the process of formatting
SGML and XML documents for print and HTML can be improved by first
translating to a suitable profile This may seem contrary to
common sense The first point, however, is that numbering and
crossreferences can be worked out at an early stage, so that one can
have consistency in this regard between the print and HTML outputs
The second point is metaphorical Think of the trip from a source
document to an end format as a downhill journey One can jump the
entire distance, or one can move more slowly, checking in at way
stations along a path; at each of these stages one strives to retain
as much as possible for that stage of the authors expressed intention
as found in the sourceSuggestions for EvolutionSlide latexproject presents a capsule description of what
I think the Project should undertake in order to support
the generation of HTML and other nontraditional formats from
sourcepSlidelatexproject:Suggestion for the Projectvspace24bpp{0.03}p{0.65}p{0.03}Sponsor one or more reference profilesSponsor translations from reference profiles to
PDF and HTMLBecause the Project needs to continue to provide support for
legacy documents, a document instance written under a profile
must be clearly identifiable at the outset My suggestion, used from
the outset in the GELLMU Project, is that one of these new document
instances, prepared under a profile, should begin with
documenttype rather than documentclassThe argument of documenttype should be the name of the root
element in the XML document type corresponding to the profile
being used The name of the root element in an XML document type
falls far short of specifying completely what document type definition
(command list) is involved With GELLMU documenttype has an
option whose content is typically a string that serves as a key to (or
name for) a data structure that has been made known to the syntactic
translator (See 3.1 of the GELLMU Manual
glman.) If this option is missing, the syntactic translator
looks for a default value for that key corresponding to the name of
the root element While presently in GELLMU the documenttype option
points to information characterizing the document type and style
choices are determined by the manner of running processors on a
document instance, it would be possible with profiles, if
desired, to incorporate style choice information in the data
structures behind these keysAs with the ad hoc system created for the TDS specification (section
tds) there will be various choices for processing a document
instance prepared under a profile In particular, there are
a number of choices for print formatting Slide printroute
indicates three possibilities:pSlideprintroute:Paper Typesetting of a Profilevspace24bpp{0.03}p{0.65}p{0.03}There are several possibilities:
Translate to classical Translate to ContextTeach itself to digest the profileIn case it is not completely clear, I should point out that the third
of these routes might be substantially different from the first two in
that the latter probably should involve first explicitly generating
the XML shadow of the document instance and then translating from
there If one is also going to have HTML output, it would, of
course, be expected that the HTML output would be translated from the
same XML shadow With the third route, however, there will be the
question of bypassing generation of a formal XML shadow and then
losing the advantage of structural validation or maybe constructing
the XML shadow for structural validation and for staging nonprint
outputs but generating the print output directly from the sourceAt this point I hope that the suggestions in Slide publishing
will be obviouspSlidepublishing:Publishingvspace24bpp{0.03}p{0.65}p{0.03}Encourage maintainers of XML document types
to reach HTML and PDF by translating first
to reference profilesEncourage authors to submit articles to
journals as instances under reference profilesTechnical editing by a journal should not be necessary when an
article is submitted under a reference profile The journal
will have its own profile that is a modification of a reference
profile enabling the journal to incorporate metadata For each
article a journal will prepare metadata, and the journals processing
stream will merge that metadata with the authors source to generate
a document instance under the journals profile that, in turn, will
be processed to end formats using the journals formatting softwareIssues with ImplementationWithin the GELLMU project, particularly its didactic production system,
there is demonstration that everything discussed here is possible
The question is how these ideas might be introduced so as to provide
as smooth as possible a transition in authoring techniques for those
users who wish to avail themselves of the advantages of source
markup that is amenable to generalized processing rather than only
processing for print by enginesSyntaxThe discussion following slide printroute suggests that a possible
route to print for a document instance under a profile might
bypass the profiles XML shadow There are related questions:
Might a modern engine like luatex be a good vehicle for
generating the SGML shadow Similarly, might such an engine
be a better vehicle than the GNU Emacs Lisp engine for generating
the Texinfo version of the TDS specification (see section tds)Shall the engine used to generate the SGML shadow use knowledge
(unlike the GELLMU syntactic translator) of the
corresponding document type definitionThat the GELLMU syntactic translator operates only on syntax, largely
without knowledge of command vocabulary, enables the syntactic translator
to be employed for writing virtually any SGML or XML document type using
directly the vocabulary of that document type with the advantage for
the author of being able to use GELLMUs newcommand with arguments.
in so doing For example, shall this stage of processing be
allowed to know that frac takes two arguments, numerator and
denominator, and to know what the names of those arguments are
In regard to the second of these questions, if the processor for generation
of the SGML shadow is allowed to use knowledge of command vocabulary, then
the syntactical requirements for a document instance could be somewhat
looser than in GELLMU For example, as in but not in GELLMU,
spaces could be allowed between the successive arguments and options in
a command invocation This would be both possible and, in a sense,
authorfriendly However, I do not recommend loose syntax The syntactic
tightness of GELLMU was motivated by that of Texinfo The enforcement of
syntactic tightness can help prevent author errors Moreover, the overall
design of processing is more modular when the first stage deals only
with syntaxAlso if the processor for generation of the SGML shadow incorporates
knowledge of the command vocabulary, then it may be reasonable for that
processor to write the XML shadow directly without first going through
an SGML shadow and then relying on an SGML parser and a subsequent
processor with knowledge of the command vocabulary to write the XML
shadowCountersWhile has infrastructure for managing counters, there is nothing
entirely parallel in the SGML world Document types can provide hooks
for counting, and the processors operating on those document types can
take those into account Section 5.5 in the GELLMU Manual
glman, Labels, References, and Anchors, explains the approach
to this in the GELLMU didactic production systemWhere there are to be multiple end formats of a given document
instance, it is best if counters, numbering, and crossreferences are
managed centrally, as in the GELLMU didactic production system, so
that there is consistency among the various end formatsNamesFor a faithful representationFaithful to the source apart from
newcommands that should appear expanded.
of source markup under a profile as an XML document every item
of markup needs to have a nameFor the document type of the GELLMU didactic production system the minimum
number of characters in a command name is three One and two character names are
reserved for user macros While this is not necessary, I recommend itA number of frequently used commands in classical do not have
names The SGML and XML shadows need names for them For example,
is nonbreaking space in In the GELLMU didactic production
system it becomes the empty element named nbs.Of course,
nonbreaking space is the Unicode character U00A0, but writing that
in the XML shadow would make the shadow not a faithful representation of
the source.While the argument in a command such as emph simply corresponds
to the content of an element emph in the XML shadow, the
arguments in a command taking more than one argument such as frac need
to be named Thus, for example, frac37 would be represented in
the XML shadow as
fracnumr3numrdenm7denmfracSpecial ASCII CharactersOne commonly sees the 128 characters in the ASCII character set
in a table of 8 rows of 16 characters each The first 2 rows are control
characters that are, apart from newlines, nonprintable and not used either
in or in SGML document types Thus there are 6 rows of 16 characters
that are the printable ASCII characters except for the very last of
these, which is not printable and not relevant here Within the ASCII
realm, we need to deal with the 95 printable characters Of these 62
are alphanumeric upper and lower case letters and numerals The 33
remaining printable ASCII characters are the special ASCII
charactersWithin the realm of electronic formats each of the 33 special ASCII
characters is a candidate for use as a control character of some type
For this reason it is wise that a name be provided for each of these characters
in a profile This is the case in the GELLMU didactic document
type Thus, for example, has markup meaning in , and
one may use to place an actual left brace in ones document;
in the GELLMU didactic production system is represented
by the empty element lbr in the XML shadow The character is
only a bit different Normally it is perfectly safe to use this character
for itself in a document, and normally there is no harm in passing
it through as itself to the XML shadow If, however, the author, as in
the case of the TDS specification (see tds), wants to translate the
document to Texinfo, there is suddenly a problem since has markup significance
in TexinfoFor each of these 33 special characters there can be found contexts where
they have markup or control significance Names should be available
for all of themNonASCII CharactersBecause and originally handled only 7 bit characters,
has legacy names for characters that are no longer strictly necessary
or, at least, almost no longer strictly necessary in the sense that we expect
unicodecapable modern engines soon to be mainstreamed For example,
there is the character , U0142, which may be entered as
lIn keeping with the thought that one character
names should be reserved for user macros, the name for this character in
the GELLMU didactic production system is csll.
in and as lstrok; in classical HTMLFor the long term it seems clear that names for Unicode characters beginning
with the Latin 1 range of Unicode are not neededCSSCSS stands for Cascading Style Sheets, which is a web
technology for controlling the appearance of HTML and of arbitrary
authorlevel XML document types for display in mainstream web browsersAt the point where some documents have XML shadows, one may become
interested in writing CSS sheets for governing the display
of those XML shadows in web browsers Beyond that the question
arises whether there might some day be gain in using CSS sheets
to govern, at least in part, the typesetting of such a document by w3cxml Tim Bray, Jean Paoli, C. M. SperbergMcQueen,
Extensible Markup Language (XML) 1.0, World Wide Web Consortium
Recommendation, 10 February 1998,
http:www.w3.orgTR1998RECxml19980210, currently
superseded by http:www.w3.orgTRRECxmlgoldfarb Charles F. Goldfarb, The SGML Handbook,
Oxford University Press, 1990lwc Michel Goossens and Sebastian Rahtz et al., The
Web Companion, AddisonWesley, 1999lamport Leslie Lamport, : A Document Preparation System,
2nd Edition, AddisonWesley, 1994glman William F. Hammond, The GELLMU Manual, 2007, available
at CTAN, http:mirror.ctan.orgsupportgellmudocglman.pdf, or
http:mirror.ctan.orgsupportgellmudocglman.xhtml
(XHTML MathML)bridge William F. Hammond,
GELLMU: A Bridge for Authors from to XML,
TUGBoat: The Communications of the Users Group, vol. 22 (2001),
pp. 204207; also available online at
http:www.tug.orgTUGboatContentscontents223.htmldual William F. Hammond,
Dual presentation with math from one source using GELLMU,
TUGboat: The Communications of the Users Group,
vol. 28 (2007), pp. 306311; also available online at
http:www.tug.orgTUGboatContentscontents283.html
A video recording of the presentation at TUG2007, July2007, in
SanDiego is available at
http:www.rivervalley.tvconferencestextug2007multipurpose William F. Hammond,
Multipurpose like markup for math, talk given in
the AMSMAA Special Session Putting Math on the Web the Correct Way
at the Joint Mathematics Meetings in San Diego in January2008 This
has not been published, but HTML slides that link to many examples are
available on the web at
http:math.albany.edumathpershammondPresenJMM08Putting