H. Design Goals

This appendix is informative.

In this appendix, design goals are identified with a label "Gn", and requirements are identified with a label "Rn.n". There are four major design goals for the modularization framework for XHTML:

• [G1] To group semantically related parts of XHTML together.
• [G2] Using DTD technology, to support the creation of related languages (subsets, supersets) for specific purposes (small devices, special-purpose devices), while guaranteeing commonality of the overlapping parts.
• [G3] To facilitate future development by allowing parts of the language to be replaced by improved modules (for instance, forms) without disturbing the rest of the language.
• [G4] To encourage and facilitate the reuse of modules in other languages.

H.1. Requirements

The design goals listed in the previous section lead to a large number of requirements for the modularization framework. These requirements, summarized in this section, can be further classified according to the major features of the framework to be described.

H.1.1. Granularity

Collectively the requirements in this section express the desire that the modules defined within the framework hit the right level of granularity:

• [R1.1] Abstract modules should promote and maintain content portability.
• [R1.2] Abstract modules should promote platform profile standardization.
• [R1.3] Abstract modules should be large enough to promote interoperability.
• [R1.4] Abstract modules should be small enough to avoid the need for subsets.
• [R1.5] Abstract modules should collect elements with similar or related semantics.
• [R1.6] Abstract modules should separate elements with dissimilar or unrelated semantics.
• [R1.7] Modules should be small enough to allow single element document type modules.

H.1.2. Composibility

The composibility requirements listed here are intended to ensure that the modularization framework be able to express the right set of target modules required by the communities that will be served by the framework:

• [R2.1] The module framework should allow construction of abstract modules for XHTML 1.0.
• [R2.2] The module framework should allow construction of abstract modules that closely approximate HTML 4.
• [R2.3] The module framework should allow construction of abstract modules for other W3C Recommendations.
• [R2.4] The module framework should allow construction of abstract modules for other XML document types.
• [R2.5] The module framework should allow construction of abstract modules for a wide range of platform profiles.

H.1.3. Ease of Use

The modularization framework will only receive widespread adoption if it describes mechanisms that make it easy for our target audience to use the framework:

• [R3.1] The module framework should make it easy for document type designers to subset and extend XHTML abstract modules.
• [R3.2] The module framework should make it easy for document type designers to create abstract modules for other XML document types.
• [R3.3] The module framework should make it easy for document authors to validate elements from different abstract modules.

H.1.4. Compatibility

The intent of this document is that the modularization framework described here should work well with the XML and other standards being developed by the W3C Working Groups:

• [R4.1] The module framework should strictly conform to the XML 1.0 Recommendation.
• [R4.2] The module framework should be compatible with the XML Linking Language (XLink) [XLINK] specification.
• [R4.3] The module framework should be compatible with the Associating Style Sheets with XML documents [XMLSTYLE] specification.
• [R4.4] The module framework should be able to adopt new W3C Recommendations where appropriate.
• [R4.5] The module framework should not depend on W3C work in progress.
• [R4.6] The module framework should not depend on work done outside W3C.

H.1.5. Conformance

The effectiveness of the framework will also be measured by how easy it is to test the behavior of modules developed according to the framework, and to test the documents that employ those modules for validation:

• [R5.1] It should be possible to validate documents constructed using elements and attributes from abstract modules.
• [R5.2] It should be possible to explicitly describe the behavior of elements and attributes from abstract modules.
• [R5.3] It should be possible to verify the behavior of elements and attributes from abstract modules.
• [R5.4] It should be possible to verify a hybrid document type as an XHTML document type.
• [R5.5] Modules defined in accordance with the methods in this document shall not duplicate the names of elements or parameter entities defined in XHTML modules.