W3C home > Mailing lists > Public > www-html-editor@w3.org > January to March 2003

comments on Last Call draft of XHTML Modularization in XML Schema

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: Fri, 31 Jan 2003 20:03:51 -0700
Message-Id: <>
To: www-html-editor@w3.org
Cc: W3C XML Schema IG <w3c-xml-schema-ig@w3.org>


At its face to face meeting in Pasadena earlier this month, the
XML Schema Working Group discussed its review of the Last Call
draft of XHTML Modularization in XML Schema and instructed the
task force responsible to make some changes to the text of our
comments.  Those changes have now been made, and I have the duty
of transmitting to you, on behalf of the XML Schema WG, our
comments on your draft.

We congratulate you on your work and hope our comments, questions,
and suggestions are helpful.  Please get back to us if you have
any questions or if further discussion seems likely to be helpful.

The text of our comments is available in HTML at

I append an ASCII version for the convenience of those who prefer

-C. M. Sperberg-McQueen
  on behalf of the XML Schema WG


Notes on Modularization of XHTML in XML Schema

W3C XML Schema WG

    Ed. by
    C. M. Sperberg-McQueen
    Mary Holstege

31 January 2003

      * 1. [1]Simple types
      * 2. [2]Substitution groups
      * 3. [3]Multiple schemas for one namespace
      * 4. [4]Block and final
      * 5. [5]Namespace conventions
      * 6. [6]External documentation
      * 7. [7]Internal documentation
      * 8. [8]Conformance
      * 9. [9]Exposition
      * 10. [10]Showing the structure of the schema

    This document contains notes on the specification XHTML modularization
    in XML Schema. They have been discussed and approved in their
    substance by the XML Schema Working Group, and the editors have been
    instructed to transmit them to the XHTML Working Group.

    The XML Schema WG congratulates the XHTML Working Group on progressing
    this specification to Last Call status, and we are grateful for the
    opportunity to comment on it.

    We do have a number of comments, questions, and suggestions, which we
    outline in what follows. We have tried to distinguish between comments
    which bear directly upon XML Schema and thus upon our area of
    responsibility and special expertise, on the one hand, and comments
    which make editorial suggestions or technical observations such as any
    reader might make, for which we claim no particular expertise but
    which we offer in the hopes that they may prove useful to you in
    working on your spec.

