- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: Fri, 31 Jan 2003 20:03:51 -0700
- To: www-html-editor@w3.org
- Cc: W3C XML Schema IG <w3c-xml-schema-ig@w3.org>
Colleagues:
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
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html
I append an ASCII version for the convenience of those who prefer
it.
-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
notation.
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
schema.
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
digression.
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
[14]http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-edit-1.mod:
<!ATTLIST %ins.qname;
%Common.attrib;
cite %URI.datatype; #IMPLIED
datetime %Datetime.datatype; #IMPLIED
>
and in
[15]http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-datatypes-1.mod:
<!-- 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:group>
<xsd:choice>
<xsd:element ref="one.foo"/>
<xsd:element ref="two.foo"/>
</xsd:choice>
</xsd:group>
<xsd:element name="one.foo">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="one.contents"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
An extension of this schema must redefine the group, thus:
<xsd:redefine schemaLocation="wherever">
<xsd:group name="foo.class">
<xsd:choice>
<xsd:group ref="foo.class"/>
<xsd:element ref="my.foo"/>
</xsd:choice>
</xsd:group>
</xsd:redefine>
<xsd:complexType name="my.type">
<xsd:sequence>
<xsd:element ref="my.contents"/>
</xsd:sequence>
</xsd:complexType>
<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:complexType>
<xsd:element name="one.foo">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction base="foo.type">
<xsd:sequence>
<xsd:element ref="whatever"/>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<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:complexContent>
<xsd:restriction base="foo.type">
<xsd:sequence>
<xsd:element ref="my.contents"/>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="my.foo" type="my.type" substitutionGroup="foo.class"/>
We strongly recommend that you exploit substitution groups in your
schema.
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">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/html401/types.html#h-6.11"/>
</xs:annotation>
</xs:notation>
(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"
targetNamespace="http://www.w3.org/1999/xhtml"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:html="http://www.w3.org/1999/xhtml"
elementFormDefault="unqualified"
attributeFormDefault="unqualified"
blockDefault="#all"
finalDefault="#all">
<xs:annotation>
<xs:documentation>
<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>
<xs:documentation source="../../xhtml-copyright-1.xsd"/>
</xs:annotation>
<!--* ... 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"
targetNamespace="http://www.w3.org/1999/xhtml"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:html="http://www.w3.org/1999/xhtml"
elementFormDefault="unqualified"
attributeFormDefault="unqualified"
blockDefault="#all"
finalDefault="#all"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.w3.org/1999/xhtml
http://www.w3.org/TR/xhtml-m12n-schema/SCHEMA/xhtml1.1.xsd">
<!--* ... 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
description.
(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,
heading.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,
p.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,
q.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,
span.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,
tt
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,
noscript.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,
map.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,
table.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,
button.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,
button
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
_________________________________________________________________
Notes
[[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.
References
1.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3b7
2.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3b9
3.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3c11
4.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3c13
5.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3c15
6.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3c17
7.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3c19
8.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3c21
9.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3c23
10.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3c25
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/
17.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ab2b3b3b7c11b1
18.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html
19.
http://www.w3.org/XML/Group/2003/01/xmlschema-notes-on-xhtml-modularization.html#ref-to-ab2b3b3b7c11b1
Received on Friday, 31 January 2003 22:05:48 UTC