Ich hab ein Problem mit der XML-spezifikation

[TobiasBuschi]

hallo allerseits

ich verstehe nicht wieso das Zeichen "<" in einem Tag-Attribut nicht erlaubt ist.

Beispiel:
<div title="dies sind Pfeile: <- und ->">

Wieso soll das nicht erlaubt sein? Der Stringbereich im Value-Teil eines Tag-Attributes ist ja ohnehin durch Hochkomma geschützt!

Das einzige Zeichen das meiner Meinung nach nicht vorkommen darf, ist das zur Begrenzung gewählte Hochkomma.

Weil die das so definiert haben, kann man jetzt leider so schöne Sachen wie
<div id="<?php echo $id; ?>">

nicht machen ohne dass es nicht mehr gültiges XML ist.

Was meint ihr dazu?

Grüsse

[Cheatah]

Hi,

ich verstehe nicht wieso das Zeichen "<" in einem Tag-Attribut nicht erlaubt ist.
<div title="dies sind Pfeile: <- und ->">
Wieso soll das nicht erlaubt sein?

weil die spitzen Klammern hochwertige Sonderzeichen sind.

Weil die das so definiert haben, kann man jetzt leider so schöne Sachen wie
<div id="<?php echo $id; ?>">
nicht machen ohne dass es nicht mehr gültiges XML ist.

Das muss es auch nicht sein, es ist schließlich Programmcode. Das _Ergebnis_ muss evtl. XML-valide sein. Oder willst Du daran gehindert werden, Code wie

if (x<i and z>12)

zu schreiben?

PHP-Code ist kein XML. Dessen Ausgabe kann es sein.

Cheatah

[TobiasBuschi]

weil die spitzen Klammern hochwertige Sonderzeichen sind.

Ein Argument ist das nicht. Das einzige Argument wäre vieleicht, dass es die xml-Parser dadurch beträchtlich leichter haben und das xml dadurch schneller geparsed werden kann.

Das muss es auch nicht sein, es ist schließlich Programmcode. Das _Ergebnis_ muss evtl. XML-valide sein. Oder willst Du daran gehindert werden, Code wie

if (x<i and z>12)

zu schreiben?

PHP-Code ist kein XML. Dessen Ausgabe kann es sein.

Weiss ich.
Ich will jedoch ein CMS programmieren, das mit xml-validen php-templates arbeitet.

Ich bin schon lange daran, eine geeignete Template-Technik zu suchen. Dabei will ich keinen neuen Standard erfinden wie das zum Beispiel Smarty macht; einfach html und php.

[Cheatah]

Hi,

Ich will jedoch ein CMS programmieren, das mit xml-validen php-templates arbeitet.

da kannst Du ebenso gut verlangen, dass das Dokument den Regeln der deutschen Sprache entspricht - nur dass das schon spätestens beim unbekannten Wort "html" aussteigt. PHP _ist_ _kein_ XML, warum sollte also PHP-Code XML-valide sein müssen?

Cheatah

[Gunnar Bittersmann]

PHP _ist_ _kein_ XML,

Cheatah,
Nimmst du ihm das „Weiss ich“ etwa nicht ab? ...

Ich will jedoch ein CMS programmieren, das mit xml-validen php-templates arbeitet.

... Ich auch nicht.

See ya up the road,
Gunnar

[Cheatah]

Hi,

Nimmst du ihm das „Weiss ich“ etwa nicht ab? ...

das einzige, was ich abnehme, ist hin und wieder der Telefonhörer. Deswegen klappt bei mir auch keine Diät ...

Cheatah

[TobiasBuschi]

Cheatah,
Nimmst du ihm das „Weiss ich“ etwa nicht ab? ...

Ich will jedoch ein CMS programmieren, das mit xml-validen php-templates arbeitet.

... Ich auch nicht.

Aber so ist es.
Nur die Templates müssen (bei meinem geplanten Template-System) xml-valid sein.
Sieht dann zum Beispiel so aus:

<div>
  <div>
    <?php echo getPage('navi'); ?>
  </div>
  <div>
    <?php echo $page->getContent(); ?>
  </div>
</div>

Soweit ist es immernoch XML, wenn ich jedoch <div id="<?php echo $id; ?>"> schreibe nicht mehr.
XML-Valid desshalb, damit ich beispielsweise mit meinem programmierten Template-Editor die XML-Tags per drag&drop verschieben kann (javascript).

[Jonathan]