1. Simple types

    We note with a little puzzlement that the schema does not make use of
    any of the built-in simple datatypes of XML Schema 1.0 except string
    and the legacy types. We can see two possible reasons for this: either

      * it is not clear how best to use the built-in types and type
        derivation constructs of XML Schema 1.0 in order to define the
        datatypes used by XHTML,

    or else

      * the XHTML Working Group has decided, as a matter of principle,
        that the set of documents allowed by the XML Schema 1.0 schema for
        XHTML should be the same as the set of documents allowed by the
        document type definition in [11]XHTML(TM) 1.1 - Module-based
        XHTML, and that the schema should not exploit the ability of XML
        Schema to express the restrictions on datatypes given in [12]sec.
        6 of [13]HTML 4.01 more precisely than can be done in DTD

    Judging by the overall technical quality of the schema, we believe the
    first explanation is implausible, but if there are in fact any
    confusions or questions we will be happy to assist in constructing a

    We are left with the second explanation, which we believe is based
    upon a misconception of the nature of XML and SGML DTDs. If the second
    explanation is not a correct reflection of the XHTML Working Group's
    reasoning, we apologize for taking up your time with the following

    Let us consider, as a simple example, the legal values for the cite
    and datetime attributes on the ins and del elements.
    XHTML 1.1 defines these attributes this way in

       <!ATTLIST %ins.qname;
             cite         %URI.datatype;           #IMPLIED
             datetime     %Datetime.datatype;      #IMPLIED

    and in

       <!-- date and time information. ISO date format -->
       <!ENTITY % Datetime.datatype "CDATA" >

       <!--* ... *-->

       <!-- a Uniform Resource Identifier, see [URI] -->
       <!ENTITY % URI.datatype "CDATA" >

    Section 21 of [16]HTML 4.01 defines them similarly, and makes explicit
    that dates must use ISO date format.

    Working with these declarations, a validating XML parser will accept
    elements like the following as legal in an XHTML document:

       <p>This deliverable will
       <ins datetime="Friday">probably</ins>
       be ready by Monday.</p>

    The schema presented in the document under review similarly allows
    such elements.

    The problem is that the elements in question are not legal according
    to the document type definition for XHTML.

    A document type definition is the set of rules governing the
    application of markup to a given type of document. The term is not
    formally defined by the XML 1.0 specification, but it is formally
    defined by ISO 8879:

       4.105 document (type) definition: Rules, determined by an
       application, that apply SGML to the markup of documents of a
       particular type.

       NOTE -- Part of a document type definition can be specified by
       an SGML documt type declaration. Other parts, such as the
       semantics of elements and attributes, or any application
       conventions, cannot be expressed formally in SGML. Comments can
       be used, however, to express them informally.

    That is, a DTD is not identical to the set of element declarations,
    attribute declarations, notation declarations, etc., used by a
    validating parser. A document type definition is captured by such
    declarations only in part: application conventions and other rules not
    captured by the formal declarations are strictly part of the document
    type definition. As we understand the specifications, the definition
    of XHTML 1.1 is based on, and logically incorporates, the
    documentation and other rules of XHTML 1.0, which in turn relies on
    and logically incorporates the rules for element usage enunciated in
    HTML 4.01.

    In HTML 4.01, Datetime and URI do not appear to be intended as
    synonyms for CDATA: the parameter entities are used (as we understand
    the spec) to signal additional rules and semantics which go beyond
    those expressed by the keyword CDATA. The documentation seems to us to
    make clear that in the languages defined by the family of XHTML
    specifications, the string Friday is not a legal lexical form for a
    date-time value, and thus that the example given above is not in fact
    legal XHTML, despite the fact that element and attribute declarations
    which use XML 1.0 DTD notation are not in a position to enforce all of
    the relevant rules.

    We believe strongly that any schema for XHTML, whatever schema
    language it is expressed in (XML 1.0 DTD notation or XML Schema 1.0 or
    any other) should capture as much of the definition of the language as
    its notation is capable of capturing.[[17]1]

    That means that the schema expressed in XML Schema 1.0 notation should
    make use of the dateTime, anyURI, and other built-in simple types, and
    should use the pattern construct of XML Schema to capture, as
    accurately as possible, the rules for legal lexical forms of the
    datatypes used by XHTML.

    Only then will the schema for XHTML in the document under review
    actually match up with the document type definition for XHTML.
    We believe this to be a severe problem and recommend that you not go
    to CR without changing your schema to use the appropriate built-in
    simple types.

