Verständnisproblem: Ausnahmen von Verschachtelungsregeln

[Robert Bamler]

Hallo Forumer, XML- und XHTML-Profis,

in SELFHTML ist mir seit längerem folgendes Kapitel über Unterschiede zwischen HTML 4.0 und XHTML aufgefallen: http://selfhtml.teamone.de/html/xhtml/unterschiede.htm#verschachtelung

Dort steht, dass in XHTML ein a-Element keine weiteren a-Elemente enthalten darf, was mir ja auch logisch erscheint. Aber es heißt dort auch:

"Mit Hilfe von SGML ist die Formulierung solcher Ausnahmen möglich. XML bietet dagegen keine Möglichkeit an, solche Ausnahmen zu formulieren."

Jetzt habe ich mich gefragt: Wieso ist in XML so etwas nicht möglich? In XML kann doch für jeden Elementtyp bestimmt werden, welche Elemente es enthalten darf (vereinfacht gesagt). Wenn also in der Angabe der erlaubten Unterelemente für das a-Element das a-Element selbst nirgends aufgeführt wird, ist dieses doch nicht erlaubt. Daraufhin habe ich zuerst einmal überprüft, ob das W3C etwas zu diesen Ausnahmen sagt - und bin fündig geworden: http://www.w3.org/TR/xhtml1/#h-4.9 entspricht ziemlich genau dem Inhalt des Kapitels in SELFHTML.

Weil ich das immer noch nicht glauben konnte, habe ich einen Blick in die DTD geworfen: In XTHML 1.0 Strict ist laut http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_a der erlaubte Inhalt eines a-Elements als "%a.content;" definiert. Dieser Entity steht ausformuliert für folgendes:

(#PCDATA | br | span | bdo | map | object | img |
  tt | i | b | big | small | em | strong | dfn | code |
  q | samp | kbd | var | cite | abbr | acronym | sub |
  sup | input | select | textarea | label | button |
  ins | del | script)*

Es sind also mit anderen Worten Zeichendaten und ein haufen Elemente in beliebiger Reihenfolge und Wiederholung erlaubt, aber kein weiteres a-Element. Damit ist doch bereits durch die DTD bestimmt, dass ein a-Element keine weiteren a-Elemente enthalten darf. Kann mir jemand erklären, wozu man dann noch den "normativen Anhang" braucht? Wo liegt mein Denkfehler?

Bin auf die Lösung des Rätsels gespannt.

Robert

[Thomas J.S.]

Hallo,

Ich verstehe nicht worauf du hinaus willst.
XML ist weder XHTML noch HTML. In xml ist das volkommen egal, ob du <a><a><a><a></a></a></a></a> oder sontwas schreibst.
Aus XML sicht bedeutet <a> absolute "nichts", d.h. dass <a> ein Link ist, ist nur in (X)HTML von Bedeutung.
Und da in HTML keine bi- bzw. multidirektionale Links exsitieren, muss diese Verschachtelungsverbot für (X)HTML gemacht werden.

Grüße
Thomas

[Robert Bamler]

Hallo Thomas,

danke für deine Antwort. Ich habe mich wahrscheinlich missverständlich ausgedrückt.

XML ist weder XHTML noch HTML.

