Jens Oliver Meiert

Ruby-Annotation (W3C)

Originalversion:
https://www.w3.org/­TR/ruby/
Übersetzer:
Jens Oliver Meiert, meiert.com
Datum der Übersetzung:
19. Oktober 2003 (↻ 7. Februar 2007)

Bei diesem Dokument handelt es sich um die deutsche Übersetzung eines W3C-Textes. Dieser Text ist urheberrechtlich geschĂŒtzt; bitte beachten Sie die Hinweise des Originaldokuments sowie die Anmerkungen der W3C-Dokumentlizenz. Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.

Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an den Übersetzer. Kommentare des Übersetzers, die als solche gekennzeichnet sind, unterliegen dem Urheberrecht des Übersetzers. Sie sind kein Bestandteil des Ursprungsdokuments. – Interessierte finden in JGloss eine Anwendung, die dem HinzufĂŒgen von Lesungs- und Übersetzungs-Annotationen zu Wörtern in einem japanischen Textdokument dient und diese Spezifikation berĂŒcksichtigt.

W3C.

Ruby-Annotation

W3C-Empfehlung vom 31. Mai 2001

Diese Version:
https://www.w3.org/TR/2001/REC-ruby-20010531
(ZIP)
Aktuelle Version:
https://www.w3.org/TR/ruby
Vorherige Version:
https://www.w3.org/TR/2001/PR-ruby-20010406
Herausgeber:
Marcin Sawicki (bis zum 10. Oktober 1999)
Michel Suignard, Microsoft
Masayasu Ishikawa (çŸłć· 雅ćș·), W3C
Martin DĂŒrst, W3C
Tex Texin, Progress Software Corp.
(Bitte beachten Sie die Danksagung, um mehr ĂŒber weitere Mitwirkende zu erfahren)

Kurzfassung

»Ruby« sind kurze Texte entlang einer Textbasis, die hauptsĂ€chlich in ostasiatischen Dokumenten zu finden sind, wenn eine besondere Betonung oder eine kurze ErlĂ€uterung dargestellt werden soll. Die vorliegende Spezifikation definiert das Markup fĂŒr Ruby als XHTML-Modul [XHTMLMOD].

Status dieses Dokuments

Dieser Abschnitt beschreibt den Status dieses Dokuments zur Zeit seiner Veröffentlichung. Andere Dokumente können an seine Stelle treten. Der letzte Stand dieser Reihe von Dokumenten wird vom W3C betreut.

Dieses Dokument wurde von Mitgliedern des W3C und anderen interessierten Parteien geprĂŒft und vom Direktor als W3C-Empfehlung bestĂ€tigt. Es ist ein stabiles Dokument und kann als Referenzmaterial verwendet oder als normative Referenz von einem anderen Dokument zitiert werden. Die Rolle des W3C bei der Erstellung dieser Empfehlung ist, die Spezifikation bekannt zu machen und ihre breite Anwendung zu fördern. Dies erhöht die FunktionsfĂ€higkeit und InteroperabilitĂ€t des Internets.

Das vorliegende Dokument wurde als Teil der vom W3C initiierten InternationalisierungsaktivitĂ€t von der Arbeitsgruppe Internationalisierung (I18N-WG, nur fĂŒr Mitglieder) mit UnterstĂŒtzung durch die Interessengruppe Internationalisierung (I18N-IG) geschrieben. Kommentare sollten an die öffentlich archivierte Mailingliste www-i18n-comments@w3.org gesendet werden. Kommentare und Anmerkungen auf anderen Sprachen als Englisch, insbesondere auf Japanisch, sind ebenso willkommen. Eine öffentliche Diskussion zu diesem Dokument wird auf der www-international@w3.org-Mailingliste gefĂŒhrt (siehe Archiv).

Aufgrund der Charakteristik des behandelten Themas und um realistischere Beispiele heranzuziehen behilft sich dieses Dokument einer großen Menge an Zeichen bzw. ZeichensĂ€tzen. Eventuell ist nicht jeder User-Agent (zum Beispiel Webbrowser) in der Lage, alle Zeichen korrekt darzustellen – je nach User-Agent kann es deshalb sinnvoll sein, die Konfiguration anzupassen. Es wurden fĂŒr dieses Dokument jedoch auch entsprechende Anstrengungen unternommen, um es fĂŒr verschiedenste Zeichenkodierungen und somit eine große Spanne User-Agents und Konfigurationen anbieten zu können.