2. Substitution groups

    We think the schema documents can and should make greater use of
    substitition groups. This is, to be sure, partly a matter of taste,
    and the free use of substitution groups in the schema defined here is
    somewhat hampered by the restriction in XML Schema 1.0 which requires
    an element to be a member of at most one substitution group. (XHTML
    may become the poster child for multiple-substitition group support;
    you may wish to comment on item RQ-99 in our candidate requirements
    for XML Schema 1.1.)

    It is our experience that the use of substitution groups makes schemas
    much more readable and easier to extend. At the very least the bottom
    level groups could be substitution groups.

    Compare the following example, which uses choice groups in the way the
    schema here does, with the example further below. Using choice groups,
    the base schema reads thus:

          <xsd:element ref="one.foo"/>
          <xsd:element ref="two.foo"/>

     <xsd:element name="one.foo">
           <xsd:element ref="one.contents"/>

    An extension of this schema must redefine the group, thus:

     <xsd:redefine schemaLocation="wherever">
        <xsd:group name="foo.class">
              <xsd:group ref="foo.class"/>
              <xsd:element ref="my.foo"/>

     <xsd:complexType name="my.type">
         <xsd:element ref="my.contents"/>

     <xsd:element name="my.foo" type="my.type"/>

    If substitution groups are used, then the type definition becomes
    slightly more complex: we need to ensure that all the foo's are
    type-related to the head of the substitution group. In the worst case,
    this gives us an extra type definition for the head of the
    substitution group, and an extra restriction for the type of each
    member in the group (where members of the group have no substructure
    in common). Most cases, including XHTML, are better than the worst
    case. The base schema reads:

    <xsd:complexType name="foo.type">
      <xsd:extension base="xsd:anyType"/>

     <xsd:element name="one.foo">
           <xsd:restriction base="foo.type">
               <xsd:element ref="whatever"/>

    <xsd:element name="foo.class" abstract="true" type="foo.type"/>

    In a schema which extends this base, the definition of the type of the
    new member of the class must pick up a new relation with the base type
    of the class (hence an extra restriction). But adding the new element
    to the existing class is much simpler: the new element just declares
    itself as a member of the class. If several new elements share the
    same type, the simplicity of adding them to the class more than
    outweighs the need for an additional type definition. If they use the
    same type as the head of the substitution group, there is no need for
    any additional type definition at all.

     <xsd:complexType name="my.type">
         <xsd:restriction base="foo.type">
             <xsd:element ref="my.contents"/>

     <xsd:element name="my.foo" type="my.type" substitutionGroup="foo.class"/>

    We strongly recommend that you exploit substitution groups in your

3. Multiple schemas for one namespace

    (Partly editorial, partly substantive) Given that the XHTML namespace
    is associated with not one but many schemas, covering a family of
    related languages, we believe that it would be in order to discuss the
    consequences, for the user and for the software developer, of this
    fact. Section 3.3 says

      The behavior of any XML processor in cases of validation errors is
      well-defined in the XML 1.0 specification. Therefore the real test
      of any modularization system for XHTML is whether the resulting
      schema can be used to determine if any particular XHTML document
      instance is valid.

    but we believe that this description covers only one of two equally
    important scenarios. It is important to know whether, given a
    particular schema, one can use the schema to validate an XHTML
    document and produce the correct answer.

    But for the software developer, it is also a matter of moment to know,
    given a particular XHTML document, how to locate the appropriate
    schema for the particular language variant intended. Since there are
    multiple schemas and schema documents for items in the XHTML
    namespace, the software cannot usefully be instructed simply to
    dereference the appropriate namespace name and take what it finds
    there. Should software which processes XHTML documents trust the
    schemaLocation hints it finds in the document instance? Should it, on
    the contrary, rely on out-of-band specifications of some sort? What
    alternatives might there be?

    We think it would be highly desirable to include in this specification
    a discussion of the facts of the matter, some of the consequences of
    those facts, some account of the alternative approaches schema
    processors might take, warnings of the pitfalls, perhaps even some
    recommended best practices with take-home notes for vendors.

    We will be happy to engage with the XHTML WG in discussing and
    clarifying these issues.

4. Block and final

    We note that the schema element defines blockDefault="#all" and
    finalDefault="#all", and that the element declarations in the modules
    all take these default values.

    We think this is somewhat more restrictive than you may wish to be:
    finalDefault="#all" means that no schema authors (including you) may
    derive new types on the basis of types defined in these modules,
    whether by restriction or by extension, and blockDefault="#all" means
    that elements with derived types (say, date-after-1990, as a
    restriction of date) must not be substituted where their base type is
    expected. Each of these constraints is much more restrictive than the
    rules in DTD-based XHTML Modularization, and we believe each
    unnecessarily impairs the utility of the schema you provide.

    We strongly recommend that you change these defaults to allow further
    derivation of types on the basis of the types you define, and to allow
    the substitution of types derived by extension or restriction
    everywhere except in those places where you believe such a
    substitution would be hard for software to handle.

5. Namespace conventions

    We do not understand Section 2.2.6.

    The second paragraph seems to say either (a) that it is a rule of
    XHTML Modularization that elements and attributes in the XHTML
    namespace need not be qualified when used in document instances, no
    matter what the Namespaces in XML Recommendation says, or (b) that the
    schema documents provided declare the XHTML namespace as the default
    namespace, so that no namespace prefixes are required for this
    namespace and none will be found in the schema documents.

    The first interpretation seems dangerous to us; we hope you intend the
    second meaning. But the ability to use unprefixed (not unqualified!)
    names in the schema documents is a consequence of the way you deploy
    namespace declarations in the schema documents themselves, not of
    anything special to the XML Schema language.

    Paragraph 3 is wrong to imply that the elementFormDefault has any
    effect at all in this schema: the elementFormDefault attribute on the
    schema element provides a default value for the form attributes on
    local element declarations. It has no effect on top-level (global)
    element declarations, only on element declarations which are local to
    some complex type. Since your schema has no local element
    declarations, only global (top-level) ones, the elementFormDefault
    attribute on the schema element has no effect.

    We believe that this specification should not go forward to CR without
    a clarification of this section.

6. External documentation

    (Editorial suggestion) The schema documents would be more useful, we
    believe, if each definition or declaration pointed to the part(s) of
    the XHTML spec which document the construct being declared or defined.
    For example, instead of

         <!-- date and time information. ISO date format -->
         <xs:notation name="datetime"
           public="-//W3C//NOTATION XHTML Datatype: Datetime//EN"/>

    it would probably be preferable to write

         <!-- date and time information. ISO date format -->
         <xs:notation name="datetime"
           public="-//W3C//NOTATION XHTML Datatype: Datetime//EN">

    (In this particular case, it would also be preferable to derive a type
    from the built-in dateTime type.)

7. Internal documentation

    The internal documentation would perhaps be more useful -- it would
    certainly be easier to display nicely -- if it were marked up with
    HTML. The schema for XML Schema documents is designed to make this
    fairly simple. Since in these schema documents the XHTML namespace is
    already declared as the default namespace, you can simply use HTML
    instead of ASCII text without markup inside of documentation elements.
    Alternatively, in order to stress for human readers that the markup
    used inside documentation elements is XHTML, you could use an explicit
    prefix for it:

       <?xml version="1.0" encoding="UTF-8"?>
       <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

             <html:p>This is the XML Schema Hypertext module for XHTML
             This is a REQUIRED module.</html:p>

             <html:p>@author: Daniel Austin austin.d@ic.grainger.com<html:br/>
             $Id: xmlschema-notes-on-xhtml-modularization.html,v 1.4 
2003/02/01 02:50:
       19 cmsmcq Exp $</html:p>
           <xs:documentation source="../../xhtml-copyright-1.xsd"/>
         <!--* ... and so on ... *-->

    A schemaLocation attribute can also be used to specify where to find
    the schema for XHTML, if desired or if needed for some tools:

       <?xml version="1.0" encoding="UTF-8"?>
       <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
         <!--* ... and so on ... *-->

    We strongly urge you to exploit the ability to provide high-quality
    marked-up documentation in your schema documents.