Soweit ist es immernoch XML, wenn ich jedoch <div id="<?php echo $id; ?>"> schreibe nicht mehr.

Ja, das ist klar. PHP ist ja eben auch nicht dazu gedacht, als XML verarbeitet zu werden. ;)

XML-Valid desshalb, damit ich beispielsweise mit meinem programmierten Template-Editor die XML-Tags per drag&drop verschieben kann (javascript).

Dann ist dein Template-Editor schwachsinnig, wenn der verlangt, das PHP-Codes XML-valid sind.

Noch ein kleiner Tipp: Schreib doch anstatt

<div id="<?php echo $id; ?>">

<?php echo "<div id="$id;">"; ?>

Das müsste dann eigentlich als XML verarbeitbar sein.

[TobiasBuschi]

XML-Valid desshalb, damit ich beispielsweise mit meinem programmierten Template-Editor die XML-Tags per drag&drop verschieben kann (javascript).
Dann ist dein Template-Editor schwachsinnig, wenn der verlangt, das PHP-Codes XML-valid sind.

Wieso? Ich will es dem Anwender so leicht wie möglich machen und bin auf die Idee gekommen ein Template-Editor zu programmieren mit dem man das Template per Drag&Drop gestalten kann.
Was ist daran schlecht XML-konform bleiben zu müssen?
Ich denke PHP wird nicht zufälligerweise in diesen <?php ?> ausgeführt, die (ausserhalb von Tags) an der XML-Validität nichts anhaben.

[TobiasBuschi]

... Ich auch nicht.

php-Datein müssen nicht XML sein.
Sie können es aber! Und das will ich nutzen in meinem Template-System

[Cheatah]

Hi,

php-Datein müssen nicht XML sein.
Sie können es aber! Und das will ich nutzen in meinem Template-System

damit schränkst Du die Möglichkeiten des PHP-Codes ein. Problem gelöst. Der nächste bitte!

Cheatah

[Mathias Brodala]

Hallo TobiasBuschi.

Nur die Templates müssen (bei meinem geplanten Template-System) xml-valid sein.
Sieht dann zum Beispiel so aus:

<div>
  <div>
    <?php echo getPage('navi'); ?>
  </div>
  <div>
    <?php echo $page->getContent(); ?>
  </div>
</div>

Warum nicht so:

<div>  
  <div>  
    <tpl:navi/>  
  </div>  
  <div>  
    <tpl:content/>  
  </div>  
</div>

Die Platzhalter könntest du dann z. B. per DOM-Parser sauber durch den gewünschten Inhalt ersetzen.

Einen schönen Donnerstag noch.

Gruß, Mathias

[TobiasBuschi]

Hallo Mathias

Bin froh, dass noch jemand antwortet, der mir mein XML-basiertes Template-System nicht aus dem Kopf schlagen will :-)

Die Lösung mit den Namespaces ist sicher eine korrekte, ich wollte jedoch einfach den Funktionsumfang von PHP brauchen können.

[Mathias Brodala]

Hallo TobiasBuschi.

Bin froh, dass noch jemand antwortet, der mir mein XML-basiertes Template-System nicht aus dem Kopf schlagen will :-)

Wie könnte ich. XML ist mein favorisiertes Format für Datenhaltung aller Art.

Die Lösung mit den Namespaces ist sicher eine korrekte, ich wollte jedoch einfach den Funktionsumfang von PHP brauchen können.

Welche Version nutzt du? Sollte es mindestens die fünfte sein, solltest du in jedem Falle einmal einen Blick auf die von mir bevorzugt genutzten DOM-Funktionen werfen.

Einen schönen Freitag noch.

Gruß, Mathias

[TobiasBuschi]

Welche Version nutzt du? Sollte es mindestens die fünfte sein, solltest du in jedem Falle einmal einen Blick auf die von mir bevorzugt genutzten DOM-Funktionen werfen.

Die benutze ich bereits:
Wenns dich ineressiert, geh mal auf meine Test-Seite
Template-Editor

Du kannst dich ruhig austoben :-), und benutze auch die rechte Maustaste.

Ist noch nicht ausgereift, aber was meinst du soweit?
Bei grösserem Interesse schicke ich dir gerne den Code.

Guet Nacht

[Thomas J.S.]

Hallo,

Sieht dann zum Beispiel so aus:

<div>
  <div>
    <?php echo getPage('navi'); ?>
  </div>
  <div>
    <?php echo $page->getContent(); ?>
  </div>
