Toon posts:

[DTD] Vreemde regel in document type definition

Pagina: 1
Acties:

Verwijderd

Topicstarter
Na het bouwen een wat mij betreft redelijk geslaagde parser (XML/XHTML), wil ik meer flexibiliteit inbouwen. Dat betekent dat ik echt met alles rekening moet kunnen houden.

Ik kwam op het idee om dan ook maar een parser te bouwen voor DTD's, en daar heb ik wel aardige ideeën over, maar ik stuitte op een rare regel in al bestaande DTD's, namelijk de html DTD's van www.w3c.org.

Bij elk element in een XML document, is in de document type definition vastgelegd welke waarden er tussen de betreffende tags mogen staan. Veelal is dat een datatype waarde, of een verzameling van een groep andere tags.

Ook zijn er meer complexe mogelijkheden, gelijkend op regular expressions, bijvoorbeeld het volgende:
code:
1
<!ELEMENT table (caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))>

Deze kan ik nog wel begrijpen, en het gaat ook wel lukken om dit toe te passen, maar ik stuitte ook op de volgende regel, en die kwam vrij onlogisch over:
code:
1
<!ELEMENT head (%head.misc;, ((title, %head.misc;, (base, %head.misc;)?) | (base, %head.misc;, (title, %head.misc;))))>

Hierin is %head.misc; de verzameling: (script|style|meta|link|object)*
Kortom, dit levert altijd een match. Er hoeft dus niets te staan.

Maar waarom is dit alles gewikkeld in zo een vage constructie? Ik weet dat de title tag verplict is, en dat de base tag optioneel is. Slaat dit uberhaupt ergens op, of is dit gewoon een fout geweest en is het gewoon het volgende:
code:
1
<!ENTITY % (&head.content; title, base?)>

Dit kwam ik later tegen op een pagina van W3C. (HTML 4.01 REC) En dit is ook wat ik eigenlijk had verwacht.

Ik kom niet echt op een logische interpretatie van die ene regel, zoals vermeld in http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
Kan iemand hierbij verlichting geven? Ik wil uiteraard gráág verder met die parser, maar dan moet ik wel constructies als deze begrijpen, anders kan ik er net zo goed niet aan beginnen :)

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Cheatah: Na het bouwen een wat mij betreft redelijk geslaagde parser (XML/XHTML), wil ik meer flexibiliteit inbouwen. Dat betekent dat ik echt met alles rekening moet kunnen houden.
Ah, je wilt dus heel de XML standaard gaan ondersteunen? Waarom ben je hier trouwens mee bezig, gewoon voor de fun of vanwege het signaleren van een gebrek in een bepaalde omgeving?
Ik wil uiteraard gráág verder met die parser, maar dan moet ik wel constructies als deze begrijpen, anders kan ik er net zo goed niet aan beginnen :)
Tja, allereerst: je hoeft dergelijke constructies natuurlijk niet te begrijpen om een DTD parser en validator te kunnen schrijven. De keuzen die hier gemaakt zijn, zijn simpelweg de toepassing van DTDs die als het goed is voldoen aan de standaard voor DTDs. Als je deze standaard verwerkt in je grammatica, is er verder niets aan de hand.


Dat je het wel wilt begrijpen is natuurlijk logisch ;) .
Deze kan ik nog wel begrijpen, en het gaat ook wel lukken om dit toe te passen, maar ik stuitte ook op de volgende regel, en die kwam vrij onlogisch over
Volgens mij is deze uitermate obscure constructie in deze DTD gekozen om 'interleaving' mogelijk te maken. Je kunt namelijk in de head-sectie van een XHTML document alles in willekeurige volgorde zetten. Daar is interleaving voor nodig. Het is echter ook weer zo dat er maar 1 title mag voorkomen en dat zorgt voor constructies die je niet goed kunt uitdrukken in DTDs (wat wel ;) ). Hier zie je het resultaat van dit gebrek.

Interleaving is iets wat je ontzettend goed kunt uitdrukken in Relax NG (zie de tutorial), maar dus echt voor geen meter in DTDs.
Slaat dit uberhaupt ergens op, of is dit gewoon een fout geweest en is het gewoon het volgende:
code:
1
<!ENTITY % (&head.content; title, base?)>

Dit kwam ik later tegen op een pagina van W3C. (HTML 4.01 REC) En dit is ook wat ik eigenlijk had verwacht.
Als ik het goed heb (maar ben geen detail-kenner van DTDs) is hier geen interleaving mogelijk en moet de title dus altijd achteraan staan, eventueel gevolgd door een base. Dat is dus echt iets anders.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Verwijderd

