Dit document is een Nederlandse vertaling van een Engelstalig document (http://www.w3.org/TR/xhtml-modularization). Deze vertaling is gemaakt door Andy Camps, maar kan nog enkele fouten bevatten. In geval van twijfel verwijzen wij naar de officiële Engelstalige versie. Engelse versie: http://www.w3.org/TR/xhtml-modularization Deze versie: http://www.playgarden.com/w3c/TR/xhtml-modularization/Overview.html (zip archief van HTML) Vertaler: Andy Camps Auteursrecht: Copyright © 1999 W3C ( MIT, INRIA, Keio). Alle rechten voorbehouden. W3C-regels betreffende aansprakelijkheid, handelsmerk, documentgebruik en softwarelicentiëring zijn van toepassing. [W3C] Modularisatie van XHTML™ W3C Aanbeveling 10 April 2001 Deze versie: http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410 Laatste versie: http://www.w3.org/TR/xhtml-modularization Vorige versie: http://www.w3.org/TR/2001/PR-xhtml-modularization-20010222 Editors: Murray Altheim, Sun Microsystems Frank Boumphrey, HTML Writers Guild Sam Dooley, IBM Shane McCarron, Applied Testing and Technology Sebastian Schnitzenbaumer, Mozquito Technologies AG Ted Wugofski, Openwave (voorheen Gateway) Vertaling: Andy Camps, Playgarden Copyright ©2001 W3C® (MIT, INRIA, Keio), Alle Rechten Voorbehouden. W3C verantwoordelijheid, handelsmerk, document gebruik en software licentie regels gelden. ------------------------------------------------------------------------ Samenvatting Deze Aanbeveling specificeert een abstracte modularisatie van XHTML en een implementatie van de abstractie bij gebruik van XML Document Type Definities (DTDs). Deze modularisatie biedt een middel om subsets en uitbreidingen (extensions) voor XHTML te maken. Dit is nodig om het bereik van XHTML uit te breiden naar verschijnende platforms. Status van dit document Dit deel omschrijft de status van dit document op het ogenblik van publicatie. Andere documenten kunnen dit document opvolgen. De laatste status van deze documentreeks wordt bijgehouden op het W3C. Dit document is nagekeken door W3C Leden en andere geïnteresseerde partijen en is bekrachtigd door de Directeur als een W3C Aanbeveling. Het is een stabiel document en kan gebruikt worden als referentie materiaal of geciteerd als een normatieve referentie vanuit een andere document. De rol van W3C in het maken van de Aanbeveling is aandacht richten op de specificatie en de verspreiding ervan promoten. Dit verbetert de functionaliteit en de interoperabiliteit van het Web. Dit document is gemaakt door de W3C HTML Working Group (enkel leden) als deel van de W3C HTML Activity. Het doel van de HTML Working Group is omschreven in het HTML Working Group charter. De contactpersoon van de W3C staff voor HTML is Masayasu Ishikawa. Publieke discussie van HTML wordt gevoerd op www-html@w3.org (archief). Stuur een email naar www-html-request@w3.org met het woord subscribe als onderwerp om in te schrijven. Meldt fouten in de Engelstalige versie van dit document aan www-html-editor@w3.org (archief). De lijst van gekende fouten in deze specificatie is beschikbaar op http://www.w3.org/2001/04/REC-xhtml-modularization-20010410-errata. Meldt fouten in de vertaling van dit document aan andy.camps@playgarden.com. Er wordt dan zo spoedig mogelijk gereageerd op uw opmerkingen. De Engelstalige versie van deze specificatie is de enige normatieve versie. Informatie over vertalingen van dit document is beschikbaar op http://www.w3.org/MarkUp/translations. Vanuit het W3C is het verplicht om de voorgaande zin ook in het Engels in de vertaling op te nemen. Vandaar de volgende paragraaf. The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/MarkUp/translations. Een lijst van huidige W3C Aanbevelingen en andere technische documenten can gevonden worden op http://www.w3.org/TR. Korte inhoudstabel * 1. Introductie * 2. Begrippen en definities * 3. Conformiteitsdefinitie * 4. Definitie van Abstracte Modules * 5. XHTML Abstracte Modules * A. Schema Modules bouwen * B. Ontwerpen van Schema met gedefinieerde en uitbreidingsmodules * C. XHTML Schema Module Implementaties * D. DTD Modules bouwen * E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules * F. XHTML DTD Module Implementaties * G. Referenties * H. Ontwerpdoelen * J. Dankwoord Volledige inhoudstabel * 1. Introductie o 1.1. Wat is XHTML? o 1.2. Wat is XHTML Modularisatie? o 1.3. Waarom XHTML Modulariseren ? + 1.3.1. Abstracte modules + 1.3.2. Module implementaties + 1.3.3. Hybride document types + 1.3.4. Validatie + 1.3.5. Opmaakmodel * 2. Begrippen en definities * 3. Conformiteitsdefinitie o 3.1. XHTML Host Taal Document Type Conformiteit o 3.2. XHTML Integratie Set Document Type Conformiteit o 3.3. XHTML Family Module Conformiteit o 3.4. XHTML Family Document Conformiteit o 3.5. XHTML Family User Agent Conformiteit o 3.6. Naamgevingsregels o 3.7. XHTML Module Evolutie * 4. Definitie van Abstracte Modules o 4.1. Syntactische Conventies o 4.2. Inhoudstypes o 4.3. Attribuuttypes o 4.4. Een Voorbeeld Abstracte Module Definitie + 4.4.1. XHTML Skiing Module * 5. XHTML Abstracte Modules o 5.1. Attribuut Verzamelingen o 5.2. Kern Modules + 5.2.1. Structuur Module + 5.2.2. Tekst Module + 5.2.3. Hypertext Module + 5.2.4. Lijst Module o 5.3. Applet Module o 5.4. Tekst Uitbreiding Modules + 5.4.1. Presentatie Module + 5.4.2. Bewerkingsmodule + 5.4.3. Bi-directionele Tekst Module o 5.5. Formulieren Modules + 5.5.1. Basis Formulieren Module + 5.5.2. Formulieren Module o 5.6. Tabel Modules + 5.6.1. Basis Tabellen Module + 5.6.2. Tabellen Module o 5.7. Figuren Module o 5.8. Client-side Image Map Module o 5.9. Server-side Image Map Module o 5.10. Object Module o 5.11. Frames Module o 5.12. Doel Module o 5.13. Iframe Module o 5.14. Intrinsieke Gebeurtenis Module o 5.15. Meta informatie Module o 5.16. Scripting Module o 5.17. Style Sheet Module o 5.18. Style Attribuut Module o 5.19. Link Module o 5.20. Base Module o 5.21. Naam Identificatie Module o 5.22. Erfenis Module * A. Schema Modules bouwen * B. Ontwerpen van Schema met gedefinieerde en uitbreidingsmodules * C. XHTML Schema Module Implementaties * D. DTD Modules bouwen o D.1. Parameter Entiteits Naamgeving o D.2. Definitie van de Namespace van een Module + D.2.1. Kwalificerende Names sub-module + D.2.2. Declaratie sub-module(s) + D.2.3. Gebruik van de module als een stand-alone DTD + D.2.4. Namespace Eigenaardigheden * E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules o E.1. Definiëren van aanvullende attributen o E.2. Definiëren van aanvullende elementen o E.3. Definiëren van het inhoudsmodel voor een verzameling van modules + E.3.1. Een stand-alone module integreren in XHTML + E.3.2. Een nieuwe module mixen door de modules in XHTML o E.4. Een nieuwe DTD maken + E.4.1. Een eenvoudige DTD maken + E.4.2. Een DTD maken door XHTML uit te breiden + E.4.3. Een DTD maken door XHTML modules te verwijderen en te vervangen + E.4.4. Een niuewe DTD maken o E.5. Een nieuwe DTD gebruiken * F. XHTML DTD Module Implementaties o F.1. XHTML karakter Entiteiten + F.1.1. XHTML Latin 1 Karakter Entiteiten + F.1.2. XHTML Speciale Karakters + F.1.3. XHTML Wiskundige, Griekse en Symbolische Karakters o F.2. XHTML Modulair Framework + F.2.1. XHTML Base Architectuur + F.2.2. XHTML Notaties + F.2.3. XHTML Datatypes + F.2.4. XHTML Gemeenschappelijke Attribuut Definities + F.2.5. XHTML Kwalificerende Namen + F.2.6. XHTML Karakter Entiteiten o F.3. XHTML Module Implementaties + F.3.1. XHTML Kern Modules + F.3.2. Applet + F.3.3. Tekst Modules + F.3.4. Formulieren + F.3.5. Tabellen + F.3.6. Figuur + F.3.7. Client-side Image Map + F.3.8. Server-side Image Map + F.3.9. Object + F.3.10. Frames + F.3.11. Doel + F.3.12. Iframe + F.3.13. Intrinsieke Gebeurtenissen + F.3.14. Metainformatie + F.3.15. Scripting + F.3.16. Style Sheet + F.3.17. Style Attribuut + F.3.18. Link + F.3.19. Base + F.3.20. Naam Identificatie + F.3.21. Erfenis o F.4. XHTML DTD Ondersteunings Modules + F.4.1. Woordgroep blok + F.4.2. Presentationeel blok + F.4.3. Structureel blok + F.4.4. Inline Woordgroep + F.4.5. Inline Presentationeel + F.4.6. Inline Structureel + F.4.7. Param + F.4.8. Erfenis Herdeclaraties * G. Referenties o G.1. Normatieve Referenties o G.2. Informatieve Referenties * H. Ontwerpdoelen o H.1. Vereisten + H.1.1. Geleidelijkheid + H.1.2. Opbouwbaarheid + H.1.3. Gebruiksgemak + H.1.4. Compatibiliteit + H.1.5. Conformiteit * J. Dankwoord 1. Introductie Dit deel is informatief. 1.1. Wat is XHTML? XHTML is de herformulering van HTML 4 als een toepassing van XML. XHTML 1.0 [XHTML1] specificeert drie XML document types die overeenkomen met de drie HTML 4 DTD's: Strict, Transitional en Frameset. XHTML 1.0 is de basis voor een family van document types die een subset en een uitbreiding vormen op HTML. 1.2. Wat is XHTML Modularisatie? XHTML Modularisatie is een decompositie van XHTML 1.0, door referentie HTML 4, in een collectie van abstracte modules die specifieke types van functionaliteit voorzien. Deze abstracte modules zijn geïmplementeerd in deze specificatie door gebruik te maken van de XML Document Type Definition taal. Er wordt echter een implementatie door gebruik te maken van XML Schemas verwacht. De regels voor definiëren van de abstracte modules, en voor het implementeren ervan door gebruik van XML DTD's, worden ookk gedefinieerd in dit document. Deze modules kunnen gecombineerd worden met elkaar en met andere modules om XHTML subset en uitbreiding document types te maken die voldoen als leden van de XHTML-family van document types. 1.3. Waarom XHTML Modulariseren? De modularisatie van XHTML heeft betrekking op de taak om goed-gedefinieerde sets van XHTML elementen te specificeren die gecombineerd en uitgebreid kunnen worden door document auteurs, document type architecten, andere XML standaard specificaties en toepassings- en productontwerpers om het economisch haalbaar te maken dat inhoudontwerpers inhoud leveren op een groter aantal verschillende platforms. In de laatste paar jaren hebben veel gespecialiseerde markten HTML gezien als een inhoudstaal. Er is een grote beweging naar het gebruik van HTML over toenemende diverse computing platforms. Momenteel is er beweging om HTML te verplaatsen naar mobiele toestellen (hand held computers, draagbare telefoons, enz.), televisie toestellen (digitale televisies, TV-gebaseerde Web browsers, enz.) en apparaten (toestellen met een vaste functie). Elk van deze toestellen heeft andere vereisten en andere beperkingen. Modularisering van XHTML biedt productontwerpers een middel om te specificeren welke elementen ondersteund worden door een toestel, door gebruik te maken van standaard bouwblokken en standaard methoden, om te specificeren welke bouwblokken gebruikt worden. Deze modules dienen als "punten van aanpassing" voor de inhoud gemeenschap. De inhoud gemeenschap kan nu kijken naar de geënstalleerde basis die een bepaalde collectie van modules ondersteund, in plaats van zich zorgen te moeten maken over de geënstalleerde basis basis die deze of gene permutatie van XHTML elementen ondersteund. HEt gebruik van standaards is kritiek voor gemodulariseerde XHTML om op een grote schaal succesvol te kunnen zijn. Het is niet economisch haalbaar dat inhoudontwerpers trachten de inhoud aan elke permutation van XHTML elementen aan te passen. Door een standaard te specificeren kunnen, ofwel software processen autonoom de inhoud aanpassen aan een toestel, ofwel kan het toestel automatisch de software laden die nodig is om een module te verwerken. Modularisatie laat ook toe dat de layout- en presentatiemogelijkheden van XHTML uitgebreid worden door gebruik te maken van de uitbreidbaarheid van XML. Dit alles zonder de XHTML standaard met de voeten te treden. Deze manier van werken biedt een stabiel, bruikbaar en uitvoerbaar kader waarin inhoudontwerpers en uitgevers de snelle technologische evolutie van het Web kunnen beheersen. 1.3.1. Abstracte modules Een XHTML document type wordt gedefinieerd als een set van abstracte modules. Een abstracte module definieerd een soort van data die op semantische wijze verschilt van alle andere. Abstracte modules kunnen gecombineerd worden in document types zonder dat een gedetailleerd begrip van de onderliggende schema's, die de modules definiëren, nodig is. 1.3.2. Module implementaties Een module implementatie bestaat uit een set van element types, een set van attribuut-lijst declaraties en een set van inhousmodel declaraties, waar elk van deze drie sets leeg mag zijn. Een attribuut-lijst declaratie in een module mag een element type aanpassen buiten de element types gedefinieerd in de module en een inhoudsmodel declaratie mag een element type aanpassen buiten de element type set van de module. XML DTD's vormen een implementatiemechanisme. Een XML DTD is een middel om de structuur van een klasse van XML documenten, samen gekend als een XML document type, te omschrijven. XML DTD's worden omschreven in de XML 1.0 Aanbeveling [XML]. Een ander implementatiemechanisme is XML Schema [XMLSCHEMA]. 1.3.3. Hybride document types Een hybride document type is een document type dat samengesteld wordt uit een collectie van XML DTD's of DTD Modules. Het hoofddoel van het modularisatie kader omschreven in dit document is een DTD auteur toelaten om elementen van verschillende abstracte modules te combineren in een hybride document type, ontwerpen van documenten met dit hybride document type en dit document valideren met de geassocieerde hybride document type definitie. Een van de meest waardevolle voordelen van XML ten opzichte van SGML is dat XML de instapbarrière verkleint voor standardisatie van sets van elementen die gemeenschappen toelatten om data uit te wisselen via een uitwisselbaar formaat. Hoewel de relatieve static natuur van HTML als de inhoudstaal voor het Web betekende dat elk van deze gemeenschappen weinig hoop had dat hun XML document types uitgebreid verspreid zou worden als deel van Web standaards. Het modularisatie kader laat de dynamische omvatting van deze diverse document types toe in de XHTML-family van document types. Hierdoor worden de barrières voor de omvatting van deze domein-specifieke vocabulares in XHTML documenten verder verkleint. 1.3.4. Validatie Het gebruik van correct gevormde, maar niet geldige, documenten is een belangrijk voordeel van XML. In het ontwikkelprocess van een document type, is echter de aanvullende hefboomwerking, voorzien door een validatie parser voor foutcontrole, belangrijk. Dezelfde uitdrukking geldt voor XHTML document types met elementen van meerdere abstracte modules. Een document is een geval van een specifiek document type gedefinieerd door de DTD die geïdentificeerd wordt in de proloog van het document. Validatie van het document is het proces van controle waaruit blijkt dat het document voldoet met de regels in de document type definitie. Een document kan bestaan uit meerdere document fragmenten. Validatie van delen van een document, waar elk deel een ander document type heeft dan de andere delen van het document, valt buiten de draagwijdte van dit kader - aangezien het een technologie zou vereisen die nog niet gedefinieerd is. Het modularisatie kader laat echter wel toe dat meerdere document type definities geïntegreerd worden en zo een nieuw document type vormen (bijvoorbeeld SVG geïntegrerd in XHTML). De nieuwe document type definitie kan gebruikt worden voor normale XML 1.0 validatie. 1.3.5. Opmaakmodel Eerdere versies van HTML trachten delen van het model te definiëren die user agents moesten gebruiken wanneer ze een document opmaakten. Met de verschijning van HTML 4, startte het W3C het proces van scheiding van presentatie van structuur. XHTML 1.0 behield deze scheiding en dit document gaat verder met de verschuiving van HTML en de afstammelingen ervan. Daarom stelt dit document geen vereisten op het opmaakmodel dat geassocieerd wordt met de presentatie van documenten die opgemaakt zijn met XHTML Family document types. Dit document raadt in de plaats aan dat inhoudsauteurs vertrouwen op style mechanismen zoals CSS om het opmaakmodel voor hun inhoud te bepalen. Wanneer user agents deze style mechanismen ondersteunen zullen documenten uitzien zoals verwacht. Wanneer user agents de style mechanismen niet ondersteunen zullen documenten weergegeven worden op een manier die geschikt is voor die user agent. Dit laat XHTML Family user agents toe om rijke opmaakmodellen te ondersteunen voor toestellen waar dat voor geschikt is, terwijl opmaakmodellen ingekort (eng:lean) kunnen worden op toestellen waar dat geschikt is. 2. Begrippen en definities Dit deel is informatief. Een aantal begrippen worden gedefinieerd op de plaats waar ze ter sprake komen. De volgende definities worden gebruikt in dit document. Kennis van de W3C XML 1.0 Aanbeveling [XML] is sterk aanbevolen. abstracte module een eenheid van document type specificatie die overeenkomt met een afgescheiden type van inhoud, overeenkomend met een opmaakconstructie die dit afgescheiden type weerspiegelt. inhoudsmodel de gedeclareerde opmaakstructuur toegelaten in voorbeelden van een element type. XML 1.0 onderscheidt twee types: elementen die enkel element inhoud bevatten (geen karakter data) en gemengde inhoud (elementen mogen karakter data bevatten met optioneel verstrooide child elementen). Het laatste wordt gekenmerkt door een inhoudsspecificatie die begint met de "#PCDATA" string (hetgeen karakter data aangeeft). document model de effectieve structuur en beperkingen van een gegeven document type. Het documentmodel schept de abstracte representatie van de fysische of semantische structuren van een klasse van documenten. document type een klasse van documenten delen een gemeenschappelijke abstracte structuur. De ISO 8879 [SGML] definitie is als volgt: "een klasse van documenten hebben vergelijkbare karakteristieken zoals bijvoorbeeld journaal, artikel, technisch handboek of memo. (4.102)" document type definitie (DTD) een formele, voor de machine leesbare, uitdrukking van de XML structuur en syntax regels waaraan een document geval van een specifiek document type moet voldoen; het schema type gebruikt in XML 1.0 il de Conformiteit van een document te valideren aan het gedeclareerde document type. Hetzelfde opmaakmodel kan uitgedrukt worden door een variatie van DTD's. driver meestal een kort bestand dat gebruikt wordt om de modules van een DTD te declareren. Een goede vuistregel is dat een DTD driver geen opmaakdeclaraties bevat die deel uitmaken van het document model itself. element een geval van een element type. element type de definitie van een element. Eigenlijk een container voor een afgescheiden semantische klasse van documentinhoud. entiteit een entiteit is een logische of fysische opslageenheid die documentinhoud bevat. Entiteiten mogen samengesteld zijn uit parse-able XML opmaak of karakter data, of niet-parse-able (bijvoorbeeld, niet-XML, mogelijk niet-tekstueel) inhoud. Entiteitsinhoud mag ofwel compleet in de document entiteit gedefinieerd worden ("interne entiteiten") of extern aan de document entiteit ("externe entiteiten"). In geparsete entiteiten mag de vervangingstekst verwijzingen naar andere entiteiten bevatten. entiteitsreferentie een mnemontechnische string die gebruikt wordt als een referentie voor de inhoud van een gedeclareerde entiteit (zoals "&" voor "&", "<" voor "<", "©" voor "©".) generieke identifier Het element type dat de name van een element identificeert. Ook wel element type naam genoemd. hybride document Een hybride document is een document dat meer dan één XML namespace gebruikt. Hybride documenten mogen gedefinieerd worden als documenten die elementen of attributen bevatten van hybride document types. instantiate het vervangen van een entiteitsreferentie met de gedeclareerde inhoud ervan. opmaakdeclaratie een syntactische constructie binnen een DTD die een entiteit declareert of een opmaakstructuur definieert. Binnen XML DTD's zijn er vier specifieke types: entiteitsdeclaratie definieert de band tussen een mnemonisch symbool en de vervangende inhoud ervoor; element declaratie beperkingen die aangeven welke element types mogen voorkomen als nakomelingen binnen een element (zie ook inhoudsmodel); attribuut definitielijst declaratie definieert de set van attributen voor een gegeven element type en mag ook de basis zijn voor type beperkingen en standaardwaarden; notatie declaratie definieert de band tussen de schrijfwijze van een naam en een externe identifier die verwijst naar de opmaak van een niet-geparsete entiteit. opmaakmodel de opmaakwoordenschat (zoals de reeks van element- en attribuutnamen, notaties, enz.) en grammatica (zoals het voorgeschreven gebruik van die woordenschat) zoals deze gedefinieerd is door een document type definitie (zoals een schema) Het opmaakmodel is de tastbare representatie in opmaaksyntax van het document model en mag gedefinieerd worden met wisselende niveaus van stricte Conformiteit. Hetzelfde document model mag uitgedrukt worden door verschillende opmaakmodellen. module een abstracte eenheid binnen een document model uitgedrukt als een DTD fragment, gebruikt om opmaakdeclaraties te vermengen om de flexibiliteit, aanpasbaarheid, hergebruik en begrijpen van specifieke logische of semantische structuren te vergroten. modularisatie een uitvoering van een modularisatiemodel; de procedure van compositie en de-compositie van een DTD door de opmaakdeclaraties op te delen in eenheden of groepen die specifieke doelen ondersteunen. Modules kunnen, maar moeten niet bestaan als afzonderlijke bestandsentiteiten (zoals de fysische en logische structuren van een DTD op elkaar mogen afgespiegeld worden, zonder dat dit verplicht is). modularisatiemodel het abstracte ontwerp van de document type definitie (DTD) als ondersteuning van de modularisatie doelen zoals hergebruik, uitbreidbaarheid, betekenisvol zijn, gemak van documentatie, code grootte, consistentheid en intuitiviteit in gebruik. Het is belangrijk om op te merken dat een modularisatiemodel enkel orthogonaal gerelateerd is met het documentmodel dat het beschrijft zodat twee zeer verschillende modularisatie modellen hetzelfde document type mogen omschrijven. parameter entiteit een entiteit waarvan de aktieruimte in de document proloog ligt (zoals de externe subset/DTD of interne subset). Parameter entiteiten worden niet toegestaan binnen het document zelf. parent document type Een parent document type van een hybride document is het document type van het root element. tag omschrijvende opmaak die de start en het einde (inclusief de generiek identifier en alle attributen ervan) van een element afbakent. 3. Conformiteitsdefinitie Dit deel is normatief. Om ervoor te zorgen dat XHTML-family documenten maximaal uitwisselbaar zijn tussen XHTML-family user agenten, definieert deze specificatie precies de conformiteitseisen voor zowel deze en voor XHTML-family document types. Aangezien de conformiteitsdefinities gevonden kunnen worden in deze sectie, refreren ze noodzakelijkerwijs naar normatieve tekst in dit document, binnen de basis XHTML specificatie [XHTML1], en binnen andere gerelateerde specificaties. Het is enkel mogelijk om de volledige conformiteitsvereisten van XHTML te begrijpen door alle normatieve referenties te lezen. De sleutelwoorden "MOETEN (MUST)", "MOETEN NIET (MUST NOT)", "VEREIST (REQUIRED)", "ZULLEN (SHALL)", "ZULLEN NIET (SHALL NOT)", "ZOUDEN (SHOULD)", "AANBEVOLEN (RECOMMENDED)", "MOGEN (MAY)" en "OPTIONEEL (OPTIONAL)" in dit document moeten geïnterpreteerd worden zoals omschreven in [RFC2119]. 3.1. XHTML Host Taal Document Type Conformiteit Het is mogelijk om bestaande document types aan te passen en compleet nieuwe document types te maken door gebruik te maken van zowel modules die gedefinieerd worden in deze specificatie en andere modules. Zulk een document type is "Conform XHTML Host Taal" wanneer het voldoet aan de volgende volgende criteria: 1. Het document type moet gedefinieerd worden door gebruik te maken van een van de implementatiemethodes die gedefinieerd worden door het W3C. Momenteel wordt dit beperkt tot XML DTD's, maar XML Schema zal binnenkort beschikbaar zijn. De rest van deze sectie verwijst naar "DTD's" hoewel andere implementaties mogelijk zijn. 2. De DTD doe het document type definieert moet een unieke identifier hebben zoals gedefinieerd in Naamgevingsregels die gebruik maakt van de string "XHTML" in de eerste token van de publieke tekst omschrijving. 3. De DTD die het document type definieert moet ten minste de Structuur, Hypertext, Tekst en Lijst modules bevatten die gedefinieerd worden in deze specificatie. 4. Voor elk van de door het W3C-gedefinieerde modules die opgenomen worden, moeten alle elementen, attributen, types van attributen (inclusief alle vereiste numerieke waardenlijsten) en alle vereiste minimale inhoudmodellen opgenomen (en optioneel uitgebreid) worden in het document type's inhoudsmodel. Wanneer inhoudsmodellen uitgebreid worden, moeten alle elementen en attributen (samen met hun types of alle vereiste numerieke waardenlijsten) vereist in het originele inhoudsmodel vereist blijven. 5. De DTD die het document type definieert mag aanvullende elementen en attributen definiëren. Deze moeten echter in hun eigen XML namespace [XMLNAMES] zitten. 3.2. XHTML Integratie Set Document Type Conformiteit Het is ook mogelijk om document types te definiëren die gebaseerd zijn op XHTML, maar die niet blijven bij de structuur ervan. Zo een document type is "XHTML Integratie Set Conformiteit" wanneer het voldoet aan de volgende criteria: 1. Het document type moet gedefinieerd worden door gebruik te maken van een van de implementatiemethodes gedefinieerd door het W3C. Momenteel wordt dit beperkt tot XML DTD's, maar XML Schema zal binnenkort beschikbaar zijn. De rest van deze sectie refereert naar "DTD's" hoewel andere implementaties mogelijk zijn. 2. De DTD welke het document type definieert moet een unieke identifier hebben zoals deze gedefinieerd wordt in Naamgevingsregels die NIET gebruik maken van de string "XHTML" in de eerste token van de publieke tekst omschrijving ervan. 3. De DTD welke het document type definieert moet ten minste de Hypertext, Tekst en Lijstmodules bevatten die gedefinieerd worden in deze specificatie. 4. Voor elke van de door het W3C-gedefinieerde modules die opgenomen worden moeten alle elementen, attributen, types van attributen (inclusief alle vereiste numerieke lijsten) en alle vereiste minimale inhoudsmodellen opgenomen (en optioneel itgebreid) worden in het document type's inhoudsmodel. Wanneer inhoudsmodellen uitgebreid worden moeten alle elementen en attributen (samen met hun types of alle vereiste numerieke waardenlijsten) vereist in het originele inhoudsmodel opgenomen blijven. 5. De DTD welke het document type definieert mag aanvullende elementen en attributen definiëren. Deze moeten echter in hun eigen XML namespace [XMLNAMES] zitten. 3.3. XHTML Family Module Conformiteit Deze specificatie definieerd een methode om XHTML-conforme modules te definiëren. Een module is conform aan deze specificatie als voldaan wordt aan alle volgende voorwaarden: 1. Het document type moet gedefinieerd worden door gebruik te maken van één van de implementatiemethodes die gedefinieerd worden door het W3C. Momenteel is dit beperkt tot XML DTD's, maar XML Schema zal binnenkort beschikbaar zijn. De rest van dit deel verwijst naar "DTD's" hoewel andere implementaties mogelijk zijn. 2. De DTD die de module definieert moet een unieke identificatie hebben zoals gedefinieerd in Naamgevingsregels. 3. Wanneer de module gedefinieerd is door gebruik te maken van een DTD, moet de parmater entiteitsnamen van de module afgeschermd worden door gebruik te maken van unieke prefixen of andere, gelijkaardige methodes. 4. De module definitie moet een omschrijvingsdefinitie hebben die de syntactische en semantische vereisten van de elementen, attributen en/of inhoudsmodellen, die de module definitie declareert, omschrijft. 5. De module definitie mag geen elementnamen die gedefinieerd zijn in andere W3C-gedefinieerde modules hergebruiken, behalve wanneer het inhoudsmodel en semantiek van deze elementen identiek aan of een uitbreiding van het origineel zijn of wanneer de hergebruikte elementnamen in hun eigen namespace zijn (zie verder). 6. De elementen en attributen van de module definitie moeten deel uitmaken van een XML namespace [XMLNAMES]. Als de module gedefinieerd us door een andere organisatie dan het W3C, mag deze namespace niet dezelfde zijn als de namespace waarin andere W3C modules gedefinieerd worden. 3.4. XHTML Family Document Conformiteit Een conform XHTML family document is een geldig voorbeeld van een XHTML Host Taal Document Type Conformiteit. 3.5. XHTML Family User Agent Conformiteit Een Conforme user agent moet voldoen aan alle volgende voorwaarden (zoals gefinieerd in [XHTML1]): 1. Om consistent te zijn met de XML 1.0 Aanbeveling [XML], moet de user agent een XHTML document parsen en evalueren voor correct-gevormdheid. Als de user agent beweert een validerende user agent te zijn, moet het ook documenten valideren tenopzichte van hun verwijzende DTD's volgens [XML]. 2. Wanneer de user agent beweert mogelijkheden te ondersteunen die gedefinieerd worden in deze specificatie of vereist door deze specificatie door normatieve verwijzing, moet het deze mogelijkheden ondersteunen consistent aan de definitie van de mogelijkheden. 3. Wanneer een user agent XHTML document verwerkt als generieke [XML], zal het enkel attributen van het type ID (zoals het id attribuut op de meeste XHTML elementen) herkennen als fragment identificatoren. 4. Als een user agent een element tegenkomt dat het niet herkent, moet het verder gaan met het verwerken van de kinderen (children) van dat element. Als de inhoud tekst is, moet de tekst gepresenteerd worden aan de gebruiker. 5. Als een user agent een attribuut tegenkomt dat het niet herkent, moet het de volledige attribuut specificatie (zijnde het attribuut en de waarde ervan) negeren . 6. Als een user agent een attribuutwaarde tegenkomt die het niet herkent, moet het de standaard attribuutwaarde gebruiken. 7. Als het een entiteitsverwijzing (anders dan één van de voorgedefinieerde entiteiten) tegenkomt waarvoor de user agent geen declaratie verwerkt heeft (hetgeen kan gebeuren als de declaratie in de externe subset zit welke de user agent nog niet gelezen heeft), zou de entiteitsverwijzing moeten weergegeven worden als de karakters (startend met de ampersand en eindigend met de punt-komma) die de entiteitsverwijzing vormen. 8. Wanneer inhoud weergegeven wordt, zouden user agents die karakters of karakter entiteitsverwijzingen tegenkomen die herkend worden, maar niet weergegeven kunnen worden, het document moeten weergegeven op een zodanige manier dat het duidelijk is voor de gebruiker dat de inhoud niet op een normale manier weergegeven wordt. 9. Witruimte wordt behandeld volgens de volgende regels. De volgende karakters worden in [XML] gedefinieerd als witruimtekarakters: o SPATIE (SPACE) ( ) o HORIZONTALE TAB (HORIZONTAL TABULATION) ( ) o ALINEA-EINDE (CARRIAGE RETURN) ( ) o REGELEINDE (LINE FEED) ( ) De XML processor normaliseert de regeleindecodes van verschillende systemen in één REGELEINDE (LINE FEED) karakter, dat doorgegeven wordt aan de toepassing. De user agent moet de witruimtetekens in de data van de XML processor als volgt verwerken: o Alle witruimte rond blokelementen moet verwijderd worden. o Opmerkingen worden volledig verwijderd en hebben geen invloed op witruimtebehandeling. Een witruimteteken aan beide kanten van een opmerking zal aangenomen worden als twee witruimtetekens. o Wanneer het 'xml:space' attribuut ingesteld is op 'preserve', moeten witruimtetekens behouden worden en daardoor worden REGELEINDE tekens binnen een blok niet omgezet. o Wanneer het 'xml:space' attribuut niet ingesteld is op 'preserve': + Moeten alle voorafgaande en volgende witruimtetekens in een blokelement verwijderd worden. + REGELEINDE tekens moeten omgezet worden in één van de volgende karakters: een SPATIE karakter, a NUL BREEDTE SPATIE karakter (​) of geen karakter (hetgeen wil zeggen verwijderd). De keuze van het resulterende karakter hangt af van de user agent en wordt bepaald door de script eigenschap (schrift) van de karakters voorafgaand en volgend op het REGELEINDE character. + Een reeks van witruimtetekens zonder REGELEINDE tekens moet gereduceerd worden tot één SPATIE karakter. + Een reeks van witruimtetekens met één of meer REGELEINDE karakters moet gereduceerd worden op dezelfde manier als één enkel REGELEINDE karakter. Witruimte in attribuutwaarden wordt verwerkt volgens [XML]. Opmerking (informatief): Bij het beslissen hoe een user agent een REGELEINDE karakter zou moeten omzetten moeten de volgende gevallen, waarbij de schrijfwijze van karakters aan beide kanten van het REGELEINDE karakter bepalen welke de keuze van vervanging is, beschouwd worden. Karakters van COMMON schrift (zoals interpunctie) worden op dezelfde manier behandeld als de schrijfwijze aan de andere kant: 1. Als de karakters voorafgaand en volgend op het REGELEINDE karakter horen tot een schrift waar het SPATIE karakter gebruikt wordt als woordscheiding, zou het REGELEINDE karakter omgezet moeten worden in een SPATIE karakter. Voorbeelden van zulke schriften zijn Latijns, Grieks en Cyrillisch. 2. Als de karakters voorafgaand en volgend op het REGELEINDE karakter horen tot een ideografisch-gebaseerd schrift of schrijfsysteem waarin er geen woordscheidingsteken is, zou het REGELEINDE teken omgezet moeten worden in geen karakter. Voorbeelden van zulke schriften of schrijfsystemen zijn Chinees en Japans. 3. Als de karakters voorafgaand en volgend op het REGELEINDE karakter horen tot een niet ideografisch-gebaseerd schrift waarin er geen woordscheidingsteken is, zou het REGELEINDE teken omgezet moeten worden in een NUL BREEDTE SPATIE karakter (​) of in geen karakter. Voorbeelden van zulke schriften zijn Thai en Khmer. 4. Als geen van de voorwaarden in (1) tot (3) geldt, the zou het REGELEINDE teken omgezet moeten worden in een SPATIE karakter. Het Unicode [UNICODE] technische rapport TR#24 (Script Names) biedt een toewijzing van schriftnamen aan alle karakters. 3.6. Naamgevingsregels XHTML Host Taal document types moeten stricte naamgevingsregels volgen zodat het voor software en gebruikers mogelijk is om de relatie van document types tot XHTML te bepalen. De namen voor document types die geïimplementeerd zijn als XML document type definities worden gedefinieerd via Formele Publieke Identificatoren (FPI's). Binnen FPI's worden velden gescheiden door een dubbel slash karakter (//). De verschillende velden moeten als volgt opgebouwd worden: 1. Het startveld moet "-" zijn om een privaat gedefinieerde bron aan te geven. 2. Het tweede veld moet de naam van de organisatie, die verantwoordelijk is voor het onderhoud van het benoemde item, bevatten. Er is geen formele registratie voor deze organisatienamen. Elke organisatie zou een naam moeten definiëren die uniek is. De naam die door het W3C gebruikt wordt is bijvoorbeeld W3C. 3. Het derde veld bevat twee constructies: de publieke tekst klasse gevolgde door de publieke tekst omschrijving. Het eerste token in het derde veld is de publieke tekst klasse welke ISO 8879 Clause 10.2.2.1 Public Text Class zou moeten volgen. Enkel XHTML Host Taal conforme documenten zouden de publieke tekst omschrijving mogen beginnen met de token XHTML. De publieke tekst omschrijving zou de string XHTML moeten bevatten als het document type Integratie Set conform is. Het veld moet ook door de organisatie gedefinieerde unieke identificator moeten bevatten (bijvoorbeeld MijnML 1.0). Deze identificator zou opgebouwd moeten zijn uit een unieke naam en een versie-identificator die geupdated kan worden als het document type evolueert. 4. Het vierde veld definieert de taal waarin het item ontwikkeld werd (bijvoorbeeld EN). Door deze regels te bebruiken zou de naam voor een XHTML Host Taal conform document type -//MijnBedrijf//DTD XHTML MijnML 1.0//EN kunnen zijn. De naam voor een XHTML familie conforme module zou -//MijnBedrijf//ELEMENTS XHTML MijnElementen 1.0//EN kunnen zijn. De naam voor een XHTML Integratie Set conform document type zou -//MijnBedrijf//DTD Speciale Opmaak met XHTML//EN kunnen zijn. 3.7. XHTML Module Evolutie Elke module gedefinieerd in deze specificatie krijgt een unieke identificator die de naamgevingsregels in het voorgaande deel volgt. Een module kan evolueren in de tijd. Een logische afgeleide van een dergelijke evolutie kan zijn dat sommige aspecten van de module niet langer compatible zijn met de vorige definitie. Om te garanderen dat document types, die gedefinieerd worden aan de hand van modules die in deze specificatie gedefinieerd worden, blijven werken, zullen de identificatoren geassocieerd met een module die wijzigt geupdated worden. De Formele Publieke Identificator en Systeem Identificator van de module zullen gewijzigd worden door aanpassing van de versie identificator in beide opgenomen. Document types die de geupdate functionaliteit willen gebruiken zullen gelijkaardig geupdated moeten worden. Aanvullend zullende eerdere versie(s) van de module beschikbaar blijven via de vroegere unieke identificator(en). Op deze manier zullen document types ontwikkeld door gebruik te maken van XHTML modules blijven functioneren door gebruik te maken van de originele definities, zelfs als de collectie uitgebreid wordt en evolueert. Gelijkaardig zullen documenten geschreven met zulke document types geldig (valid) blijven via de oudere module definities. Andere XHTML Familie Module en Document Type auteurs worden aangeraden om een gelijkaardige strategie te volgen zodat document types gebaseerd op deze modules en documenten gebaseerd op deze document types blijvend functioneren. 4. Definitie van Abstracte Modules Dit deel is normatief. Een abstracte module is een definitie van een XHTML module waarbij gebruik gemaakt wordt van prosatekst en enkele informele opmaakconventies. Aangezien een dergelijke definitie algemeen niet bruikbaar is in de geautomatiseerde verwerking van document types, is het critisch dat mensen geholpen worden in het begrijpen van hetgene in een module bevat zit. Dit deel definieert de wijze waarop XHTML abstracte modules gedefinieerd worden. Een XHTML-conforme module is niet vereist om een abstracte module definitie te verzorgen. Iedereen die een XHTML module ontwikkeld wordt echter aangeraden om een abstractie (samenvatting) te voorzien om het gebruik van de module te vergemakkelijken. 4.1. Syntactische Conventies De abstracte modules worden niet gedefinieerd in een formele grammatica. De definities leunen echter aan bij de volgende syntactische conventies. Deze conventies zijn vergelijkbaar met deze van XML DTD's en zouden bekend moeten voorkomen voor XML DTD auteurs. Elk discreet syntactisch element kan gecombineerd worden met anderen om complexere expressies te kunnen vormen die conform zijn aan de algebra die hier gedefinieerd wordt. elementnaam Wanneer een element opgenomen wordt in een inhoudsmodel zal de expliciete naam ervan genoteerd worden. inhoudset (content set) Sommige modules definiëren lijsten van expliciete elementnamen die inhoudsets genoemd worden. Wanneer een inhoudset opgenomen wordt in een inhoudsmodel zal de naam ervan genoteerd worden. expr ? Nul of één geval van zijn toegestaan. expr + Eén of meer gevallen van expr zijn vereist. expr * Nul of meer gevallen van expr zijn toegestaan. a , b Uitdrukking a, gevolgd door uitdrukking b is vereist. a | b Ofwel uitdrukking a of uitdrukking b is vereist. a - b Uitdrukking a is toegestaan wanneer de elementen van uitdrukking b wegvallen. haakjes Wanneer een uitdrukking tussen haakjes staat, neemt de evaluatie van alle subuitdrukkingen binnen de haakjes plaats voor de evaluatie van uitdrukkingen buiten de haakjes (start bij het diepste niveau van nesting). uitbreiding van voorgedefinieerde elementen In een aantal gevallen voegt een module attributen toe aan een element. In deze gevallen wordt de elementnaam gevolgd door een ampersand (&). definitie van vereiste attributen Wanneer een element de definitie van een attribuut vereist wordt die attribuutnaam gevolgd door een sterretje (asterisk) (*). definitie van het type van attribuutwaarden Wanneer een module het type van een attribuutwaarde definieert, wordt dit gedaan door de types op te sommen tussen haakjes achter de attribuutnaam. definitie van geldige waarden voor attributen Wanneer een module de geldige waarden voor een attribuut definieert, wordt dit gedaan door de geldige waarden expliciet op te sommen (tussen aanhalingstekens), gescheiden door verticale balken (|), binnen haakjes volgend op de attribuutnaam. Als het attribuut een standaardwaarde heeft, wordt deze waarde gevolgd door een sterretje (asterisk) (*). Als het attribuut een vaste (fixed) waarde heeft, wordt de attribuutnaam gevolgde door een gelijkheidsteken (=) en de vaste (fixed) waarde wordt omsloten door aanhalingstekens. 4.2. Inhoudstypes Abstracte module definities definiëren minimale, atomische inhoudsmodellen voor elke module. Deze minimale inhoudsmodellen verwijzen naar de elementen in de module zelf. Ze mogen ook verwijzen naar elementen in andere modules waar de abstracte module van af hangt. In veel gevallen vereist het inhoudsmodel dat tekst toegestaan is als inhoud voor één of meer elementen. In deze gevallen is het symbool dat gebruikt wordt voor tekst PCDATA. Deze term, die gedefinieerd wordt in de XML 1.0 Aanbeveling, verwijst naar "processed character data" (verwerkte karakterdata. Een inhoudstype kan ook gedefinieerd worden als EMPTY, hetgeen betekend dat het element geen inhoud heeft in het minimale inhoudsmodel. 4.3. Attribuuttypes In sommige gevallen is het nodig dat de types of attribuutwaarden of de expliciete set van toegelaten waarden voor attributen gedefinieerd wordt. De volgende attribuuttypes (gedefinieerd in de XML 1.0 Aanbeveling) worden gebruikt in de definitiesvan de abstracte modules: Attribuuttype Definitie CDATA Karakterdata (Character data) ID Een documentunieke identificator IDREF Een verwijzing naar een documentunieke identificator IDREFS Een door spaties gescheiden lijst van verwijzingen naar een documentunieke identificatoren NAME Een naam met dezelfde karakterbeperkingen als ID hierboven NMTOKEN Een naam samengesteld uit alleen naamtokens zoals deze gedefinieerd worden in XML 1.0 [XML] NMTOKENS Eén of meer witruimtetekens gescheiden door NMTOKEN waarden PCDATA Verwerkte karakterdata (Processed character data) Aanvullend op deze voorgedefinieerde data types definieert XHTML Modularisatie de volgende data types en hun (overeenkomstige) semantieken: Data type Omschrijving Character Een enkel karakter uit [ISO10646]. Characterset Een karaktercodering zoals volgens [RFC2045]. CharactersetsEen door spaties gescheiden lijst van karaktercoderingen zoals volgens [RFC2045]. De attribuutwaarde van het type "Color" verwijst naar kleurdefinities zoals deze gespecificeerd worden in [SRGB]. Een kleurwaarde kan ofwel een hexadecimaal getal (voorafgegaan door een hekje (hash mark)) ofwel één van de volgende zestien kleurnamen zijn. De kleurnamen zijn hoofdletter-ongevoelig. Kleurnamen en sRGB waarden Zwart (Black) = Groen (Green) = "#008000" "#000000" Zilver (Silver) = Lichtgroen (Lime) = "#C0C0C0" "#00FF00" Color Grijs (Gray) = "#808080" Olijf (Olive) = "#808000" Wit (White) = "#FFFFFF" Geel (Yellow) = "#FFFF00" Bruin (Maroon) = Navy = "#000080" "#800000" Rood (Red) = "#FF0000" Blauw (Blue) = "#0000FF" Paars (Purple) = Blauwgroen (Teal) = "#800080" "#008080" Fuchsia = "#FF00FF" Aqua = "#00FFFF" De kleurwaarden "#800080" en "Purple" verwijzen beide naar de kleur paars. ContentType Een mediatype zoals volgens [RFC2045]. ContentTypes Een door komma's gescheiden lijst van mediatypes zoals volgens [RFC2045]. Coords Een door komma's gescheiden lijst van coördinaten die gebruikt worden om gebieden te definiëren. Datetime Datum- en tijdsinformatie. FPI Een karakter string die een SGML Formele Publieke Identificator vertegenwoordigd. FrameTarget Frame naam die gebruikt wordt als doel voor resultaten van bepaalde acties. LanguageCode Een taalcode zoals volgens [RFC3066]. De waarde kan ofwel in pixels ofwel een percentage van de Length beschikbare horizontale of verticale ruimte zijn. De waarde "50%" betekent dus de helft van de beschikbare ruimte. Auteurs kunnen de volgende link types, hier vermeld met hun conventionele interpretaties, gebruiken. Een LinkTypes waarde verwijst naar een door spaties gescheiden lijst van link types. Witruimtetekens zijn niet toegestaan in link types. Deze link types zijn hoofdletterongevoelig, hetgeen wil zeggen dat "Alternate" hetzelfde betekent als "alternate". User agents, search engines, enz. kunnen deze link types op verschillende manieren interpreteren. User agents kunnen bijvoorbeeld toegang bieden aan gelinkte documents via een navigatiebalk. Alternate Duidt plaatsvervangende versies van het document aan waarin de link voorkomt. Wanneer het samen gebruikt wordt met het hreflang attribuut, duidt het op een vertaalde versie van het document. Wanneer het samen met het media attribuut gebruikt wordt, duidt het op een versie die ontworpen is voor een ander medium (of media). Stylesheet Verwijst naar een extern stylesheet. Raadpleeg de Style Module voor details. Dit wordt samen met het link type "Alternate" gebruikt voor door de gebruiker selecteerbare alternatieve stylesheets. Start Verwijst naar het eerste document in een collectie van documenten. Dit link type geeft voor search engines aan welk document door de auteur beschouwd wordt als het startpunt van de collectie. Next Verwijst naar het volgende document in een lineaire reeks van documenten. User agents kunnen kiezen om het "next" document te pre-loaden om zo de waargenomen laadtijd te reduceren. Prev Verwijst naar het vorige document in een geordende reeks LinkTypes van documenten. Sommige user agents ondersteunen ook het synoniem "Previous". Contents Verwijst naar een document dat dienst doet als inhoudstabel. Sommige user agents ondersteunen ook het synoniem ToC (van "Table of Contents"). Index Verwijst naar een document dat een index voorziet voor het huidige document. Glossary Verwijst naar een document dat een begrippenlijst voorziet voor begrippen van het huidige document. Copyright Verwijst naar een copyright statement voor het huidige document. Chapter Verwijst naar een document dat dienst doet als een hoofdstuk in een collectie van documenten. Section Verwijst naar een document dat dienst doet als een onderdeel van een collectie van documenten. Subsection Verwijst naar een document dat dienst doet als een subdeel van een collectie van documenten. Appendix Verwijst naar een document dat dienst doet als een appendix van een collectie van documenten. Help Verwijst naar een document dat hulp biedt (meer informatie, links naar andere bronnen van informatie, enz.) Bookmark Verwijst naar een bladwijzer (bookmark). Een bladwijzer is een link naar een bepaalde plaats binnen een lang document. Het title attribuut kan bijvoorbeeld gebruikt worden om de bladwijzer te labelen. Merk op dat verschillende bladwijzers gedefinieerd kunnen worden in elk document. Het MediaDesc attribuut is een door komma's gescheiden lijst van media omschrijvingen. Hier volgt een lijst van herkende media omschrijvingen: screen Bedoeld voor (non-paged) computerschermen. tty Bedoeld voor media die een raster gebruiken met een vaste karakterbreedte, zoals teletypes, terminals of draagbare toestellen met beperkte weergavemogelijkheden. tv Bedoeld voor televisietoestellen (lage resolutie, kleur, beperkte scrollbaarheid). projection Bedoeld voor projectors. handheld Bedoeld voor draagbare toestellen (handhelds) (klein scherm, monochrome, gebitmapte figuren, beperkte bandbreedte). print Bedoeld voor gepagineerd, opaak materiaal (afdrukken dus) en voor documenten die op het scherm bekeken worden in print preview mode. braille Bedoeld voor braille tastfeedback toestellen. aural Bedoeld voor spraaksynthesizers. all Geschikt voor alle toestellen. Toekomstige versies van XHTML kunnen nieuwe waarden MediaDesc introduceren en zouden geparameteriseerde waarden kunnen toelaten. Om de introductie van deze uitbreidingen te vergemakkelijken, moeten conforme user agenten in staat zijn om de media attribuutwaarde als volgt te verwerken (parsen): 1. De waarde is een door komma's gescheiden lijst. media="screen, 3d-glasses, print and resolution > 90dpi" wordt bijvoorbeeld gemapped naar: "screen" "3d-glasses" "print and resolution > 90dpi" 2. Elk deel van de lijst wordt afgekapt vlak voor het eerste karakter dat geen US ASCII letter [a-zA-Z] (ISO 10646 hex 41-5a, 61-7a), digit [0-9] (hex 30-39) of koppelteken (hex 2d) is. In het voorbeeld geeft dit: "screen" "3d-glasses" "print" 3. Vervolgens wordt een hoofdletterongevoelige match gemaakt met de set van media types hierboven gedefinieerd. User agenten mogen de delen die niet overeenkomen negeren. In het voorbeeld houden we screen en print over. Opmerking. Stylesheets kunnen media-afhankelijke variaties bevatten (zoals de CSS @media construct). In zulke gevallen kan het gepast zijn om "media =all" te gebruiken. De waarde kan een lengte of een relatieve lengte zijn. Een relatieve lengte heeft de vorm "i*", waar "i" een integer is. Wanneer user agenten de plaats verdelen voor de elementen die plaats willen innemen, verdelen ze eerst pixel en percentage lengtes. Daarna wordt de resterende beschikbare ruimte verdeeld onder de relatieve lengtes. Elke relatieve lengte MultiLength ontvangt een deel van de beschikbare ruimte die proportioneel is aan de integer die voorafgaat aan het "*". De waarde "*" is equivalent aan "1*". Als er dus 60 pixels plaats beschikbaar is nadat een user agent de ruimte ingedeeld heeft in pixel en percentage ruimte en de deelnemende relatieve lengtes zijn 1*, 2* en 3*, zal 1* 10 pixels toegewezen krijgen, zal 2* 20 pixels toegewezen kijgen en zal 3* 30 pixels toegewezen krijgen. MultiLengths Een door komma's gescheiden lijst van items van het type MultiLength. Number Eén of meer digits De waarde is een integer die het aantal pixels van de canvas Pixels aangeeft (scherm, papier). De waarde "50" betekent dus vijftig pixels. Raadpleeg [CSS2] voor normatieve informatie over de definitie van een pixel Script data kan de inhoud van het "script" element en de waarde van intrinsieke gebeurtenisattributen zijn. User agenten moeten script data niet evalueren als HTML opmaak, maar in de plaats de data doorgeven aan een script engine. Script De hoofdlettergevoeligheid van script data hangt af van de scripttaal. Merk op dat script data die elementinhoud is bepaalde tekens niet mag bevatten terwijl script data die de waarde is van een attribuut dit wel kan. Shape De vorm van een region. Text Arbitraire textuele data, waarschijnlijk bedoeld als leesbaar door de mens. URI Een Uniform Resource Identifier (Uniforme Bron Identificator) zoals volgens [URI]. URIs Een door spaties gescheiden lijst van Uniform Resource Identifiers zoals volgens [URI]. 4.4. Een Voorbeeld Abstracte Module Definitie Dit deel is informatief Dit deel definieert een voorbeeld abstracte module om aan te geven hoe voordeel kan bekomen worden van de syntaxregel hierboven gedefinieerd. Aangezien dit voorbeeld tracht alle verschillende syntactische elementen die gedefinieerd zijn te gebruiken, is het behoorlijk complex. Normale module definities zullen veel eenvoudiger zijn dan deze. Merk tot slot op dat deze module referentie de attribuut collectie Common gebruikt. Dit is een collectie die gedefinieerd wordt in de XHTML Modularisatie aanbeveling die alle basisattributen bevat die de meeste elementen nodig hebben. 4.4.1. XHTML Skiing Module De XHTML Skiing Module definieert opmaak gebruikt wanneer kenmerken van een skihut omschreven worden. De elementen en attributen in deze module zijn: Elementen Attributen Minimale Inhoudsmodel vakantieoord Common, href (CDATA) omschrijving, Aspen+ hut Common omschrijving, (Aspen - lift)+ lift Common, href omschrijving? vakantiehuisjeCommon, href omschrijving? kamer Common, href omschrijving? hal Common, href omschrijving? open haard Common, href omschrijving? omschrijving Common PCDATA* Deze module definieert ook de inhoudset Aspen met het minimale inhoudsmodel hut | lift | vakantiehuisje | kamer | hal | open haard. 5. XHTML Abstracte Modules Dit deel is normatief. Dit deel specificeert de inhoud van de XHTML abstracte modules. Deze modules zijn abstracte definities van verzamelingen van elementen, attributen en hun inhoudsmodellen. Deze abstracte modules kunnen gekoppeld worden op elk passend specificatiemechanisme. XHTML DTD Module Implementaties koppelen deze modules bijvoorbeeld aan DTD's zoals omschreven in [XML]. Inhoudontwikkelaars en toestelontwerpers zouden dit deel moeten zien als een leidraad voor de definitie van de functionaliteit die geboden wordt door de verschillende XHTML-gedefinieerde modules. Wanneer men documenten ontwerpt of een profiel definieert voor een classe van documenten, kunnen inhoudontwikkelaars beslissen welke van deze modules essentieel is om hun boodschap over te brengen. Wanneer men clients ontwerpt zouden toestelontwerpers hun toestelprofielen moeten ontwerpen door te kiezen van de abstracte modules die hier gedefinieerd worden. Behalve wanneer door dit document opgeheven (overriden), zijn de semantiek van deze elementen en attributen gedefinieerd in [HTML4]. 5.1. Attribuut Verzamelingen Veel van de abstracte modules in dit deel definiëren de vereiste attributen voor elementen. De oinderstaande tabel definieert enkele verzamelingen van attributen waarnaar verwezen wordt doorheen de modules. Deze uitdrukkingen zouden op geen enkele manier beschouwd moeten worden als normatief of verplicht. Ze vormen een editorieel gemak voor dit document. Wanneer ze gebruikt worden in de rest van dit deel, is het de uitbreiding van de term die normatief is en niet de term zelf. De volgende basisattribuutsets worden gebruikt voor veel elementen. In elk geval waar ze gebruikt worden, is hun gebruik geïdentificeerd via hun collectienaam in plaats van via een opsommingslijst. Collectienaam Attributen in Collectie Core class (NMTOKENS), id (ID), title (CDATA) I18N xml:lang (NMTOKEN) onclick (Script), ondblclick (Script), onmousedown (Script), Events onmouseup (Script), onmouseover (Script), onmousemove (Script), onmouseout (Script), onkeypress (Script), onkeydown (Script), onkeyup (Script) Style style (CDATA) Common Core + Events + I18N + Style Merk op dat de Gebeurteniscollectie (Events collection) enkel geddefinieerd is wanneer de Intrinsieke Gebeurtenismodule (Intrinsic Events Module) geselecteerd is. Anders is de Gebeurteniscollectie leeg. Merk ook op dat de Stijlcollectie (Style collection) enkel gedefinieerd is wanneer de Stijlattribuutcollectie (Style Attribute Module) geselecteerd is. Anders is de Stijlcollectie leeg. 5.2. Kern Modules De kernmodules zijn modules die vereist zijn in elk XHTML Familie Conform Document Type. 5.2.1. Structuur Module De Structuur Module definieert de hoofd structurele elementen voor XHTML. Deze elementen gedragen zich effectief als de basis voor het inhoudsmodel van veel XHTML familie document types. De elementen en attributen opgenomen in deze module zijn: Elementen Attributen Minimaal Inhoudsmodel body Common (Heading | Block | List)* head I18N, profile (URI) title html I18N, version (CDATA), xmlns (URI = head, body "http://www.w3.org/1999/xhtml") title I18N PCDATA Deze module is de basis structurele definitie voor XHTML inhoud. Het html element gedraagt zich als het wortelelement voor alle XHTML Familie Document Types. Merk op dat de waarde van het xmlns attribuut gedefinieerd is om "http://www.w3.org/1999/xhtml" te zijn. Merk eveneens op dat omdat het xmlns attribuut speciaal behandeld wordt door XML namespace-bewuste parsers [XMLNAMES], het legaal is om het aanwezig te hebben als een attribuut van elk element. Elke keer dat het xmlns attribuut gebruikt wordt in de context van een XHTML module, met een prefix of niet, zal de waarde van het attribuut de XHTML namespace zijn zoals hier gedefinieerd. Zie Definitie van de Namespace van een Module voor meer over regels wat betreft namespace gebruik met XHTML familie modules. Implementatie: DTD 5.2.2. Tekst Module Deze module definieert alle basis tekstcontainer elementen, attributen en hun inhoudsmodel: Element Attributen Minimaal Inhoudsmodel abbr Common (PCDATA | Inline)* acronym Common (PCDATA | Inline)* address Common (PCDATA | Inline)* blockquoteCommon, cite (URI) (PCDATA | Heading | Block | List)* br Core EMPTY cite Common (PCDATA | Inline)* code Common (PCDATA | Inline)* dfn Common (PCDATA | Inline)* div Common (PCDATA | Flow)* em Common (PCDATA | Inline)* h1 Common (PCDATA | Inline)* h2 Common (PCDATA | Inline)* h3 Common (PCDATA | Inline)* h4 Common (PCDATA | Inline)* h5 Common (PCDATA | Inline)* h6 Common (PCDATA | Inline)* kbd Common (PCDATA | Inline)* p Common (PCDATA | Inline)* pre Common, xml:space="preserve" (PCDATA | Inline)* q Common, cite (URI) (PCDATA | Inline)* samp Common (PCDATA | Inline)* span Common (PCDATA | Inline)* strong Common (PCDATA | Inline)* var Common (PCDATA | Inline)* Het minimale inhoudsmodel voor deze module definieert enkele inhoudsets: Heading (Koppen) h1 | h2 | h3 | h4 | h5 | h6 Block (Blokken) address | blockquote | div | p | pre Inline (In de lijn) abbr | acronym | br | cite | code | dfn | em | kbd | q | samp | span | strong | var Flow (Stroming) Heading | Block | Inline Implementatie: DTD 5.2.3. Hypertext Module De Hypertext Module biedt het element dat gebruikt wordt om hypertext links te definiëren naar andere bronnen. Deze module ondersteunt het volgende element en attributen: Element Attributen Minimaal Inhoudsmodel Common, accesskey (Character), charset (Charset), href (URI), hreflang a (LanguageCode), rel (LinkTypes), rev (PCDATA | Inline - (LinkTypes), tabindex (Number), type a)* (ContentType) Deze module voegt het a element toe aan de Inline inhoudset van de Tekstmodule. Implementatie: DTD 5.2.4. Lijst Module Zoals de naam voorstelt biedt de Lijst Module lijst-georiënteerde elementen. De Lijst Module ondersteunt de volgende elementen en attributen: ElementenAttributen Minimaal Inhoudsmodel dl Common (dt | dd)+ dt Common (PCDATA | Inline)* dd Common (PCDATA | Flow)* ol Common li+ ul Common li+ li Common (PCDATA | Flow)* Deze module definieert ook de inhoudset Lijst met het minimale inhoudsmodel (dl | ol | ul)+ en voegt deze set toe aan de Stromingsinhoudset van de Tekstmodule. Implementatie: DTD 5.3. Applet Module Deze module wordt afgeraden. GElijkaardige functionaliteit kan gevonden worden in de Object Module. De Applet Module biedt elementen voor verwijzing naar externe toepassingen. De Applet Module ondersteunt de volgende elementen en attributen: Element Attributen Minimaal Inhoudsmodel Core, alt* (Text), archive (CDATA), code applet (CDATA), codebase (URI), height* (Length), (PCDATA | Flow | object (CDATA), width* (Length) param)* id (ID), name* (CDATA), type param (ContentType), value (CDATA), valuetype EMPTY ("data"* | "ref" | "object") Wanneer de Applet Module gebruikt wordt, voegt dit het applet element toe aan de Inline inhoudset van de Tekstodule. Implementatie: DTD 5.4. Tekst Uitbreiding Modules Dit deel definieert een keuze van aanvullende textuele opmaakmodules. 5.4.1. Presentatie Module Deze module definieert elementen, attributen en een minimaal inhoudsmodel voor eenvoudige presentatie-gerelateerde opmaak: ElementAttributen Minimaal Inhoudsmodel b Common (PCDATA | Inline)* big Common (PCDATA | Inline)* hr Common EMPTY i Common (PCDATA | Inline)* small Common (PCDATA | Inline)* sub Common (PCDATA | Inline)* sup Common (PCDATA | Inline)* tt Common (PCDATA | Inline)* Wanneer deze module gebruikt wordt, wordt het hr element toegevoegd aan de Block inhoudset van de Tekstmodule. Aanvullend worden de b, big, i, small, sub, sup en tt elementen toegevoegd aan de Inline inhoudset van de Tekstmodule. Implementatie: DTD 5.4.2. Bewerkingsmodule Deze module definieert elementen en attributen voor gebruik in bewerkingsgerelateerde opmaak: Element Attributen Minimaal Inhoudsmodel del Common, cite (URI), datetime (Datetime) (PCDATA | Flow)* ins Common, cite (URI), datetime (Datetime) (PCDATA | Flow)* Wanneer deze module gebruikt wordt, worden de del en ins elementen toegevoegd aan de Inline inhoudset van de Tekstmodule. Implementatie: DTD 5.4.3. Bi-directionele Tekst Module De Bi-directional Tekst module definieert een element dat gebruikt kan worden om de bi-directionele regels voor de inhoud van een element vast te leggen. Elements Attributes Minimaal Inhoudsmodel bdo Core, dir* ("ltr" | "rtl") (PCDATA | Inline)* Wanneer deze module gebruikt wordt, wordt het bdo element toegevoegd aan de Inline inhoudset van de Tekstmodule. Deze module selecteren voegt ook het dir* ("ltr" | "rtl") attribuut toe aan de I18N attribuut verzameling. Implementatie: DTD 5.5. Formulieren Modules 5.5.1. Basis Formulieren Module De Basis Formulieren Module biedt de formulier-gerelateerde elementen, maar enkel in een beperkte vorm. De Basis Formulieren Module ondersteunt de volgende elementen, attributen en minimaal inhoudsmodel: Elementen Attributen Minimaal Inhoudsmodel form Common, action* (URI), method ("get"* | (Heading | List | Block "post"), enctype (ContentType) - form)+ Common, accesskey (Character), checked ("checked"), maxlength (Number), name (CDATA), size (Number), src (URI), input tabindex (Number), type ("text"* | EMPTY "password" | "checkbox" | "radio" | "submit" | "reset" | "hidden" ), value (CDATA) label Common, accesskey (Character), for (PCDATA | Inline - (IDREF) label)* Common, multiple ("multiple"), name select (CDATA), size (Number), tabindex option+ (Number) option Common, selected ("selected"), value PCDATA (CDATA) Common, accesskey (Character), cols* textarea (Number), name (CDATA), rows* (Number), PCDATA tabindex (Number) Deze module definieert twee inhoudsets: Form form Formctrl input | label | select | textarea Als deze module gebruikt wordt, voegt het de Formulier inhoudset aan de Block inhoudset toe en voegt het de Formctrl inhoudset toe aan de Inline inhoudset zoals deze gedefinieerd zijn in de Tekstmodule. Implementatie: DTD 5.5.2. Formulieren Module De Formulieren Module biedt alle formulierkenmerken als in HTML 4.0. De Formulieren Module ondersteunt: Elementen Attributen Minimaal Inhoudsmodel Common, accept (ContentTypes), form accept-charset (Charsets), action* (Heading | List | Block - (URI), method ("get"* | "post"), form | fieldset)+ enctype (ContentType) Common, accept (ContentTypes), accesskey (Character), alt (Text), checked ("checked"), disabled ("disabled"), maxlength (Number), name (CDATA), readonly input ("readonly"), size (Number), src EMPTY (URI), tabindex (Number), type ("text"* | "password" | "checkbox" | "button" | "radio" | "submit" | "reset" | "file" | "hidden" | "image"), value (CDATA) Common, disabled ("disabled"), select multiple ("multiple"), name (optgroup | option)+ (CDATA), size (Number), tabindex (Number) Common, disabled ("disabled"), option label (Text), selected PCDATA ("selected"), value (CDATA) Common, accesskey (Character), cols* (Number), disabled textarea ("disabled"), name (CDATA), PCDATA readonly ("readonly"), rows* (Number), tabindex (Number) Common, accesskey (Character), disabled ("disabled"), name (PCDATA | Heading | List | button (CDATA), tabindex (Number), type Block - Form | Inline - ("button" | "submit"* | "reset"), Formctrl)* value (CDATA) fieldset Common (PCDATA | legend | Flow)* label Common, accesskey (Character), for (PCDATA | Inline - label)* (IDREF) legend Common, accesskey (Character) (PCDATA | Inline)+ optgroup Common, disabled ("disabled"), option+ label* (Text) Deze module definieert twee inhoudsets: Form form | fieldset Formctrl input | select | textarea | label | button Wanneer deze module gebruikt wordt, voegt het de Formulieren inhoudset toe aan de Block inhoudset en het voegt de Formctrl inhoudset toe aan de Inline inhoudset zoals deze gedefinieerd zijn in de Tekstmodule. De Formulieren Module is een superset van de Basis Formulieren Module. Deze modules kunnen niet samen gebruikt worden in eenzelfde document type. Implementatie: DTD 5.6. Tabel Modules 5.6.1. Basis Tabellen Module De Basis Tabellen Module biedt tabel-gerelateerde elementen, maar enkel in een beperkte vorm. De Basis Tabellen Module ondersteunt: Elementen Attributen Minimaal Inhoudsmodel caption Common (PCDATA | Inline)* table Common , summary ( Text ), width ( caption?, tr+ Length ) Common, abbr (Text), align ("left" | "center" | "right"), axis (CDATA), td colspan (Number), headers (IDREFS), (PCDATA | Flow - rowspan (Number), scope ("row" | "col"), table)* valign ("top" | "middle" | "bottom") Common, abbr (Text), align ("left" | "center" | "right"), axis (CDATA), th colspan (Number), headers (IDREFS), (PCDATA | Flow - rowspan (Number), scope ("row" | "col" table)* ), valign ("top" | "middle" | "bottom") Common, align ("left" | "center" | tr "right"), valign ("top" | "middle" | (td | th)+ "bottom") Wanneer deze module gebruikt wordt zal het table element toegevoegd worden aan de Block inhoudset zoals gedefinieerd in de Tekstmodule. Implementatie: DTD 5.6.2. Tabellen Module Zoals de naam voorstelt, biedt de Tabellen Module tabel-gerelateerde elementen die beter geschikt zijn om geraadpleegd te worden door niet-visuele user agents. De Tabellen Module ondersteunt de volgende elementen, attributen en inhoudsmodel: Elementen Attributen Minimaal Inhoudsmodel caption Common (PCDATA | Inline)* Common, border (Pixels), cellpadding (Length), cellspacing (Length), datapagesize (CDATA), frame caption?, ( col* | colgroup* table ("void" | "above" | below" | ), (( thead?, tfoot?, tbody+ ) "hsides" | "lhs" | "rhs" | "vsides" | "box" | "border"), | ( tr+ )) rules ("none" | "groups" | "rows" | "cols" | "all"), summary (Text), width (Length) Common, abbr (Text), align ("left" | "center" | "right" | "justify" | "char"), axis (CDATA), char (Character), td charoff (Length), colspan (PCDATA | Flow)* (Number), headers (IDREFS), rowspan (Number), scope ("row", "col", "rowgroup", "colgroup"), valign ("top" | "middle" | "bottom" | "baseline") Common, abbr (Text), align ("left" | "center" | "right" | "justify" | "char"), axis (CDATA), char (Character), th charoff (Length), colspan (PCDATA | Flow)* (Number), headers (IDREFS), rowspan (Number), scope ("row", "col", "rowgroup", "colgroup"), valign ("top" | "middle" | "bottom" | "baseline") Common, align ("left" | "center" | "right" | "justify", "char"), tr char (Character), charoff (td | th)+ (Length), valign ("top" | "middle" | "bottom" | "baseline") Common, align ("left" | "center" | "right" | "justify", "char"), col char (Character), charoff EMPTY (Length), span (Number), valign ("top" | "middle" | "bottom" | "baseline"), width (MultiLength) Common, align ("left" | "center" | "right" | "justify", "char"), colgroup char (Character), charoff col* (Length), span (Number), valign ("top" | "middle" | "bottom" | "baseline"), width (MultiLength) Common, align ("left" | "center" | "right" | "justify", "char"), tbody char (Character), charoff tr+ (Length), valign ("top" | "middle" | "bottom" | "baseline") Common, align ("left" | "center" | "right" | "justify", "char"), thead char (Character), charoff tr+ (Length), valign ("top" | "middle" | "bottom" | "baseline") Common, align ("left" | "center" | "right" | "justify", "char"), tfoot char (Character), charoff tr+ (Length), valign ("top" | "middle" | "bottom" | "baseline") Wanneer deze module gebruikt wordt zal het table element toegevoegd worden aan de Block inhoudset van de Tekstmodule. Implementatie: DTD 5.7. Figuur Module De Figuur Module biedt basis figuurembedding en kan gebruikt worden in sommige implementaties onafhankelijk van client side image maps. De Figuren Module ondersteunt het volgende element en de volgende attributen: Element Attributen Minimaal Inhoudsmodel img Common, alt* (Text), height (Length), EMPTY longdesc (URI), src* (URI), width (Length) Wanneer deze module gebruikt wordt, zal het img element toegevoegd worden aan de Inline inhoudset van de Tekstmodule. Implementatie: DTD 5.8. Client-side Image Map Module De Client-side Image Map Module biedt elementen voor client side image maps. Het vereist dat de Figuren Module (of een andere module die het img element ondersteunt) opgenomen is. De Client-side Image Map Module ondersteunt de volgende elementen: Elementen Attributen Minimaal Inhoudsmodel a& coords (CDATA), shape ("rect" | n/a "circle" | "poly" | "default") Common, accesskey (Character), alt* (Text), coords (CDATA), href (URI), area nohref ("nohref"), shape ("rect"* | EMPTY "circle" | "poly" | "default"), tabindex (Number) img& usemap (IDREF) n/a input& usemap (IDREF) n/a map I18N, Events, class (NMTOKEN), id* ((Heading | Block) | area)+ (ID), title (CDATA) object& usemap (IDREF) Note: Only when the object module is included Wanneer deze module gebruikt wordt, zal het map element toegevoegd worden aan de Inline inhoudset van de Tekstmodule. Implementatie: DTD 5.9. Server-side Image Map Module De Server-side Image Map Module biedt ondersteuning voor figuurselectie en transmissie van selectiecoördinaten. Het vereist dat de Figuur Module (of een andere module die het img element ondersteunt) opgenomen wordt. De Server-side Image Map Module ondersteunt de volgende attributen: Elementen Attributen Minimaal Opmerkingen Inhoudsmodel img& ismap n/a ("ismap") Als de Formulieren of de Basis input& ismap n/a Formulieren Module ("ismap") geselecteerd is. Implementatie: DTD 5.10. Object Module De Object Module biedt elementen voor general-purpose object opname. De Object Module ondersteunt: Elementen Attributen Minimaal Inhoudsmodel Common, archive (URIs), classid (URI), codebase (URI), codetype (ContentType), object data (URI), declare ("declare"), height (PCDATA | Flow | (Length), name (CDATA), standby (Text), param)* tabindex (Number), type (ContentType), width (Length) id (ID), name* (CDATA), type param (ContentType), value (CDATA), valuetype EMPTY ("data"* | "ref" | "object") Als deze module gebruikt wordt, zal het object element toegevoegd worden aan de Inline inhoudset van de Tekstmodule. Implementatie: DTD 5.11. Frames Module Zoals de naam voorstelt, biedt de Frames Module frame-gerelateerde elementen. De Frames Module ondersteunt: Elementen Attributen Minimaal Inhoudsmodel frameset Core , cols ( MultiLength ), rows ( (frameset | frame)+, MultiLength ) noframes? Core , frameborder ("1" | "0"), longdesc ( URI ), marginheight ( Pixels frame ), marginwidth ( Pixels ), noresize EMPTY ("noresize"), scrolling ("yes" | "no" | "auto"*), src ( URI ) noframes Common body Als deze module geselecteerd wordt, zal het minimale inhoudsmodel van het html element van de Structuur Module gewijzigd worden in (head, frameset). Implementatie: DTD 5.12. Doel Module De inhoud van een frame kan doelen specificeren voor een selectie. Deze module voegt het target element toe aan de area en link definiërende elementen. Dit wordt gedefinieerd als een afgescheiden module zodat het opgenomen kan worden in documenten die opgenomen worden in frames en documenten die de target eigenschap gebruiken om een nieuw venster te openen. Elementen Attributen OPmerkingen a& target ( CDATA ) area& target ( CDATA ) Als de Client-side Image Map Module geselecteerd wordt. base& target ( CDATA ) Als de Erfenis Module geselecteerd wordt. link& target ( CDATA ) Als de Link Module geselecteerd wordt. form& target ( CDATA ) Als de Basis Formulieren of Formulieren module geselecteerd wordt. Implementatie: DTD 5.13. Iframe Module De Iframe Module definieert een element voor de definitie van inline frames. Het element en attribuut opgenomen in deze module zijn: Elementen Attributen Minimaal Inhoudsmodel Core, frameborder ("1" | "0"), height (Length), longdesc (URI), marginheight iframe (Pixels), marginwidth (Pixels), scrolling (PCDATA | Flow)* ("yes" | "no" | "auto"*), src (URI), width (Length) Als deze module gebruikt wordt, zal het iframe element toegevoegd worden aan de Inline inhoudset zoals deze gedefinieerd wordt door de Tekstmodule. Implementatie: DTD 5.14. Intrinsieke Gebeurtenis Module Intrinsieke gebeurtenissen zijn attributen die gebruikt worden in verbinding met elementen waar specifieke gebeurtenissen kunnen voorkomen wanneer bepaalde acties uitgevoerd worden door de gebruiker. De attributen aangegeven in de volgende tabel worden toegevoegd aan de attribuutset voor hun respectievelijke elementen enkel wanneer de modules die deze elementen definiëren geselecteerd worden. Merk ook op dat bij selectie van deze module de attribuut reeks Gebeurtenis gedefinieerd wordt zals hierboven beschreven. Attributen gedefinieerd door deze module zijn: Elementen Attributen Opmerkingen a& onblur (Script), onfocus (Script) area& onblur (Script), onfocus Als de Client-side Image Map (Script) Module ook gebruikt wordt. frameset&onload (Script), onunload ALs de Frames Module ook (Script) gebruikt wordt. Als de Basis Formulieren of form& onreset (Script), onsubmit Formulieren Module gebruikt (Script) wordt. body& onload (Script), onunload (Script) label& onblur (Script), onfocus Als de Formulieren Module (Script) gebruikt wordt. onblur (Script), onchange Als de Basis Formulieren of input& (Script), onfocus (Script), Formulieren Module gebruikt onselect (Script) wordt. Als de Basis Formulieren of select& onblur (Script), onchange Formulieren Module gebruikt (Script), onfocus (Script) wordt. onblur (Script), onchange Als de Basis Formulieren of textarea&(Script), onfocus (Script), Formulieren Module gebruikt onselect (Script) wordt. button& onblur (Script), onfocus Als de Formulieren Module (Script) gebruikt wordt. Implementatie: DTD 5.15. Meta informatie Module De Meta informatie Module definieert een element dat in het declaratieve deel van een document informatie geeft (in XHTML binnen het head element). Deze module neemt het volgende element op: Elementen Attributen Minimaal Inhoudsmodel meta I18N, content* (CDATA), http-equiv EMPTY (NMTOKEN), name (NMTOKEN), scheme (CDATA) Als deze module geselecteerd wordt, zal het meta element toegevoegd worden aan het inhoudsmodel van het head element zoals gedefinieerd in de Structuur Module. Implementatie: DTD 5.16. Scripting Module De Scripting Module definieert elementen die gebruikt worden om informatie te bevatten over uitvoerbare scripts of het gebrek aan ondersteuning voor uitvoerbare scripts. Elementen en attributen opgenomen in deze module zijn: Elementen Attributen Minimaal Inhoudsmodel noscript Common (Heading | List | Block)+ charset (Charset), defer ("defer"), src script (URI), type* (ContentType), PCDATA xml:space="preserve" Als deze module gebruikt wordt, wullen de script en noscript elementen toegevoegd worden aan de Block en Inline inhoudsets van de Tekstmodule. Bovendien zal het script element toegevoegd worden aan het inhoudsmodel van het head element dat gedefinieerd wordt in de Structuur Module. Implementatie: DTD 5.17. Style Sheet Module De Style Sheet Module definieert een element dat gebruikt wordt wanneer interne style sheets gedeclareerd worden. Het element en de attributen die gedefinieerd worden door deze module zijn: Elementen Attributen Minimaal Inhoudsmodel style I18N, media (MediaDesc), title (Text), PCDATA type* (ContentType), xml:space="preserve" Als deze module gebruikt wordt, zal het style element toegevoegd worden aan het inhoudsmodel van het head element van de Structuur Module. Implementatie: DTD 5.18. Style Attribuut Module De Style Attribuut Module definieert het style attribuut. Als deze module geselecteerd wordt, activeert het de Style Attribuut Collectie. Implementatie: DTD 5.19. Link Module De Link Module definieert een element dat gebruikt kan worden om links te definiëren naar externe bronnen. Deze bronnen worden dikwijls gebruikt om de mogelijkheden van de user agent om het geassocieerde XHTML document te verwerken te vergroten. Het element en de attributen opgenomen in deze module zijn: Elementen Attributen Minimaal Inhoudsmodel Common, charset (Charset), href (URI), link hreflang (LanguageCode), media EMPTY (MediaDesc), rel (LinkTypes), rev (LinkTypes), type (ContentType) Als deze module gebruikt wordt, zal het link element toegevoegd worden aan het inhoudsmodel van het head element zoals gedefinieerd in de Structuur Module. Implementatie: DTD 5.20. Base Module De Base Module definieert een element dat kan gebruikt worden om een base URI te definiëren waartegen relatieve URI's in het document zullen worden opgelost. Het element en het attribuut opgenomen in deze module zijn: Elementen Attributen Minimaal Inhoudsmodel base href* (URI) EMPTY Als deze module gebruikt wordt, zal het base element toegevoegd worden aan het inhoudsmodel van het head element van de Structuur Module. Implementatie: DTD 5.21. Naam Identificatie Module Deze module wordt afgeraden. De Naam Identificatie Module definieert de attribuutname voor een reeks elementen. Het name attribuut werd historisch gezien gebruikt om bepaalde elementen te identificeren binnen HTML documenten. Hoewel het name attribuut verdrongen wordt door het id attribuut in alle elementen, kan het zijn dat bepaalde opmaaktalen beide willen blijven ondersteunen. Zulke opmaaktalen kunnen dit doen door deze module op te nemen. Merk op dat door opname van deze module, zowel het name als het id attribuut gedefinieerd zijn voor de aangegeven elementen. In deze situatie zal, als het name attribuut gedefinieerd is voor een element, het id attribuut ook moeten gedefinieerd worden. Bovendien moeten deze attributen dezelfde waarde hebben. Tot slot zal van documenten die dit attribuut gebruiken en served worden als Internet Media Type "text/xml" of "application/xml", de waarde van het name attribuut op deze elementen niet gebruikt worden als een fragment identificator. Elementen Attributen Opmerkingen a& name (CDATA) applet& name (CDATA) Als de Applet Module geselecteerd is. form& name (CDATA) Als de Formulieren of Basis Formulieren Module geselecteerd is. frame& name (CDATA) Als de Frames Module geselecteerd is. iframe& name (CDATA) Als de Iframe Module geselecteerd is. img& name (CDATA) Als de Image Module geselecteerd is. map& name (CDATA) Als de Client-side Image Map Module geselecteerd is. Implementatie: DTD 5.22. Erfenis Module The Erfenis Module definieert elementen en attributen die reeds afgeraden waren in voorgaande versies van HTML en XHTML. Deze blijven afgeraden in XHTML Modularisatie. Opmaaktaal auteurs zouden deze elementen en attributen best niet meer gebruiken. De volgende tabbel definieert de elementen en attributen die gedefinieerd worden wanneer de Erfenis Module geselecteerd is. Elementen Attributen Minimaal Inhoudsmodel basefont color (Color), face (CDATA), id (ID), size EMPTY (CDATA) center Common (PCDATA | Flow)* dir Common, compact ("compact") (li)+ font Core, I18N, color (Color), face (CDATA), (PCDATA | Inline)* size (CDATA) isindex Core, I18N, prompt (Text) EMPTY menu Common, compact ("compact") (li)+ s Common (PCDATA | Inline)* strike Common (PCDATA | Inline)* u Common (PCDATA | Inline)* De volgende tabel toont bijkomende attributen voor elementen die elders gedefinieerd zijn wanneer de Erfenis module geselected is. Elementen Attributen Opmerkingen alink (Color), background (URI), body& bgcolor (Color), link (Color), text (Color), vlink (Color) br& clear ("left" | "all" | "right" | "none"*) caption& align ("top" | "bottom" | "left" | "right") div& align ("left" | "center" | "right" | "justify") dl& compact ("compact"), type (CDATA) h1-h6& align ("left" | "center" | "right" | "justify") align ("left" | "center" | hr& "right" | "justify"), noshade ("noshade"), size (Pixels), width (Length), align ("left" | "center" | img& "right" | "justify"), border (Pixels), hspace (Pixels), vspace (Pixels) Als de Basis Formulieren of input& align ("top" | "middle" | Formulieren Module "bottom" | "left" | "right") geselecteerd is. legend& align ("left" | "center" | Als de Formulieren Module "right" | "justify") geselecteerd is. li& type (CDATA), value (Number) ol& compact ("compact"), start (Number), type (CDATA) p& align ("left" | "center" | "right", "justify") pre& width (Number) script& language (CDATA) Als de Scripting module geselecteerd is. table& align ("left" | "center" | Als de Tabbellen module "right"), bgcolor (Color) geselecteerd is. tr& bgcolor (Color) Als de Tabbellen module geselecteerd is. bgcolor (Color), height (Pixels) th& nowrap ("nowrap"), width Als de Tabbellen module (Length) geselecteerd is. bgcolor (Color), height (Length) td& nowrap ("nowrap"), width Als de Tabbellen module (Pixels) geselecteerd is. ul& compact ("compact"), type (CDATA) Implementatie: DTD A. Schema Modules bouwen Deze appendix is normatief. Deze appendix zal instructies bevatten waarin aangegeven wordt hoe XML Schema modules gedefinieerd moeten worden die compatibel zijn met de uitvoering van Gemodulariseerde XHTML via XML Schema [XMLSCHEMA] zodra XML Schema een W3C Aanbeveling wordt. B. Ontwerpen van Schema met gedefinieerde en uitbreidingsmodules Deze appendix is normatief. Deze appendix zal instructies bevatten die aangeven hoe volledige opmaaktalen gedefinieerd kunnnen worden door gebruik te maken van XHTML modules via XML Schema [XMLSCHEMA] zodra XML Schema een W3C Aanbeveling wordt. C. XHTML Schema Module Implementaties Deze appendix is normatief. Deze appendix zal uitvoeringen van de modules gedefinieerd in XHTML Abstracte Modules via XML Schema [XMLSCHEMA] bevatten zodra XML Schema een W3C Aanbeveling wordt. D. DTD Modules bouwen Deze appendix is normatief. XHTML modules worden geïmplementeerd als DTD fragmenten. Wanneer deze fragmenten op een specifieke mannier samengebracht worden (omschreven in DTD's ontwerpen met gedefinieerde en uitbreidingsmodules), is de resulterende DTD een representatie van een compleet document type. Deze representatie kan dan gebruikt worden voor validatie van gevallen van het document type. De sleutel in combinatie van deze fragmenten in een betekenisvolle DTD zijn de regels die gebruikt worden om de fragmenten te definiëren. Dit deel definieert deze regels. Als deze regels gevolgd worden, kunnen DTD auteurs er zeker van zijn dat hun modules op een zuivere manier zullen interfacen met andere XHTML-compatiebele modules. Modules conform aan deze regels moeten ook voldoen aan de conformiteitseisen gedefinieerd in XHTML Family Module Conformiteit opdat ze XHTML Family Modules genoemd kunnen worden. D.1. Parameter Entiteits Naamgeving Deze specificatie classificeert parameter entiteiten in zeven categorieën en benoemt deze op consequente manier door het gebruik van de volgende achtervoegsels: .mod parameter entiteiten gebruiken het achtervoegsel .mod als ze gebruikt worden om een DTD module (een collectie van elementen, attributen, parameter entiteiten, enz) te representeren. In deze specificatie is elke module een atomaire eenheid en kan voorgesteld worden als een afzonderlijk bestand. .module parameter entiteiten gebruiken het achtervoegsel .module als ze gebruikt worden om de opname van een DTD module te controleren door één van beide conditionele sectie sleutelwoorden INCLUDE of IGNORE op te nemen. .qname parameter entiteiten gebruiken het achtervoegsel .qname als ze gebruikt worden om de bevoegde naam van een element voor te stellen. Raadpleeg Definitie van de Namespace van een Module voor meer informatie over bevoegde namen. .content parameter entiteiten gebruiken het achtervoegsel .content als ze gebruikt worden om het inhoudsmodel van een element type voor te stellen. .class parameter entiteiten gebruiken het achtervoegsel .class als ze gebruikt worden om elementen van dezelfde class voor te stellen. .mix parameter entiteiten gebruikten het achtervoegsel .mix als ze gebruikt worden om een verzameling van element types van verschillende classes voor te stellen. .attrib parameter entiteiten gebruiken het achtervoegsel .attrib als ze gebruikt worden om een groep van tokens voor te stellen die één of meer complete attribuutspecificaties voorstellen binnen een ATTLIST declaratie. In HTML 4 wordt de %block; parameter entiteit bijvoorbeeld gedefinieerd om de heterogene collectie van element types voor te stellen die block-level elementen zijn. In deze specificatie is de overeenkomende parameter entiteit %Block.mix;. Wanneer parameter entiteiten gedefinieerd worden in de classes die hier gedefinieerd worden, zouden de modules de namen van de entiteiten moeten omvatten door unieke voorvoegsels te gebruiken. Het inhoudsmodel voor het element mijnelement in de module mijnmodule zou MIJNMODULE.mijnelement.inhoud genoemd kunnen worden. Andere schema's zijn mogelijk. Onafhankelijk van het gebruikte scheam zouden module auteurs ernaar moeten streven dat parameter entiteiten die ze definië:ren uniek benoemd worden zodat ze niet botsen met andere parameter entiteiten en zodat de interface methodes voor de module duidelijk zijn voor de gebruikers ervan. D.2. Definitie van de Namespace van een Module XHTML vereist dat de elementen en attributen die gedeclareerd worden in een module in een gedefinieerde XML namespace [XMLNAMES] zitten. De identificatie van deze namespace is een willekeurige URI. XHTML vereist dat wanneer een module geïmplementeerd wordt door gebruik van een XML DTD, de module de namespace declareert op een speciale mannier. Het doel hiervan is de selectie toelaten, in document parse/validatie tijd, van het gebruik van namespace voorvoegsels en van het voorvoegsel dat gebruikt wordt om elementen en attributen van de module te identificeren. Inhoudontwikkelaars die documenten wensen te ontwerpen gebaseerd op hybride document types kunnen kiezen om XML namespace voorvoegsels te gebruiken op elementen van de XHTML namespace, op elementen van andere namespaces of op beide. Om te verzekeren dat zulke documenten XHTML conform zijn en backward compatible aijn met niet-namespace bewuste toepassingen, beveelt W3C aan dat inhoudontwikkelaars geen XML namespace voorvoegsels gebruiken op elementen van de XHTML namespace. Als inhoudontwikkelaars interesse hebben om hun inhoud verwerkt te laten worden door namespace-bewuste processors, raad W3C verder aan dat elementen in niet-XHTML namespaces gespecificeerd worden door gebruik van een XML namespace voorvoegsel in plaats van vertrouwen op standaard XML namespace mechanismen. Elke XHTML-conforme module geïmplementeerd als een XML DTD moet een standaard XML namespace voorvoegsel definiëren, een methode voor wijziging van dit voorvoegsel binnen een document en een kenmerkend deel dat zich baseert op de verwerking van het voorvoegsel. Merk op dat het geldig is en verwacht wordt dat meerdere modules deel uitmaken van dezelfde namespace als ze gerelateerd zijn. Alle XHTML modules zijn bijvoorbeeld deel van dezelfde namespace. D.2.1. Kwalificerende Names sub-module Om te beginnen moet je een kwalificerende names sub-module definiëren (een sub-module is enkel een bestand entiteit die gescheiden is zodat het opgenomen kan worden in de allerbeste DTD op het gepaste punt). De kwalificerende names sub-module wordt opgebouwd door gebruik te maken van de volgende stappen (waar de string MODULE vervangen is door een gepaste string voor de nieuwe module): 1. Definieer een parameter entiteit MODULE.prefixed die aangeeft of de elementen in de module gebruik gaan maken van XML namespace voorvoegselnamen of niet. De standaard waarde van deze parameter entiteiten zou "%NS.prefixed;" moeten zijn. De NS.prefixed parameter entiteit wordt gedefinieerd door het XHTML framework zodat deze standaard wordt GENEGEERD en kan gebruikt worden in een document om te schakelen tussen voorvoegsels voor alle opgenomen namespaces (inclusief van de XHTML modules). 2. Definieer een parameter entiteit MODULE.xmlns die de namespace identificator voor deze module bevat. 3. Definieer een parameter entiteit MODULE.prefix die de standaard voorvoegsel string bevat die gebruikt wordt wanneer voorvoeging geactiveerd is. 4. Definieer een parameter entiteit MODULE.pfx die "%MODULE.prefix;:" is als voorvoeging geactiveerd is en "" is wanneer dit niet het geval is. 5. Definieer een parameter entiteit MODULE.xmlns.extra.attrib dat de declaratie van alle XML namespace attributen voor namespaces waarnaar verwezen wordt door deze module bevat (zoals xmlns:xlink). Als %MODULE.prefixed ingesteld is op INCLUDE, zou dit attribuut de xmlns:%MODULE.prefix; declaratie evenens moeten opnemen. 6. Definieer een parameter entiteit XHTML.xmlns.extra.attrib als MODULE.xmlns.extra.attrib. Hieraan wordt gewoonlijk voorbijgegaan door het document type stuurbestand. Als dit niet het geval is neemt deze definitie de standaard waarde over. 7. Maak voor elk van de elementen gedefinieerd door de module, een parameter entiteit van de vorm "MODULE.NAME.qname" om de gekwalificeerde naam te bewaren. De waarde voor deze parameter entiteit moet "%MODULE.pfx;NAME" zijn. Op deze manier zal de parsed waarde "PREFIX:NAME" zijn wanneer voorvoegsels geactiveerd zijn en "NAME" in het andere geval. Als de module attributen toevoegt aan elementen gedefinieerd in modules die niet de namespace van deze module gemeenschappelijk hebben, moeten deze attributen gedeclareerd worden zodat ze het %MODULE.pfx voorvoegsel gebruiken. Bijvoorbeeld: Een voorbeeld van een qname sub-module voor een hypothetische Inventaris Module wordt hierna opgegeven: ]]> ]]> D.2.2. Declaratie sub-module(s) De volgende stap is de definitie van één of meer "declaratie sub-modules". Het doel van deze bestandentiteiten is de declaratie van de XML DTD elementen en attribuutlijsten. Een XHTML declaratie module kan gemaakt worden door het volgende process te volgen: 1. Definieer een parameter entiteit om te gebruiken binnen de ATTLIST van elk gedeclareerd element. Deze parameter entiteit zou %NS.decl.attrib; moeten bevatten wanneer %MODULE.prefixed; ingesteld is op INCLUDE en %NS.decl.attrib; plus "xmlns %URI.datatype; #FIXED '%MODULE.xmlns;'" wanneer %MODULE.prefixed; ingesteld is op IGNORE. 2. Declareer alle elementen en attributen voor de module. Neem binnen elke ATTLIST voor een element de parameter entiteit hierboven gedefinieerd op zodat alle vereiste xmlns attributen beschikbaar zijn op elk element in de module. 3. Als de module attributen toevoegt aan elementen gedefinieerd in modules die de namespace van deze module niet delen, declareer dan deze attributen zodat ze de %MODULE.pfx prefix gebruiken. Bijvoorbeeld: Dit zou een attribuut moeten toevoegen aan het img element van de Image Module, maar de naam van het attribuut zal een gekwalificeerde naam, met prefix, zijn wanneer prefixes geselecteerd zijn voor een document. Het voegt ook het xmlns:MODULE_PREFIX attribuut toe aan de img element attribuutlijst zodat een XML Namespace-bewuste parser zou weten hoe de namespace gebaseerd op de prefix ervan moet opgelost worden. Het volgende voorbeeld toont een declaratie sub-module voor een hypothetische Inventaris module. ]]> D.2.3. Gebruik van de module als een stand-alone DTD Het is soms gewenst om een XHTML module te hebben die ook gebruikt kan worden als een stand alone DTD. Een goed voorbeeld hiervan is onze Inventaris module hierboven. Deze items moeten opneembaar zijn in een XHTML document en moeten ook beschikbaar zijn als free-standing documenten gegenereerd uit een database (bijvoorbeeld). De eenvoudigste manier om dit te realiseren is om een DTD bestand te definiëren dat de componenten van de module opdeelt. Zo een DTD zou deze structuur hebben: 1. Neem de XHTML Datatypes Module op (jouw qnames module gebruikt waarschijnlijk sommige van deze datatypes - het gebruikt zeker het URI datatype voor het xmlns attribuut). 2. Neem de Qnames Module voor jouw module op. 3. Definieer de parameter entiteit NS.decl.attrib zodat deze %MODULE.xmlns.extra.attrib; is. 4. Neem de Declaratie Module(s) voor jouw module op. Een voorbeeld hiervan voor onze Inventaris module is hierna opgenomen: %xhtml-datatypes.mod; %Inventaris-qname.mod; %Inventaris.mod; Er kan dan naar deze DTD verwezen worden door documenten die enkel de elementen van jouw module gebruiken: dit is een omschrijving. dit is de prijs. dit is de prijs. Deze methode laat de definitie van elementen en attributen die beperkt zijn tot hun eigen namespace toe. Het laat inhoudsontwikkelaars ook toe om de standaard prefix voor de elementen en attributen te gebruiken: ]> dit is een omschrijving. dit is de sku. dit is de prijs. Tot slot kan een document een andere XML namespace prefix gebruiken door redeclaratie ervan in de DOCTYPE header en de interne subset ervan: ]> dit is een omschrijving. dit is de prijs. dit is de prijs. D.2.4. Namespace Eigenaardigheden Hoewel de benadering hier gedefinieerd de definitie van opmaaktalen toelaat die XML en XML namespaces conform zijn, worden sommige gedragingen gedefinieerd door de XML namespaces specificatie niet ondersteund: 1. XML namespaces laten de redeclaratie van het xmlns attribuut voor een namespace op elk ount in de boom toe. Het laat deze redeclaratie verder toe om te switchen tussen namespace standaard en prefixed gebruik en laat wijzigen van de prefix toe. De methode gedefinieerd in dit document laat dit niet toe. Doorheen een document moet een gegeven namespace dezelfde namespace prefix (wanneer prefixing gebruikt wordt) blijven gebruiken of de standaard blijven gebruiken. 2. Wanneer XML namespace standaard gebruikt wordt is het geldig om te vertrouwen op de DTD van het document om parsers te informeren van de namespace van elementen. Hoewel namespace bewuste processors de DTD niet verplicht moeten opnemen wanneer een document geëvalueerd wordt, zouden inhoudontwikkelaars de XML namespace van een element best declareren telkens de namespace wijzigt: ...

E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules Deze appendix is informatief. Het primary doel van definiëren van XHTML modules en een algemene modularisatie methodologie is het ontwikkelgemak van documenttypes die gebaseerd zijn op XHTML. Deze document types kunnen XHTML uitbreiden door integratie van aanvullende mogelijkheden (zoals [SMIL]), of ze kunnen een subset van XHTML definiëren voor het gebruik in een gespecialiseerd toestel. Dit deel omschrijft de technieken die document typeontwerpers moeten gebruiken om de XML DTD implementatie van deze modularisatie architectuur uit te buiten. Het doet dit door gaandeweg complexere toepassing van de XHTML Modularisatie technieken in de aanmaak van een compleet document type door culmineren van verschillende modules. Merk op dat deze voorbeelden in geen geval de aanpassing van de de door XHTML voorziene module bestand entiteiten zelf vereisen. De XHTML module bestand entiteiten worden volledig geparameteriseerd, zodat het mogelijk is om via verschillende module definities en driver bestanden de definitie en het inhoudsmodel van elk element en elke elementhierarchie aan te passen. Onhoudt tot slot dat er van de meeste gebruikers van XHTML niet verwacht wordt dat ze DTD auteurs zijn. DTD auteurs zijn in het algemeen mensen die gespecialiseerde opmaak definiëren die de leesbaarheid, de eenvoud van weergave van een document of gemak van machineverwerking van documenten verhogen. DTD auteurs kunnen ook client ontwerpers zijn die de gespecialiseerde DTD definiëren voor hun specifieke client. Beschouw de volgende gevallen: * Een organisatie biedt informatie van de abonnee's via een Web interface. De organisatie bewaart de informatie van de abonnee in een XML-gebaseerde database. Een manier om deze informatie vanuit de database naar het Web te rapporteren is door de XML records van de database direct op te nemen in het XHTML document. Hoewel het mogelijk is om enkel de records op te nemen, zou de organisatie een DTD module kunnen definiëren die de records omschrijft, deze module koppelen aan een XHTML DTD en daarbij een complete DTD voor de pagina's maken. De organisatie kan dan toegang krijgen tot de data met nieuwe elementen via het Document Object Model [DOM], de documenten valideren, stijldefinities voorzien voor de elementen die cascaden door gebruik van Cascading Style Sheets [CSS2], enz. Door de tijd te nemen om de structuur van hun data te definiëren en een DTD te maken door gebruikt van de processen gedefinieerd in dit deel, kan de organisatie de volledige voordelen van XML benutten. * Een Internet client ontwikkelaar ontwerpt een gespecialiseerd toestel. Dat toestel zal enkel een subset van XHTML ondersteunen en het toestel zal altijd toegang krijgen tot het Internet via een proxy server die de inhoud valideert voordat het naar de client gestuurd wordt (om error handling op de client te minimaliseren). Om te garanderen dat de inhoud geldig is maakt de ontwikkelaar een DTD die een subset van XHTML is door gebruik te maken van de processen gedefinieerd in dit deel. Hij kan dan de nieuwe DTD gebruiken in zijn proxy server en in zijn toestellen en zo de DTD ook beschikbaar maken voor inhoudontwikkelaars zodat ontwikkelaars hun inhoud kunnen valideren voordat ze deze beschikbaar maken. Door het uitvoeren van een paar eenvoudige stappen kan de client ontwikkelaar de architectuur gedefinieerd in dit document gebruiken om de ontwikkeling van zijn DTD te vergemakkelijken en te verzekeren dat ze volledig de subset van XHTML, die ze wensen op te nemen, te ondersteunen. E.1. Definiëren van aanvullende attributen In een aantal kan een uitbreiding van XHTML zo eenvoudig zijn als aanvullende attributen. Attributen kunnen aan een element toegevoegd worden door enkel een aanvullende ATTLIST voor het element te specificeren, bijvoorbeeld: zou het "mijnattr" attribuut toevoegen met een optionele prefix gedefinieerd door "%MijnModule.pfx", met een waardetype CDATA voor het "a" element. Dit werkt omdat XML de definitie of uitsluiting van de attribuutlijst voor een element toelaat op elk punt in een DTD. Raadpleeg voor een bespreking van gekwalificeerde namen en namespace prefixen Definitie van de Namespace van een Module. Toevoegen van een attribuut aan een DTD betekent uiteraard niet dat een nieuw gedrag gedefinieerd wordt voor clients. Een inhoudontwikkelaar kan (bijvoorbeeld) een extra attribuut gebruiken om informatie in te bewaren die gebruikt wordt door gekoppelde scripts via het Document Object Model. E.2. Definiëren van aanvullende elementen Definiëren van aanvullende elementen is weinig moeilijker dan definiëren van aanvullende attributen. DTD auteurs zouden de element declaratie voor elk element moeten schrijven: Nadat de elementen gedefinieerd zijn, moeten ze geïntegreerd worden in het inhoudsmodel. Strategiëen voor integratie van nieuwe elementen of sets van elementen in het inhoudsmodel worden bekeken in het volgende deel. E.3. Definiëren van het inhoudsmodel voor een verzameling van modules Aangezien het inhoudsmodel van XHTML modules volledig geparameteriseerd is, mogen DTD auteurs het inhoudsmodel aanpassen voor elk element in elke module. De details van de DTD module interface worden gedefinieerd in DTD Modules bouwen. Er zijn fundamenteel twee manieren om deze aanpassing te benaderen: 1. Herdefinieer de ".content" parameter entiteit voor elk element. 2. Herdefinieer één of meer van de globale inhoudsmodelentiteiten (normaal via de ".extras" parameter entiteit). De gekozen strategie zal afhangen van de aard van de gecombineerde modules en de aard van de geïntegreerde elementen. De rest van dit deel omschrijft technieken voor integratie van twee verschillende classen van modules. E.3.1. Een stand-alone module integreren in XHTML Als een module (onthoudt dat een module een collectie van andere modules kan zijn) elementen bevat die enkel verwijzen naar elkaar in hun inhoudsmodel, wordt gezegdt dat het "intern volledig (internally complete)" is. Zo kan de module op zichzelf gebruikt worden; (je kan bijvoorbeeld een DTD definiëren die bestaat uit één module en één van zijn elementen gebruikt als root element). Integreren van zo een module in XHTML is een proces uit drie stappen: 1. Beslis welk(e) element(en) gezien kunnen worden als de root(s) van de nieuwe module. 2. Beslis waar deze elementen gekoppeld worden in de XHTML inhoudsboom. 3. Voeg dan voor elk koppelpunt in de inhoudsboom de root element(en) toe aan de inhoudsdefinitie voor de XHTML elementen. Beschouw het koppelen van de elementen hierboven gedefinieerd. In dat voorbeeld is het element mijnelement de root. Om dit element te koppelen onder het img element en enkel het img element van XHTML, zou het volgende werken: Een DTD gedefinieerd met dit inhoudsmodel zou een document zoals het volgende fragment toelaten: Dit is inhoud van een lokaal gedefinieerd element Het is belangrijk om op te merken dat het img element normaal als inhoudsmodel EMPTY heeft. Door het toevoegen van mijnelement aan dat inhoudsmodel wordt EMPTY vervangen door mijnelement. In het geval van andere elementen die al inhoudsmodellen gedefinieerd hebben, zal de toevoeging van een het herstarten van het bestaande inhoudsmodel vereisen in aanvulling van mijnelement. E.3.2. Een nieuwe module mixen door de modules in XHTML Uitbreidend op het bovenstaande voorbeeld, zou om deze module overal te koppelen zoals volgens het %Flow.mix inhoudsmodel groep toegelaten wordt, iets zoals het volgende vereisen: Omdat de %Misc.extra inhoudsmodel classe gebruikt wordt in de %Misc.class parameter entiteit en deze parameter entiteit gebruikt wordt doorheen de XHTML modules, zou de nieuwe module beschikbaar worden doorheen een uitgebreid XHTML document type. E.4. Een nieuwe DTD maken Tot hier hebben de voorbeelden in dit deel de methoden van uitbreiding van XHTML en het inhoudsmodel van XHTML omschreven. Als dit gedaan is, wordt de volgende stap het verzamelen van de modules die de DTD samenbrengen in een DTD driver waarbij de nieuwe definities opgenomen worden zodat ze de basis XHTML definities op een gepaste manier overriden en aanvullen. E.4.1. Een eenvoudige DTD maken Door gebruik te maken van het triviale voorbeeld hierboven is het eenvoudig mogelijk om een nieuwe DTD te definiëren die de XHTML modules gebruikt en uitbreid. Definieer eerst de nieuwe elementen en hun inhoudsmodel in een module: %xhtml-basic-model.mod; Definieer vervolgens de DTD driver voor de nieuwe taal: %xhtml-datatypes.mod; ]]> ]]> %xhtml-basic.dtd; Wanneer deze DTD gebruikt wordt is het mogelijk om het gebruik van XML namespace prefixes te activeren. Als dit gedaan wordt zou de start van een document die deze nieuwe DTD gebruikt kunnen uitzien als: ]> Een standaard voorbeeld