Ja, natürlich. Ich weiß, was die einzelnen Abkürzungen bedeuten, und wie sie zueinander in Verbindung stehen. Ich kann nur den normativen Anhang (http://www.w3.org/TR/xhtml1/#h-4.9) zur Definition von XHTML nicht verstehen.

In xml ist das volkommen egal, ob du <a><a><a><a></a></a></a></a> oder sontwas schreibst.

Aber einem XML-Parser ist das nicht egal, wenn er eine DTD vorgesetzt bekommt, in der steht, dass so etwas nicht erlaubt ist. Und genau das steht doch - soweit ich es verstehen konnte - in der DTD für XHTML. In dieser DTD wird eine Verschachtelung vom Typ <a>...<a>...</a>...</a> verboten. Wozu also noch der normative Anhang? Es ist doch bereits alles in der DTD gesagt.

Aus XML sicht bedeutet <a> absolute "nichts", d.h. dass <a> ein Link ist, ist nur in (X)HTML von Bedeutung.

Aber wenn in einem XML-Dokument (und eine XHTML-Datei mit korrekter XML-Deklaration ist ein XML-Dokument) auf eine DTD Bezug genommen wird, bedeutet "<a>" doch zumindest, dass für dieses Element bestimmte, in der DTD genau definierte Verschachtelungsregeln gelten. Und wenn die DTD, auf die Bezug genommen wird, diejenige ist, die XHTML beschreibt, dann lauten diese Verschachtelungsregeln für das a-Element wie folgt:

(#PCDATA | br | span | bdo | map | object | img |
  tt | i | b | big | small | em | strong | dfn | code |
  q | samp | kbd | var | cite | abbr | acronym | sub |
  sup | input | select | textarea | label | button |
  ins | del | script)*

Es wird also ein weiteres a-Element innerhalb eines a-Elements verboten.

Und da in HTML keine bi- bzw. multidirektionale Links exsitieren, muss diese Verschachtelungsverbot für (X)HTML gemacht werden.

Ja, genau hier liegt mein Verständnisproblem: Dieses Verschachtelungsverbot existiert doch, nämlich in der DTD. Dort wird genau definiert, welche Unterelemente ein a-Element enthalten darf. Da bei dieser Definition das a-Element als Unterelement nicht aufgeführt wird, ist es verboten. Jetzt gibt es aber zusätlich zu der DTD noch einen normativen Anhang in dem genau dieses Verschachtelungsverbot noch einmal verbal ausformuliert wird. Als Begründung für diesen normativen Anhang wird angegeben, dass sich so ein Verschachtelungsverbot nicht in einer XML-DTD formulieren lässt. Aber es lässt sich doch in der DTD formulieren (und es wurde ja auch formuliert). Somit erscheint mir der normative Anhang nicht nur sinnlos, sondern einfach falsch. Ich kann mir aber nicht vorstellen, dass dieser Anhang wirklich falsch ist, deswegen gehe ich davon aus, dass ich diesen normativen Anhang falsch verstanden habe. Ich komme aber nicht darauf.

Zusammengefasst: Zur Definition von von XHTML gibt es einen sogenannten normativen Anhang, in dem bestimmte Verschachtelungsregeln ausformuliert wurden. Diese wurde deshalb ausformuliert, weil es angeblich nicht möglich ist, die Regeln in einer für Computer verständlichen Art in der Definition für XHTML zu formulieren. Meiner Einschätzung nach *ist* es aber möglich, diese Regeln für Computer verständlich zu formulieren und das wurde auch getan.

Ich hoffe, du kannst jetzt verstehen, was ich meine.

Robert

[Thomas Meinike]

Hallo,

Ja, natürlich. Ich weiß, was die einzelnen Abkürzungen bedeuten, und wie sie zueinander in Verbindung stehen. Ich kann nur den normativen Anhang (http://www.w3.org/TR/xhtml1/#h-4.9) zur Definition von XHTML nicht verstehen.

Der Abschnitt 4.9 ist Teil von Kapitel 4: "Differences with HTML 4" und direkt darunter steht: "This section is informative."

Was ist daran unverstaendlich?

MfG, Thomas

[Robert Bamler]

Hallo Thomas,

Der Abschnitt 4.9 ist Teil von Kapitel 4: "Differences with HTML 4" und direkt darunter steht: "This section is informative."

Was ist daran unverstaendlich?

Danke, das ist meine Rettung ;-)
Damit lässt sich der Abschnitt 4.9 als "Ausformulierung eines Teils der DTD" auffassen.

Trotzdem verstehe ich den Wortlaut dieses Abschnittes nicht. Das mag jetzt erbsenzählerisch klingen, aber mir erscheint das schon etwas seltsam:

<q>
SGML gives the writer of a DTD the ability to exclude specific elements from being contained within an element. Such prohibitions (called "exclusions") are not possible in XML.
</q>

Warum sind diese "exclusions" in XML nicht möglich? Sie werden doch sogar verwendet.

<q>
For example, the HTML 4 Strict DTD forbids the nesting of an 'a' element within another 'a' element to any descendant depth. It is not possible to spell out such prohibitions in XML.
</q>

Hier wieder: Genau dieses Verbot wurde doch in der DTD formuliert. Wieso steht dann in diesem Abschnitt, es sei "nicht möglich, solche Verbote in XML auszudrücken" (frei übersetzt)?

Auch wenn der Abschnitt nicht "normativ" ist, sollte er doch zumindest korrekt sein.

Robert

[MudGuard]

Hi,

Hallo Thomas,

Der Abschnitt 4.9 ist Teil von Kapitel 4: "Differences with HTML 4" und direkt darunter steht: "This section is informative."

Was ist daran unverstaendlich?

Danke, das ist meine Rettung ;-)
Damit lässt sich der Abschnitt 4.9 als "Ausformulierung eines Teils der DTD" auffassen.