Topicstarter
Op woensdag 15 mei 2002 00:34 schreef mbravenboer het volgende:

Ah, je wilt dus heel de XML standaard gaan ondersteunen? Waarom ben je hier trouwens mee bezig, gewoon voor de fun of vanwege het signaleren van een gebrek in een bepaalde omgeving?
Vooral om er zelf nog het een en ander van te leren, aangezien ik het allemaal vrij interessant vind, de standaardisatie, en de gestructureerdheid hiervan.
Ik wil eigenlijk ongeveer hetzelfde als validator.w3.org namaken, maar dan nog iets uitgebreider qua foutmeldingen zoals syntax errors.
Misschien te hoog gegrepen, maar ik vind het het proberen waard :)
Tja, allereerst: je hoeft dergelijke constructies natuurlijk niet te begrijpen om een DTD parser en validator te kunnen schrijven. De keuzen die hier gemaakt zijn, zijn simpelweg de toepassing van DTDs die als het goed is voldoen aan de standaard voor DTDs. Als je deze standaard verwerkt in je grammatica, is er verder niets aan de hand.
Dat klopt uiteraard, maar toch lijkt het me een uitdaging om custom DTD's te gebruiken om mee te valideren. Een universeel product is vaak interessanter dan iets dat teveel gespecialiseerd is.
Dat je het wel wilt begrijpen is natuurlijk logisch ;) .

[..]

Volgens mij is deze uitermate obscure constructie in deze DTD gekozen om 'interleaving' mogelijk te maken. Je kunt namelijk in de head-sectie van een XHTML document alles in willekeurige volgorde zetten. Daar is interleaving voor nodig. Het is echter ook weer zo dat er maar 1 title mag voorkomen en dat zorgt voor constructies die je niet goed kunt uitdrukken in DTDs (wat wel ;) ). Hier zie je het resultaat van dit gebrek.
Na dit verhaal ben ik het eens gaan controleren, en uit alles blijkt dat je inderdaad gelijk had over die volgorde.
Dat had ik me blijkbaar niet gerealiseerd in de andere regels, ik had gedacht dat de waarden in een door komma's gescheiden lijst in een willekeurige volgorde voor mogen komen.

Waarschijnlijk heb ik me verkeken op het feit dat tfoot vóór de tr of tbody tags moet. Ik heb deze tfoot tag eigenlijk nog nooit gebruikt. :)

Met deze informatie is het inderdaad een stuk logischer waarom er zulk een aparte en uitgebreide notatie voor nodig was. Het moet nu denk ik toch wel lukken om iets werkends te schrijven.
Interleaving is iets wat je ontzettend goed kunt uitdrukken in Relax NG (zie de tutorial), maar dus echt voor geen meter in DTDs.
[..]

Als ik het goed heb (maar ben geen detail-kenner van DTDs) is hier geen interleaving mogelijk en moet de title dus altijd achteraan staan, eventueel gevolgd door een base. Dat is dus echt iets anders.
Dat Relax NG ziet er inderdaad wel aardig uit, en daar zal ik ook zeker eens naar gaan kijken. Maar dat lijkt me nog iets meer gericht op het XML gebied, en daar heb ik nog niet echt veel ervaring mee. Relax NG gaat voor mij dus nog even in de wachtstand.

Maar goed: de volgorde van de waarden achter een element in een DTD zijn dus wel degelijk belangrijk, en daar was ik nog niet van op de hoogte. Ik denk dat ik nu weer verder kan, dus in ieder geval bedankt voor je tips :)

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Cheatah: Misschien te hoog gegrepen, maar ik vind het het proberen waard :)
Zeker :) .
Dat Relax NG ziet er inderdaad wel aardig uit, en daar zal ik ook zeker eens naar gaan kijken. Maar dat lijkt me nog iets meer gericht op het XML gebied, en daar heb ik nog niet echt veel ervaring mee. Relax NG gaat voor mij dus nog even in de wachtstand.
Relax NG wordt vooral geprezen vanwege de grote eenvoud en helderheid ten opzichte van W3C's XML Schema. Daarnaast heeft Relax NG ondanks de bulk van W3C's XML Schema toch een grotere uitdrukkingskracht en kan dus een grotere klasse van XML documenten beschrijven.

Relax NG is gebaseerd op de reguliere grammatica's, wat dus ook voor velen een bekend formalisme is :) . Relax NG validatie is ook vrij eenvoudig te implementeren, in tegenstelling tot W3C's XML Schema, waar zelfs de grootste spelers in de markt grote moeite mee hebben (Microsoft, IBM/Apache).
Ik denk dat ik nu weer verder kan, dus in ieder geval bedankt voor je tips :)
Succes :) .

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment