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

Volledige inhoudstabel

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 "&amp;" voor "&", "&lt;" voor "<", "&copy;" 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:

   • SPATIE (SPACE) (&#x0020;)
   • HORIZONTALE TAB (HORIZONTAL TABULATION) (&#x0009;)
   • ALINEA-EINDE (CARRIAGE RETURN) (&#x000D;)
   • REGELEINDE (LINE FEED) (&#x000A;)

   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:

   • Alle witruimte rond blokelementen moet verwijderd worden.
   • Opmerkingen worden volledig verwijderd en hebben geen invloed op witruimtebehandeling. Een witruimteteken aan beide kanten van een opmerking zal aangenomen worden als twee witruimtetekens.
   • Wanneer het 'xml:space' attribuut ingesteld is op 'preserve', moeten witruimtetekens behouden worden en daardoor worden REGELEINDE tekens binnen een blok niet omgezet.
   • 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 (&#x200B;) 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 (&#x200B;) 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:

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].
Charactersets	Een door spaties gescheiden lijst van karaktercoderingen zoals volgens [RFC2045].
Color	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) = "#000000" Groen (Green) = "#008000" Zilver (Silver) = "#C0C0C0" Lichtgroen (Lime) = "#00FF00" Grijs (Gray) = "#808080" Olijf (Olive) = "#808000" Wit (White) = "#FFFFFF" Geel (Yellow) = "#FFFF00" Bruin (Maroon) = "#800000" Navy = "#000080" Rood (Red) = "#FF0000" Blauw (Blue) = "#0000FF" Paars (Purple) = "#800080" Blauwgroen (Teal) = "#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].
Length	De waarde kan ofwel in pixels ofwel een percentage van de beschikbare horizontale of verticale ruimte zijn. De waarde "50%" betekent dus de helft van de beschikbare ruimte.
LinkTypes	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 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.
MediaDesc	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 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): 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" 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" 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.
MultiLength	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 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
Pixels	De waarde is een integer die het aantal pixels van de canvas aangeeft (scherm, papier). De waarde "50" betekent dus vijftig pixels. Raadpleeg [CSS2] voor normatieve informatie over de definitie van een pixel
Script	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. 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:

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.

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:

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:

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:

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:

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:

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:

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:

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.

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:

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:

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:

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:

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:

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:

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:

Implementatie: DTD

5.10. Object Module

De Object Module biedt elementen voor general-purpose object opname. De Object Module ondersteunt:

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:

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.

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:

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: