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−[email protected] (archief). Stuur een email naar www−html−[email protected] met het woord subscribe als onderwerp om in te schrijven. Meldt fouten in de Engelstalige versie van dit document aan www−html−[email protected] (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 [email protected]. Er wordt dan zo spoedig mogelijk gereageerd op uw opmerkingen.
1
Modularisatie van XHTML
Modularisatie van XHTML"
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.
2
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
♦ 5.18. Style Attribuut Module ♦ 5.19. Link Module ♦ 5.20. Base Module ♦ 5.21. Naam Identificatie Module ♦ 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 ♦ D.1. Parameter Entiteits Naamgeving ♦ 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 ♦ E.1. Definiëren van aanvullende attributen ♦ E.2. Definiëren van aanvullende elementen ♦ 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 ♦ 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 ♦ E.5. Een nieuwe DTD gebruiken • F. XHTML DTD Module Implementaties ♦ 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 ♦ 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 ♦ 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
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
7
Modularisatie van XHTML
1. Introductie
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.
8
Modularisatie van XHTML
1. Introductie
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.
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.
11
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,
12
Modularisatie van XHTML
3. Conformiteitsdefinitie
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.
13
Modularisatie van XHTML
3. Conformiteitsdefinitie
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) ( ) ♦ HORIZONTALE TAB (HORIZONTAL TABULATION) ( ) ♦ ALINEA−EINDE (CARRIAGE RETURN) ( ) ♦ 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: ♦ 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 () 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.
14
Modularisatie van XHTML
3. Conformiteitsdefinitie
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. NL, ELEMENTS −> ELEMENTEN Door deze regels te bebruiken zou de naam voor een XHTML Host Taal conform document type −//MijnBedrijf//DTD XHTML MijnML 1.0//NL kunnen zijn. De naam voor een XHTML familie conforme module zou −//MijnBedrijf//ELEMENTEN XHTML MijnElementen 1.0//NL kunnen zijn. De naam voor een XHTML Integratie Set conform document type zou −//MijnBedrijf//DTD Speciale Opmaak met XHTML//NL 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.
15
Modularisatie van XHTML
3. Conformiteitsdefinitie
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.
16
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.
17
Modularisatie van XHTML
4. Definitie van Abstracte Modules
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 Character Characterset Charactersets Color
Omschrijving Een enkel karakter uit [ISO10646]. Een karaktercodering zoals volgens [RFC2045]. Een 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) = "#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"
18
Modularisatie van XHTML
4. Definitie van Abstracte Modules
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 beschikbare horizontale of verticale ruimte Length 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.
19
Modularisatie van XHTML
4. Definitie van Abstracte Modules
Section
MediaDesc
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 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.
20
Modularisatie van XHTML
4. Definitie van Abstracte Modules
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 ontvangt een deel van de beschikbare ruimte die MultiLength 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 aangeeft (scherm, papier). De waarde "50" Pixels 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
Shape Text URI URIs
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. De vorm van een region. Arbitraire textuele data, waarschijnlijk bedoeld als leesbaar door de mens. Een Uniform Resource Identifier (Uniforme Bron Identificator) zoals volgens [URI]. 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
21
Modularisatie van XHTML
4. Definitie van Abstracte Modules
vakantieoord Common, href (CDATA) omschrijving, Aspen+ hut Common omschrijving, (Aspen − lift)+ lift Common, href omschrijving? vakantiehuisje Common, 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.
22
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), onmouseup (Script), onmouseover (Script), Events 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:
23
Modularisatie van XHTML
5. XHTML Abstracte Modules
Elementen Attributen Minimaal Inhoudsmodel body Common (Heading | Block | List)* head I18N, profile (URI) title html I18N, version (CDATA), xmlns (URI = "http://www.w3.org/1999/xhtml") head, body 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)* blockquote Common, 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:
24
Modularisatie van XHTML
5. XHTML Abstracte Modules
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 Common, accesskey (Character), charset (Charset), href (URI), hreflang a (LanguageCode), rel (LinkTypes), rev (LinkTypes), tabindex (Number), type (ContentType) Deze module voegt het a element toe aan de Inline inhoudset van de Tekstmodule.
Minimaal Inhoudsmodel (PCDATA | Inline − a)*
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: Elementen Attributen 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 applet
id (ID), name* (CDATA), type (ContentType), value (CDATA), valuetype ("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: Element Attributen 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.
26
Modularisatie van XHTML
5. XHTML Abstracte Modules
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 (Heading | List | Block − form)+
Common, multiple ("multiple"), name (CDATA), size (Number), tabindex (Number) option Common, selected ("selected"), value (CDATA) Common, accesskey (Character), cols* (Number), name (CDATA), rows* textarea (Number), tabindex (Number) Deze module definieert twee inhoudsets: select
option+ PCDATA PCDATA
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 form
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 ( Length ) caption?, tr+ Common, abbr (Text), align ("left" | "center" | "right"), axis (CDATA), colspan (PCDATA | Flow − td (Number), headers (IDREFS), rowspan (Number), scope ("row" | "col"), valign table)* ("top" | "middle" | "bottom") Common, abbr (Text), align ("left" | "center" | "right"), axis (CDATA), colspan (PCDATA | Flow − th (Number), headers (IDREFS), rowspan (Number), scope ("row" | "col" ), valign table)* ("top" | "middle" | "bottom") tr Common, align ("left" | "center" | "right"), valign ("top" | "middle" | "bottom") (td | th)+ Wanneer deze module gebruikt wordt zal het table element toegevoegd worden aan de Block inhoudset zoals gedefinieerd in 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), longdesc (URI), src* (URI), width (Length) EMPTY Wanneer deze module gebruikt wordt, zal het img element toegevoegd worden aan de Inline inhoudset van de Tekstmodule. Implementatie: DTD
29
Modularisatie van XHTML
5. XHTML Abstracte Modules
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 a& coords (CDATA), shape ("rect" | "circle" | "poly" | "default") Common, accesskey (Character), alt* (Text), coords (CDATA), href (URI), area nohref ("nohref"), shape ("rect"* | "circle" | "poly" | "default"), tabindex (Number) img& usemap (IDREF) input& usemap (IDREF)
Minimaal Inhoudsmodel n/a EMPTY
n/a n/a ((Heading | Block) | map I18N, Events, class (NMTOKEN), id* (ID), title (CDATA) area)+ Note: Only when the object& usemap (IDREF) 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 Inhoudsmodel img& ismap ("ismap") n/a input&
ismap ("ismap") n/a
Opmerkingen Als de Formulieren of de Basis Formulieren Module 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 (PCDATA | Flow | object (ContentType), data (URI), declare ("declare"), height (Length), name (CDATA), param)* standby (Text), tabindex (Number), type (ContentType), width (Length) id (ID), name* (CDATA), type (ContentType), value (CDATA), valuetype param EMPTY ("data"* | "ref" | "object") Als deze module gebruikt wordt, zal het object element toegevoegd worden aan de Inline inhoudset van de Tekstmodule. Implementatie: DTD
30
Modularisatie van XHTML
5. XHTML Abstracte Modules
5.11. Frames Module Zoals de naam voorstelt, biedt de Frames Module frame−gerelateerde elementen. De Frames Module ondersteunt: Elementen frameset
Core , frameborder ("1" | "0"), longdesc ( URI ), marginheight ( Pixels ), marginwidth ( Pixels ), noresize ("noresize"), scrolling ("yes" | "no" | "auto"*), EMPTY 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). frame
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 a& target ( CDATA ) area& target ( CDATA ) base& target ( CDATA ) link& target ( CDATA ) form& target ( CDATA ) Implementatie: DTD
OPmerkingen Als de Client−side Image Map Module geselecteerd wordt. Als de Erfenis Module geselecteerd wordt. Als de Link Module geselecteerd wordt. Als de Basis Formulieren of Formulieren module geselecteerd wordt.
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 ("yes" | "no" | "auto"*), src (URI), width (PCDATA | Flow)* (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
31
Modularisatie van XHTML
5. XHTML Abstracte Modules
de attribuut reeks Gebeurtenis gedefinieerd wordt zals hierboven beschreven. Attributen gedefinieerd door deze module zijn: Elementen Attributen a& onblur (Script), onfocus (Script) area&
Opmerkingen Als de Client−side Image Map Module ook gebruikt wordt. ALs de Frames Module ook gebruikt wordt. Als de Basis Formulieren of Formulieren Module gebruikt wordt.
Als de Formulieren Module gebruikt wordt. Als de Basis Formulieren of Formulieren Module gebruikt wordt. Als de Basis Formulieren of Formulieren Module gebruikt wordt. Als de Basis Formulieren of Formulieren Module gebruikt wordt. Als de Formulieren Module gebruikt wordt.
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 I18N, content* (CDATA), http−equiv (NMTOKEN), name (NMTOKEN), meta EMPTY 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 (URI), type* (ContentType), script 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
32
Modularisatie van XHTML
5. XHTML Abstracte Modules
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 I18N, media (MediaDesc), title (Text), type* (ContentType), style PCDATA 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), hreflang (LanguageCode), media link 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
33
Modularisatie van XHTML
5. XHTML Abstracte Modules
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 a& name (CDATA) applet& name (CDATA) form& name (CDATA) frame& name (CDATA) iframe& name (CDATA) img& name (CDATA) map& name (CDATA) Implementatie: DTD
Opmerkingen Als de Applet Module geselecteerd is. Als de Formulieren of Basis Formulieren Module geselecteerd is. Als de Frames Module geselecteerd is. Als de Iframe Module geselecteerd is. Als de Image Module geselecteerd is. Als de Client−side Image Map Module geselecteerd is.
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 (CDATA) EMPTY center Common (PCDATA | Flow)* dir Common, compact ("compact") (li)+ font Core, I18N, color (Color), face (CDATA), size (CDATA) (PCDATA | Inline)* 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 body& br& caption& div& dl& h1−h6&
Als de Basis Formulieren of Formulieren Module geselecteerd is. Als de Formulieren Module geselecteerd is.
Als de Scripting module geselecteerd is. Als de Tabbellen module geselecteerd is. Als de Tabbellen module geselecteerd is. Als de Tabbellen module geselecteerd is. Als de Tabbellen module geselecteerd is.
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.
36
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.
37
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.
38
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 definiuniek benoemd worden zodat ze niet botsen met andere parameter entiteiten en zodat
39
Modularisatie van XHTML
D. DTD Modules bouwen
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.
40
Modularisatie van XHTML
D. DTD Modules bouwen
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: <ENTITY % MODULE.img.mijnattr.qname "%MODULE.pfx;mijnattr" >
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
41
Modularisatie van XHTML
D. DTD Modules bouwen
%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: <ENTITY % MODULE.img.mijnattr.qname "%MODULE.pfx;mijnattr" >
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. ]]>
42
Modularisatie van XHTML
D. DTD Modules bouwen
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:
Er kan dan naar deze DTD verwezen worden door documenten die enkel de elementen van jouw module gebruiken: dit is een omschrijving. <sku> dit is de prijs. <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: ]>
44
Modularisatie van XHTML
D. DTD Modules bouwen
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: ...
<mijnelement xmlns="..." />
45
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:
CDATA
#IMPLIED
46
Modularisatie van XHTML
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
%MijnModule.xmlns.extras.attrib; >
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.
47
Modularisatie van XHTML
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
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: <mijnml:mijnelement >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:
48
Modularisatie van XHTML
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
%xhtml−basic−model.mod;
Definieer vervolgens de DTD driver voor de nieuwe taal: %xhtml−datatypes.mod; ]]> ]]>
49
Modularisatie van XHTML
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
SYSTEM "simpleml−model−1.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
<simpleml:element> Dit is inhoud in de SimpleML namespace. <simpleml:anderelement />
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;
50
Modularisatie van XHTML
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
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 gereedschapskoffer om een nieuwe opmaaktaal te maken. Deze taal moet gemaakt zijn uit de minimaal vereiste modules van XHTML. Het kan ok andere XHTML−gedefinieerde modules of elke andere module bevatten die de auteur wenst te gebruiken. In dit voorbeeld nemen we de XHTML vereiste modules en enkele XHTML−gedefinieerde modules en voegen daarbij de bovenstaande module. De eerste stap is om de XHTML−voorziene template te gebruiken voor een nieuwe gekwalificeerde names module, aangepast om de gekwalificeerde names en namespace voor onze nieuwe elementen te definiëren. %MijnML−datatypes.mod;
51
Modularisatie van XHTML
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
]]> ]]> ]]>
Definieer vervolgens een module die de elementen en attributen definieert door gebruik te maken van de XHTML voorziene template.
52
Modularisatie van XHTML
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
Bouw nu een inhoudsmodel omschrijving die de nieuwe elementen en attributen koppelt aan de andere XHTML elementen. Het volgende voorbeeld is gemodelleerd naar het XHTML Basic inhoudsmodel, maar is een volledig onafhankelijke inhoudsmodelmodule:
Inline Elementen
...................... −−>
53
Modularisatie van XHTML
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
Gebruik tot slot de XHTML−voorziene template voor een nieuwe DTD, geschikt aangepast voor onze nieuwe opmaaktaal: %xhtml−framework.mod; %xhtml−text.mod;
55
Modularisatie van XHTML
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
E.5. Een nieuwe DTD gebruiken Zodra een nieuwe DTD ontwikkeld is, kan het gebruikt worden in elk document. Een DTD gebruiken is zo eenvoudig als ernaar verwijzen in de DOCTYPE declaratie van een document: Een standaardvoorbeeld
Dit is inhoud in de XHTML namespace
<mijnelement> Dit is inhoud in de SimpleML namespace. <mijnanderelement />
Het document kan ook de elementen buiten de XHTML namespace gebruiken door ze te prefixen: ]> Een standaardvoorbeeld
56
Modularisatie van XHTML
E. DTD's ontwerpen met gedefinieerde en uitbreidingsmodules
Dit is inhoud in de XHTML namespace
<mijnml:mijnelement> Dit is inhoud in de mijnml namespace. <mijnml:mijnanderelement />
57
F. XHTML DTD Module Implementaties Deze appendix is normatief. Deze appendix zal implementaties van de modules gedefinieerd in XHTML Abstracte Modules bevatten via XML DTD's. Deze module implementaties kunnen gebruikt worden door XHTML Family Document Types.
F.1. XHTML Karakter Entiteiten XHTML DTD's maken een standaard collectie van benoemde karakter entiteiten beschikbaar. Deze entiteiten worden gedefinieerd in dit deel.
F.1.1. XHTML latijnse 1 Karakter Entiteiten %xhtml−lat1; Deze DTD module wordt geïdentifideerd door de PUBLIC en SYSTEM identificatoren: PUBLIC "−//W3C//ENTITIES latijnse 1 for XHTML//EN" SYSTEM "http://www.w3.org/TR/xhtml−modularization/DTD/xhtml−lat1.ent" Herziening:
Portions (C) International Organization for Standardization 1986: Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. −−>
nbsp iexcl cent pound curren yen brvbar sect uml copy ordf laquo not shy reg macr deg plusmn sup2 sup3 acute micro para middot cedil
superscript één = superscript getal één, U+00B9 ISOnum −−> mannelijke ordinale indicator, U+00BA ISOnum −−> rechts−wijzend dubbele hoek aanhalingsteken = rechts wijzende guillemet, U+ ordinaire breuk één vierde = breuk één vierde, U+00BC ISOnum −−> ordinaire breuk een half = breuk een half, U+00BD ISOnum −−> ordinaire breuk drie vierde = breuk drie vierde, U+00BE ISOnum −−> omgekeerd vraagteken = gedraaid vraagteken, U+00BF ISOnum −−> latijnse hoofdletter A met grave = latijnse hoofdletter A grave, U+00C0 ISO latijnse hoofdletter A met acute, U+00C1 ISOlat1 −−> latijnse hoofdletter A met circumflex, U+00C2 ISOlat1 −−> latijnse hoofdletter A met tilde, U+00C3 ISOlat1 −−> latijnse hoofdletter A met deelteken, U+00C4 ISOlat1 −−> latijnse hoofdletter A met ring boven = latijnse hoofdletter A ring, U+00C5 latijnse hoofdletter AE = latijnse hoofdletter koppelletter AE, U+00C6 ISOl latijnse hoofdletter C met cedilla, U+00C7 ISOlat1 −−> latijnse hoofdletter E met grave, U+00C8 ISOlat1 −−> latijnse hoofdletter E met acute, U+00C9 ISOlat1 −−> latijnse hoofdletter E met circumflex, U+00CA ISOlat1 −−> latijnse hoofdletter E met deelteken, U+00CB ISOlat1 −−> latijnse hoofdletter I met grave, U+00CC ISOlat1 −−> latijnse hoofdletter I met acute, U+00CD ISOlat1 −−> latijnse hoofdletter I met circumflex, U+00CE ISOlat1 −−> latijnse hoofdletter I met deelteken, U+00CF ISOlat1 −−> latijnse hoofdletter ETH, U+00D0 ISOlat1 −−> latijnse hoofdletter N met tilde, U+00D1 ISOlat1 −−> latijnse hoofdletter O met grave, U+00D2 ISOlat1 −−> latijnse hoofdletter O met acute, U+00D3 ISOlat1 −−> latijnse hoofdletter O met circumflex, U+00D4 ISOlat1 −−> latijnse hoofdletter O met tilde, U+00D5 ISOlat1 −−> latijnse hoofdletter O met deelteken, U+00D6 ISOlat1 −−> vermenigvuldigingsteken, U+00D7 ISOnum −−> latijnse hoofdletter O doorstreept = latijnse hoofdletter O slash, U+00D8 I latijnse hoofdletter U met grave, U+00D9 ISOlat1 −−> latijnse hoofdletter U met acute, U+00DA ISOlat1 −−> latijnse hoofdletter U met circumflex, U+00DB ISOlat1 −−> latijnse hoofdletter U met deelteken, U+00DC ISOlat1 −−> latijnse hoofdletter Y met acute, U+00DD ISOlat1 −−> latijnse hoofdletter THORN, U+00DE ISOlat1 −−> latijnse kleine scherpe s = ess−zed, U+00DF ISOlat1 −−> latijnse kleine a met grave = latijnse kleine a grave, U+00E0 ISOlat1 −−> latijnse kleine a met acute, U+00E1 ISOlat1 −−> latijnse kleine a met circumflex, U+00E2 ISOlat1 −−> latijnse kleine a met tilde, U+00E3 ISOlat1 −−> latijnse kleine a met deelteken, U+00E4 ISOlat1 −−> latijnse kleine a met ring boven = latijnse kleine a ring, U+00E5 ISOlat1 − latijnse kleine ae = latijnse kleine koppelletter ae, U+00E6 ISOlat1 −−> latijnse kleine c met cedilla, U+00E7 ISOlat1 −−> latijnse kleine e met grave, U+00E8 ISOlat1 −−> latijnse kleine e met acute, U+00E9 ISOlat1 −−> latijnse kleine e met circumflex, U+00EA ISOlat1 −−> latijnse kleine e met deelteken, U+00EB ISOlat1 −−> latijnse kleine i met grave, U+00EC ISOlat1 −−> latijnse kleine i met acute, U+00ED ISOlat1 −−> latijnse kleine i met circumflex, U+00EE ISOlat1 −−> latijnse kleine i met deelteken, U+00EF ISOlat1 −−> latijnse kleine eth, U+00F0 ISOlat1 −−> latijnse kleine n met tilde, U+00F1 ISOlat1 −−> latijnse kleine o met grave, U+00F2 ISOlat1 −−> latijnse kleine o met acute, U+00F3 ISOlat1 −−> latijnse kleine o met circumflex, U+00F4 ISOlat1 −−> latijnse kleine o met tilde, U+00F5 ISOlat1 −−> latijnse kleine o met deelteken, U+00F6 ISOlat1 −−> delingsteken, U+00F7 ISOnum −−> latijnse kleine o doorstreept, = latijnse kleine o slash, U+00F8 ISOlat1 −− latijnse kleine u met grave, U+00F9 ISOlat1 −−> latijnse kleine u met acute, U+00FA ISOlat1 −−> latijnse kleine u met circumflex, U+00FB ISOlat1 −−>
59
Modularisatie van XHTML
F. XHTML DTD Module Implementaties kleine kleine kleine kleine
u met deelteken, U+00FC ISOlat1 −−> y met acute, U+00FD ISOlat1 −−> thorn, U+00FE ISOlat1 −−> y met deelteken, U+00FF ISOlat1 −−>
F.1.2. XHTML Speciale Karakters %xhtml−special; Deze DTD module wordt geïdentificeerd door de PUBLIC en SYSTEM identificatoren: PUBLIC "−//W3C//ENTITIES Special for XHTML//EN" SYSTEM "http://www.w3.org/TR/xhtml−modularization/DTD/xhtml−special.ent" Herziening:
Portions (C) International Organization for Standardization 1986: Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. Herzieningen: 2000−10−28: toegevoegd ' en aangepast XML Voorgedefinieerde Entiteiten voor compatibiliteit −−>
en Basis latijnse −−> "&<" > ">" > "&&" > "'" > """ >
voorgesteld, maar is nog niet ISO gestandardiseerd −−> "‹" > voorgesteld, maar is nog niet ISO gestandardiseerd −−> "›" > "€" >
F.1.3. XHTML Wiskundige, Griekse en Symbolische Karakters %xhtml−symbol; Deze DTD module wordt geïdentificeerd door de PUBLIC en SYSTEM identificatoren: PUBLIC "−//W3C//ENTITIES Symbols for XHTML//EN" SYSTEM "http://www.w3.org/TR/xhtml−modularization/DTD/xhtml−symbol.ent" Herziening:
Portions (C) International Organization for Standardization 1986: Permission to copy in any form is granted for use with conforming SGML systems and applications as defined in ISO 8879, provided this notice is included in all copies. −−>
"Α" >
61
Modularisatie van XHTML
F. XHTML DTD Module Implementaties
griekse hoofdletter beta, U+0392 −−> griekse hoofdletter gamma, U+0393 ISOgrk3 −−> griekse hoofdletter delta, U+0394 ISOgrk3 −−> griekse hoofdletter epsilon, U+0395 −−> griekse hoofdletter zeta, U+0396 −−> griekse hoofdletter eta, U+0397 −−> griekse hoofdletter theta, U+0398 ISOgrk3 −−> griekse hoofdletter iota, U+0399 −−> griekse hoofdletter kappa, U+039A −−> griekse hoofdletter lambda, U+039B ISOgrk3 −−> griekse hoofdletter mu, U+039C −−> griekse hoofdletter nu, U+039D −−> griekse hoofdletter xi, U+039E ISOgrk3 −−> griekse hoofdletter omicron, U+039F −−> griekse hoofdletter pi, U+03A0 ISOgrk3 −−> griekse hoofdletter rho, U+03A1 −−> U+03A2 karakter −−> griekse hoofdletter sigma, U+03A3 ISOgrk3 −−> griekse hoofdletter tau, U+03A4 −−> griekse hoofdletter upsilon, U+03A5 ISOgrk3 −−> griekse hoofdletter phi, U+03A6 ISOgrk3 −−> griekse hoofdletter chi, U+03A7 −−> griekse hoofdletter psi, U+03A8 ISOgrk3 −−> griekse hoofdletter omega, U+03A9 ISOgrk3 −−> griekse kleine letter alpha, U+03B1 ISOgrk3 −−> griekse kleine letter beta, U+03B2 ISOgrk3 −−> griekse kleine letter gamma, U+03B3 ISOgrk3 −−> griekse kleine letter delta, U+03B4 ISOgrk3 −−> griekse kleine letter epsilon, U+03B5 ISOgrk3 −−> griekse kleine letter zeta, U+03B6 ISOgrk3 −−> griekse kleine letter eta, U+03B7 ISOgrk3 −−> griekse kleine letter theta, U+03B8 ISOgrk3 −−> griekse kleine letter iota, U+03B9 ISOgrk3 −−> griekse kleine letter kappa, U+03BA ISOgrk3 −−> griekse kleine letter lambda, U+03BB ISOgrk3 −−> griekse kleine letter mu, U+03BC ISOgrk3 −−> griekse kleine letter nu, U+03BD ISOgrk3 −−> griekse kleine letter xi, U+03BE ISOgrk3 −−> griekse kleine letter omicron, U+03BF NEW −−> griekse kleine letter pi, U+03C0 ISOgrk3 −−> griekse kleine letter rho, U+03C1 ISOgrk3 −−> griekse kleine letter final sigma, U+03C2 ISOgrk3 −−> griekse kleine letter sigma, U+03C3 ISOgrk3 −−> griekse kleine letter tau, U+03C4 ISOgrk3 −−> griekse kleine letter upsilon, U+03C5 ISOgrk3 −−> griekse kleine letter phi, U+03C6 ISOgrk3 −−> griekse kleine letter chi, U+03C7 ISOgrk3 −−> griekse kleine letter psi, U+03C8 ISOgrk3 −−> griekse kleine letter omega, U+03C9 ISOgrk3 −−> griekse kleine letter theta symbol, U+03D1 NEW −−> griekse upsilon met haak symbool, U+03D2 NEW −−> grieks pi symbool, U+03D6 ISOgrk3 −−>
>
script hoofdletter P = power set = Weierstrass p, U+2118 ISOamso −−> blackletter hoofdletter I = imaginair deel, U+2111 ISOamso −−> blackletter hoofdletter R = reëel deel, U+211C ISOamso −−> handelsmerk teken U+2122 ISOnum −−>
62
Modularisatie van XHTML
F. XHTML DTD Module Implementaties
63
Modularisatie van XHTML
supe oplus otimes perp sdot operator
F. XHTML DTD Module Implementaties
"⊇" > "⊕" > "⊗" > "⊥" > "⋅" > is NIET hetzelfde karakter als U+00B7 middle dot −−>
F.2. XHTML Modulair Framework Opdat men voordeel haalt uit de XHTML DTD Modules, moeten DTD auteurs het inhoudsmodel voor hun DTD definiëren. XHTML biedt een keuze van werktuigen om dit te vergemakkelijken. Ze worden gedefinieerd in een set van ondersteuningsmodules, opgedeeld door een hoofd Framework module:
notaties datatypes namespace−qualified namen gemeenschappelijke attributen document model
64
Modularisatie van XHTML +
F. XHTML DTD Module Implementaties
karakter entiteiten
De Intrinsieke Gebeurtenis module wordt standaard genegeerd maar komt in deze module voor omdat het vermeld moet worden voorafgaand aan Attributen maar volgend op Datatypes. −−> %xhtml−arch.mod;]]> %xhtml−notations.mod;]]> %xhtml−datatypes.mod;]]> %xhtml−xlink.mod; %xhtml−qname.mod;]]> %xhtml−events.mod;]]> %xhtml−attribs.mod;]]> %xhtml−model.redecl; %xhtml−model.mod;]]>
65
Modularisatie van XHTML
F. XHTML DTD Module Implementaties
%xhtml−charent.mod;]]>
Merk op dat de bovenstaande module verwijst naar een inhoudsmodel module. Deze module wordt gedefinieerd per document type als aanvulling op het document type driver bestand. Het Modular framework vertrouwt ook op de volgende component modules:
