Contents
This appendix is normative.
XHTML modules are implemented as XML Schemas. When these XML Schemas 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 schema components into a meaningful, cohesive schema is the rules used to define the individual XML Schemas. 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 in order to be called XHTML Family Modules.
This specification classifies named content model into categories and names them consistently using the following suffixes
.content when they are used
to represent the content model of an element type..class when they are used
to represent elements of the same class..mix when they are used to
represent a collection of element types from different classes..extra when they are used
to extend other groups above..export
when they are to be used by a host language as the basis for
extending the related content model (e.g.,
xhtml.Flow.mix could have an
xhtml.Flow.mix.export that defines a collection of
elements that must be included in a redefinition of the
xhtml.Flow.mix by a host language..type when they are used
to represent type of an element. Types usually include the
.attlist and .content components..attlist when they are used
to represent the attributes for a specific element..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 xhtml.Block.mix.
When defining named content models in the classes defined here, modules
should scope the names of the model group definitions and attribute groups
by using unique prefixes (this recommendation uses the prefix
xhtml.). For example, the content model for the element
myelement in the module mymodule could be named
mymodule.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.
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 does not require
that a module declare its target namespace using the
targetnamespace attribute. XHTML Modularization using
XML Schema has adopted a "late binding" approach to associating with a
namespace. This permits the development of so-called "chameleon"
modules, where the elements and attributes of a module can be incorporated into more
than one namespace.
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.
While the approach defined here permits the definition of global as well as local attribute 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 explicitly prefixed.
An XML Schema provides definitions that belong to a given target namespace. A schema must use the import element to include components from an XML Schema that uses a different target namespace. The import element in XML Schema requires a namespace attribute and a optional schemaLocation attribute. Multiple modules (included in a document type) importing components from the same external namespace but providing different schema location URI values will result in invalid driver schema. To avoid such issues modularization requires that modules importing external schemas must not provide a schemaLocation attribute so that a document type's driver file may import these schemas with the schemaLocation attribute.
While the elements and attributes of a module should NOT be in a namespace until they are used
by a markup language, the datatypes that a module relies upon may need to be. This is especially important
if the datatypes are to be shared with other markup languages. If your module has datatypes that you want
to share with other modules, you should define a namespace for those datatypes, place the datatype definitions
in a separate "module" and bind that module to the namespace. In XHTML Modularization, for example, we use
the namespace http://www.w3.org/1999/xhtml/datatypes/.
Quite often modules change the content model of elements defined by other modules. For example, the XHTML Events module adds event attributes to elements defined by the forms module. It is also possible that 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 the use of a redefine element that redefines the named content model and type definition, XML Schema does not directly support redefinition of an element or attribute declaration.
To support element content model redefinitions, all content models are defined with a .content
identifier. This identifier can be easily redefined when creating a driver module.
.type. Further the named schema types
must be defined in terms of named content model .content and
.attlist.export group for each element or content class that
needs to have its content model extended. Host languages will
use this .export group as the basis for the content
model of an element, extending it with whatever additional
content is appropriate.
elements that