</div>

Soweit ist es immernoch XML,

Nur weil dein Freund Rainer Zufall das für dich erledigte.
"<?" zeigt dem XML-Parser, dass es sich um eine Verarbeitungsanweisung handelt (was es in der Tat ist, nur der Parser kann damit trotzdem nichts anfangen, bzw. ich kenne keinen XML-Parser der PHP verarbeiten kann)

Das mit "->" ist pures Glück

wenn ich jedoch <div id="<?php echo $id; ?>"> schreibe nicht mehr.

Das ist auch richtig so. Dir muss es ja auch nicht gefallen bzw. du kannst dich bei der ISO und W3C beschweren.

Grüße
Thomas

[TobiasBuschi]

Hallo,

Nur weil dein Freund Rainer Zufall das für dich erledigte.
"<?" zeigt dem XML-Parser, dass es sich um eine Verarbeitungsanweisung handelt (was es in der Tat ist, nur der Parser kann damit trotzdem nichts anfangen, bzw. ich kenne keinen XML-Parser der PHP verarbeiten kann)

Das mit dem Parser mache ich mit PHP zusammen.

Das mit "->" ist pures Glück

Glück? Zufall? Sind das die Methoden des W3C's??

wenn ich jedoch <div id="<?php echo $id; ?>"> schreibe nicht mehr.

Das ist auch richtig so. Dir muss es ja auch nicht gefallen bzw. du kannst dich bei der ISO und W3C beschweren.

Das problem ist nicht das es mir nicht gefällt und ich mich beim W3C beschweren will.
Nein, ich möchte wissen wieso.
Das es "richtig" ist habe ich auch in der spezifikation gelesen.
Die beim W3C haben sich bestimmt was dabei überlegt.

mfg Tobias

[Thomas J.S.]

Hallo,

Das mit "->" ist pures Glück

Glück? Zufall? Sind das die Methoden des W3C's??

Nein, sondern die deine :)

Das problem ist nicht das es mir nicht gefällt und ich mich beim W3C beschweren will.

Also mir scheint schon, dass das dein Problem ist.

Nein, ich möchte wissen wieso.

Nun ja, was hast du in dem Absatz: Zeichendaten und Markup nicht verstanden?

Natürlich hätte man für XML andere Markup-Begrenzungen als "<" und ">" nehmen können (das hätte man in der SGML-Deklaration für XML machen können), das dann zu einer kompletten Inkompatibilität mit SGML geführt hätte: "wayne interessiert's"?  Schließlich hätte man schon mitte der 90-er wissen müssen, dass PHP viel wichtiger wird als SGML und XML.

Auf der anderen Seite könnte man sich fragen, warum muss PHP so bescheuert sein, und "<" und ">" zu verwenden?

Grüße
Thomas

[TobiasBuschi]

Hallo Thomas

Ok, ich beschränke mich auch auf die Frage aus welchem Grund das Zeichen ">" in xml-Attributen erlaubt ist und das hier "<" nicht.
Unabhängig von PHP oder sonst was.
Mit PHP hätte ich sowieso das Problem, dass ich so etwas nicht scheiben könnte:

<tab attribute="<?php echo "hallo".$planet; ?>">

weil die Hochkommas im php-code das XML begründet beschädigen.
Aber wieso das "<"?

Und wenn es nur wegen der kompatibilität zu SGML ist stellt sich dort die Frage.

Ich glaube das zu erfahren, entwickelt sich zu meiner Lebensaufgabe :-)

Na dann noch n'schönen Abend.

[Schenkeli Thomas]

Was meint ihr dazu?

<> sind ebenso geschützte Sonderzeichenm man kann das ganze aber umgehen:

1. alles in einen CDATA-Block stecken, da ist alles drin erlaubt (außer natürlich die Zeichenkette die einen CDATA-Block beendet)
2. &lt;  oder &gt; stattdessen verwenden

Grüsse

lg Thomas

[Gunnar Bittersmann]

Hello out there!

<> sind ebenso geschützte Sonderzeichen

'>' nicht.

[10] AttValue ::= '"' ([^<&"] | Reference)* '"' |  "'" ([^<&'] | Reference)* "'" [XML]

1. alles in einen CDATA-Block stecken, da ist alles drin erlaubt

Ein CDATA-Block aber nicht in einem Attributwert. Wie auch, wenn '<' nicht vorkommen darf.

See ya up the road,
Gunnar

[TobiasBuschi]

Besten dank für eure hilfreichen/kritischen Hinweise.

Was mich noch beschäftigt ist die Frage, warum das zeichen "<" in XML-Attributen nicht erlaubt ist.
Ich denke, die beim W3C haben bestimmt ein Grund dafür, ich kenne ihn nicht. Wenn da noch jemand die Antwort weiss...?

Es wünscht einen schönen Abend:
Tobias

[Daniel Thoma]

Hallo TobiasBuschi,

Ich denke, die beim W3C haben bestimmt ein Grund dafür, ich kenne ihn nicht. Wenn da noch jemand die Antwort weiss...?

In der Spezifikation steht schonmal nichts dazu soweit ich das sehe.
Irgendwelche Effizienzgründe beim Parsen kann das auch nicht haben. Mit typischen Parsing-Verfahren kann man XML parsen, ob da nun diese '<' zugelassen werden oder nicht.
Ich vermute mal, dass diese Einschränkung aus SGML übernommen wurde und das es da entweder Aufgrund der freieren Syntax einen Grund dafür gab oder dass man sich die Möglichkeit offen halten wollte, das Zeichen in einer späteren Version zu verwenden, bspw. für Tags in Attributen o.ä.
Wenn Du das wirklich herausfinden willst, musst Du wohl mindestens in die SGML-Spezifikation schauen. Wenn sich daraus kein Grund ergibt, bleibt Dir wohl nur die Leute zu fragen, die XML und SGML mit entwickelt haben...

Für eine praktische Lösung kannst Du Dir immer noch einen Workaround ausdenken. Bspw:

<foo>
  <tmpl:attribute name="bla"><?php echo("blub")?></tmpl:attribute>
</foo>

Das kannst Du mit Deinem Editor dann verabreiten und zur Ausführung konvertierst Du das in ein PHP-Script der Form:

<foo bla="<?php echo("blub")?>"></foo>

Eine richtige Templatesprache, die Du dann evtl. auch in PHP übersetzt, könnte allerdings dennoch sinnvoller sein. Dann hast Du nämlich auch die Möglichkeit zu prüfen, ob das Template sich an bestimmte Regeln hält und nicht irgendetwas gefährliches tut.
Wenn da PHP drin steht, musst Du dem Benutzer vertrauen.

Grüße

Daniel

[Tim Tepaße]

Hallo,

ich verstehe nicht wieso das Zeichen "<" in einem Tag-Attribut nicht erlaubt ist.

So doof es klingt, eine bessere Antwort als mein Betreff kann es darauf nicht geben.

Ich versuche das mal anhand der Standards zu erklären:

Laut Definition bestehen wohlgeformte XML-Dokumente aus Markup und Text. Lass Dich nicht durch das ständige Reden von Entities in der XML-Spezifikation verwirren, das bezieht sich nur aufs Parsen, die physikalische Ebene. Markup und Text ist dann die logische Ebene. Meiner Meinung nach trägt diese sicherlich wichtige Unterscheidung stark zur Schwierigkeit des Lesens der XML-Spec bei. Bleiben wir auf der logischen Ebene.

Laut einer weiteren Definition besteht Markup aus diversen Zeugs:

„Markup takes the form of start-tags, end-tags, empty-element tags, entity
  references, character references, comments, CDATA section delimiters,
  document type declarations, processing instructions, XML declarations,
  text declarations, and any white space that is at the top level of the
  document entity“

Markup ist also mehr als das am häufigsten verwendete <tag>inhalt</tag>. Weiter im Test steht da auch:

„The ampersand character (&) and the left angle bracket (<) MUST NOT
  appear in their literal form, except when used as markup delimiters [...]“

Wir lernen: XML besteht aus Markup (und Text) und dieses unterschiedliche Markup erkennt man immer daran, dass es mit dem „start delimiter“ "<" beginnt (und je nach Art des Markups anders endet, aber doch mit einem ">"). Markup ist hier der entscheidende Begriff. Zwei Formen von Markup interessieren uns hier besonders.

Zum einen Processing Instructions, die sehen so aus:

<?target inhalt?>

„target“ ist hier die Bezeichnung für den Prozessor, der die PI ausführen soll. Ja, das ist die Syntax, die PHP für eine seiner Tags gewählt hat.

Ein ganz anderes Markup sind Start-Tags (<tag>), End-Tags (</tag>) und Empty-Element-Tags (<tag/>). Start- und End-Tags dürfen Attribute beinhalten. Attribute sind streng genommen Abbildungen von einem Namen auf einen Wert. Und der Wert besteht bitte nur aus Text und nicht aus Markup, denn der Wert ist Teil von Markup.

Ok, das ist ganz viel formale Definition, nur um zu sagen, was Du schon weisst, in Werten von Attributen darf kein Markup enthalten sein, Attribute sind Teil des Markups. Noch da? ;)

Die XML-Spezifikation ist in Sachen Intentionen eher mau. Aber Du hast mitgekriegt, es gibt eine physikalische und eine logische Ebene, XML zu betrachten. Auf der logischen Ebene gibt es diese Regeln für Markup, das wirkt sich dann auf die physikalische Ebene aus. Die physikalische und die logische Ebene kriegt XML aber nicht aus dem blauen Dunst. XML ist ein vereinfachtes SGML. XML-Dokumente sind demzufolge auch SGML-Dokumente. Und all die Definitionen und Intentionen erbt XML sozusagen von SGML. Also gucken wir dort mal nach.

(Ich zitiere hier mal überwiegend aus Anhang B des (nicht so frei verfügbaren) SGML-Standards, weil dort freundlicherweise richtiger Text steht)

SGML besteht aus Markup und Text:

„In generalized markup, the term “document” does not refer to a physical construct such as a file or a
  set of printed pages. Instead, a document is a logical construct that contains a document element, the
  top node of a tree of elements that make up the document’s content.
  [...]
  The elements are distinguished from one another by additional information, called markup, that is added
  to the data content. A document thus consists of two kinds of information: data and markup.“

Markup kann aus verschiedenen Dingen bestehen:

„Markup is text that is added to the data of a document in order to convey information about it. In
  SGML, the markup in a document fails into four categories:
  a) Descriptive Markup (“Tags”) [...]
  b) Entity Reference [...]
  c) Markup Declaration [...]
  d) Processing Instructions [...]“

Unter anderem auch aus PIs.

Deskriptives Markup kann Attribute enthalten:

„A descriptive tag normally includes the element’s generic identifier (Gl)
  and may include attributes as well.“

Attribute bestehen nur aus Zeichen, nicht aus Markup:

„The value of an attribute consists of data characters and entity references, bounded by delimiters
  called “literal delimiters” (lit), which are normally quotation marks (“).“

Wir haben nicht viel gelernt, ausser, dass es in SGML wie in XML ist. Warum nehmen die Autoren von SGML die PIs nicht ernst und erlauben die überall im Inhalt?

Guck Dir mal eine Templatesprache wie Mason an, z.B. hier. Du siehst Text, in den Perl Code eingebettet ist. In etwa ist der Perl Code hier Processing Instructions, Anweisungen, die beim Verarbeiten des Dokumentes ausgeführt werden sollen. Simplifiziert kann man diese Perl-PIs überall im ansonsten unstrukturierten Text einbetten. Hier sind PIs Elemente erster Klasse, alles andere ist nur zweitrangig. Man nennt diesen Stil auch Prozedurales Markup. Markup, dass sich auf die Verarbeitung auswirkt. Markup, das sagt: Tue dies, tue das.

Das kann toll sein, hat aber auch seine Nachteile. Man ist auf einen Interpreter für genau diese PIs angewiesen, im Falle von Mason Perl. Und man kann das Dokument nicht als Struktur behandeln, denn der Text ist im schlimmsten Fall unstrukturiert. Man kann das Dokument es im Prinzip nicht anders verarbeiten, denn es stehen lauter „Tue dieses“ drin, wenn man doch lieber „Tue jenes“ machen will. Und Programmlogik und Daten sind miteinander verflochten.

Das führte dazu, dass in solchen prozeduralen Sprachen abstrahiert wurde. Es wurde nicht mehr „Tue das“ gesagt, sondern abstrahiert „Dies ist etwas“ gesagt. Anfangs geschah das noch durch Makros. Der Sprung von TeX auf LaTeX ist so ein Beispiel. TeX ist eine Makrosprache in der man sagt „Formatiere dies bitte groß und fett“, in LaTeX sagt man „Dies ist eine Überschrift“. Letztendlich landet man dann bei deklarativen Markup. Prozedurales Markup sagt „Tue etwas“, deklaratives Markup sagt: „Das hier ist etwas“. Bei letzterem liegt die Verarbeitung also ausserhalb des Inhaltes, jenseits der Daten. Dafür haben die Daten eine Struktur. Konsequenterweise gibt es keine PIs mehr oder sie sind nicht mehr so mächtig wie