8. Conformance

    We have some questions relating to the conformance clauses in
    [18]section 3.3.

    (Editorial) The definition of conformance in section 3.3.1 requires
    (in its first bullet) that schemas defining XHTML language variants
    conform to "the published language definition for that language
    variant". It is not clear to us whether this means that only W3C
    Recommendations can define language profiles by specifying a selection
    from these modules, or only that any language variant have a published

    (Substantive and fairly severe) The definition of conformance in
    section 3.3.3 is not satisfiable for any schema defined using XML
    Schema, since it requires the schema to define html as the root
    element of the document type. XML Schema has no mechanism for
    specifying, in a schema, that the root of the document must be an
    element of a certain element type. (An XML Schema document may be
    thought of as analogous, in this, to the DTD files conventionally used
    as external DTD subsets: they, also, have no declaration stipulating
    that the document element must be called html: it is only the DOCTYPE
    declaration in the document instance which makes that stipulation.)

    We suggest that this requirement be removed. It may be replaced (this
    is your call) by a requirement that XHTML documents must use an html
    element in the XHTML namespace as their document element, if you wish.
    It is probably also reasonable to require that schemas for members of
    the XHTML family allow an html element to appear as the document
    element; otherwise no XHTML document could conform to the schema.

    (Editorial / clarification) We are confused by the terminology used
    here: the term "XHTML Family of Documents" appears to denote a set of
    documents, but the definition describes not a set of documents but a
    set of languages ("the set of language variants that ..."). Perhaps
    two distinct definitions are needed?

     1. The XHTML Family of Document Types (or ... of Document
        Definitions, or ... of Langage Variants, or ... of Applications)
        is the set of language variants which ...
     2. The XHTML Family of Documents is the set of documents which are
        members of one or more of the XHTML Family of Language Variants,
        and which use the element html in the XHTML namespace as their
        document element.

    Section 3.3.1 appears to define the conformance of schemas defining
    language variants within the XHTML namespace. Section 3.3.2 defines
    conformance of schemas in general. Section 3.3.3 defines the XHTML
    Family of Documents. We don't see any definition of conformance for
    the use of these modules in other contexts, but we believe that use of
    specific XHTML modules in the context of other top-level XML
    Structures is an important use case. For example, a schema author
    might pull in specific XHTML modules for use in the internal
    documentation of an XML Schema document. The author of a schema for a
    specialized document type might wish to pull in the XHTML modules for
    lists and tables, while providing different modules for phrase-level
    elements and fundamental document structure. And so on.

    We suggest that a definition of conformance be provided for the use of
    these modules in other contexts, where html is not the document
    element. This will make more explicit that the modules are indeed
    intended to be used in this way, and will encourage their reuse in a
    broader range of applications.

    We believe, without being completely certain, that what we are
    requesting is an analogue, in this specification, to the XHTML
    Integration Set Document Type Conformance defined in the XHTML
    Modularization spec. Since XML Schema supports module integration
    somewhat more conveniently than do DTDs, we believe it important to
    signal, by means of defining a conformance clause for it, that such
    use is intended. (Some document type designers in the WG would add
    that they believe the definition of conformance here should not
    require the inclusion of as many modules as is required by XHTML
    Integration Set Document Type Conformance, but this belief does not
    command the consensus of the XML Schema WG.)

    We strongly urge you to add a definition of conforming uses of these
    modules; whether or not such a definition is added, we urge you also
    to clarify the definition of the XHTML Family and ensure that both the
    term defined and the definition suggest the same type of members
    (documents or languages) for the family. We do not believe this spec
    should progress to CR without revision of the clause relating to html
    being the root element.

9. Exposition

    (Editorial) Apart from the schema proper, we think it would be very
    useful, and crucial for proper uptake, to have better exposition of
    the various extension scenarios. There was one example showing a
    redefine for one case; we should have liked more, even though we have
    experience writing schemas that use redefine.

    We believe examples would help in the Conformance section, as well.

10. Showing the structure of the schema

    (Editorial suggestion) We believe it would be useful to provide a pair
    of some sort of tree diagrams, illustrating both the structure of the
    schema directories and the graph of inclusions in the various schema
    documents of the schema.

    For example:

      * xhtml1.1.xsd
           + includes xhtml-required-1.xsd
                o includes req/xhtml-framework-1.xsd
                     # includes req/framework/xhtml-notations-1.xsd
                     # includes req/framework/xhtml-datatypes-1.xsd
                     # includes req/framework/xhtml-attribs-1.xsd
                          @ imports namespace
                            http://www.w3.org/XML/1998/namespace (from
                            schema at xml-attribs-1.xsd)
                     # includes req/framework/xhtml11-model-1.xsd
                     # includes req/framework/xhtml-charent-1.xsd
                o includes req/xhtml-core-1.xsd
                     # includes req/core/xhtml-text-1.xsd
                          @ includes req/core/text/xhtml-blkphras-1.xsd
                          @ includes req/core/text/xhtml-blkstruct-1.xsd
                          @ includes req/core/text/xhtml-inlphras-1.xsd
                          @ includes req/core/text/xhtml-inlstruct-1.xsd
                     # includes req/core/xhtml-hypertext-1.xsd
                     # includes req/core/xhtml-list-1.xsd
                     # includes req/core/xhtml-struct-1.xsd
           + includes xhtml-optional-1.xsd
                o includes opt/xhtml-edit-1.xsd
                o includes opt/xhtml-bdo-1.xsd
                o includes opt/xhtml-pres-1.xsd
                     # includes opt/pres/xhtml-blkpres-1.xsd
                     # includes opt/pres/xhtml-inlpres-1.xsd
                o includes opt/xhtml-link-1.xsd
                o includes opt/xhtml-meta-1.xsd
                o includes opt/xhtml-base-1.xsd
                o includes opt/xhtml-script-1.xsd
                     # imports namespace
                       http://www.w3.org/XML/1998/namespace (from schema
                       at ../req/framework/xml-attribs-1.xsd)
                     # req/framework/xml-attribs-1.xsd
                o includes opt/xhtml-style-1.xsd
                o includes opt/xhtml-inlstyle-1.xsd
                o includes opt/xhtml-image-1.xsd
                o includes opt/xhtml-csismap-1.xsd
                o includes opt/xhtml-ssismap-1.xsd
                o includes opt/xhtml-param-1.xsd
                o includes opt/xhtml-applet-1.xsd
                o includes opt/xhtml-object-1.xsd
                o includes opt/xhtml-table-1.xsd
                o includes opt/xhtml-form-1.xsd
                o includes opt/xhtml-ruby-1.xsd

    Or, going into more detail:

      * xhtml1.1.xsd
           + includes xhtml-required-1.xsd
                o includes req/xhtml-framework-1.xsd
                     # includes req/framework/xhtml-notations-1.xsd
                          @ declares notations w3c-xml, cdata, fpi,
                            character, charset, charsets, contentType,
                            contentTypes, datetime, languageCode, length,
                            linkTypes, mediaDesc, multiLength, number,
                            pixels, script, text, uri, uris
                     # includes req/framework/xhtml-datatypes-1.xsd
                          @ defines simple types Length, LinkTypes,
                            MediaDesc, MultiLength, Number, Pixels,
                            Script, Color, Text, Character, Charset,
                            Charsets, ContentType, ContentTypes, Datetime,
                            FPI, LanguageCode, URI, URIs, MultiLengths
                     # includes req/framework/xhtml-attribs-1.xsd
                          @ imports namespace
                            http://www.w3.org/XML/1998/namespace (from
                            schema at xml-attribs-1.xsd)
                          @ defines attribute groups id, class, title,
                            Core.extra.attrib, Core.attrib, BIDI,
                            I18n.attrib, Common.extra, Common.attrib
                     # includes req/framework/xhtml11-model-1.xsd
                          @ defines model groups HeadOpts.mix, Edit.class,
                            Script.class, Misc.extra, Misc.class,
                            InlStruct.class, InlPhras.class,
                            InlPres.class, I18n.class, Anchor.class,
                            InlSpecial.class, InlForm.class, Inline.extra,
                            Ruby.class, Inline.class, InlNoRuby.class,
                            InlNoAnchor.class, InlNoAnchor.mix,
                            Inline.mix, Heading.class, List.class,
                            BlkStruct.class, BlkPhras.class,
                            BlkPres.class, BlkSpecial.class, Block.extra,
                            Block.class, Block.mix, Flow.mix
                          @ defines complex type NoRuby.content
                     # includes req/framework/xhtml-charent-1.xsd
                o includes req/xhtml-core-1.xsd
                     # includes req/core/xhtml-text-1.xsd
                          @ includes req/core/text/xhtml-blkphras-1.xsd
                               - defines attribute groups address.attlist,
                                 blockquote.attlist, pre.attlist,
                               - defines model group pre.content
                               - defines complex types address.type,
                                 blockquote.type, pre.type, heading.type
                               - declares elements address, blockquote,
                                 pre, h1, h2, h3, h4, h5, h6
                          @ includes req/core/text/xhtml-blkstruct-1.xsd
                               - defines attribute groups div.attlist,
                               - defines complex types div.type, p.type
                               - declares elements div, p
                          @ includes req/core/text/xhtml-inlphras-1.xsd
                               - defines attribute groups
                                 InlPhras.attlist, q.attlist
                               - defines complex types InlPhras.type,
                               - declares elements abbr, acronym, cite,
                                 code, dfn, em, kbd, samp, strong, var, q
                          @ includes req/core/text/xhtml-inlstruct-1.xsd
                               - defines attribute groups br.attlist,
                               - defines complex types br.type, span.type
                               - declares elements br, span
                     # includes req/core/xhtml-hypertext-1.xsd
                          @ defines attribute group a.attlist
                          @ defines complex type a.type
                          @ declares element a
                     # includes req/core/xhtml-list-1.xsd
                          @ defines attribute groups dt.attlist,
                            dd.attlist, dl.attlist, li.attlist,
                            ol.attlist, ul.attlist
                          @ defines model group dl.content
                          @ defines complex types dt.type, dd.type,
                            dl.type, li.type, ol.type, ul.type
                          @ declares elements dt, dd, dl, li, ol, ul
                     # includes req/core/xhtml-struct-1.xsd
                          @ defines attribute groups title.attlist,
                            head.attlist, body.attlist, html.attlist
                          @ defines model group head.content
                          @ defines complex types title.type, head.type,
                            body.type, html.type
                          @ declares elements title, head, body, html
           + includes xhtml-optional-1.xsd
                o includes opt/xhtml-edit-1.xsd
                     # defines attribute group edit.attlist
                     # defines model group edit.content
                     # defines complex type edit.type
                     # declares elements ins, del
                o includes opt/xhtml-bdo-1.xsd
                     # defines attribute group bdo.attlist
                     # defines complex type bdo.type
                     # declares element bdo
                o includes opt/xhtml-pres-1.xsd
                     # includes opt/pres/xhtml-blkpres-1.xsd
                          @ defines attribute group hr.attlist
                          @ defines complex type hr.type
                          @ declares element hr
                     # includes opt/pres/xhtml-inlpres-1.xsd
                          @ defines attribute group InlPres.attlist
                          @ defines complex type InlPres.type
                          @ declares elements b, big, i, small, sub, sup,
                o includes opt/xhtml-link-1.xsd
                     # defines attribute group link.attlist
                     # defines complex type link.type
                     # declares element link
                o includes opt/xhtml-meta-1.xsd
                     # defines attribute group meta.attlist
                     # defines complex type meta.type
                     # declares element meta
                o includes opt/xhtml-base-1.xsd
                     # defines attribute group base.attlist
                     # defines complex type base.type
                     # declares element base
                o includes opt/xhtml-script-1.xsd
                     # imports namespace
                       http://www.w3.org/XML/1998/namespace (from schema
                       at ../req/framework/xml-attribs-1.xsd)
                     # req/framework/xml-attribs-1.xsd
                          @ defines attribute group specialAttrs
                          @ declares attributes lang, space
                     # defines attribute groups script.attlist,
                     # defines complex types script.type, noscript.type
                     # declares elements script, noscript
                o includes opt/xhtml-style-1.xsd
                     # defines attribute group style.attlist
                     # defines complex type style.type
                     # declares element style
                o includes opt/xhtml-inlstyle-1.xsd
                     # defines attribute group style.inline.attlist
                o includes opt/xhtml-image-1.xsd
                     # defines attribute group img.attlist
                     # defines complex type img.type
                     # declares element img
                o includes opt/xhtml-csismap-1.xsd
                     # defines attribute groups a.csim.attlist,
                       img.csim.attlist, input.csim.attlist,
                       object.csim.attlist, shape.attrib, area.attlist,
                     # defines model group map.content
                     # defines complex types area.type, map.type
                     # declares elements area, map
                o includes opt/xhtml-ssismap-1.xsd
                     # defines attribute group img.ssimap.attlist
                o includes opt/xhtml-param-1.xsd
                     # defines attribute group param.attlist
                     # defines complex type param.type
                     # declares element param
                o includes opt/xhtml-applet-1.xsd
                     # defines attribute group applet.attlist
                     # defines model group applet.content
                     # defines complex type applet.type
                     # declares element applet
                o includes opt/xhtml-object-1.xsd
                     # defines attribute group object.attlist
                     # defines model group object.content
                     # defines complex type object.type
                     # declares element object
                o includes opt/xhtml-table-1.xsd
                     # defines attribute groups frame.attrib,
                       rules.attrib, CellVAlign.attrib, CellHAlign.attrib,
                       scope.attrib, td.attlist, th.attlist, tr.attlist,
                       col.attlist, colgroup.attlist, tbody.attlist,
                       tfoot.attlist, thead.attlist, caption.attlist,
                     # defines model groups tr.content, colgroup.content,
                       tbody.content, tfoot.content, thead.content,
                       caption.content, table.content
                     # defines complex types td.type, th.type, tr.type,
                       col.type, colgroup.type, tbody.type, tfoot.type,
                       thead.type, caption.type, table.type
                     # declares elements td, th, tr, col, colgroup, tbody,
                       tfoot, thead, caption, table
                o includes opt/xhtml-form-1.xsd
                     # defines attribute groups form.attlist,
                       label.attlist, type.attrib, input.attlist,
                       select.attlist, optgroup.attlist, option.attlist,
                       textarea.attlist, fieldset.attlist, legend.attlist,
                     # defines model groups Table.class, BlkNoForm.mix,
                       form.content, label.content, select.content,
                       optgroup.content, button.content
                     # defines complex types form.type, label.type,
                       input.type, select.type, optgroup.type,
                       option.type, textarea.type, fieldset.type,
                       legend.type, button.type
                     # declares elements form, label, input, select,
                       optgroup, option, textarea, fieldset, legend,
                o includes opt/xhtml-ruby-1.xsd
                     # defines attribute groups Ruby.common.attrib,
                       Ruby.common.attlist, Rbc.attrib, Rtc.attrib,
                       Rb.attrib, Rt.attrib, Rp.attrib
                     # defines model groups Ruby.content.simple,
                       Ruby.content.group, Ruby.content
                     # defines complex types Ruby.type, Rbc.type,
                       Rtc.type, Rb.type, Rt.type, Rp.type
                     # declares elements ruby, rbc, rtc, rb, rt, rp


    [[19]1] As a general rule, this holds for any schema for any language,
    but in particular cases there might also be a need for more forgiving
    schemas, analogous to the transitional DTDs which have been part of
    recent HTML specifications.


   11. http://www.w3.org/TR/xhtml11/
   12. http://www.w3.org/TR/html401/types.html
   13. http://www.w3.org/TR/html401/
   14. http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-edit-1.mod
   15. http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-datatypes-1.mod
   16. http://www.w3.org/TR/html401/
Received on Friday, 31 January 2003 22:05:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:08:48 UTC