Trotzdem verstehe ich den Wortlaut dieses Abschnittes nicht. Das mag jetzt erbsenzählerisch klingen, aber mir erscheint das schon etwas seltsam:

<q>
SGML gives the writer of a DTD the ability to exclude specific elements from being contained within an element. Such prohibitions (called "exclusions") are not possible in XML.
</q>

Warum sind diese "exclusions" in XML nicht möglich? Sie werden doch sogar verwendet.

In SGML geht das per

<!ELEMENT bla (%whatever;)* -blubb -- bla darf beliebige Elemente aus der Entity whatever enthalten, aber kein blubb>
                            ^^^^^^

XML ist aber reduziertes SGML. Hier ist diese exclusion eben nicht möglich.
Klar, es ist im Kommentar angegeben (<!-- content is %Inline; except that anchors shouldn't be nested -->). Aber eben nur im Kommentar. Nicht in der Element-Definition selbst, weil XML dies nicht zuläßt.
Vergleiche die Elementdefinition in HTML 4.01:

<!ELEMENT A - - (%inline;)* -(A)       -- anchor -->
                            ^^^^

Hier ist dieser Ausschluß in der Element-Definition möglich.

cu,
Andreas

[MudGuard]

Hi,

Aber wenn in einem XML-Dokument (und eine XHTML-Datei mit korrekter XML-Deklaration ist ein XML-Dokument) auf eine DTD Bezug genommen wird, bedeutet "<a>" doch zumindest, dass für dieses Element bestimmte, in der DTD genau definierte Verschachtelungsregeln gelten. Und wenn die DTD, auf die Bezug genommen wird, diejenige ist, die XHTML beschreibt, dann lauten diese Verschachtelungsregeln für das a-Element wie folgt:

(#PCDATA | br | span | bdo | map | object | img |
  tt | i | b | big | small | em | strong | dfn | code |
  q | samp | kbd | var | cite | abbr | acronym | sub |
  sup | input | select | textarea | label | button |
  ins | del | script)*

Es wird also ein weiteres a-Element innerhalb eines a-Elements verboten.

Nicht ganz.

Es wird hiermit ein a-Element als Kind des a-Elements verboten.
Nicht jedoch ein a-Element als Enkel, Urenkel, Ururenkel...

<a><a>bla</a></a> ist also nicht möglich,

<a><b><a>bla</a></b></a> ist aber theoretisch noch möglich.

Denn b darf %Inline; enthalten, was als
(#PCDATA | %inline; | %misc.inline;)*
definiert ist, %inline (kleines i!) wiederum ist als
a | %special; | %fontstyle; | %phrase; | %inline.forms;
definiert, womit a in b vorkommen dürfte.

cu,
Andreas

[Thomas J.S.]

Hallo Robert,

Du hast schon ein SGML Beispiel von Andreas (wieso muss er sich nur MudGuard nennen?? ...na ja sollte mir egal sein *g*) bekommen.

Aus XML sicht bedeutet <a> absolute "nichts", d.h. dass <a> ein Link ist, ist nur in (X)HTML von Bedeutung.

Aber wenn in einem XML-Dokument (und eine XHTML-Datei mit korrekter XML-Deklaration ist ein XML-Dokument) auf eine DTD Bezug genommen wird, bedeutet "<a>" doch zumindest, dass für dieses Element bestimmte, in der DTD genau definierte Verschachtelungsregeln gelten. Und wenn die DTD, auf die Bezug genommen wird, diejenige ist, die XHTML beschreibt, dann lauten diese Verschachtelungsregeln für das a-Element wie folgt:

OK, ich glaube dein Unverständniss gründet sich auf die Beziehung von HTML und XML zu SGML.

HTML ist eine SGML-Anwendung, (deshalb sind die DTDs für HTML SGML DTDs) XML dagegen ist eine echte Teilmenge von SGML.
Die Inclusionen und Exclusionen in SGML bedeuten für einen SGML-Editor, dass er bevor die Element-Deklarationen nutzen kann, die Metaregeln überprüfen muss (dazu gehören eben die Excl. und Incl.) was einen vorherigen Kompilierungsschrit erfordert. In SGML ist es weniger wichtig wie lange die Validierung von Dokumenten dauert.
Im Web ist das anders und XML wurde (auch) deshalb als eine vereinfachte Version von SGML entwickelt und verzichtet auf Kontstrukte die eine unmittelbare Verarbeitung erschwären.

Deshalb sind XML-dokumente, wenn sie eine DTD besitzen, auch SGML-Dokumente, ein SGML-Dokument ist dagegen nur dann auch ein XML-Dokument, wenn es bestimmte auf XML bezoge SGML-Deklarationen unterliegt.

Z.B. ein SGML-Dokument kann nur auf Validität überprüft werden, ein XML-Dokument kann darüberhinaus zusätzlich auf Wohlgeformtheit überprüft werden, d.h. sie brauchen nicht zwinged eine DTD.

Grüße
Thomas

[MudGuard]

Hi,

Du hast schon ein SGML Beispiel von Andreas (wieso muss er sich nur MudGuard nennen?? ...na ja sollte mir egal sein *g*) bekommen.

Mein Internet-Leben wurde anfangs maßgeblich vom "Mudcat Cafe", einem Forum zu traditional music, bestimmt.
Dort legte ich mir den Nickname MudGuard zu, Mud von Mudcat Cafe, und Guard als Übersetzung von Waechter, meinem Nachnamen.
Zusammengesetzt mudguard = Schutzblech, paßt wiederum zu mir als Fahrradfahrer...

Und den Nickname hab ich dann in anderen Foren ebenfalls genutzt...

Und wegen des Wiedererkennungswertes bleib ich jetzt auch dabei.

cu,
Andreas

[Thomas J.S.]

Hallo Adreas,

(wieso muss er sich nur MudGuard nennen?? ...na ja sollte mir egal sein *g*) bekommen.

Mein Internet-Leben wurde anfangs maßgeblich vom "Mudcat Cafe", einem Forum zu traditional music, bestimmt. [...]

Ah so ;-)

Und wegen des Wiedererkennungswertes bleib ich jetzt auch dabei.

Ich habe ja nicht gesagt, dass du es nicht darfst ;-)
Ich habe bloß Probleme Andreas Waecheter und MudGuard unter einem Hut zu bringen ;-) (habe ich bisher irgendwie die "beiden" als zwei versch. Personen gesehen)

