[vorige]   [volgende]   [inhoud]

3. Conformiteitsdefinitie

Inhoud

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, refereren 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 die het document type definieert moet een unieke identifier hebben zoals gedefinieerd in Naamgevingsregels die gebruik maakt van de string "XHTML" in de eerste token van de publieke tekst omschrijving.
  3. De DTD die het document type definieert moet ten minste de Structuur, Hypertext, Tekst en Lijst modules bevatten die gedefinieerd worden in deze specificatie.
  4. Voor elk van de door het W3C-gedefinieerde modules die opgenomen worden, moeten alle elementen, attributen, types van attributen (inclusief alle vereiste numerieke waardenlijsten) en alle vereiste minimale inhoudmodellen opgenomen (en optioneel uitgebreid) worden in het document type's inhoudsmodel. Wanneer inhoudsmodellen uitgebreid worden, moeten alle elementen en attributen (samen met hun types of alle vereiste numerieke waardenlijsten) vereist in het originele inhoudsmodel vereist blijven.
  5. De DTD die het document type definieert mag aanvullende elementen en attributen definiëren. Deze moeten echter in hun eigen XML namespace [XMLNAMES] zitten.

3.2. XHTML Integratie Set Document Type Conformiteit

Het is ook mogelijk om document types te definiëren die gebaseerd zijn op XHTML, maar die niet blijven bij de structuur ervan. Zo een document type is "XHTML Integratie Set Conformiteit" wanneer het voldoet aan de volgende criteria:

  1. Het document type moet gedefinieerd worden door gebruik te maken van een van de implementatiemethodes gedefinieerd door het W3C. Momenteel wordt dit beperkt tot XML DTD's, maar XML Schema zal binnenkort beschikbaar zijn. De rest van deze sectie refereert naar "DTD's" hoewel andere implementaties mogelijk zijn.
  2. De DTD welke het document type definieert moet een unieke identifier hebben zoals deze gedefinieerd wordt in Naamgevingsregels die NIET gebruik maken van de string "XHTML" in de eerste token van de publieke tekst omschrijving ervan.
  3. De DTD welke het document type definieert moet ten minste de Hypertext, Tekst en Lijstmodules bevatten die gedefinieerd worden in deze specificatie.
  4. Voor elke van de door het W3C-gedefinieerde modules die opgenomen worden moeten alle elementen, attributen, types van attributen (inclusief alle vereiste numerieke lijsten) en alle vereiste minimale inhoudsmodellen opgenomen (en optioneel 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 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 definieert 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, moeten de parmater entiteitsnamen van de module afgeschermd worden door gebruik te maken van unieke prefixen of andere, gelijksoortige 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 is 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 met de definitie van de mogelijkheden.
  3. Wanneer een user agent XHTML document verwerkt als generieke [XML], zal het enkel attributen van het type ID (zoals het id attribuut op de meeste XHTML elementen) herkennen als fragment identificatoren.
  4. Als een user agent een element tegenkomt dat het niet herkent, moet het verder gaan met het verwerken van de kinderen (children) van dat element. Als de inhoud tekst is, moet de tekst gepresenteerd worden aan de gebruiker.
  5. Als een user agent een attribuut tegenkomt dat het niet herkent, moet het de volledige attribuut specificatie (zijnde het attribuut en de waarde ervan) negeren .
  6. Als een user agent een attribuutwaarde tegenkomt die het niet herkent, moet het de standaard attribuutwaarde gebruiken.
  7. Als het een entiteitsverwijzing (anders dan één van de voorgedefinieerde entiteiten) tegenkomt waarvoor de user agent geen declaratie verwerkt heeft (hetgeen kan gebeuren als de declaratie in de externe subset zit welke de user agent nog niet gelezen heeft), zou de entiteitsverwijzing moeten weergegeven worden als de karakters (startend met de ampersand en eindigend met de punt-komma) die de entiteitsverwijzing vormen.
  8. Wanneer inhoud weergegeven wordt, zouden user agents die karakters of karakter entiteitsverwijzingen tegenkomen die herkend worden, maar niet weergegeven kunnen worden, het document moeten weergegeven op een zodanige manier dat het duidelijk is voor de gebruiker dat de inhoud niet op een normale manier weergegeven wordt.

  9. Witruimte wordt behandeld volgens de volgende regels. De volgende karakters worden in [XML] gedefinieerd als witruimtekarakters:

    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:

    Witruimte in attribuutwaarden wordt verwerkt volgens [XML].

    Opmerking (informatief): Bij het beslissen hoe een user agent een REGELEINDE karakter zou moeten omzetten moeten de volgende gevallen, waarbij de schrijfwijze van karakters aan beide kanten van het REGELEINDE karakter bepalen welke de keuze van vervanging is, beschouwd worden. Karakters van COMMON schrift (zoals interpunctie) worden op dezelfde manier behandeld als de schrijfwijze aan de andere kant:

    1. Als de karakters voorafgaand en volgend op het REGELEINDE karakter horen tot een schrift waar het SPATIE karakter gebruikt wordt als woordscheiding, zou het REGELEINDE karakter omgezet moeten worden in een SPATIE karakter. Voorbeelden van zulke schriften zijn Latijns, Grieks en Cyrillisch.
    2. Als de karakters voorafgaand en volgend op het REGELEINDE karakter horen tot een ideografisch-gebaseerd schrift of schrijfsysteem waarin er geen woordscheidingsteken is, zou het REGELEINDE teken omgezet moeten worden in geen karakter. Voorbeelden van zulke schriften of schrijfsystemen zijn Chinees en Japans.
    3. Als de karakters voorafgaand en volgend op het REGELEINDE karakter horen tot een niet ideografisch-gebaseerd schrift waarin er geen woordscheidingsteken is, zou het REGELEINDE teken omgezet moeten worden in een NUL BREEDTE SPATIE karakter (​) of in geen karakter. Voorbeelden van zulke schriften zijn Thai en Khmer.
    4. Als geen van de voorwaarden in (1) tot (3) geldt, 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ïmplementeerd 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 geüpdatet 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 gebruiken zou de naam voor een XHTML Host Taal conform document type -//MijnBedrijf//DTD XHTML MijnML 1.0//EN kunnen zijn. De naam voor een XHTML familie conforme module zou -//MijnBedrijf//ELEMENTS XHTML MijnElementen 1.0//EN kunnen zijn. De naam voor een XHTML Integratie Set conform document type zou -//MijnBedrijf//DTD Speciale Opmaak met XHTML//EN kunnen zijn.

3.7. XHTML Module Evolutie

Elke module gedefinieerd in deze specificatie krijgt een unieke identificator die de naamgevingsregels in het voorgaande deel volgt. Een module kan evolueren in de tijd. Een logische afgeleide van een dergelijke evolutie kan zijn dat sommige aspecten van de module niet langer compatible zijn met de vorige definitie. Om te garanderen dat document types, die gedefinieerd worden aan de hand van modules die in deze specificatie gedefinieerd worden, blijven werken, zullen de identificatoren geassocieerd met een module die wijzigt geüpdatet 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 geüpdate functionaliteit willen gebruiken zullen gelijkaardig geüpdatet moeten worden.

Aanvullend zullende eerdere versie(s) van de module beschikbaar blijven via de vroegere unieke identificator(en). Op deze manier zullen document types ontwikkeld door gebruik te maken van XHTML modules blijven functioneren door gebruik te maken van de originele definities, zelfs als de collectie uitgebreid wordt en evolueert. Gelijkaardig zullen documenten geschreven met zulke document types geldig (valid) blijven via de oudere module definities.

Andere XHTML Familie Module en Document Type auteurs worden aangeraden om een gelijksoortige strategie te volgen zodat document types gebaseerd op deze modules en documenten gebaseerd op deze document types blijvend functioneren.

[vorige]   [volgende]   [inhoud]