Weitere auf dieses Dokument bezogene Informationen können auf der öffentlichen Ruby-Seite (https://www.w3.org/International/O-HTML-ruby) gefunden werden, welche neben weiteren Übersetzungen dieser Spezifikation auch mögliche Errata beinhaltet. Eine Liste aktueller W3C-Empfehlungen und weiterer technischer Dokumente finden Sie unter https://www.w3.org/TR.

Zu dieser Spezifikation gibt es bislang keine patentbezogenen ErklÀrungen seitens der Arbeitsgruppe Internationalisierung.


Inhaltsverzeichnis


1. Einleitung

Dieser Abschnitt ist informell.

Dieses Dokument stellt einen Überblick ĂŒber die Ruby-Annotation dar, definiert das entsprechende Markup und bietet eine Reihe von Beispielen. Nichtsdestotrotz werden in diesem Dokument keinerlei Mechanismen fĂŒr die PrĂ€sentation (Visualisierung) oder die Gestaltung der Ruby-Annotation spezifiziert, da dies Aufgabe der verwendeten Stylesheet-Sprache ist.

Das Dokument ist wie folgt aufgebaut:

Abschnitt 1.1 bietet eine Übersicht ĂŒber die Ruby-Annotation.

Abschnitt 1.2 bietet eine Übersicht ĂŒber das Markup von Ruby.

Abschnitt 2 liefert die normative Definition von Ruby-Markup.

Abschnitt 3 erörtert das gewöhnliche Rendern und Gestalten von Ruby-Text.

Abschnitt 4 definiert die KonformitÀtskriterien.

1.1 Was ist Ruby?

Ruby ist ein Begriff fĂŒr einen Textbereich, der mit einem anderen Text, der sogenannten Textbasis, verbunden ist. Ruby-Text wird gebraucht, um eine kurze ErlĂ€uterung zum verknĂŒpften Basistext zu liefern, meistens jedoch, um gewissermaßen als Ausspracheanleitung die entsprechende Lesart zu definieren. Ruby-Annotationen werden in Japan hĂ€ufig als Bestandteil vieler Arten von Publikationen (wie BĂŒchern und Zeitschriften) verwendet, aber sie finden ihre Anwendung auch in China, wo sie insbesondere in SchulbĂŒchern herangezogen werden.

Ruby-Text wird gewöhnlich mit kleinerer Schriftart entlang des Basistextes (auch: Textbasis) dargestellt. Der Name »Ruby« stammt ursprĂŒnglich vom Namen der 5,5-pt-SchriftgrĂ¶ĂŸe im britischen Buchdruck, welche lediglich etwa die HĂ€lfte der gewöhnlich verwendeten 10-Punkt-GrĂ¶ĂŸe fĂŒr normalen Text betrĂ€gt. Abbildung 1.1 zeigt ein Beispiel anhand von drei Ideogrammen (Kanji) als Textbasis sowie sechs Hiragana, die die Lesart bestimmen (hier: Shinkansen, ein japanischer Hochgeschwindigkeitszug).

Untere Zeile: Drei japanische Ideogramme (von links nach rechts). Obere Zeile: Sechs Hiragana-Zeichen in halber GrĂ¶ĂŸe. Ganz rechts: Pfeile und Text zur Kennzeichnung von »Ruby-Basis« (unten) und »Ruby-Text« (oben).

Abbildung 1.1: Ruby-Text, der die Lesart jedes Zeichens des Basistextes erörtert.

Die ostasiatische Typographie hat eine Vielzahl von Besonderheiten hervorgebracht, die nicht in der westlichen erscheinen. Die meisten davon können ĂŒber Stylesheet-Sprachen wie CSS oder XSL ausreichend angegangen werden – trotzdem ist es notwendig, dass zusĂ€tzliches Markup die Verbindung zwischen Basis- und Ruby-Text herstellt.

Diese Spezifikation definiert ein solches Markup, das zusammen mit XHTML verwendet werden und somit im Web ohne besondere Workarounds oder Graphiken zum Einsatz kommen kann. Obwohl diese Spezifikation Beispiele zum gegenwĂ€rtigen Rendern liefert, um es den meisten Lesern leichter zu machen, das Markup zu verstehen, sind diese Beispiele nur informeller Natur. Dieses Dokument spezifiziert keinerlei Mechanismen fĂŒr die PrĂ€sentation oder die Formatierung, da dies wie oben beschrieben Aufgabe der gebrauchten Stylesheet-Sprache ist.

Manchmal kann es vorkommen, dass mehr als ein Ruby-Text mit derselben Textbasis assoziiert wird. Ein typisches Beispiel ist, sowohl Bedeutung als auch Aussprache bzw. Lesart fĂŒr eine Textbasis anzeigen zu wollen. In solchen FĂ€llen können Ruby-Texte auf beiden Seiten der Textbasis erscheinen: Ruby-Text vor der Basis wird oft dazu verwendet, die Lesart darzustellen, wĂ€hrend er hinter der Textbasis die Bedeutung aufzeigen soll. Abbildung 1.2 veranschaulicht dies anhand von zwei Ruby-Texten, die sowohl die Lesart via Hiragana als auch die Bedeutung in lateinischen Schriftzeichen festlegen.

Mittlere Zeile: Drei japanische Ideogramme (von links nach rechts). Obere Zeile: Sechs Hiragana-Zeichen in halber GrĂ¶ĂŸe. Untere Zeile: Der Text »Shinkansen«. Ganz rechts: Pfeile und Text zur Kennzeichnung von »Ruby-Basis« (Mitte), »Ruby-Text« (oben) und »Ruby-Text 2« (unten).

Abbildung 1.2: Zwei Ruby-Texte, angewandt auf denselben Basistext.

ZusĂ€tzlich kann jeder Ruby-Text auch mit unterschiedlichen Teilen der Textbasis verknĂŒpft werden, wie es das folgende Beispiel veranschaulicht:

Tag Monat Jahr
31 10 2002
Verfallsdatum

Abbildung 1.3: Basistext mit zwei unterschiedlich verbundenen Ruby-Texten.

In diesem Beispiel ist der Basistext das Datum »31 10 2002«. Ein Ruby-Text entspricht dem Begriff »Verfallsdatum« und wird dabei auf die komplette Textbasis angewandt, wĂ€hrend hingegen der andere Ruby-Text in drei Teile separiert ist: »Tag«, »Monat« und »Jahr«. Jeder Teil hiervon ist mit einem unterschiedlichen Part des Basistextes verknĂŒpft, denn »Tag« wird mit »31« assoziiert, »Monat« mit »10«, und »Jahr« mit »2002«.

1.2 Überblick ĂŒber Ruby-Markup

Das in dieser Spezifikation definierte Markup wurde entworfen, um alle oben genannten FĂ€lle abzudecken, im einzelnen also Markup fĂŒr ein oder zwei Ruby-Texte, die zur selben Basis stehen, sowie Markup fĂŒr VerknĂŒpfungen von Untereinheiten von Ruby-Text mit einzelnen Bestandteilen der Textbasis.

Es gibt zwei Varianten des Ruby-Markups, die als einfaches Ruby-Markup (simple ruby markup) und komplexes Ruby-Markup (complex ruby markup) bezeichnet werden. Einfaches Ruby-Markup verbindet einen einzelnen Ruby-Text mit einem Basistext und bietet zusĂ€tzlich als Fallback noch einen Mechanismus, der es Browsern, die Ruby-Markup nicht parsen können, erlaubt, den Ruby-Text darzustellen. Komplexes Ruby-Markup kann zum einen zwei Ruby-Texte mit einer Basis assoziieren, zum anderen erlaubt es aber auch eine feinkörnige VerknĂŒpfung von einzelnen Komponenten eines Ruby-Textes mit Teilen der Textbasis. Das komplexe Ruby-Markup inkludiert jedoch keinen Fallback-Mechanismus fĂŒr Browser, die das Ruby-Markup nicht verstehen.

Dieser Abschnitt bietet einen Überblick ĂŒber das in dieser Spezifikation definierte Markup fĂŒr Ruby. Die vollstĂ€ndig formale Definition befindet sich in Abschnitt 2.

1.2.1 Einfaches Ruby-Markup

Im einfachsten Fall definiert das Ruby-Markup ein ruby-Element, welches ein rb- fĂŒr den Basistext und ein rt-Element fĂŒr den Ruby-Text beinhaltet. Folglich erstellt das ruby-Element eine VerknĂŒpfung von Textbasis und Ruby-Text, was in den meisten FĂ€llen ausreichend sein sollte. Hier ein Beispiel fĂŒr einfaches Ruby-Markup:

<ruby>
  <rb>WWW</rb>
  <rt>World Wide Web</rt>
</ruby>

Abbildung 1.4: Beispiel fĂŒr einfaches Ruby-Markup.

Dies könnte wie folgt gerendert werden:

Untere Zeile: Drei Großbuchstaben »WWW«. Obere Zeile: Der Text »World Wide Web« in kleinerer SchriftgrĂ¶ĂŸe. Ganz rechts: Pfeile und Text zur Kennzeichnung von »Ruby-Basis« (unten) und »Ruby-Text« (oben).

Abbildung 1.5: Beispiel fĂŒr das Rendern des einfachen Ruby-Markups aus Abbildung 1.4

Anmerkung: Das umschließende ruby-Element sollte mit der Bedeutung interpretiert werden, dass sein Inhalt den mit Basistext assoziierten Ruby-Text darstellt. Es sollte nicht so verstanden werden, dass der komplette eingeschlossene Teil (inklusive dem Basistext) Ruby ist; vielmehr wurde der Name des einkapselnden Elements so gewĂ€hlt, dass er klar und in kompakter Form die Funktion des Markup-Konstrukts identifiziert, wĂ€hrend die anderen Elementen so benannt wurden, um ihre GesamtlĂ€nge kurz zu halten.

1.2.2 Einfaches Ruby-Markup mit Parenthesen

Einige User-Agents verstehen Ruby-Markup unter UmstĂ€nden nicht bzw. sind nicht in der Lage, Ruby-Text korrekt darzustellen. In beiden Situationen mag es vorzuziehen sein, dass der Ruby-Text gerendert wird, damit die entsprechenden Informationen nicht verloren gehen. Ein durchaus annehmbarer Fallback besteht darin, den Ruby-Text unmittelbar hinter dem Basistext zu platzieren und ihn mit einer Parenthese (Klammer) zu umschließen. Diese Parenthese verringert die Wahrscheinlichkeit, dass Ruby-Text mit anderem Text verwechselt wird. (Es sollte ErwĂ€hnung finden, dass in Parenthesen dargestellter Text in der japanischen Typographie niemals »Ruby« genannt wird.)

Um KompatibilitĂ€t zu Ă€lteren User-Agents, die das Ruby-Markup nicht verstehen und einfach den Inhalt der Elemente rendern, die sie nicht kennen, zu ermöglichen, können rp-Elemente zum einfachem Ruby-Markup hinzugefĂŒgt werden, um Ruby-Text hervorzuheben.

Der Elementname rp steht fĂŒr »Ruby-Parenthese« (ruby parenthesis). Die rp-Elemente und umfassten Parenthesen (bzw. anderen Zeichen) werden lediglich als Fallback-Mechanismus angeboten. User-Agents, die unbekannte Elemente ignorieren, aber deren Inhalte darstellen, werden den Inhalt jedes rp-Elements ausgeben. Folglich kann das rp-Element dazu gebraucht werden, um sowohl Anfang als auch Ende des Ruby-Textes zu kennzeichnen.

User-Agents, die Ruby-Markup verstehen, werden das rp-Element erkennen und somit seinen Inhalt absichtlich nicht darstellen; statt dessen werden sie das einfache Ruby-Markup auf sachgemĂ€ĂŸere Weise rendern.

Das folgende Beispiel illustriert den Gebrauch des rp-Elements:

<ruby>
  <rb>WWW</rb>
  <rp>(</rp><rt>World Wide Web</rt><rp>)</rp>
</ruby>

Abbildung 1.6: Beispiel fĂŒr einfaches Ruby-Markup mit rp-Element als Fallback.

User-Agents, die entweder

  • kein Ruby-Markup verstehen, aber den Inhalt ihnen unbekannter Elemente rendern, oder die
  • keinen Ruby-Text entlang der Textbasis rendern können,

werden obiges Markup wie folgt darstellen:

WWW (World Wide Web)

Abbildung 1.7: Rendern von einfachem Ruby-Markup unter Verwendung von Parenthesen als Fallback.

User-Agents, die mit Ruby-Markup umgehen können und fortgeschrittenere PrĂ€sentationsarten fĂŒr Ruby-Text beinhalten, werden die Parenthesen nicht rendern. Als Beispiel soll das Markup aus Abbildung 1.6 entsprechend visualisiert werden:

Untere Zeile: Drei Großbuchstaben »WWW«. Obere Zeile: Der Text »World Wide Web« in kleinerer SchriftgrĂ¶ĂŸe. Ganz rechts: Pfeile und Text zur Kennzeichnung von »Ruby-Basis« (unten) und »Ruby-Text« (oben).

Abbildung 1.8: Ein infolge fortgeschritteneren Renderns ignoriertes rp-Element.

1.2.3 Komplexes Ruby-Markup

Komplexes Ruby-Markup wird verwendet, um mehr als einen Ruby-Text mit einem Basistext zu assoziieren, oder um Teile dieses Textes mit korrespondierenden Teilen des Basistextes zu verknĂŒpfen.

Komplexes Ruby-Markup sieht vor, dass mehrere rb- und rt-Elemente eingebunden werden. Diese Spezifikation definiert spezielle Elemente als Container, um die Assoziation zwischen einzelnen Elementen deutlich zu machen. Der Ruby-Base-Container (rbc-Element) umschließt rb-Elemente, wĂ€hrend es ein oder zwei Ruby-Text-Container (die rtc-Elemente) geben kann, die die entsprechenden rt-Elemente einschließen. Dies ermöglicht die VerknĂŒpfung von zwei Ruby-Text-Containern mit demselben Basistext. Mit komplexem Ruby-Markup ist es auch möglich, Teile der Textbasis mit Teilen eines Ruby-Textes zu assoziieren, indem man eine Anzahl von rb-Elementen sowie die entsprechend selbe Menge rt-Elemente definiert. Des weiteren kann das rt-Element ĂŒber das rbspan-Attribut anzeigen, dass ein einzelnes rt- mit mehreren rb-Elementen assoziiert wird und diese umspannt. Dies entspricht in etwa dem colspan-Attribut der th- und td-Elemente in Tabellen ([HTML4], Abschnitt 11.2.6).

Wo und wie jeder Teil komplexen Ruby-Markups gerendert wird, ist jeweils Aufgabe der verwendeten Stylesheet-Sprache; siehe Abschnitt 3 fĂŒr weitere Informationen.

Das folgende Beispiel verdeutlicht alle zuvor aufgefĂŒhrten Merkmale:

<ruby>
  <rbc>
    <rb>31</rb>
    <rb>10</rb>
    <rb>2002</rb>
  </rbc>
  <rtc>
    <rt>Tag</rt>
    <rt>Monat</rt>
    <rt>Jahr</rt>
  </rtc>
  <rtc>
    <rt rbspan="3">Verfallsdatum</rt>
  </rtc>
</ruby>

Abbildung 1.9: Komplexes Ruby-Markup, das zwei Ruby-Texte mit unterschiedlichen Bereichen derselben Textbasis assoziiert.

Im Beispiel umschließt der erste Ruby-Text-Container drei Komponenten, nĂ€mlich »Tag«, »Monat« und »Jahr«. Jeder dieser Bereiche wird mit einer entsprechenden Komponente im Basistext assoziiert (»31«, »10«, »2002«). Der zweite Ruby-Text-Container (»Verfallsdatum«) besteht aus einem einzigen Ruby-Text-Teil, der mit dem gesamten Basistext (»31 10 2002«) verknĂŒpft wird. Dies kann wie in Abbildung 1.10 gerendert werden:

Tag Monat Jahr
31 10 2002
Verfallsdatum

Abbildung 1.10: Beispiel fĂŒr das Rendern des komplexen Ruby-Markups aus Abbildung 1.9.

Das Beispiel zeigt, dass die VerknĂŒpfung von Ruby- und Basistext so granular wie jeweils erforderlich sein kann. So kann zum Beispiel sinnvoll sein, Ruby-Text mit dem kompletten Basistext zu assoziieren, wenn

  • eine detailliertere Beziehung nicht bekannt ist, oder wenn
  • die Lesart oder ErlĂ€uterung nur auf die gesamte Einheit angewandt und nicht weiter aufgeteilt werden kann.

Es können weitere feinkörnige Assoziationen geschaffen werden, sofern die Beziehungen bzw. VerhĂ€ltnisse zur Textbasis bekannt sind. So kann der Name einer Person in Vorname und Nachname zerlegt werden, auch kann beispielsweise eine Kanji-Zusammensetzung oder ein Satz in semantische Untereinheiten bzw. unterschiedliche Zeichen aufgeteilt werden. Egal welche Art von GranularitĂ€t gewĂŒnscht wird, die Spanne des jeweiligen Ruby-Textes kann den korrespondierenden Teilen des Basistextes entsprechend gesetzt werden, so dass möglicherweise eine bessere Lesbarkeit und ein ausgeglicheneres Layout erzielt werden.

Das rp-Element kann im Falle komplexen Ruby-Markups nicht verwendet werden, wofĂŒr es zwei GrĂŒnde gibt: Zum einen dient das rp-Element lediglich als Fallback-Mechanismus, welcher im hĂ€ufigeren Fall, nĂ€mlich der Verwendung von einfachem Ruby-Markup, als notwendiger angesehen wurde. Zum anderen ist es in Bezug auf die komplexeren FĂ€lle schwierig, sich eine angemessene Fallbackdarstellung einfallen zu lassen, und das Kreieren von Markup fĂŒr solche FĂ€lle kann schwierig, wenn nicht gar unmöglich sein.

1.2.4 Zusammenfassung

Das ruby-Element dient als Container in den folgenden FĂ€llen:

  • Eine Kombination aus rb-, rt- und evtl. rp-Elementen (einfaches Ruby-Markup) als
    • VerknĂŒpfung eines einzigen Ruby-Textes mit einem Basistext
    • Fallback fĂŒr den Fall, dass das Ruby-Markup nicht verstanden wird.
  • Eine Kombination eines einzelnen rbc- und einem oder zwei rtc-Container-Elementen (komplexes Ruby-Markup) als:
    • VerknĂŒpfung von zwei Ruby-Texten mit demselben Basistext
    • Definition feingranularer VerknĂŒpfungen zwischen Teilen eines Ruby-Textes und Teilen der Textbasis.

2. Formelle Definition des Ruby-Markup

Dieser Abschnitt ist normativ.

Dieser Abschnitt beinhaltet die formelle Syntaxdefinition und die Spezifikation der FunktionalitÀt des Ruby-Markups. Eine gewisse Vertrautheit mit dem Framework der XHTML-Modularisierung, im Besonderen der Modularization of XHTML-Spezifikation [XHTMLMOD], wird vorausgesetzt.

2.1 Abstrakte Definition des Ruby-Markups

Der folgende Teil entspricht der abstrakten Definition der Elemente des Ruby-Markups, die in Einklang mit dem Framework der XHTML-Modularisierung steht. Weitere Informationen ĂŒber abstrakte XHTML-Module liegen in der Dokumentation von [XHTMLMOD] vor.

Elemente Attribute Minimales Inhaltsmodell
ruby Common (rb, (rt | (rp, rt, rp)))
rbc Common rb+
rtc Common rt+
rb Common (PCDATA | Inline - ruby)*
rt Common, rbspan (CDATA) (PCDATA | Inline - ruby)*
rp Common PCDATA*

Das maximale Inhaltsmodell (maximal content model) des ruby-Elements entspricht:

((rb, (rt | (rp, rt, rp))) | (rbc, rtc, rtc?))

Das minimale Inhaltsmodell (minimal content model) des ruby-Elements entspricht einfachem Ruby-Markup. Der (rbc, rtc, rtc?)-Part des maximalen Inhaltsmodells des ruby-Elements ist hingegen ausschließlich komplexem Ruby-Markup zuzuordnen.

Auf eine Implementierung dieser abstrakten Definition als XHTML-DTD-Modul wird in Anhang A referenziert. An einer XML-Schema-Implementierung [XMLSchema] wird gearbeitet, siehe auch [ModSchema].

2.2 Das ruby-Element

Das ruby-Element ist ein Inline- bzw. Text-Level-Element, welches als Gesamtcontainer dient. Es beinhaltet entweder rb-, rt- und optional rp-Elemente (einfaches Ruby-Markup), oder rbc- und rtc-Elemente (komplexes Ruby-Markup).

Im Falle einfachen Ruby-Markups beinhaltet das ruby-Element entweder ein rb-, gefolgt von einem rt-Element, oder eine Sequenz eines rb-, rp-, rt- und eines weiteren rp-Elements. Der Inhalt des rt-Elements wird als Ruby-Text angesehen und mit dem Inhalt des rb-Elements (Basistext) assoziiert. Der Inhalt des rp-Elements wird, sofern vorhanden, ignoriert.

Liegt komplexes Ruby-Markup vor, umfasst das ruby-Element ein rbc-, gefolgt von einem oder zwei rtc-Elementen. Der Inhalt der Subelemente jedes rtc-Elements wird als Ruby-Text angenommen und mit dem Inhalt der Subelemente des rbc-Elements assoziiert, welches die Textbasis darstellt.

Das Ruby-Element besitzt lediglich common-Attribute. Beispiele fĂŒr common-Attribute sind id, class oder xml:lang. Sie hĂ€ngen von der jeweiligen Markupsprache ab, in deren Zusammenhang Ruby-Markup verwendet wird – im Fall von [XHTML 1.1] sind diese unter XHTML Modularization, Abschnitt 5.1 [XHTMLMOD] zu finden.

2.3 Das rbc-Element

Das rbc-Element (Ruby-Base-Container) dient im Falle komplexen Ruby-Markups als Container fĂŒr rb-Elemente. Innerhalb eines ruby-Elements darf nur ein rbc-Element verwendet werden.

Das rbc-Element besitzt lediglich common-Attribute.

2.4 Das rtc-Element

Das rtc-Element (Ruby-Text-Container) dient im Falle komplexen Ruby-Markups als Container fĂŒr rt-Elemente. Innerhalb eines ruby-Elements dĂŒrfen ein oder zwei rtc-Elemente verwendet werden, um als Ruby-Texte mit einem Basistext assoziiert zu werden. Dieser Basistext wird durch ein rbc-Element reprĂ€sentiert. Es DÜRFEN NICHT mehr als zwei rtc-Elemente innerhalb eines ruby-Elements verwendet werden.

Das rtc-Element besitzt lediglich common-Attribute.

2.5 Das rb-Element

Das rb-Element (ruby base) hebt den Basistext hervor. Innerhalb von einfachem Ruby-Markup darf nur ein rb-Element erscheinen; bei komplexem Ruby-Markup können mehrere rb- innerhalb eines rbc-Elements verwendet werden. Jedes rb-Element wird mit dem korrespondierenden rt-Element assoziiert, was eine feinkörnige Kontrolle der Ruby-Visualisierung gestattet.

Das rb-Element kann Inline-Elemente oder Zeichen (character data) als Inhalt haben. Das ruby-Element darf nicht Nachkomme dieses Elements sein.

Das rb-Element besitzt lediglich common-Attribute.

2.6 Das rt-Element

Das rt-Element ist das Markup fĂŒr Ruby-Text. Bei einfachem Ruby-Markup darf lediglich ein rt-Element verwendet werden; bei komplexem Ruby-Markup dĂŒrfen mehrere rt-Elemente innerhalb eines rtc-Elements gebraucht werden, wobei jedes rt-Element den Ruby-Text fĂŒr den relevanten Basistext darstellt, welcher durch die entsprechenden rb-Elemente reprĂ€sentiert wird.

Das rt-Element kann Inline-Elemente oder Zeichen (character data) als Inhalt haben. Das ruby-Element darf nicht Nachkomme dieses Elements sein.

Das rt-Element besitzt die common- sowie das rbspan-Attribut. Im Falle komplexen Ruby-Markups erlaubt das rbspan-Attribut einem rt-Element, mehrere rb-Elemente zu umspannen. Der entsprechende Wert sollte ein Integer-Wert sein, der grĂ¶ĂŸer als Null (»0«) ist; Default-Wert dieses Attributs ist Eins (»1«). Das rbspan-Attribut sollte nicht in einfachem Ruby-Markup verwendet werden, und User-Agents sollten es ignorieren, wenn es innerhalb von einfachem Ruby-Markup verwendet wird.

2.7 Das rp-Element

Das rp-Element kann innerhalb von einfachem Ruby-Markup gebraucht werden, um Zeichen zu spezifizieren, die Anfang und Ende von Ruby-Text kennzeichnen sollen, wenn User-Agents keinen anderen Weg finden, Ruby-Text unverwechselbar vom Basistext darzustellen. Parenthesen (oder Àhnliche Zeichen) können somit einen akzeptablen Fallback darstellen: In diesem Fall wird Ruby-Text so verÀndert, dass er inline gerendert und von den Fallback-Parenthesen umschlossen wird. Dies entspricht dem am wenigsten unpassenden Rendern unter der Voraussetzung, dass nur Inline-Rendern möglich ist. Das rp-Element kann nicht innerhalb von komplexem Ruby-Markup verwendet werden.

Das rp-Element besitzt lediglich common-Attribute.

Parenthesen als Fallback-Mechanismus zu verwenden mag zu Konfusion zwischen Textabschnitten, die Ruby-Text darstellen sollen, und anderen Textbereichen, die von Parenthesen umschlossen sind, fĂŒhren. Der Autor des Dokuments oder Stylesheets sollte sich dieser Gefahr bewusst sein, und es wird deshalb geraten, unzweideutige Begrenzungszeichen fĂŒr diesen Fallback zu wĂ€hlen.

3. Hinweise zum Rendern und Darstellen

Dieser Abschnitt ist informell.

Dieser Abschnitt behandelt verschiedene Aspekte bezĂŒglich Rendern und Gestalten von Ruby-Markup, wie es in diesem Dokument definiert wird. Dieses Dokument spezifiziert jedoch keine Mechanismen fĂŒr die PrĂ€sentation oder das Styling – dies wird der entsprechenden Stylesheet-Sprache ĂŒberlassen. Formateigenschaften, die Ruby in Form von Styles zugewiesen werden können, werden fĂŒr CSS und XSL entwickelt, siehe zum Beispiel CSS3 Module: Ruby [CSS3-RUBY] (in Bearbeitung).

Details zur Formatierung von Ruby im Zusammenhang zum japanischen Druck können unter JIS-X-4051 [JIS4051] gefunden werden.

3.1 Ruby im Web vs. traditionelle typographische Verwendung

Der Begriff »Ruby« wird im Japanischen nur fĂŒr Text gebraucht, der entlang eines Basistextes gerendert wird. Überlegungen zu solchen FĂ€llen werden in Abschnitt 3.2 (SchriftgrĂ¶ĂŸe), Abschnitt 3.3 (Positionierung) und Abschnitt 3.4 (Darstellung von Ruby-Markup) angestellt. Diese Art der PrĂ€sentation sollte möglichst ĂŒberall angewandt werden. Die EinfĂŒhrung von Ruby im Internet könnte jedoch zu besonderen PhĂ€nomenen und Problemen fĂŒhren, die es auf dem Gebiet der traditionellen Typographie so nicht gibt. So kann strukturelles Markup fĂŒr Ruby, wie es in dieser Spezifikation definiert wird, nicht garantieren, dass Ruby-Text auch immer entlang des Basistextes gerendert wird. Es gibt außerdem eine große Bandbreite an vorhandenen und zukĂŒnftigen AusgabegerĂ€ten fĂŒr Dokumente, deren Markup aus XHTML besteht, was zu folgenden Szenarien und GrĂŒnden fĂŒr unterschiedliches Rendern fĂŒhren kann:

3.2 SchriftgrĂ¶ĂŸe von Ruby-Text

Im gewöhnlichen Gebrauch wird Ruby-Text mit etwa der halben SchriftgrĂ¶ĂŸe von der des Basistextes dargestellt. Der Name »Ruby« entspringt ursprĂŒnglich dem Namen der 5,5-Punkt-SchriftgrĂ¶ĂŸe im britischen Buchdruck, welche lediglich etwa die HĂ€lfte der gewöhnlich verwendeten 10-Punkt-GrĂ¶ĂŸe fĂŒr normalen Text betrĂ€gt.

3.3 Positionierung von Ruby-Text

Es gibt diverse Positionen, an denen Ruby-Text in Relation zu seinem Basistext erscheinen kann. Da ostasiatischer Text sowohl vertikal als auch horizontal gerendert werden kann, werden die Begriffe »vor« und »nach« hier eher gebraucht als Â»ĂŒber« und »unter« bzw. »rechts« und »links«. Die Begriffe »vor« und »nach« sollten verstanden werden als »vor«/»nach« der Zeile, die den Basistext enthĂ€lt. Der Zusammenhang wird in der folgenden Tabelle verdeutlicht:

Terminologie Horizontales Layout
(links nach rechts, oben nach unten)
Vertikales Layout
(oben nach unten, rechts nach links)
vor ĂŒber rechts
nach unter links

Ruby-Texte werden meistens vor dem Basistext platziert (siehe Abbildung 1.1 und Abbildung 3.2). Manchmal kann Ruby-Text jedoch auch nach (unter) dem Basistext erscheinen, besonders bei zu Bildungszwecken horizontal ausgerichteten Dokumenten, siehe Abbildung 3.1. Auch im Chinesischen ist es eher so, dass Ruby-Text (Pinyin) nach dem Basistext folgt, ebenso in vertikalem Layout, wie es Abbildung 3.3 illustriert. In all diesen FÀllen entspricht die Schreibrichtung des Ruby-Textes der des Basistextes, ergo ist sie vertikal, wenn der Basistext vertikal verlÀuft, und horizontal, wenn dieser horizontal verlÀuft.

Obere Zeile: Drei japanische Ideogramme (von links nach rechts). Untere Zeile: Der Text »Shinkansen«. Ganz rechts: Pfeile und Text zur Kennzeichnung von »Ruby-Basis« (oben) und »Ruby-Text« (unten).

Abbildung 3.1: Ruby-Text (in lateinischen Schriftzeichen) nach/unter der Textbasis (japanische Ideogramme).

Linke Spalte: Drei japanische Ideogramme (von oben nach unten). Rechte Spalte: Sechs Hiragana-Zeichen in halber GrĂ¶ĂŸe. Ganz unten: Pfeile und Text zur Kennzeichnung von »Ruby-Basis« (links) und »Ruby-Text« (rechts).

Abbildung 3.2: Ruby-Text in vertikaler Schreibweise nach bzw. rechts der Textbasis.

Beispiel von Ruby-Text, links von japanischem Basistext.

Abbildung 3.3: Ruby-Text in vertikaler Schreibweise vor bzw. links der Textbasis.

In traditionellen chinesischen Texten kann Bopomofo-Ruby-Text sogar bei horizontaler Ausrichtung rechts entlang der Textbasis verlaufen.

Von links nach rechts: Ein großes chinesisches Ideogramm, drei kleinere Bopomofo-Buchstaben von oben nach unten (in blau), ein Bopomofo-Akzent (in rot), ein weiteres chinesisches Ideogramm, zwei kleinere Bopomofo-Buchstaben von oben nach unten (in blau) und ein weiterer Bopomofo-Akzent (in rot).

Abbildung 3.4: Bopomofo-Ruby-Text (in blauer und roter Farbe hervorgehoben) in traditionellem Chinesisch und horizontalem Layout.

Beachten Sie, dass Bopomofo-Betonungszeichen (in obigem Beispiel in rot gekennzeichnet) sich in einer separaten Spalte zu befinden scheinen (rechts entlang des Bopomofo-Ruby-Textes) und dadurch wie »Ruby in Ruby« aussehen mögen. Letztlich wurden diese Zeichen einfach als Teil des Ruby-Textes kodiert, wobei Details zu dieser Kodierung nicht in diesem Dokument erörtert werden.

3.4 Darstellung von Ruby-Markup

Diese Spezifikation schreibt nicht vor, wie Ruby-Markup dargestellt werden soll. Im Allgemeinen werden Stylesheets dafĂŒr verwendet, um das Verhalten des Markups exakt zu determinieren.

Anmerkung: Obwohl das Rendern des Ruby-Textes von Stylesheets kontrolliert werden sollte, wird empfohlen, dass visuelle User-Agents den Ruby-Text vor den Basistext platzieren, sofern nur ein Ruby-Text verwendet wird und keine Style-Informationen von Autor oder Benutzer geliefert werden. Dies sollte ebenfalls fĂŒr einfaches Ruby-Markup gelten. Wenn zwei Ruby-Texte vorliegen, sollte der erste Text vor und der zweite nach dem Basistext angeordnet werden. Ein beispielhaftes Standard-Stylesheet, welches diese Formatierung beschreibt, wird von [CSS3-RUBY] oder seinem Nachfolgedokument geliefert werden.

FĂŒr non-visuelles Rendern wird bei Fehlen von Stylesheet-Informationen empfohlen, dass sowohl Basistext als auch Ruby-Text(e) unter besonderer Hervorhebung (zum Beispiel durch unterschiedliche Stimme oder Tonlage) gerendert werden, um den jeweiligen Status anzuzeigen.

Um Stylesheets zu ermöglichen, einen Stil anwenden zu können, oder um anderen Mechanismen zu erlauben, Ruby-Text in sachgemĂ€ĂŸer Form zu rendern, ist es Ă€ußerst wichtig, genug Informationen ĂŒber die Funktion jeder Komponente zu bieten. Das folgende Beispiel illustriert den Gebrauch des class-Attributs, welches Stylesheets gestattet, die exakte Darstellung des Ruby-Textes zu definieren. Die (CSS-)Klasse reading wird auf einen Ruby-Text angewandt, um die Lesart zu definieren; die Klasse annotation wird gebraucht, um anzuzeigen, dass der entsprechende Ruby-Text die Erörterung (Annotation) des Basistextes beinhaltet. Das xml:lang-Attribut zeigt die Sprache des Textes an.

<ruby xml:lang="ja">
  <rbc>
    <rb>斎</rb>
    <rb>藤</rb>
    <rb>信</rb>
    <rb>男</rb>
  </rbc>
  <rtc class="reading">
    <rt>さい</rt>
    <rt>とう</rt>
    <rt>のぶ</rt>
    <rt>お</rt>
  </rtc>
  <rtc class="annotation">
    <rt rbspan="4" xml:lang="en">W3C Associate Chairman</rt>
  </rtc>
</ruby>

Abbildung 3.5: Ruby-Markup mit class- und xml:lang-Attributen.

Wenn ein Stylesheet gebraucht wird, um horizontalen Text und das Rendern der Lesart vor sowie das Rendern der ErlÀuterung nach der Textbasis zu definieren, könnte das obige Markup wie folgt gerendert werden:

Mittlere Zeile: Vier japanische Ideogramme (von links nach rechts). Obere Zeile: Hiragana-Zeichen in kleinerer SchriftgrĂ¶ĂŸe. Untere Zeile: Der Text »W3C Associate Chairman«.

Abbildung 3.6: Horizontales Rendern von zwei Ruby-Texten, assoziiert mit einem Basistext.

3.5 Hinweise zum non-visuellen Rendern

Dokumente, die Ruby-Markup verwenden, können in manchen FÀllen von non-visuellen User-Agents wie Sprach-Browsern oder Braille-User-Agents gerendert werden. In solchen FÀllen ist es wichtig, folgendes zu beachten:

Je nach den WĂŒnschen des Benutzers kann die Art, wie ein Text (vor-)gelesen wird, zwischen schneller und flĂŒchtiger bis hin zu Ă€ußerst sorgfĂ€ltiger und detaillierter Lesart variieren. Dies kann zu verschiedenen Weisen fĂŒhren, nach denen Ruby-Text beim non-visuellen Rendern behandelt wird, und zwar vom Überspringen des Ruby-Textes bei schneller Lesweise bis hin zu detaillierter Wiedergabe der Ruby-Struktur und der gegenwĂ€rtigen Beschaffenheit bei sorgfĂ€ltiger Lesart.

Im hĂ€ufig auftretenden Fall, dass Ruby-Texte die Lesart reprĂ€sentieren, kann das Rendern sowohl des Basis- als auch des Ruby-Textes zu störenden Duplikaten fĂŒhren. Ein Sprachsynthesizer könnte hier in der Lage sein, den Basistext aufgrund eines großen Wortschatzes korrekt auszusprechen, und vielleicht kann er in anderen FĂ€llen auch die entsprechende Aussprache anhand der vom Ruby-Text gelieferten Lesart wĂ€hlen.

Nicht alle Ruby-Texte reprĂ€sentieren die Aussprache des jeweiligen Basistextes. Autoren sollten Ruby-Texte, die fĂŒr andere Zwecke gebraucht werden, entsprechend mit dem class-Attribut kennzeichnen. Dies wird oben anhand der Anwendung von class="reading" auf den Ruby-Text (zum Hervorheben der Lesart) illustriert.

Ruby-Text, der die Lesart anzeigt, mag nicht unbedingt die richtige Aussprache produzieren, selbst wenn das verwendete Skript auf den ersten Blick phonetisch perfekt scheint. Bopomofo beispielsweise wird mit jedem Zeichen des Basistextes unabhĂ€ngig assoziiert; kontextabhĂ€ngige Klang- oder TonverĂ€nderungen werden somit nicht widergespiegelt. Ähnlich ist es im Japanischen, wo durchaus UnregelmĂ€ĂŸigkeiten in der Schreibweise vorkommen können, etwa bei は (»hiragana ha«) fĂŒr das Themensuffix, welches わ (»wa«) ausgesprochen wird, oder beim Gebrauch von Vokalen, um die Dehnung hervorzuheben. In solchen FĂ€llen wollen Autoren vielleicht fĂŒr genau diesen Zweck die tatsĂ€chliche Aussprache mit besonderem Markup bereitstellen, oder sie verlassen sich auf ein auditives Rendersystem, das in der Lage ist, solche FĂ€lle korrekt handzuhaben.

3.6 Alternativen zum rp-Element

Wenn der jeweilige Autor sich keine Gedanken um Fallback-Mechanismen fĂŒr User-Agents macht, die weder etwas ĂŒber Ruby-Markup wissen noch CSS-2- [CSS2] oder XSL-Stylesheets [XSL] unterstĂŒtzen, werden rp-Elemente nicht benötigt.

Nichtsdestotrotz ist es möglich, den Ruby-Text als Fallbacklösung in Klammern zu setzen, wenn sich zum Beispiel die GerĂ€teauflösung nicht gut fĂŒr das traditionelle Rendern von Ruby eignet. Bei Gebrauch von [CSS2] können die Parenthesen ĂŒber die content-Eigenschaft ([CSS2], Abschnitt 12.2) und die :before- und :after-Pseudoelemente ([CSS2], Abschnitt 12.1) generiert werden, wie zum Beispiel in dem folgenden Style-Fragment:

rt:before { content: "(" }
rt:after { content: ")" }

Abbildung 3.8: CSS-2-Fragment zur Generierung von Parenthesen um ein rt-Element.

In dem obigen Beispiel wird das rt-Element automatisch in Klammern gesetzt. Es wird dabei vorausgesetzt, dass die obigen Style-Regeln zusammen mit anderen Regeln verwendet werden, die den Ruby-Text inline positionieren. Die Erzeugung von Parenthesen ist ebenso einfach mit XSLT [XSLT] realisierbar.

4. KonformitÀtskriterien

Dieser Abschnitt ist normativ.

Im Zusammenhang mit dieser Spezifikation kann entsprechende KonformitĂ€t von Markup, Dokumenttypen, Modulimplementierungen, Dokumenten, Generatoren und Interpretern erfordert werden. FĂŒr die meisten dieser FĂ€lle sind zwei Level an KonformitĂ€t verfĂŒgbar: Einfache ErfĂŒllung und volle ErfĂŒllung (KonformitĂ€t). Einfache ErfĂŒllung bedeutet, dass das konforme Objekt das minimale Inhaltsmodell des Ruby-Elements unterstĂŒtzt (siehe Abschnitt 2.1), zum Beispiel einfaches Ruby-Markup. Volle ErfĂŒllung bedeutet, dass das konforme Objekt das maximale Inhaltsmodell des Ruby-Elements unterstĂŒtzt (siehe Abschnitt 2.1), und zwar durch die UnterstĂŒtzung von sowohl einfachem als auch komplexem Ruby-Markup.

Markup entspricht einfachem Ruby-Markup, wenn es ein oder mehr ruby-Elemente beinhaltet und der Inhalt all dieser Elemente (inklusive ihrer Kindelemente) dem minimalen Inhaltsmodell aus Abschnitt 2.1 entspricht, das heißt, dass nur einfaches Ruby-Markup erlaubt ist. Markup entspricht vollem (komplexem) Ruby-Markup, wenn es ein oder mehr ruby-Elemente beinhaltet und der Inhalt all dieser Elemente (inklusive ihrer Kindelemente) dem maximalen Inhaltsmodell aus Abschnitt 2.1 entspricht, das heißt, es ist sowohl einfaches als auch komplexes Ruby-Markup erlaubt.

Ein Dokumenttyp ist ein zu einfachem Ruby-Markup konformer Dokumenttyp, wenn er einfaches Ruby-Markup durch das sachgemĂ€ĂŸe EinfĂŒgen des ruby-Elements innerhalb entsprechender Elemente und durch das Definieren der notwendigen Elemente und Attribute in konformer Form integriert. Ein Dokumenttyp ist ein zu vollem Ruby-Markup konformer Dokumenttyp, wenn er volles (komplexes) Ruby-Markup durch das sachgemĂ€ĂŸe EinfĂŒgen des ruby-Elements innerhalb entsprechender Elemente und durch die Definition der notwendigen Elemente und Attribute in konformer Form integriert.

Eine Modulimplementierung (zum Beispiel mit DTD- oder XML-Schema-Technologie) ist eine konforme Modulimplementierung von einfachem Ruby-Markup, wenn sie so entworfen wurde, dass sie einfaches Ruby-Markup zusammen mit anderen Modulen in oben beschriebene Dokumenttypen integriert. Eine Modulimplementierung ist eine konforme Modulimplementierung von komplexem Ruby-Markup, wenn sie so entworfen wurde, dass sie komplexes Ruby-Markup zusammen mit anderen Modulen in oben beschriebene Dokumenttypen integriert. Eine Modulimplementierung ist eine konforme Modulimplementierung von vollem Ruby-Markup, wenn sie so entworfen wurde, dass sie entweder einfaches oder volles (komplexes) Ruby-Markup zusammen mit anderen Modulen in oben beschriebene Dokumenttypen integriert (zum Beispiel durch Bereitstellen eines Umschaltmechanismus oder durch Anbieten zweier separater Modulimplementierungen).

Ein Dokument ist ein zu einfachem Ruby-Markup konformes Dokument, wenn es konformes einfaches Ruby-Markup und kein komplexes oder nicht-konformes Ruby-Markup beinhaltet. Ein Dokument ist ein zu vollem Ruby-Markup konformes Dokument, wenn es konformes volles (komplexes) Ruby-Markup und kein nicht-konformes Ruby-Markup beinhaltet.

Ein Generator ist ein Generator von konformem einfachem Ruby-Markup, wenn er konformes einfaches Ruby-Markup und kein komplexes oder nicht-konformes Ruby-Markup generiert. Ein Generator ist ein Generator von konformem vollem Ruby-Markup, wenn er konformes volles (komplexes) Ruby-Markup und kein nicht-konformes Ruby-Markup generiert.

Ein Interpreter ist ein Interpreter von konformem einfachem Ruby-Markup, wenn er nicht-konformes Ruby-Markup ablehnt, konformes einfaches Ruby-Markup akzeptiert, und, sobald er Ruby-Markup interpretiert, dies gemĂ€ĂŸ dieser Spezifikation tut. Ein Interpreter ist ein Interpreter von konformem vollem Ruby-Markup, wenn er nicht-konformes Ruby-Markup ablehnt, konformes volles (komplexes) Ruby-Markup akzeptiert, und, sobald er Ruby-Markup interpretiert, dies gemĂ€ĂŸ dieser Spezifikation tut. Interpreter sind dabei zum Beispiel serverseitige Analyse- oder Transformierungswerkzeuge und -renderer.

Details zur KonformitÀt im Bereich XHTML-Modularisierung sind unter Abschnitt 3 von [XHTMLMOD] zu finden.


Anhang

A. Ruby-Modul fĂŒr XHTML

Dieser Anhang ist informell.

Das folgende ist ein Verweis zum Ruby-DTD-Modul, das in XHTML 1.1 [XHTML11] verwendet wird.

B. Anmerkungen zu Designentscheidungen

Dieser Anhang ist informell. Er resultiert aus den wĂ€hrend der abschließenden Revisionsperiode eingegangenen Fragen und Kommentaren und beinhaltet einige Anmerkungen zu den getroffenen Designentscheidungen.

Es gab wĂ€hrend dieses Zeitraums VorschlĂ€ge, zum Beispiel <rbc><rb>
</rbc> in <rb><rbc>
</rb> zu Ă€ndern (Ă€hnliches auch fĂŒr rt/rtc), was in gewisser Weise natĂŒrlicher aussieht. Nichtsdestotrotz ist der Inhalt eines Elements in XML entweder gemischter Natur (und kann somit sowohl aus Zeichen als auch aus Elementen bestehen, ohne BeschrĂ€nkung des Vorkommens oder der Reihenfolge), oder er beinhaltet ausschließlich weitere Elemente (unter EinschrĂ€nkungen). Dies bedeutet, dass es unmöglich ist, festzulegen, dass rb entweder nur rbc-Elemente oder nur Zeichen sowie Inline-Elemente enthĂ€lt.

Es gab auch verschiedene VorschlĂ€ge, das rp-Element aus dem minimalen Inhaltsmodell zu entfernen. DarĂŒber wurde beraten, der Vorschlag jedoch aus den folgenden GrĂŒnden abgelehnt:

Es wurde vorgeschlagen, auch die Namen der Elemente zu Ă€ndern, und im Besonderen ruby in gloss umzubenennen. Obwohl Ruby-Markup in der Tat Ă€hnlich einem Markup fĂŒr Fußnoten ist, wurde es jedoch nicht fĂŒr diesen Zweck entworfen.

C. Anmerkungen zur AbwÀrtskompatibilitÀt

Dieser Anhang ist informell.

Aus historischen GrĂŒnden könnten Autoren- bzw. Entwicklungswerkzeuge Ruby-Markup ohne Start- und End-Tags des rb-Elements generieren, und somit eher

<ruby>
  A
  <rp>(</rp><rt>aaa</rt><rp>)</rp>
</ruby>

als das folgende Markup kreieren:

<ruby>
  <rb>A</rb>
  <rp>(</rp><rt>aaa</rt><rp>)</rp>
</ruby>

Das erstere Markup ist nicht konform zu dieser Spezifikation, aber User-Agents, die sich um KompatibilitĂ€t mit Dokumenten, die von solchen Autorenwerkzeugen erzeugt wurden, bemĂŒhen, könnten dieses Markup behandeln, als ob es letzterem entsprechen wĂŒrde.

D. Glossar

Dieser Anhang ist informell.

Basistext
Abschnitt von Text, der mit Ruby-Text assoziiert wird. (Anmerkung des Übersetzers: In diesem Dokument werden sowohl der Begriff »Basistext« als auch »Textbasis« fĂŒr den englischen Ausdruck base text verwendet.)
Bopomofo
37 Zeichen und 4 Betonungszeichen, die als Laute bzw. Ausspracheform im Chinesischen gebraucht werden, insbesondere im Standard-Mandarin.
Einfaches Ruby-Markup
In dieser Spezifikation: Ruby-Markup, das einen einzelnen Ruby-Text mit einer Ruby-Basis (Basistext) verknĂŒpft und optionale Begrenzungszeichen wie zum Beispiel Parenthesen (als Fallback) anbietet.
Gruppiertes Ruby
In japanischer Typographie: Mit mehr als einem Zeichen des Basistextes verknĂŒpfter Ruby-Text.
Hiragana
Japanische silbenbildende Schrift bzw. Zeichen dieser Schrift. Untermenge des japanischen Schriftsystems, wird zusammen mit Kanji und Katakana gebraucht. Wird in neuester Zeit meistens verwendet, wenn Kanji nicht ausreichend oder verfĂŒgbar ist.
Ideogramm
Ein Zeichen, das benutzt wird, um Begrifflichkeiten, Worte oder Wortbestandteile darzustellen, im Gegensatz zu Zeichen, die einer an einem Alphabet oder Silben orientierten Schrift entstammen. Die bekannteste aus Ideogrammen bestehende Schrift wird (in Variationen) in Ostasien gebraucht (China, Japan, Korea, 
).
Kana
Zusammenfassender Begriff fĂŒr Hiragana und Katakana.
Kanji
Japanischer Begriff fĂŒr Ideogramme. Untermenge des japanischen Schriftsystems, wird zusammen mit Hiragana und Katakana gebraucht.
Katakana
Japanische silbenbildende Schrift bzw. Zeichen dieser Schrift. Untermenge des japanischen Schriftsystems, wird zusammen mit Kanji und Hiragana gebraucht. Wird in neuester Zeit meistens dazu verwendet, Fremdwörter zu schreiben.
Komplexes Ruby-Markup
In dieser Spezifikation: Ruby-Markup, das sowohl die VerknĂŒpfung von zwei Ruby-Texten mit einem Basistext als auch feingranulare Assoziationen zwischen Teilen von Ruby-Text und Basistext erlaubt.
Lesart
Bei Ideogrammen: Technischer Ausdruck, Darstellung der möglichen Aussprache. Unterschiedlich zur Aussprache in mehrerer Hinsicht: Die verwendete Schrift muss nicht unbedingt vollstÀndig lautlich (phonetisch) sein; die tatsÀchliche Aussprache ist abhÀngig vom Sprecher; die Aussprache muss nicht erfolgen, wenn der Text still gelesen wird. Im Chinesischen oder Koreanischen haben manche Ideogramme mehrere Bedeutungen, wÀhrend Ideogramme im Japanischen mindestens zwei Lesarten besitzen, einige sogar wesentlich mehr. Die Lesart bzw. -weise hÀngt des weiteren auch vom Kontext ab.
Monoruby
In japanischer Typographie: Mit einem einzelnen Zeichen des Basistextes assoziiertes Ruby.
Ruby-Text
Textlauf bzw. -abschnitt, der in unmittelbarer NĂ€he eines anderen Abschnitts (sogenannter »Basistext«) erscheint und als Erörterungs- (Annotation) oder AussprachefĂŒhrer fungiert, wenn mit der Basis assoziiert.

E. Änderungen gegenĂŒber der vorgeschlagenen Empfehlung

Dieser Anhang ist informell.

Änderungen gegenĂŒber der vorgeschlagenen Empfehlung (https://www.w3.org/TR/2001/PR-ruby-20010406):

Danksagung

Dieser Abschnitt ist informell.

Takao Suzuki (鈎朚 歝雄) und Chris Wilson haben als Verfasser zu den vorherigen EntwĂŒrfen beigetragen.

Diese Spezifikation wĂ€re nicht ohne die Hilfe der Mitglieder der W3C-I18N-Arbeitsgruppe möglich gewesen, insbesondere die von Mark Davis und Hideki Hiura (暋攊 秀æšč) sowie die der Mitglieder der W3C-I18N-Interessengruppe.

Weitere Mitwirkende waren Murray Altheim, Laurie Anna Edlund, Arye Gittelma, Koji Ishii, Rick Jelliffe, Eric LeVine, Chris Lilley, Charles McCathieNevile, Shigeki Moro (ćž« 茂æšč), Chris Pratley, Nobuo Saito (æ–Žè—€ 俥男), Rahul Sonnad, Chris Thrasher.

Das in dieser Spezifikation definierte Markup wurde mit dem von der Arbeitsgruppe 2 (WG 2, Typesetting) des Electronic Document Processing System Standardization Investigation and Research Committee of the Japanese Standards Association entwickelten Ruby-Markup aus [JIS4052] in Einklang gebracht. Wir möchten den Mitgliedern der WG 2 fĂŒr ihre Mitarbeit danken, insbesondere Shibano (芝野 è€•ćž, Vorsitz) und Masafumi Yabe (柶èŸș ć‹æ–‡). Technisch gesehen unterscheidet sich das Ruby-Markup in [JIS4052] in zwei Punkten von dem aus dieser Spezifikation: Zum einen gibt es eine nicht zu XML kompatible Form von Markup, die auf besonderen Symbolen basiert, und zum anderen ist kein rp-Element erlaubt.

Wertvolle Kommentare wurden auch von der HTML-, der CSS-, der XSL- und der WAI-Arbeitsgruppe sowie Steven Pemberton, Trevor Hill, Susan Lesch und Frank Yung-Fong Tang eingebracht. Akira Uchida (内田 明) bot RĂŒckmeldung aus Übersetzungssicht.

Ein frĂŒherer Vorschlag fĂŒr bestimmtes Markup fĂŒr Ruby, welches Attribute verwendet, wird in [DUR97] beschrieben.

Referenzen

Normative Referenzen

[XHTML11]
XHTML 1.1 – Module-based XHTML, W3C-Empfehlung
M. Altheim, S. McCarron, Herausgeber, 31. Mai 2001
Siehe: https://www.w3.org/TR/2001/REC-xhtml11-20010531
Letzte Version siehe: https://www.w3.org/TR/xhtml11
[XHTMLMOD]
Modularization of XHTML, W3C-Empfehlung
M. Altheim et al., Herausgeber, 10. April 2001
Siehe: https://www.w3.org/TR/2001/REC-xhtml-modularization-20010410
Letzte Version siehe: https://www.w3.org/TR/xhtml-modularization
[XML]
Extensible Markup Language (XML) 1.0 (Zweite Ausgabe), W3C-Empfehlung
T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, Herausgeber, 6. Oktober 2000
Siehe: https://www.w3.org/TR/2000/REC-xml-20001006
Letzte Version siehe: https://www.w3.org/TR/REC-xml

Informelle Referenzen

[CSS2]
Cascading Style Sheets, Level 2 (CSS2) Specification, W3C-Empfehlung
B. Bos, H. W. Lie, C. Lilley und I. Jacobs, Herausgeber, 12. Mai 1998
Siehe: https://www.w3.org/TR/1998/REC-CSS2-19980512
Letzte Version siehe: https://www.w3.org/TR/REC-CSS2
[CSS3-RUBY]
CSS3 Module: Ruby, W3C-Arbeitsentwurf
M. Suignard, Herausgeber, 16. Februar 2001
Siehe: https://www.w3.org/TR/2001/WD-css3-ruby-20010216/
Letzte Version siehe: https://www.w3.org/TR/css3-ruby
[DUR97]
Ruby in the HyperText Markup Language, Internet Draft
Martin DĂŒrst, 28. Februar 1997, verfallen
Siehe: https://www.w3.org/International/draft-duerst-ruby-01
[HTML4]
HTML 4.01 Specification, W3C-Empfehlung
D. Raggett, A. Le Hors, I. Jacobs, Herausgeber, 24. Dezember 1999
Siehe: https://www.w3.org/TR/1999/REC-html401-19991224
Letzte Version siehe: https://www.w3.org/TR/html4
[JIS4051]
Line Composition Rules for Japanese Documents (æ—„æœŹèȘžæ–‡æ›žăźèĄŒç”„版æ–čæł•)
JIS X 4051-1995, Japanese Standards Association, 1995 (Japanisch)
[JIS4052]
Exchange Format for Japanese Documents With Composition Markup (æ—„æœŹèȘžæ–‡æ›žăźç”„ç‰ˆæŒ‡ćźšäș€æ›ćœąćŒ)
JIS X 4052:2000, Japanese Standards Association, 2000 (Japanisch)
[ModSchema]
Modularization of XHTML™ in XML Schema, W3C-Arbeitsentwurf
Daniel Austin und Shane McCarron, Herausgeber, 22. MĂ€rz 2001
Siehe: https://www.w3.org/TR/2001/WD-xhtml-m12n-schema-20010322
Letzte Version siehe: https://www.w3.org/TR/xhtml-m12n-schema
[XMLSchema]
Schema Part 1: Structures, W3C-Empfehlung
H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, Herausgeber, 2. Mai 2001
Siehe: https://www.w3.org/TR/2001/REC-xmlschema-1-20010502
Letzte Version siehe: https://www.w3.org/TR/xmlschema-1
XML Schema Part 2: Datatypes
Siehe: https://www.w3.org/TR/xmlschema-2
[XSL]
Extensible Style Language (XSL), W3C-Candidate Recommendation
S. Adler et al., Herausgeber, 21. November 2000
Siehe: https://www.w3.org/TR/2000/CR-xsl-20001121
Letzte Version siehe: https://www.w3.org/TR/xsl
[XSLT]
XSL Transformations (XSLT) Version 1.0, W3C-Empfehlung
J. Clark, Herausgeber, 16. November 1999
Siehe: https://www.w3.org/TR/1999/REC-xslt-19991116
Letzte Version siehe: https://www.w3.org/TR/xslt