A. Building Schema Modules

This chapter is normative.

This chapter contains instructions on how to define XML Schema modules that are compatible with the XHTML Modularization implementation via XML Schema [XMLSCHEMA]. This is in an appendix so that it can be a drop in replacement for the corresponding appendix in XHTML Modularization [XHTMLMOD].

XHTML Schema modules are implemented as fragments. When these fragments are assembled in a specific manner (described in Developing Schemas with defined and extended modules), the resulting Schema is a representation of a complete document type. This representation can then be used for validation of instances of the document type.

The key to combining these fragments into a meaningful, cohesive Schema is the rules used to define the fragments. This section defines those rules. When these rules are followed, markup language authors can be confident that their modules will interface cleanly with other XHTML-compatible modules.

Modules conforming to these rules also need to satisfy the conformance requirements defined in XHTML Family Module Conformance of XHTML Modularization [XHTMLMOD] in order to be called XHTML Family Modules.

A.1. Named Content Models

This specification classifies named content model into categories and names them consistently using the following suffixes

.content

model group definitions use the suffix .content when they are used to represent the content model of an element type.

.class

model group definitions use the suffix .class when they are used to represent elements of the same class.

.mix

model group definitions use the suffix .mix when they are used to represent a collection of element types from different classes.

.extra

model group definitions use the suffix .extra when they are used to extend other groups above.

.type

named complex type definitions use the suffix .type when they are used to represent type of an element.

.attlist

attribute groups use the suffix .attlist when they are used to represent the attributes for a specific element.

.attrib

attribute groups use the suffix .attrib when they are used to represent a group of tokens representing one or more complete attribute specifications within an .attlist declaration.

For example, in HTML 4, the %block; parameter entity is defined to represent the heterogeneous collection of element types that are block-level elements. In this specification, the corollary named content model is Block.mix.

When defining named content model in the classes defined here, modules should scope the names of the model group definitions and attribute groups by using unique prefixes. For example, the content model for the element myelement in the module mymodule could be named myelement.content. Other schemes are possible. Regardless of the scheme used, module authors should strive to ensure that named content model they define are named uniquely so that they do not collide with other named content model and so that the interface methods for the module are obvious to its users.

A.2. Defining the Namespace of a Module

XHTML requires that the elements and attributes declared in a module be within a defined XML namespace [XMLNAMES]. The identification of this namespace is an arbitrary URI. XHTML requires that when a module is implemented using an XML Schema, the module declare its target namespace.

A.2.1. Global and Local Element Declarations

While XML Schema allows an the definition of global and local element declarations, to be compatible with DTD definitions of XHTML Modularization module implementations must not declare local elements.

A.2.2. Global and Local Attribute Declarations

While the approach defined here permits the definition of global as well as attributes declarations, schema authors should consider the consequences of such definitions on an document instance. Global attributes must always be explicitly prefixed in a instance document by declaring a namespace prefix xmlns:prefix, while local attributes depending on the schema implementation may be be explicitly prefixed.

A.3. Content model Redefinitions

Quite often modules change the content model of elements defined by other modules. For example, XHTML Events module add event attributes to element defined by forms module. It is also possible multiple modules may change the content model of a single element defined by a third module, for example both XHTML Events Module and XHTML Image Map module add attributes to elements in form module.

XML Schemas allows for changes to a declared content model using the redefine element. While XML Schema supports redefine element that redefines the named content model and type definition, XML Schema does not directly support redefintion of an element or attribute declaration.

To support element content model redefinitions,

• Schema module implementations must define the content model of an element using named complex types schema component .type. Further the named schema types must be defined in terms of named content model .content and .attlist
• redefine in XML Schema by default includes of the referenced schema, hence module implementations must not directly redefine content model of other modules in its implementation. The redefining module must declare the named content models (model group defintions and/or attribute groups) that may be used for redefinitions by the schema that defines the document model
• Finally, the schema defining document model (of the new document type) may redefine the content model of modules. The redefinitions define the new content model of an included element that comprise the named content models defined in both the redefined module and redefining module.