<TeXML/>·Manual  
  :: nn :: nn ::    
     


<TeXML/> Manual

think {\TeX}
write <TeXML/>
view <?xml?>
print LaTeX
 
test files
THIS IS NOT IBM's NOR GetFO's TeXML !
but a variant, always under construction
INHALT [javascript:makeTOC()]

Unterschiede

Die geniale Idee der IBM-TeXML besteht darin, daß nicht jeder TeX-Befehl in einem XML-Element abgebildet wird – das wären sehr viele Befehle & Elemente – sondern „nur“ die Struktur der TeX-Markup-Sprache. Das reduziert die Zahl der Elemente auf lediglich 8 (derzeit 10 bei mir) und macht die “Document Type Definition” extrem einfach. Dabei sind einige der Elemente sogar nur der Bequem­lich­keit geschuldet.

Zusätzlich, weil die “Document Type Definition” keine Annahmen und Vorgaben zu Befehlsnamen hat, bleibt die Transformation nach TeX robust gegenüber vom Anwender neudefinierten Befehlen. Programmiert jemand in TeX neue Befehle oder Stile, so kann man erwarten, daß er dies für die direkte Anzeige seiner Kreationen auch im XSL/CSS-Bereich selbst macht.

Elemente der IBM-TeXML (und zwingende Attribute)
<TeXML>...</TeXML>
<cmd name="texname">...</cmd>
<env name="texname">...</env>
<opt>...</opt>
<parm>...</parm>
<group>...</group>  <!-- * -->
<ctrl ch="char"/>
<active ch="char"/> <!-- * -->
<spec cat="code"/>
*NB: Das Element <active> war nur in einer früheren, das Element <group> nur in einer späteren Version von TeXML vorhanden.
Elemente der „StUs“-TeXML (und zwingende Attribute)
<TeXML>...</TeXML>
<TeX>...</TeX>  <?TeX ... ?>  <!-- * -->
<cmd name="texname">...</cmd>
<env name="texname">...</env>
<opt>...</opt>
<arg>...</arg>
<grp>...</grp>
<par>...</par>
<act on="TeX" as="XML"/>
<x>...</x>
*NB: Die „Elemente“ <TeX/> und <?TeX?> haben die gleiche Funktion, nur läßt sich die processing-instruction vielfältiger einsetzen. – z.B. innerhalb des Markups eines anderen Namensraumes, ohne dessen Inhaltsmodell neu definieren zu müssen.
“Entitags”: Entitäten als leere Elemente (Element-Tags)
<ent:isoname/>
<ent:isoname texcode="{\localcode}"/>
Derzeit iso-lat1, iso-lat2, iso-num, iso-pub und einige w3c-xhtml.

Neue (und notwendige, wichtige) Eigen­schaften müssen die Unter­schiede recht­fertigen. Ziele sind

  1. die direkte visuelle – gestaltbare – Anzeige der TeXML-Datei in einem Web-Browser (User Agent, UA), ohne vorherige Trans­formation in ein anderes Format. Je nach Gestaltung kann auch dies schon „gut druckbar“ sein. Typische Hypertext-Funktionen – da eventuell im Netz zugänglich – sollen möglich sein, ohne Neben­effekte auf TeX.
  2. Transformation in das TeX-Format ohne proprietäre Software, sondern möglichst nur mit einem XSLT-Stylesheet und einem freien (open-source) XSLT-Prozessor. Oder noch besser gleich und direkt im Browser mit eingebundenem (alternativen) Stylesheet.
  3. Das Ergebnis soll eine voll funktions­fähige TeX-Datei sein, die nicht mehr nach­bearbeitet werden muß. Alle gestalterischen Angaben zum Druck müssen in der TeXML-Datei Platz finden können, damit stets nur eine Datei zu editieren ist (von externen Stil-Dateien, die TeX importiert, abgesehen).

Die Einschränkungen der IBM-TeXML:

  1. Sie unterscheidet (d.h. trennt) den Inhalt nicht, der einerseits einem Leser präsentiert wird, von dem Inhalt, der andererseits nur zur Steuerung des TeX-Programms und des Outputs dient. Das macht es unmöglich, dieses TeXML direkt in einem UA anzuzeigen. Denn der Leser ist nicht an den TeX-Interna interessiert – die aber nicht ohne einige Intelligenz herausgefiltert werden können.
    Die Alternative wäre, nur Nutzer-relevanten Inhalt zu „kodieren“. Das bedeutet aber, daß nach jeder Trans­forma­tion die TeX-Datei (jedesmal neu) nachgearbeitet werden muß. Ich halte es für unmöglich, zumindest für unpraktisch, die gesamte TeX-Steuerung wirklich restlos in Stil-Dateien zu verbannen.
  2. Zur Transformation werden spezielle Java-Programme (“TeXMLatté” &c) gebraucht, die meines Wissens nicht ganz frei und offen sind. Einer der Gründe für ihre Notwendigkeit mag sein, daß zur Entstehungszeit (1998/99) die XSL(T)-Spezifikationen noch sehr neu waren und kaum von anderen Programmen umgesetzt wurden.

Die veränderte TeXML erlaubt es nun, den Inhalt in drei Kategorien einzu­teilen.

  1. Inhalt, der nur zur Steuerung des TeX-Programms dient. Das fängt an bei der Grundstruktur eines LaTeX-Dokuments, Seiten­gestaltung „für Papier“, Umdefini­tionen von Befehlen, Angaben zu Maßen und Schriften und dergleichen. Das sind nicht die Inhalte, um derentwillen Markup überhaupt benutzt wird, und der „Nutzer“ will sie nicht sehen.
  2. Inhalt, der nur in einem XML-Kontext eine Rolle spielt. Zum Beispiel zur Kontrolle der visuellen Anzeige und Naviga­tions-Elemente in einem Browser. Oder Inhalte – typischer­weise Verzeichnisse –, die von TeX/LaTeX automatisch generiert würden (und dort nicht gebraucht werden), aber informativ wären und deshalb „von Hand“ erstellt sind.
  3. Schließlich der „restliche“ Inhalt, auf den es eigent­lich ankommt, der mittels Markup mit maschinen­lesbarer Gliederung (Struktur) und Bedeutung (Semantik) versehen wird. Er ist der echte Quell-Text, neu geschaffen oder vorgefunden.

Besonders wichtig, eigentlich selbst­ver­ständlich um der Konsistenz der Inhalte willen: es darf nur eine Datei (Datei-Gruppe) geben, deren Inhalte editiert werden. Die Ergebnis-Dateien einer Trans­forma­tion sind für direkte Korrekturen tabu.

Die XSLTransformation in TeX übernehmen (bisher) Mozilla, Saxon oder Expat/Sablotron mit dem TeXML2TeX.xsl Stylesheet. Spezielle Java-Programme entfallen. Dagegen – auch wenn vermutlich das meiste kodierbar ist – steckt die Anzeige (bes. Formeln, Tabellen, die LaTeX-eigene picture-Umgebung usw. – mangels eigenen Bedarfs) sehr in den Anfängen. Es ist fraglich, ob alles sinnvoll anzuzeigen ist, oder ob vielmehr Formeln doppelt kodiert werden sollen: MathML und TeXML – und nur jeweils eins wird gezeigt. Es ist auch nicht das Ziel, das LaTeX-Erscheinungsbild für den UA zu kopieren, sondern es reicht eine sinnvolle und lesbare Anzeige. Typographische Finesse ist natürlich wünschenswert, muß ihre Maßstäbe jedoch aus der Web-Welt beziehen, nicht aus der Druck&Papier-Welt.

An den Beispielen weiter unten wird sich zeigen, daß TeXML eine Art „syntaktischer Redundanz“ hat. Die verschiedenen TeXML-Formen, deren Trans­formation nach TeX identisch ist, sollen dem Nutzer eine möglichst flexible Trennung der Inhalte erlauben. Er muß auch die sehr flexible TeX-Syntax nutzen und ausdrücken können, und gleichzeitig die vielleicht unterschiedliche Wirkung in XML/TeX berücksichtigen. Viele Unterschiede der Kodierung wirken sich nur im XML-Kontext aus, doch die Ergebnisse müssen ja letztlich TeX-konform bleiben. Trotzdem ist die Inhalts-Trennung im Sinne eines guten Markup und sollte sehr sorgfältig gemacht werden. Diese Arbeit ist kaum maschinell zu leisten, wenn die Trennung vorher nicht schon auf andere Weise für Maschinen lesbar gemacht wurde. Ein Programm, das z.B. TeX in TeXML übertragen sollte, müßte für jeden TeX-Befehl wissen, welchen Inhaltstyp er in seinen Argumenten erwartet. Für selbstdefinierte Befehle schwierig.

Viele TeX-Benutzer sind es gewohnt, eigene Befehle (d.h. Makros) zu definieren. Wären TeX-Befehle TeXML-Elemente, müßte jedesmal die DTD vom Benutzer geändert oder erweitert werden. Befehle (Befehlsnamen) als Element-Attribut-Werte sind frei wählbar und kommen der üblichen Arbeitsweise entgegen.

Elemente und (optionale) Attribute bzgl. “Content”
<TeX>internal</TeX>
<?TeX internal ?>

<cmd name="texname"
     args="texonly">...</cmd>
<env name="texname"
     args="texonly">
     ...
    </env>

<opt|arg|grp|x type="tex|xml">
     ...
    </opt|arg|grp|x>

<x wrap="toc|lof|..." type="tex|xml">
   e.g. TeX-generated code made by hand
   </x>
Elemente und Attribute bzgl. “Grouping”
<opt|arg|grp bg="begingroup" eg="endgroup">
     inline content
    </opt|arg|grp>

<env name="texname"
     bc="begincommand" ec="endcommand"
     bg="begingroup"   eg="endgroup">
     content
    </env>

<grp name="texname texname ..."
     bg="begingroup"   eg="endgroup">
     ...
    </grp>

<par>...</par> <!-- standard text-paragraph -->

<x> block-content </x><x> next block </x>
<x> block-content </x>
<!-- no empty lines between par's or x'es,
     but transform to -->

<par/>
<!-- dito, but w/o block-effect in XML -->
Alle bc/ec/bg/eg-Attribute sind optional, und haben Default-Werte in der DTD (sofern diese überhaupt beachtet wird). Das name-Attribut im <env>-Element ist obligatorisch mit nur einem Namen, im <grp>-Element optional und auch mit mehreren Namen möglich.
Elemente mit (optionalen) Attributen bzgl. “Linking”
<cmd|env|x ... id="id" to="idref">
     ...
    </cmd|env|x>

<cmd|env|x ... xlink:attnames="values" ...>
     ...
    </cmd|env|x>

Ein TeXML-Dokument

XML + Doctype + TeXML + Namespace

 
<?xml version="1.0"
      encoding="iso-8859-1"
      standalone="no"?>
<?xml-stylesheet
      alternate="yes"
      type="text/xml"
      href="TeXML2TeX.xsl"
      title="TeXML/XSLTransform to TeX"?>
 <!-- alternate not operating !? -->
 <!-- mime-type not text/xsl  !? -->
<?xml-stylesheet
      type="text/css"
      href="TeXML.css"
      title="TeXML/CSS-2: LaTeX look-alike"?>
<!DOCTYPE TeXML PUBLIC
          "-//StUs//DTD TeXML//EN"
          "http://www.unterstein.net/ML/TeXML.dtd">
<TeXML xmlns="http://www.unterstein.net/ML/TeXML"
       xmlns:xhtml="http://www.w3.org/1999/xhtml"
       xmlns:xlink="http://www.w3.org/1999/xlink"
       xml:lang="de">
      <xhtml:title>TeXML Manual</xhtml:title>
...
</TeXML>

Für den Fenstertitel des Browsers reicht ein einfacher Rückgriff auf den xHTML-Namespace. Ebenso später (s.u.) für Links.

Zwei Style­sheets vertragen sich (noch?) nicht gleichzeitig in einem Dokument (als Alternativen mit alternate="yes|no", vgl. W3C). Mozilla erlaubte dann wie in xHTML (über “view | use stylesheet”) die Auswahl per Menü. Bisher wählt Mozilla bei xsl+css-Alter­nativen aber ausschließlich das xsl-Stylesheet. Vielleicht ändert sich dies bei xsl+xsl-Alter­nativen oder zukünftig generell. Jedenfalls wäre die gleichzeitige Einbindung verschiedener (alternativ visueller und transformierender) Stylesheets korrekt und entschieden eleganter.

TeX output mit Mozilla 1+ / MSIE 6+
<?xml-stylesheet
      type="application/xml"
 <!-- type="text/xsl" für IE+Moz -->
      href="TeXML2TeX.xsl"
      title="TeXML/XSLTransform to TeX"?>
Gleiche Stylesheets mit verschiedenen MIME-Types können gleichzeitig in der Datei sein, solange beide fehlerfrei geparst werden. interner Link TeXML-texmlxsl.xml MSIE zeigt den im Browser – und in das Browserfenster – transformierten text/plain leider nur als endlose Inline-Textschlange an; teilweise fehlen auch Nodes: ein Problem mit “whitespace”, “linefeed/break” und “subset-entities” bzw. (vermutlich) der rigorosen Normalisierung.
.htaccess (TeX output online)
AddType application/xml xml
AddType application/xml xsl
Laut Mozilla XSLT soll der MIME-Type text/xml für source und stylesheet sein. Neuer und besser (zur Encoding-Erkennung) ist application/xml, nach rfc3023. Bei Apache-Servern kann er über die .htaccess-Datei (z.B. im Wurzel-Verzeichnis) gesetzt werden. Dann klappts auch mit der Online-Transformation.
TeX output mit Saxon 6.5.2 (instant)
saxon -a -o file.TeX  file.xml
saxon    -o file.TeX  file.xml  TeXML2TeX.xsl
Saxon kann sowohl interne (XML PI, -a) als auch externe Stylesheets verarbeiten. Anscheinend ist es sinnvoll, eine lokale Kopie der TeXML.dtd zu haben, und die DOCTYPE-uri darauf zu legen. Saxon möchte sonst „anrufen“. Es ist auch möglich, die DOCTYPE-Deklaration heraus zu kommentieren. Allerdings bleiben dann die Defaultwerte der Attribute unbeachtet. Bis jetzt nimmt TeXML2TeX.xsl aber Rücksicht darauf, da auch Mozilla die DTD nicht liest.
TeX output mit Sablotron 0.98 (+ Expat 1.95.6)
sabcmd  TeXML2TeX.xsl  file.xml  file://file.TeX
Probleme kann es mit dem Output-Encoding mancher Entitäten geben. Die typographischen Zeichen &ldquo; &rdquo; &ndash; &mdash; usf. im iso-8859-1 sind bei mir die üblichen Verdächtigen. Es empfiehlt sich, die Zeichen nicht direkt in den Output schreiben zu lassen, sondern stattdessen über generische Entitäten ebenso generische TeX-Befehle, siehe z.B. \textquotedblleft
FIXED: TeX output mit MSXML 3.40/4.20 (+ msxsl.exe)
msxsl  file.xml  TeXML2TeX.xsl  -o file.TeX
msxsl.exe – alternativ: WSHxslt.wsf – ist das cmd/sh-Interface für msxml.dll, den Microsoft-XML-Parser. Die Versionen sollten 3+ sein. Obwohl der Parser validieren kann (Option -v), scheitert dies an den externen Namensräumen (“namespace”) in Dokumenten, für die DTDs nicht richtig geeignet sind.

LaTeX Class + Styles + Document

Natürlich ist es nicht zwingend, ein LaTeX-Dokument zu erzeugen. Jedes beliebige TeX sollte möglich sein. Nur ist TeX viel „näher“ am konstanten Papier, der Drucker­schwärze und der punktgenauen Druck/Seiten­steuerung, als am Bild­schirm und an variablen Fenster­größen. Die Ziel­setzungen der Ausgabe klaffen einfach weiter auseinander. Deshalb ist es schwieriger, TeX visuell in einem Style­sheet umzu­setzen. LaTeX ist bereits generisches Markup und deshalb wesentlich besser geeignet. Je weniger “low level”, desto besser.

Das TeXML.css stellt nur die grundlegenden Stile der Standard-Befehle zur Verfügung, ähnlich wie auch Browser nur einfachste Defaults für die xHTML-Elemente kennen. Alle Neu- und Um­defini­tionen von TeX-Befehlen sind „Interna“ und haben erstmal keine Aus­wirkungen auf die visuelle Erscheinung. Alles muß doppelt definiert werden: für Papier und Bild­schirm sind verschiedene Stil-Dateien und Stil-Sprachen zuständig.

 
<TeXML xmlns="...">
<cmd name="documentclass"
     args="[10pt,a4paper]{article}"/>
    <cmd name="usepackage"
         args="[T1]{fontenc}"/>
    <cmd name="usepackage"
         args="[latin1]{inputenc}"/>
    <cmd name="usepackage"
         args="{hyperref}"/>
...
<env name="document">
...
</env> <!-- end document -->
</TeXML>

Das Stil-Paket fontenc mit Option T1 stellt mehr Zeichen und verbesserte Trennung zur Verfügung.

Das Stil-Paket hyperref sollte zusammen mit <xhtml:a href="URI">...</xhtml:a> in TeXML verwendet werden, um zu \href{URI}{...} o.Ä. transformieren zu können.

Das Stil-Paket inputenc mit Option latin1 korrespondiert mit encoding="iso-8859-1" zur unkodierten Eingabe vieler gängiger „Sonder“-Zeichen (Umlaute, Akzente &c).

 

Es ist ausreichend, wenn der TeX-Teil den Bedingungen eines importierbaren TeX-Files genügt.

Teildokumente z.B. für \import{file}
<TeXML xmlns="...">
<x type="xml">
   ...
  </x> <!-- xml visible header -->
<x wrap="doc">
   ...
  </x> <!-- end pseudo document -->
<x type="xml">
   ...
  </x> <!-- xml visible footer -->
</TeXML>
Selbst der “Wrapper” <x wrap="doc"> ... </x> könnte noch entfallen. Er erleichtert aber die visu­elle Gestaltung, wenn er ersatz­weise die document-Stile übernimmt. Beachten: ein type="tex" würde nicht angezeigt! Ebenso wie umge­kehrt die type="xml" Teile nur der visuellen Vervoll­ständigung der XML-Anzeige dienen.
Variante mit xhtml:table
<TeXML xmlns="..."
       xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xhtml:table summary="forematter">
   ...
  </xhtml:table>
<x wrap="doc">
   ...
  </x>
<xhtml:table summary="backmatter">
   ...
  </xhtml:table>
</TeXML>
Tabellen des Typs <xhtml:table> ... </xhtml:table> werden nicht trans­formiert. Sie sind geeignet, web-spezifische Funktionen aufzunehmen, und kommen damit der gängigen Arbeitsweise im xHTML-Seitenlayout entgegen, Elemente in/mit Tabellen zu positionieren.

Verschiedene Ansätze zur Arbeitsweise.

  1. Jedes Dokument ist für sich ein gültiges TeX-Doku­ment, das als gültiges TeXML kodiert ist. Es enthält Defini­tionen und Anweisungen für Stil-Importe, die nur (La)TeX sind – wie generell die Stil-Dateien selbst – und deren Anzeige unter­drückt wird.
  2. Nur die Teildokumente werden in TeXML kodiert (und sind für das Netz vor­ge­sehen), während das Hauptdoku­ment, das alle Stil-Importe, Defini­tionen und (Teil-) Doku­ment-Importe enthält, wie gewohnt nur (La)TeX ist. Natürlich kann ein Projekt auch aus nur einem „Teil“-Doku­ment bestehen, das importiert wird.
  3. TeXML-Inseln werden in XHTML-Dateien einge­bettet, z.B. nur ein Daten­bestand, der in anderem Zu­sammen­hang ordent­lich gedruckt sein muß. Der Namens­raum <TeXML xmlns="http://www.unterstein.net/ML/TeXML"> wird dafür wichtig. Das TeXML2TeX.xsl Style­sheet sollte dann nur die Insel heraus­filtern und trans­formieren. (Sinn­voll? Jeden­falls noch nicht getes­tet!)

(La)TeX Interna & Kommentare

Da im Vorspann eines Dokuments üblicherweise mehrere interne und für XML unbrauchbare TeX-Anweisungen stehen, sollte es nicht nötig sein, sie extra in TeXML notieren zu müssen. Oder dafür das type="tex"-Attribut zu bemühen.

 
<TeXML xmlns="...">
...  <!-- (La)TeX preamble -->
<TeX xml:space="preserve">
%%
%%   some TeX internals in document-head
%%
\raggedbottom
\frenchspacing
\pagestyle{headings}
\makeatletter
    \clubpenalty=\@M
    \widowpenalty=\@M
\makeatother
%%
</TeX>
...
<env name="document">
...
</env> <!-- end document -->
</TeXML>

Der LaTeX Dokumenten-Vorspann ist eigentlich auch nur für TeX relevant. Deshalb ginge folgendes.

 
<TeXML xmlns="...">
<TeX xml:space="preserve">
\documentclass[10pt,a4paper,draft]{article}
    \usepackage[T1]{fontenc}
    \usepackage[latin1]{inputenc}
    \usepackage{letterspace,xspace}
    \usepackage{a4,german,hyperref}
    ...
</TeX>
<env name="document">
...
</env> <!-- end document -->
</TeXML>

Ein wichtiger Unterschied: diese Variante könnte nur sehr umständlich – wenn überhaupt oder zu welchen Zweck auch immer – von einem Stylesheet ausgewertet werden. Bei der in TeXML kodierten Variante ist das einfacher.

Zu beachten ist auch der Fall, daß TeXML-Code z.B. in einem TeX Kommentar zur Dokumentation vorkommen soll. Generell ist <TeX> das beste Element (auch “inline”), TeX Kommentare zu kodieren.

 
<TeX xml:space="preserve"><![CDATA[
%%
%%   TeX \par is <cmd name="par"/>
%%   TeX "empty line" is <par/> or empty line
%%   TeX & XML paragraph is <x>...</x>
%%   <par>...</par> is identical/standard
%%
]]></TeX>
Der innere Bereich muß in <![CDATA[...]]> ein­ge­schlossen sein.
 
<?TeX
%%
%%   TeX \par is <cmd name="par"/>
%%   TeX "empty line" is <par/> or empty line
%%   TeX & XML paragraph is <x>...</x>
%%   <par>...</par> is identical/standard
%%
?>
Ebenfalls möglich, ohne escape.

Eine processing-instruction ist auch an „verbotenen“ Orten möglich, z.B. eine <?TeX \hline ?> zwischen den Zellen einer xHTML-Tabelle.

Beispiele für Befehle

Befehle dürfen nur Optionen <opt>, Argumente <arg> oder weitere Befehle <cmd> enthalten. Keine anderen Elemente und keinen „freien“ Text.

Das name-Attribut ist zwingend. Es kann aber auch ein Leerzeichen (whitespace) name=" " enthalten.

Der Inhalt des args-Attributs wird stets als TeX-Inhalt betrachtet und sollte nach TeX-Konventionen korrekt (z.B. geklammert) sein. Er wird niemals direkt sichtbar angezeigt. Er kann natürlich von einem Stylesheet zur Darstellung des übrigen Inhalts ausgewertet und berücksichtigt werden.

Theoretisch kann das args-Attribut beliebig viel TeX-Code enthalten, aber praktisch sollte man das vielleicht nicht übertreiben.

\texname
<cmd name="texname"/>
\texname ␣ text
<cmd name="texname"/>text <!-- text=textnode -->
<cmd name="texname" args="␣"/><!-- always ws -->text
“Whitespace” (“ ␣ ”) wird automatisch eingefügt, wenn (1) <cmd/> keine Kind-Knoten hat, (2) kein args-Attribut hat, und (3) der erste folgende Knoten ein Text-Knoten ist. Whitespace in einem args-Attribut wird immer eingefügt.
\texname{}
<cmd name="texname" args="{}"/>
<cmd name="texname"><arg/></cmd>
<cmd name="texname"/><grp/>
\texname\ ␣ 
<cmd name="texname" args="\␣"/>
<cmd name="texname"/><cmd name="␣"/>
Weitere Möglichkeiten, texname mit einem expliziten “white­space” zu beenden.
{\texname}
<grp name="texname"/>
<grp><cmd name="texname"/></grp>
Gruppenklammern, die Befehle begrenzen.
{\texname ␣ text}
<grp name="texname"/>text</grp> 
<grp><cmd name="texname"/>text</grp>
“whitespace” (“ ␣ ”) wird nach dem letzten texname eingefügt, wenn (1) der erste Kind-Knoten ein Text-Knoten ist.
\texname[]{texarg}
<cmd name="texname" args="[]{texarg}"/>
\texname[optional]{argument}
<cmd name="texname"
     args="[optional]{argument}"/>

<cmd name="texname"><opt>optional</opt>
                    <arg>argument</arg></cmd>
In einem XML-Kontext sind sowohl optional als auch argument im ersten Beispiel unsichtbarer, im zweiten Beispiel sichtbarer Inhalt.
\texname\texname{argument}
<cmd name="texname1" args="\texname2">
    <arg>argument</arg></cmd>

<cmd name="texname1">
    <cmd name="texname2">
        <arg>argument</arg></cmd>
</cmd>
Im ersten Fall hat \texname2 keinen Einfluß auf den UA, bzw. müßte als args von texname1 extra ausgewertet werden, auch wenn schon ein Stil für texname2 definiert wäre. Man beachte (und unterscheide evtl. im Stylesheet): der Backslash im Attribut args ist zwingend, im Attribut name ist er verboten.
Weiterhin ist im ersten Fall unklar, welcher Befehl Argument ist oder eines bekommt.

Optionen und Argumente

Optionen <opt> und Argumente <arg> dürfen nur Kind-Elemente von Befehlen <cmd> oder Umgebungen <env> sein. Außerhalb von Elementen oder „freistehend“ in anderen Elementen sind sie undefiniert. Sie dürfen keine <env>-Elemente enthalten.

<opt> und <arg> haben ein type-Attribut, das die Werte "tex" oder "xml" annehmen kann. Der Inhalt der Elemente wird dann entsprechend des Kontextes angezeigt, ausgegeben oder unterdrückt. Dies ist für den Fall, daß TeX-Inhalte und sichtbare Inhalte in „seltsam“ gemischter Reihenfolge Befehls-Argumente sind.

Der Attributwert type="xml" hat im Zusammen­hang mit Optionen und Argumenten noch keine besondere Verwendung.

Zwei weitere Attribute sind bg und eg, “begingroup” und “endgroup”, mit denen die Default-Werte der Begrenzer ("[]" und "{}" in der DTD) für die XSLTransformation überschrieben werden können.

\texname{visible content}{texarg}
<cmd name="texname">
    <arg>visible content</arg>
    <arg type="tex">texarg</arg>
    </cmd>
texarg wird nicht angezeigt. Gleiches gilt für Befehlsvarianten mit <opt type="tex">texopt</opt> Optionen.
\verb|verbatim content|
<cmd name="verb">
    <arg bg="|" eg="|">verbatim content</arg>
    </cmd>

Beispiele für Umgebungen

\begin{texname}[texopt]{texarg} ... \end{texname}
<env name="texname"
     args="[texopt]{texarg}">
     visible block-content
    </env>

<cmd name="begin"
     args="{texname}[texopt]{texarg}"/>
     visible “not-in-a-xml-block”-block-content
<cmd name="end"
     args="{texname}"/>

<grp bg="\begin{texname}[texopt]{texarg}"
     eg="\end{texname}">
     visible block-content, no style-access
    </grp>
Nur die erste Version (mit <env>) entspricht einem block-Element in XML und kann dort den Inhalt gestalten. Die anderen Versionen sind praktisch nicht besonders sinnvoll. Aber ausreichend, wenn es nur auf den TeX-Code ankommt.
{\texname ...}
<grp><cmd name="texname"/>
     visible content </grp>

<grp bg="{\texname ">
     visible content </grp> <!-- :( -->
Pseudo-Blocks, in denen texname keinen XML-Effekt hat. Außerdem ist <grp> ein inline-Element. Der Mißbrauch der bg und eg Attribute sollte besser vermieden werden.
{\texname\texname ...} oder {\texname {\texname ...}}
<grp name="texname texname ...">
     ...
    </grp> oder

<grp name="texname">
<grp name="texname">
     ...
    </grp></grp>
Das name-Attribut ist optional und kann mehrere, durch whitespaces getrennte texnames enthalten. Eigentlich gibt es keine „benannten“ Gruppen, aber um des XML-Effekts und der gewohnten TeX-Syntax willen …. Das zweite Beispiel ist klarer in Gruppierung und Gültigkeits­bereich.
Bei der Transformation einer benannten Gruppe mit unmittelbar folgendem Text-Inhalt nach TeX wird als Befehls­begrenzer ein zusätzliches Leer­zeichen zwischen dem letzten (Befehls-) Namen und dem Gruppen­inhalt eingefügt. Genauer: wenn der erste Kindknoten ein Textknoten ist.
{\TeX}ML und {\TeX{}ML} und {\TeX ␣ ML} und \TeX ␣ ML
<grp name="TeX"/>ML und
<grp name="TeX"><grp/>ML</grp> und
<grp name="TeX">ML</grp> und
<cmd name="TeX"/>ML
Eine Gruppenklammer, die einfach einen Befehl begrenzt. Bei unmittelbar folgendem Text-Inhalt (Text-Knoten) mit zusätzlichem Leer­zeichen (“white­space”, “ ␣ ”).
FIXME: {\texname {...}}
<grp><cmd name="texname">
         <arg>visible content</arg></cmd>
    </grp>
Gültig, aber unschön; ein Mißbrauch: texname erwarte(t) eigentlich kein Argu­ment, weshalb <arg> als einfache {}-Gruppe wirkt. Der Neben­effekt ist aber, daß das Pseudo-Argu­ment in eine benannte Gruppe – das dafür zweck­entfremdete <cmd>-Element – eingebettet ist. Dies wiederum legt den XML-Wirkungs­bereich von texname fest.
\begingroup\texname content \par\endgroup^^M
<grp name="texname"
     bg="\begingroup"
     eg="\par\endgroup">
     content with style-access
    </grp><par/>
\begingroup content \endgroup
<env name="group" bg="" eg="">
     content with style-access
    </env>
$ mathmode-content $ ...
<grp bg="$" eg="$"> <!-- TeX -->
     inline mathmode-content
    </grp>

<grp bg="\(" eg="\)"> <!-- LaTeX -->
     inline mathmode-content
    </grp>

<grp bg="$$" eg="$$"> <!-- TeX -->
     mathmode-content
    </grp>

<grp bg="\[" eg="\]"> <!-- LaTeX -->
     mathmode-content
    </grp>
Besser: LaTeX <env>
\begin{...} mathmode-content \end{...}
<env name="math|displaymath|equation|eqnarray">
     mathmode-content
    </env>
Noch besser: MathML
“List/Item”-Umgebungen

Die Listen-Umgebungen (list, description, enumerate, itemize) brauchen wegen ihrer Einträge (“items”) einige gesonderte Anmerkungen.

Die folgenden Beispiele sind gleichwertig, was ihre Transformation nach (La)TeX betrifft. Die jeweils erste Variante ist die einfachste und intuitiv naheliegendste. Ihr Problem: sie gruppieren den zugehörigen Eintrag nicht, und sie klären ihre Zugehörigkeit zum item nicht!

\item content1234
<cmd name="item"/>
     content1

<cmd name="item"/>
     <x>content2</x>

<grp name="item" bg="" eg="">
     content3
    </grp>

<cmd name="item">
     <arg bg=" " eg=" ">content4</arg>
    </cmd>
\item[mark] content12
<cmd name="item"><opt>mark</opt></cmd>
     content1

<cmd name="item"><opt>mark</opt>
     <arg bg=" " eg=" ">content2</arg>
    </cmd>

Absätze

TeX kennt keine speziellen Kenn­zeichen oder Um­gebungen für Absätze. Implizit wirken Leer­zeilen auf diese Weise, und die Befehle \par und \endgraf sind eher zum Gebrauch in Definitionen. XML kennt dagegen keine Leer­zeilen, und kann Absätze nur gestalten, wenn sie in ein Element ein­ge­bettet sind, zwischen zwei Element-Tags stehen. Dies beträfe z.B. schon die üblichen und ganz gewöhn­lichen Absatz-Einzüge bei TeX.

Es wird also ein Element gebraucht, das im TeX-Output lediglich (mindestens) eine Leerzeile erzeugt – auch da, wo im TeXML-Source keine ist. Ein <cmd name="par"/> könnte die Leer­zeile „leisten“, nicht aber den XML-Block. Auch entspräche es nicht den Gewohn­heiten in TeX, den Text mit \par zu füllen.

Es läuft darauf hinaus, ein (weiteres) Element einzuführen, das keine direkte Entsprechung in TeX hat. Ich habe bewußt ein völlig unspezifisches <x>...</x> gewählt. Einmal, um eine zu enge Assoziation oder Verwechslung mit einem <par>...</par> zu vermeiden. Es soll klar sein, daß es sich um eine Erweiterung handelt, die in XML begründet liegt. Zum Anderen, um es auch für andere Zwecke (d.h. nicht als Absatz) verwenden zu können, wenn nun schon einmal ein allgemeines XML-Block-Element da ist. (Nebenbei: ein <xml>...</xml> ist laut XML Spezifikation nicht erlaubt. Das „x“ soll aber noch daran erinnern.)

<x> hat ein optionales wrap-Attribut, das den Inhalt bezeichnet, der von dem Element „eingewickelt“ wird. Als Default (d.h. bei fehlendem Attribut) ist es mit wrap="par" belegt. Es hat derzeit folgende mögliche Attribut-Werte:

  • doc : document
  • div : division, d.h. unspezifisch, wie HTML-div
  • toc : tableofcontent
  • lof : listoffigures
  • lot : listoftables
  • idx : index
  • glo : glossary
  • par : paragraph, d.i. default

Wie vielleicht ersichtlich, handelt es sich um Inhalte, die normaler­weise von TeX automatisch generiert würden. Es ginge auch mit XSL-FO (“Formatting Objects”), wenn dies ausreichend implementiert wäre. Bis dahin – wenn die Inhalte nützlich sind und gebraucht werden – empfiehlt sich Handarbeit, z.B. in der Übernahme und Umkodierung von eben dem generierten TeX-Code. Damit die Wahl bleibt, den XML-Code im TeX-Dokument doch zu behalten (manche TeX-Verzeichnisse sind nur halb-automatisch), sollten bestehende (La)TeX-Befehle in TeXML-Notation verwendet werden

Werte wie wrap="doc|div" sind nützlich, wenn unvoll­ständige TeX-Doku­mente in TeXML zu kodieren sind, oder HTML-Doku­mente nach TeXML transformiert werden. Der Default-Wert wrap="par" ist stilistisch mit Absatz-Einzügen (wie in TeX) vorbelegt. Für Dokument-Abschnitte, z.B. wrap="toc", kann <x> automatisch Überschriften („Inhalt“) generieren. Je nach Sprache müssen die Stylesheets aber modifiziert werden.

 

Einfach nur zur Bequem­lich­keit gibt es noch ein <par/>-Element, das leer nur die erforderlichen Leerzeilen für TeX einfügt, und einen neuen Absatz in XML anfängt. Es fügt keinen \par-Befehl ein und taugt auch nicht zur Absatz­steuerung in XML, d.h. des vorigen oder folgenden Absatzes (Einzüge &c). Es ist dort wie ein Zeilenumbruch.

Es bietet sich an, das <par>...</par>-Element mit Inhalt dann zu benutzen, wenn es sich um nicht weiter spezifizierte Inhalte handelt, also Standard-Text-Absätze ohne weitere Funktion. Das erleichtert mindestens die Unterscheidung im Stylesheet.
Ansonsten ist es identisch zu <x wrap="par">...</x>.

<par/> und <cmd name="par"/>
...content.<par/>
...content.

...content.<cmd name="par"/>
...content.
Das <par/>-Element fügt eine Leerzeile im TeX-Code ein. Das <cmd .../>-Element fügt einfach ein \par ein. Beide Elemente erzeugen einen Zeilen­umbruch in XML.
TeX-Absatz & XML-Block
<x>
   ...
  </x>   <!-- no empty line -->
<x wrap="par">   <!-- default -->
   ...
  </x>
<par>   <!-- identical -->
   ... (standard text-paragraph)
  </par>
Nach einem schließenden </x>-Element-Tag wird eine Leerzeile im TeX-Code eingefügt. Das wrap="par" Attribut kann entfallen. In dem Fall zur besseren Code-Lesbarkeit vielleicht statt­dessen <par>...</par> verwenden.
\tableofcontents
<cmd name="tableofcontents"/>
<x wrap="toc" type="xml"><TeX>%% by hand</TeX>
  <grp bg="\begingroup" eg="\endgroup">
      <cmd name="contentsline"
           xlink:type="simple"
           xlink:show="replace"
           xlink:actuate="onRequest"
           xlink:href="#id"
           args="{chapter}"><arg>text</arg>
          <arg/></cmd>
      <cmd name="contentsline"
           args="{section}"><arg>text</arg>
          <arg/></cmd>
      <cmd name="contentsline"
           args="{subsection}"><arg>text</arg>
          <arg/></cmd>
      <cmd name="contentsline"
           args="{subsubsection}"><arg>text</arg>
          <arg/></cmd>
      <cmd name="contentsline"
           args="{section}"><arg>text</arg>
          <arg/></cmd>
      <cmd name="contentsline"
           xlink:type="simple"
           xlink:show="replace"
           xlink:actuate="onRequest"
           xlink:href="#id"
           args="{chapter}"><arg>text</arg>
          <arg/></cmd>
  </grp>
  </x>  <!-- end toc -->
Ein Inhalts­ver­zeich­nis, wie es in file.toc von TeX generiert würde, nach TeXML umkodiert, und – abhängig vom type-Attibut – im XML Kontext angezeigt, für TeX wieder heraus-transformiert. Das leere <arg/>-Element enthielte in TeX die Seitenzahl.
Die chapter sind zur Demonstration mit xlink-Attributen versehen, die das Inhalts­ve­rzeich­nis aktiv machen. Sie werden nicht nach TeX übertragen, da dort die Funktionalität Teil der contentsline-Makro­definiton sein müßte.

Besondere Zeichen und Entitäten

Am Besten und Einfachsten in der Handhabung sind gleiche input-encodings wie latin1 und iso-8859-1. Damit werden die meisten Zeichen direkt eingegeben und behandelt. Ein weiterer Teil der sog. named commands, die kein Argument erwarten, sondern nur ein Zeichen setzen, ist im Stylesheet definierbar. Sie sind dann wie üblich als <cmd> zu kodieren. Trotzdem bleibt ein häßlicher Rest.

Als direkte Eingabe

Sowohl XML und die Transkodierung mit XSLT als auch TeX müssen mit den direkt eingegebenen Zeichen zurechtkommen. Damit das eine wirkliche Erleichterung wird, kann es sein, daß man einige Zeichen für LaTeX nach­definieren muß.

vgl. \texmf\tex\latex\base\latin1.def
\DeclareInputText{130}{\quotesinglbase}   % &lsquor;
                                          % = &rsquo;
\DeclareInputText{145}{\textquoteleft}    % &rsquor;
                                          % = &lsquo;
\DeclareInputText{132}{\quotedblbase}     % &ldquor;
                                          % = &bdquo;
\DeclareInputText{147}{\textquotedblleft} % &rdquor;
                                          % = &ldquo;

\DeclareInputText{145}{\textquoteleft}    % &rsquo;
                                          % = &rsquor;
\DeclareInputText{146}{\textquoteright}   % &lsquo;
\DeclareInputText{147}{\textquotedblleft} % &ldquo;
                                          % = &rdquor;
\DeclareInputText{148}{\textquotedblright}% &rdquo;

\DeclareInputText{139}{\guilsinglleft}    % &lsaquo;
\DeclareInputText{155}{\guilsinglright}   % &rsaquo;
\DeclareInputText{171}{\guillemotleft}    % &laquo;
\DeclareInputText{187}{\guillemotright}   % &raquo;

\DeclareInputText{150}{\textendash}       % &ndash;
\DeclareInputText{151}{\textemdash}       % &mdash;
Die direkte Eingabe der An- und Abführung verschiedener Sprachen, Gedanken­striche usw. Teilweise nur zusammen mit T1-Fontcode in LaTeX.

[FIXME: Saxon und Sablotron streiken bei einigen Output-Zeichen, die aber nach Wechsel zu UTF-8 output-encoding anstandslos durchgehen. Ist das der bessere Output-Standard? Was ist das LaTeX-Äquivalent zu UTF-8? Und dann mit welchem Editor?]

Für den häßlichen Rest (oder um die obigen Probleme zu vermeiden) erlauben die on/as-Attribute des <act>-Elements eine doppelte Kodierung – jeweils spezifisch für on="TeX" und as="XML".

Aktive Zeichen, Ligaturen, einige akzentuierte Zeichen &c sollen in Anzeige und Transformation sofort umgesetzt werden. Auch das TeX-Zeichen – der Wert des on-Attributs – muß erst durch den XML-Parser und muß deshalb der XML-Notation entsprechen. Dies gilt für Anzeige und Transformation, auch wenn jeweils ein Attributwert verworfen wird.

 
<act on="~" as="&nbsp;"/>
<act on="--" as="&ndash;"/>  <!-- * -->
<act on="---" as="&mdash;"/> <!-- * -->
<act on="``" as="&ldquo;"/>
<act on="''" as="&rdquo;"/>
<act on="\," as="&thinsp;"/>
<act on="\\" as="&#xA;"/>
*NB: Die n/mdash-acts könnten nicht „auskommentiert“ werden, da Kommentare keine weiteren Strich-Sequenzen enthalten dürfen.
\^o
<act on="\^o" as="&ocirc;"/>
<cmd name="^"><arg>o</arg></cmd>
Das Argument o des Befehls \^ (für den Circumflex-Akzent) muß Teil des on-Wertes sein, denn es wird ja mit ersetzt. Letzteres ist korrekter TeX-Code (o ist relevanter Inhalt :–), wird aber in der Anzeige nicht in „ô“ umgesetzt.
german.sty
<act on="&quot;-" as="&shy;"/>
<act on="&quot;=" as="-"/>

<act on="&quot;`" as="&bdquo;"/>
<act on="&quot;'" as="&ldquo;"/>
<act on="&quot;&gt;" as="&raquo;"/>
<act on="&quot;&lt;" as="&laquo;"/>

<act on="&quot;a" as="&auml;"/>
<act on="&quot;A" as="&Auml;"/>
<act on="&quot;o" as="&ouml;"/>
<act on="&quot;O" as="&Ouml;"/>
<act on="&quot;u" as="&uuml;"/>
<act on="&quot;U" as="&Uuml;"/>
<act on="&quot;s" as="&szlig;"/>
Als benannte Entitäten

Benannte Entitäten können ein Problem sein, abhängig davon, wie gut der XSLT Prozessor die DTD und die wiederum von ihr importierten Definitionen liest. Mozilla und Saxon verhalten sich verschieden. Bis hier Einigkeit herrscht, kann es nötig sein, benutzte Entitäten in jeder TeXML-Datei nochmals auf oberster Ebene – “internal subset” der DOCTYPE-Deklaration – einzuführen.

Entitäten
<!DOCTYPE TeXML PUBLIC
          "-//StUs//DTD TeXML//EN"
          "http://www.unterstein.net/ML/TeXML.dtd"
          [
          <!ENTITY ndash    "&#x2013;">
          <!ENTITY mdash    "&#x2014;">
          ]>

Alternativ wäre die direkte dezimale oder hexadezimale Notation der Entitäten. Also &#8211; oder &#x2013; statt &ndash;. Lästig, aber wenigstens funktionierend. Mit einigen Tools, z.B. HTML-Tidy im XML-Modus (und ohne pretty print!), geht eine Umwandlung auch nachträglich.

Zwar ist es möglich, alle Zeichen zu maskieren (z.B. <act on="``" as="&ldquo;">, oder nach Definition im Stylesheet <cmd name="textquotedblleft"/>), doch wer will das schon alles tippen. Auch hier können Entitäten helfen – und gleichzeitig die Transkodierung umgehen! Für alle problematischen Zeichen im output-encoding scheint dies die beste Methode:

“left-double-quote” Entität
<!ENTITY ldquo
         "&#x201C;">
<!ENTITY A.ldquo
         "<act on='&#096;&#096;' as='&#x201C;'/>">
<!ENTITY C.ldquo
         "<cmd name='textquotedblleft' args='{}'/>">
<!ENTITY G.ldquo
         "<grp name='textquotedblleft'/>">
<!ENTITY G.ldquo2
         "<grp name='lq lq'/>">  <!-- ligature -->

<!-- german.sty -->

<!ENTITY GRP.grqq
         "<grp name='grqq'/>">
<!ENTITY GER.ldquo
         "<act on='&quot;&#x0060;' as='&#x201C;'/>">

<!-- generic entity -->

<!ENTITY GEN.ldquo
         "&G.ldquo;">
Nur die generische Entität (und darin noch besser ein generisches TeX-Makro, z.B. \dlq...\drq) sollte in den Texten benutzt werden, um die Kodierungs­varianten leicht tauschen zu können.

Mit diesem Verfahren kann man ISO-Entitäten oder TeX-Befehle als TeXML-Sequenzen nachbilden, sofern sie vollständige (abgeschlossene, wohlgeformte) XML-Knoten ergeben. TeXML.enthält eine Reihe von Beispielen und einen Vorschlag für ein Namens­schema.

Entitäten als leere Element-Tags

Ein weiteres Verfahren, das etwas aufwendig zu implementieren ist, aber einige Vorteil bringt. ISO-Entitäten werden als Elemente mit eigenem Namensraum definiert, die ihre Darstellungs- und Transformations-Werte (CSS-, Uni- oder TeX-Code) in Attributen vorhalten. Der größte Teil des Aufwands besteht darin, die vielfach vermehrten Elemente in das Inhaltsmodell der DTD zu integrieren, und alle ihre Attribute mit Codes zu belegen.

&ldquo; als “Entitag”
<TeXML xmlns="http://www.unterstein.net/ML/TeXML"
       xmlns:xhtml="http://www.w3.org/1999/xhtml"
       xmlns:ent=
       "urn:entitags:entity-as-empty-element-tag">
      <xhtml:title>TeXML Entitags</xhtml:title>

<ent:ldquo/>

<ent:ldquo texcode="{\textquotedblleft}"
           unicode="&#x201C;"
           csscode="\00201C" />

<ent:ldquo texcode="``"/>
<ent:ldquo texcode="{\lq\lq}"/>
<ent:ldquo texcode="&#x0060;&#x0060;"/>
<ent:ldquo texcode="&quot;&#x0060;"/>

</TeXML>
Standard, mit voller Kodierungs­information, und mit alternativen Kodierungen, z.B. im Dokument.

Liest ein Parser die DTD und verfügt damit über die vorbelegten Attribut-Werte, so kann das in den Stylesheets (XSL und CSS) sehr einfach berücksichtigt und ausgewertet werden. Parser, die die DTD nicht lesen, reichen die Elemente – im Gegensatz zu den sofort ersetzten Entitäten – an die Stylesheets weiter. Diese brauchen dann lediglich noch eine zusätzliche, aber auch notwendige XML-„Datenbank“, aus denen sie die Codes auslesen können.

  • entitags.xml – ohne Stil und DTD; wird von *.xsl als Transformations-Datenbank verwendet. Bei Updates sollten die Attribut-Werte unbedingt „gleich­wertig“ zu den Werten in entitags.mod bleiben.
  • entitags.mod – DTD-Modul, das von TeXML.dtd importiert wird. Streng gesehen überflüssig, da der ganze Aufwand nur gemacht ist für Browser, die die DTD eben nicht lesen. Aber eine Trans­formation ist natürlich schneller, wenn die schon vom Parser gelesenen und vor­belegten Attribut­werte benutzt werden.
  • entitags.css – wird von TeXML.css importiert und zur Anzeige benötigt.
  • entitagX.xml – transformiert sich zu einem JavaScript-Array (für TeXML.js) und einem CSS2/3-Stylesheet (z.B. entitags.css). Entweder den ent­sprechenden Teil aus dem Browser-Fenster heraus­kopieren, oder je nach Prozessor-Option den Parameter NN='JS' oder NN='CSS' setzen.

Letztlich bringt der Ansatz wenigstens zwei nützlichen Effekte. Die Sonder­zeichen und -codes müssen nicht mehr in jedem Dokument (im Doctype-Subset als Entitäten) definiert werden. Und diese „Zeichen­kodierung“ (als “Entitag”) wird vom Parser durch­gereicht und kann später – im Style­sheet – beliebig ver­arbeitet werden. Andererseits ist es nicht möglich, Zeichen-Elemente in Attributwerten zu verwenden.


Tabellen

  • <xhtml:table> : xHTML-Tabelle
    • <xhtml:thead>...</xhtml:thead> : Gruppe
    • <xhtml:tfoot>...</xhtml:tfoot> : Gruppe
    • <xhtml:tbody>...</xhtml:tbody> : Gruppe
    • <xhtml:tr>...</xhtml:tr> : Reihe
    • <xhtml:th>...</xhtml:th> : Zelle
    • <xhtml:td>...</xhtml:td> : Zelle
    • <xhtml:th|td colspan="#">... : Zellen
  • </xhtml:table> : wird nicht transformiert
  • <env name="tabular" args="[pos]{form}"> : LaTeX-Tabelle
    • <xhtml:thead>...</xhtml:thead> : Gruppe
    • <xhtml:tfoot>...</xhtml:tfoot> : Gruppe
    • <xhtml:tbody>...</xhtml:tbody> : Gruppe
    • <xhtml:tr>...</xhtml:tr> <?TeX \hline ?> : Reihe
    • <xhtml:th>...</xhtml:th> : Zelle
    • <xhtml:td>...</xhtml:td> : Zelle
    • <xhtml:th|td colspan="#">... : Zellen
  • </env> : wird transformiert

Man beachte die processing-instruction <?TeX \hline ?> zwischen den Reihen, mit der zusätzlicher TeX-Code eingefügt wird.

Aus XML-Sicht

In XML documents conforming to this specification, no tag may contain two attributes which:
  1. have identical names, or
  2. have qualified names with the same local part and with prefixes which have been bound to namespace names that are identical.

Aus diesem Grund sind die Namensräume xhtml und xlink in der DTD reserviert und fixiert. Weder die Namensraum-Bezeichner (Präfixe) noch Bindungen an den gleichen Namensraum dürfen nochmals definiert werden. Auch die transformierenden Stylesheets arbeiten mit genau diesen Namen.

DTD
<!ATTLIST TeXML
          xmlns       CDATA #FIXED
          "http://www.unterstein.net/ML/TeXML"
          xmlns:ent   CDATA #FIXED
          "urn:entitags:entity-as-empty-element-tag"
          xmlns:xlink CDATA #FIXED
          "http://www.w3.org/1999/xlink"
          xmlns:xhtml CDATA #FIXED
          "http://www.w3.org/1999/xhtml">
XML
<TeXML xmlns="http://www.unterstein.net/ML/TeXML"
       xmlns:xhtml="http://www.w3.org/1999/xhtml"
       xmlns:xlink="http://www.w3.org/1999/xlink">
...
</TeXML>

xlink:*-Elemente/Attribute

TODO

xhtml:*-Elemente/Attribute

TODO

TeXML:*-name-Attribut

Namen dürfen enthalten:
  1. Buchstaben (groß und klein)
  2. Ziffern 0 bis 9
  3. Interpunktionszeichen „_“ (Unterstrich), „-“ (einfacher Bindestrich), „.“ (Punkt) und „:“ (Doppelpunkt) – der Doppelpunkt ist jedoch reserviert für Namensräume
  4. Das erste Zeichen eines Namens darf keine Ziffer sein, es muss ein Buchstabe oder eines der erlaubten Interpunktionszeichen sein. In der Praxis sollte das erste Zeichen möglichst immer ein Buchstabe, allenfalls ein Unterstrich sein.
  5. Namen dürfen keine Leerzeichen enthalten.
  6. Unter „Buchstabe“ versteht die XML-Spezifikation einen sehr weiten Bereich des gesamten Unicode-Systems, und auch unter „Ziffer“ ist mehr erlaubt als die arabischen Ziffern unseres Dezimalsystems. In der Praxis und in Rücksicht auf gewöhnliche Parser ist jedoch zu empfehlen, sich auf die ASCII-Buchstaben A bis Z bzw. a bis z und die 10 bei uns gebräuchlichen Ziffern zu beschränken und auf andere Zeichen zu verzichten, auch auf deutsche Umlaute oder Sonderzeichen anderer Sprachen.
  7. Namen dürfen nicht mit der Zeichenfolge xml (oder XML) beginnen, da diese Zeichenfolge für künftige Weiterentwicklungen von XML reserviert ist.
  8. Namen müssen aus mindestens einem Buchstaben bzw. Unterstrich bestehen.

TeXML:*-id/to-Attribute

Browser, die die DTD nicht lesen, wissen nicht, ob (oder daß) id-Attribute als Typ ID definiert sind – und identifizieren die Elemente damit nicht als Sprungziele. Gleiches gilt für IDREF-Attribut-Typen. Im HTML Namensraum machen sie es mindestens mit id aus Gewohnheit.

id/to-Attribute in TeXML-Elementen
<!DOCTYPE TeXML PUBLIC
          "-//StUs//DTD TeXML//EN"
          "http://www.unterstein.net/ML/TeXML.dtd"
          [
          <!ENTITY % ID.dtdefined "IGNORE">
          <!-- prevent double-def & re-def ID -->
          <!ATTLIST cmd id ID #IMPLIED
                        to IDREF #IMPLIED>
          <!ATTLIST env id ID #IMPLIED
                        to IDREF #IMPLIED>
          <!ATTLIST grp id ID #IMPLIED
                        to IDREF #IMPLIED>
          <!ATTLIST x   id ID #IMPLIED
                        to IDREF #IMPLIED>
          ]>
Eine provisorische Lösung, analog zu den Entitäten. Aber problematisch, wenn DTDs doch gelesen und ID-Attribut-Typen für ein Element doppelt deklariert werden (obwohl bei gleichem Attribut-Namen die erste Deklaration Vorrang haben sollte). Um hier Parser-Klagen zu verhindern, kann ein "IGNORE" vorgeschaltet sein.

Es bringt also vorerst wenig, alle TeXML-Elemente mit einem id-Kern­attribut auszustatten. Für ein aktives Dokument scheint es am Besten, nur das <xhtml:a> Element (den XHTML Anker) zu benutzen, das dann je nach Variante in verschiedene TeX-Befehle umgesetzt wird.

Links, Marken, Verweise

\label{id}
<xhtml:a id="id"/>

<cmd name="label" id="id"/>
\label{texmark}
<cmd name="label"
     args="{texmark}">
     id="id"/>
Das args-Attribut – und damit die TeX-interne Marke – hat Vorrang vor einem optional zusätzlichen id-Attribut. Der Anwender hat selbst darauf zu achten, daß Verweise auf die id-Marke auf den XML-Kontext beschränkt bleiben, d.h. mit Befehlen, die nicht transformieren.
\hypertarget{id}{anchor-text}
<xhtml:a id="id"> </xhtml:a>
<xhtml:a id="id">
         anchor-text
        </xhtml:a>

<cmd name="hypertarget" id="id">
    <arg>anchor-text</arg></cmd>
\hyperlink{id}{anchor-text}
<xhtml:a href="#id">
         anchor-text
        </xhtml:a>

<cmd name="hyperlink"
     xlink:type="simple"
     xlink:show="replace"
     xlink:actuate="onRequest"
     xlink:href="#id">
    <arg>anchor-text</arg></cmd>
\href{uri}{anchor-text}
<xhtml:a href="uri">
         anchor-text
        </xhtml:a>

<cmd name="href"
     xlink:type="simple"
     xlink:show="replace"
     xlink:actuate="onRequest"
     xlink:href="uri">
    <arg>anchor-text</arg></cmd>
\hyperimg{src}
<xhtml:img src="src"
           alt="description"
           height="px-height"
           width="px-width"/>

<cmd name="hyperimg"
     xlink:type="simple"
     xlink:show="embed"
     xlink:actuate="onLoad"
     xlink:title="description"
     xlink:href="src"/>
TODO: \...ref{label-id|texmark}
<cmd name="ref" args="{texmark}"/>
<cmd name="pageref" args="{texmark}"/>

<cmd name="ref" to="label-id"/>
<cmd name="pageref" to="label-id"/>

<cmd name="hyperref"
     args="[texmark]"
     to="label-id">
     <arg>anchor-text</arg>
    </cmd>
Das to-Attribut hat noch keine Funktion, das args-Attribut hat Vorrang in der Transformation. Eine to-Funktion ist vermutlich nur mit XSL-FO zu machen, wobei dann generell eine TeXML-FO.xsl die bisherige TeXML.css ersetzen sollte. Achtung: Jedes label-id kann eine TeX-Marke sein, aber nicht umgekehrt.

Jedes <cmd>, <env> und <x> Element kann mit xlink-Attributen im XML-Kontext hyperaktiv sein. Aber nur für die Befehle des hyperref.sty wird der Wert des xlink:href-Attributs in ein TeX-Argument transformiert (und in {} geklammert).

Die Vorteile von xmlns:xlink sind beträchtlich. Die Attribute können leicht in der DTD deklariert und den Elementen zugeordnet werden. Die Funktionalität ist wesentlich größer. Es ist eindeutig, welche Elemente in TeX-Befehle zu transformieren sind.

Die Elemente des xmlns:xhtml sind in sich einfacher zu handhaben, dafür ist ihr Wirkungskontext aber zusätzlich zu klären. In der DTD haben sie keinen rechten Platz, was eine Validierung verhindert.


Unbedingt zu beachten (Zitate aus den Spezifikationen für HTML 4.01 und XHTML 1.0):

12.2.2 Nested links are illegal. Links and anchors defined by the A element must not be nested; an A element must not contain any other A elements. (…)
12.2.3 Anchors with the id attribute. The id attribute may be used to create an anchor at the start tag of any element (including the A element).
In XML, fragment identifiers are of type ID, and there can only be a single attribute of type ID per element. Therefore, in XHTML 1.0 the id attribute is defined to be of type ID. In order to ensure that XHTML 1.0 documents are well-structured XML documents, XHTML 1.0 documents MUST use the id attribute when defining fragment identifiers, even on elements that historically have also had a name attribute.

Wenig sinnvoll und deshalb auszuschließen ist sicher, aus einer “hyper”-aktiven TeXML über TeX-Code im hyperref.sty wieder eine xHTML zu machen. Es bleibt also der Pfad zu „papier­fähigen“ Quer­ver­weisen, die zusätz­lich in PDF aktiv sind.



(2002–) 2005 ff. ©|©|StUs