Dit is inhoud in de XHTML namespace

Dit is inhoud in de SimpleML namespace.

Missing image

E.4.2. Een DTD maken door XHTML uit te breiden Vervolgens bestaat de situatie waar een complete, aanvullende en complexe module toegevoegd wordt aan XHTML (of een subset van XHTML wordt). In wezen is dit hetzelfde als in het triviale voobeeld hierboven, het enige verschik is dat de module die toegevoegd wordt opgebomen wordt in de DTD door verwijzing (by reference) in plaats van door expliciete opname van de nieuwe definities in de DTD. Een dergelijke complexe module is de DTD voor [MATHML]. Om MathML en XHTML te combineren in één enkele DTD moet een auteur enkel bepalen waar MathML inhoud geldig is in het document en het MathML root element toevoegen aan het inhoudsmodel op dat punt. Definieer eerst een inhoudsmodel module die de MathML DTD vastlegt en koppelt aan het inhoudsmodel: %XHTML1-math; Definieer vervolgens een DTD driver die onze nieuwe inhoudsmodel module identificeert als het inhoudsmodel voor de DTD en (bijvoorbeeld) de processingafhandeling doorgeeft aan de XHTML 1.1 driver: %xhtml11.dtd; E.4.3. Een DTD maken door XHTML modules te verwijderen en te vervangen Een andere manier waarin DTD auteurs XHTML modules mogen gebruiken is bij de definitie van een DTD die een subset is van een XHTML family document type (omdat men bijvoorbeeld toestellen of software bouwt die enkel een subset van XHTML ondersteunt). Dit doen is weinig complexer dan het voorgaande voorbeeld. De basisstappen die gevolgd moeten worden zijn: 1. Neem een XHTML family DTD als de basis voor het nieuwe document type (we zullen XHTML 1.1 gebruiken). 2. Selecteer de modules die verwijderd moeten worden van deze DTD. 3. Definieer een nieuwe DTD die de modules negeert ("IGNORE"). 4. Introduceer enkele nieuwe modules. Beschouw bijvoorbeeld een toestel dat XHTML modules gebruikt maar zonder formulieren of tabellen. De DTD voor zo een toestel zou uitzien zoals dit: %xhtml-basic-table.mod; %xhtml11.mod; Merk op dat dit niet werkelijk het inhoudsmodel van de XHTML 1.1 DTD aanpast. Aangezien XML elementen in inhoudsmodellen die niet gedefinieerd zijn negeert, worden de form en table elementen automatisch uit het model gegooid. E.4.4. Een nieuwe DTD maken Tot slot wensen sommige DTD auteurs te beginnen uit niets, gebruik makend van het XHTML Modularisatie framework als een gereedsch