H. Ontwerpdoelen

Deze appendix is informatief.

In deze appendix worden ontwerpdoelen geïdentificeerd met een label "Gn". Vereisten worden geïdentificeerd met een label "Rn.n". Er zijn vier grote ontwerpdoelen voor het modularisatie kader voor XHTML:

• [G1] Om semantisch gerelateerde delen van XHTML samen te groeperen.
• [G2] Gebruik makend van DTD technologie om de creatie van gerelateerde talen (subsets, supersets) voor specifieke doelen (kleine toestellen, toestellen voor speciale doeleinden) te ondersteunen terwijl er garanties blijven over de overlappende delen.
• [G3] Om toekomstige ontwikkeling te vergemakkelijken door toe te laten dat delen van de taal vervangen worden door verbeterde modules (bijvoorbeeld formulieren) zonder dat de rest van de taal verstoord wordt.
• [G4] Om het hergerbuik van modules in andere talen aan te moedigen en te vergemakkelijken.

H.1. Vereisten

De ontwerpdoelen opgesomd in de vorige sectie leiden tot een groot aantal vereisten voor het modularisatie kader. Deze vereisten, die opgesomd worden in deze sectie, kunnen verder geklassificeert volgens de hoofdeigenschappen van het kader dat omschreven moet worden.

H.1.1. Geleidelijkheid

De gezamenlijke vereisten in deze sectie drukken het verlangen uit dat de modules gedefinieerd in het kader het juiste niveau van geleidelijkheid bekomen wordt:

• [R1.1] Abstracte modules zouden de draagbaarheid van de inhoud moeten bevorderen.
• [R1.2] Abstracte modules zouden platform profiel standardisatie moeten promoten.
• [R1.3] Abstracte modules zouden groot genoeg moeten zijn om interoperabiliteit te promoten.
• [R1.4] Abstracte modules zouden klein genoeg moeten zijn om het gebruik van subsets te vermijden.
• [R1.5] Abstracte modules zouden elementen met gelijkaardige of gerelateerde semantiek moeten verzamelen.
• [R1.6] Abstracte modules zouden elementen met verschillende of ongerelateerde semantiek moeten scheiden.
• [R1.7] Modules zouden klein genoeg moeten zijn om enkelvoudige element document type modules toe te staan.

H.1.2. Opbouwbaarheid

De opbouwbaarheid vereisten die hier opgesomd worden zijn bedoeld om ervoor te zorgen dat het modularisatiekader in staat is om de juiste set van doelmodules voor de gemeenschappen, die bediend worden door het kader, uit te drukken:

• [R2.1] Het modulekader zou de constructie van abstracte modules voor XHTML 1.0 moeten toelaten.
• [R2.2] Het modulekader zou de constructie van abstracte modules die HTML 4 sterk benaderen moeten toelaten.
• [R2.3] Het modulekader zou de constructie van abstracte modules voor andere W3C Aanbevelingen moeten toelaten.
• [R2.4] Het modulekader zou de constructie van abstracte modules voor andere XML document types moeten toelaten.
• [R2.5] Het modulekader zou de constructie van abstracte modules voor een groot bereik van platform profielen moeten toelaten.

H.1.3. Gebruiksgemak

Het modularisatiekader zal enkel goed verspreid worden als het mechanismen omschrijft die het gemakkelijk maken voor het doelpubliek om het kader te gebruiken:

• [R3.1] Het modulekader zou het document type ontwerpers gemakkelijk moeten maken om subsets en uitbreidingen van XHTML abstracte modules te ontwerpen.
• [R3.2] Het modulekader zou het voor document type ontwerpers gemakkelijk moeten maken om abstracte modules te creëren voor andere XML document types.
• [R3.3] Het modulekader zou het voor document auteurs gemakkelijk moeten maken om elementen van verschillende abstracte modules te valideren.

H.1.4. Compatibiliteit

De bedoeling van dit document is dat het modularisatiekader hier omschreven goed zou moeten samenwerken met de XML en andere standaarden die ontworpen worden door de W3C Working Groups:

• [R4.1] Het modulekader zou strict conform aan de XML 1.0 Aanbeveling moeten zijn.
• [R4.2] Het modulekader zou compatibel moeten zijn met de XML Linking Language (XLink) [XLINK] specificatie.
• [R4.3] Het modulekader zou compatibel moeten zijn met de Associating Style Sheets with XML documents [XMLSTYLE] specificatie.
• [R4.4] Het modulekader zou in staat moeten zijn om nieuwe W3C Aanbevelingen te adopteren waar dit gepast is.
• [R4.5] Het modulekader zou niet mogen afhangen van W3C werk in uivoering.
• [R4.6] Het modulekader zou niet mogen afhangen van werk buiten W3C.

H.1.5. Conformiteit

De effectiviteit van het kader zal ook gemeten worden door het gemak waarmee het gedrag van modules, ontwikkeld volgens het kader, en documenten, die deze modules toepassen voor validatie, getest kunnen worden:

• [R5.1] Het zou mogelijk moeten zijn om documenten, gemaakt door gebruik te maken van elementen en attributen van abstracte modules, te valideren.
• [R5.2] Het zou mogelijk moeten zijn om het gedrag van elementen en attributen van abstracte modules expliciet te omschrijven.
• [R5.3] Het zou mogelijk moeten zijn om het gedrag van elementen en attributen van abstracte modules te verifiëren.
• [R5.4] Het zou mogelijk moeten zijn om een hybride document type als een XHTML document type te verifiëren.
• [R5.5] Modules die gedefinieerd worden in overeenstemming met de methodes in dit document zullen niet dezelfde mogen zijn als de namen van elementen of parameter entiteiten die gedefinieerd worden in XHTML modules.