Schöne Grüße
Thomas

[MudGuard]

Hi,

Hallo Adreas,

^^
Andreas, soviel Zeit muß sein! ;-)

Und wegen des Wiedererkennungswertes bleib ich jetzt auch dabei.
Ich habe ja nicht gesagt, dass du es nicht darfst ;-)

Würde auch nichts helfen...

Ich habe bloß Probleme Andreas Waecheter und MudGuard unter einem Hut zu bringen ;-)

^ hm. An der Zeit lags wohl doch nicht. ;-)

Und ich hasse Kopfbedeckungen... ;-)
Ach ja, ich habe auch schon darum gebeten (unabhängig von Deiner Anfrage), daß in meinen beiden Tips-und-Tricks-Artikeln das (MudGuard) hinter den Autornamen gesetzt wird. Matthias will es machen, sobald er dazu kommt...

cu,
Andreas

[Björn Höhrmann]

Dort steht, dass in XHTML ein a-Element keine weiteren a-Elemente enthalten darf, was mir ja auch logisch erscheint. Aber es heißt dort auch:

"Mit Hilfe von SGML ist die Formulierung solcher Ausnahmen möglich. XML bietet dagegen keine Möglichkeit an, solche Ausnahmen zu formulieren."

Jetzt habe ich mich gefragt: Wieso ist in XML so etwas nicht möglich?

XML DTDs erlauben das nicht. Es geht nicht um <a ...><a ...>...</a></a>, sondern um z.B. <a ...><em><a ...></a></em></a>, sprich, um alle Nachfahren, nicht nur direkte Kinder des Elements.

[Robert Bamler]

Hallo ihr alle,

danke für eure Hilfe, jetzt habe ich es auch verstanden. Ich habe nicht an die "Enkel" und "Urenkel" gedacht, sondern nur an die direkten "Kindelemente".

Manchmal ist die Lösung ja doch einfacher, als man denkt.

Robert