Aus dieser Evolution heraus ist auch SGML entstanden, es sollte größtenteils rein deklaratives Markup sein. Aus Abschnitt 0.1 Background des SGML Standards:

„Descriptive markup predominates and is distinguished from processing instructions.“

PIs gibt es zwar noch, aber sie sind nicht mehr universal überall einsetzbar. Aus Abschnitt 0.2 Objectives:

„Special delimiters for processing instructions to distinguish them from descriptive markup.
  Processing instructions can be entered when needed for situations that cannot be handled by
  the procedures, but they can easily be found and modified later when a document is sent to a
  different processing system.“

Tatsächlich macht SGML im Gegensatz zu früheren Varianten klar, dass sie sich nicht um PIs kümmern, also auch weder interne Syntax noch Semantik dafür definieren. PIs sind nicht mehr integraler Bestandteil eines SGML Prozessors sondern etwas, dass extern und programmspezifisch ist. Es gib höchstens noch eine Syntax dafür. Tatsächlich rät der SGML Standard von PIs ab, aus Abschnitt 8, Processing Instructions:

„Processing instructions are deprecated, as they reduce portability of the document.“

Meinem Empfinden nach behandelt der SGML Standard PIs als Markup zweiter Klasse: „Wenn es unbedingt sein muss, dann gibt es halt noch PIs, aber Hauptsache sie verkomplizieren nichts und stören unsere Kre.. unser kostbares deklaratives Markup nicht. Denn für letzteres sind wir eigentlich hier.“

Ich denke aus dieser Überlegung kommt auch die Syntax für PIs. Denn wären PIs überall erlaubt, müsste man sie großartig komplizieren, eine PI in einem Attribut darf z.B. nur erlaubte Zeichenketten für Attributwerte zurückgeben, etc. Wozu, wenn man doch einen Standard für deklaratives Markup erstellen will? Also wurden PIs auf so „unwichtiges Markup“ zurückgestuft wie Kommentare. PIs sind in deklarativen Markup gar nicht vorhanden oder eben Anweisungen zweiter Klasse, wenn man sich nicht stark darum bemüht.

PHP hat nun für eine Variante der Einbindung die Form der PI gewählt. Ob aus Absicht oder aus Unwissen sei mal dahingestellt, Absicht liegt nahe, weil PHP meistens HTML ausspuckt und HTML eine SGML-Anwendung ist. Allerdings gibt es da einen Konflikt, PHP will eine möglichst mächtige Sprache sein und alles verändern können, schließlich ist es eine Programmiersprache. SGML dadurch aus XML haben aber ihren PIs Beschränkungen auf der logischen Ebene (Elemente mit Tags und Attributen) auferlegt.

Konsequenterweise behandelt PHP den Inhalt nicht auf der logischen sondern nur auf der physikalischen Ebene, auf der Textebene. Dadurch, dass es sich nicht um die logische Ebene kümmern wird es mächtiger, es kann jedes andere Textformat verarbeiten, es kann aber auch die logische Ebene von SGML bzw. XML nicht wohlgeformt bis invalide machen. PHPs PIs sind also rein zufällig ähnlich den PIs von SGML/XML, tragen aber aber die nicht gleiche Bedeutung, denn PHP verarbeitet prozedurales Markup, nicht deklaratives.

Deswegen bleiben Versuche, das deklarative Markup von SGML/XML mit prozeduralem Markup auszustatten und dennoch bei wohlgeformten, verarbeitbaren, evtl. sogar validen XML zu bleiben, nicht bei den PIs von SGML/XML selber. Stattdessen erfinden sie meist neue XML-Dialekte. Beispiele dafür sind eigene Elemente wie z.B. template:ifcondition oder Attribute in einem eigenen Namensraum wie z.B. die pythonische Templatesprache Kid bzw. dessen inoffizieller Nachfolger Genshi. Die in SGML und XML eingebauten PIs sind nämlich per Definition nicht mächtig genug.

Denn schließlich: SGML bzw. XML sollen nur deklaratives Markup beschreiben.

Tim

[TobiasBuschi]

Hallo Tim

Danke für die ausführliche Diplom-Arbeit :-)
Du scheinst dich gut auszukennen.

mfg
Tobias