XML Modularization of HTML 4.0
NOTE-xhtml-modular-19990201
XML Modularization of HTML 4.0
Sun Microsystems Note - 1 February 1999
Copyright 1999 Sun Microsystems, Inc. All rights reserved.
This version
http://www.altheim.com/specs/xhtml/NOTE-xhtml-modular-19990201.html
Latest version
http://www.altheim.com/specs/xhtml/NOTE-xhtml-modular.html
Previous version
http://www.altheim.com/specs/xhtml/NOTE-xhtml-modular-19990125.html
Author:
Murray Altheim, Sun Microsystems
Status of this Document
This document is a Sun Microsystems draft document intended for public review and
comment. It does not represent a product of, nor has it been approved by the W3C
HTML Working Group or any other body and may be
updated, replaced, or rendered obsolete by other documents at any time. It is
inappropriate to use this document as reference material or to cite it as other
than a "work in progress".
[Temporary text in this specification is offset in light blue like
this passage. This represents an early working draft, and is still incomplete in many
areas of the prose text. See the section on Availability for specific information on the DTD and associated files. Also see
Appendix E. for revision information.]
Errors or omissions in this document should be reported to the
author.
Abstract
This document describes a modularized XML document type based on HTML 4.0,
explains the modularization model used, guidelines for extending HTML using this
model, and an example extension using the MathML DTD.
It includes XML DTDs and all necessary support files.
Because concepts of DTD modularization are often misunderstood, many terms
are defined in detail, an explanatory section on modularization as well as a
discussion of the HTML 4.0 document model are provided.
1. Introduction
This document describes a modularization model for HTML 4.0 modified for
compatibility with XML 1.0, including:
an explanation on what is meant by "modularization"
definitions for many key terms used in the document
modularization design issues for HTML and XML
differences between SGML and XML that necessitate changes in both the DTD
and the HTML document model itself
a detailed analysis of the document structures inherent in the HTML 4.0
document type
specific design structures used in modularization of HTML 4.0
the DTD modules and their contents
drivers for modularized HTML 4.0 Strict, Transitional and Frameset DTDs
guidelines for DTD fragment use
guidelines for extension
an example extension, adding MathML [MATHML] to the HTML document model
In this document XHTML (ie.,
"extensible HTML") is used to refer to this XML reformulation of HTML 4.0 rather
than the W3C HTML Working Group code name Voyager, in order to reduce
confusion with the products of the Working Group.
1.1 Contents
This document is organized as follows:
1. Introduction
describes design goals, relations to other specifications, and defines
key terms
2. Modularization Concepts
introduces basic modularization concepts, without
regard to the specifics of the HTML modularization
3. Differences Between SGML and XML
describes the differences between SGML and XML
that affect DTD and document model design
4. HTML 4.0 Document Model
describes the HTML document model and design rationale
used in developing the modularization model
5. Modularization of HTML 4.0
describes the specific design structures used in the
modularization model and introduces the XML modules
6. Packaging and Delivery
describes the DTD driver files for XML modularized versions
of HTML 4.0 Strict, Transitional and Frameset DTDs and
guidelines on packaging and delivery
7. Extending XHTML
describes guidelines for use of DTD fragments, for
extending a modular DTD, including an example extension
using MathML
8. XHTML as an Architecture
describes use of XHTML as an architecture, describing an optional
architectural forms module and how it might be used
Appendix A. XML Files
A.1 Catalog File
A.2 DTD Drivers
A.3 DTD Modules
A.4 Normalized DTDs
Appendix B. Document Model Changes
Appendix C. References
Appendix D. Acknowledgements
1.2 Design Goals
This document is the result of a requirements analysis based on document
interoperability and application compatibility needs, experience with SGML and
XML conversion issues, and much thought and discussion about the role of a
modularized HTML DTD as a reference XML document type, a well-understood
foundation for extension into other knowledge domains.
Following is the set of design goals used in preparation of this document:
This specification shall be strictly conformant with the XML 1.0 specification.
This specification shall not be in conflict with the XML linking or stylesheet
specifications.
This specification shall endeavour to conform to the HTML 4.0 document model
as closely as possible. Where conformance varies, this should be noted in this
specification. (A section that hilights these differences is included.)
This specification is to represent an expression of the highest priority of the
need for an XML modularization of HTML, that is, to act as a reference
document type for the use of HTML markup in XML environments, and
is designed for use as fragments, subsets, extensions and other variants.
Whereas the HTML 4.0 document model is to be matched wherever possible, when a
variance must be made, the goal is expressly not to create a conversion DTD
for use as a target document type for conversions from HTML, but a reference
DTD that preserves an assumed intention of the HTML document model. When
a variance is made, a secondary goal will be the simplicity of the DTD design,
with reuse in mind. For a discussion of DTD types, see Section 3.1.3 of [DEVDTD].
Clarity and reusability are of utmost importance.
Both public and system identifiers are to be supplied for all external entities.
1.3 How this document relates to other specifications
This document is also informed by or related to other specifications and documents.
Among these are some of note:
1.3.1 W3C Recommendation
Extensible Markup Language (XML) 1.0
This document describes a compliant application of the W3C Recommendation
Extensible Markup Language (XML) 1.0 [XML].
1.3.2 W3C Recommendation
HTML 4.0 Specification
This document describes document types based on the W3C HTML 4.0 Recommendation
[HTML40]. This includes XML versions of
the HTML 4.0 Strict, Transitional, and Frameset DTDs. Where significant changes
are necessary in the transformation to XML, these are noted in this document.
1.3.3 W3C Recommendation
Mathematical Markup Language (MathML) 1.0 Specification
This document describes an document type extension incorporating the W3C
MathML 4.0 Recommendation [MATHML].
Where changes are necessary, these are noted in this document. In particular,
two element type names are in conflict between the two markup languages which
must be resolved. Decisions regarding this matter will be made in cooperation
with the W3C HTML Working Group and the authors of the MathML specification.
1.3.4 W3C Working Draft
Reformulating HTML in XML
While informed by the ongoing work of the W3C HTML Working Group (of which the
author is an active member), this document does not represent a W3C product, nor
does it follow all decisions made by the W3C in its XML version of HTML 4.0,
code-named "Voyager", as described in the Working Draft
Reformulating HTML in XML [HTMLXML].
In particular, the element content models of this specification match those of
the HTML 4.0 SGML DTD at a child level, which is not the case with the W3C
product. The modularization model also differs greatly, as is described in detail
below. Where a choice is made between matching the document model of HTML 4.0 vs.
Voyager, this specification favors HTML 4.0. When this specification varies from
both HTML 4.0 and Voyager, it will be noted.
Both this specification and Voyager adopt a minimalist approach in implementing
XML markup, such as supplementing HTML with XML linking or other syntax. Both
specifications add xml:lang and xml:space where appropriate;
this specification fleshes out all XLink attributes on the HTML anchor element,
whereas Voyager only adds the xml:link attribute itself.
This specification will track HTML 4.0 errata as they are addressed by the
W3C HTML Working Group.
1.3.5 W3C Working Draft
XML Linking Language (XLink)
This specification implements all appropriate XLink attributes on the HTML
anchor ("A") element in order to promote experimentation. Since the
XLink specification [XLINK] is still a
W3C Working Draft, users should follow the same precautions in working with
any work-in-progress. Because XLink is expected to be the de facto
standard for linking in XML, this specification will track changes that affect
its experimental usage.
1.3.6
Developing SGML DTDs: From Text to Model to Markup
This specification and its author owe a debt of gratitude to many industry
experts. They have published a number of excellent online and printed sources of
information on SGML, HTML and XML, but few specifically on document type design.
A primary resource used in development of this document is the text by Eve Maler and
Jeanne El Andaloussi, Developing SGML DTDs: From Text to Model to Markup
[DEVDTD]. Eve Maler and Terry Allen are the
principal editors and maintainers of the DocBook 3.0 DTD, which provides an industry
benchmark in the development and use of a modularized DTD. Helpful in his regard
is the Customizer's Guide to the DocBook DTD V2.4.1 (see [DOCBOOK]), by Eve Maler and Terry Allen.
1.4 Definitions
While some terms are defined in place, the following definitions are used
throughout this document. Readers may not fully understand these definitions
without also reading through the specification. Familiarity with the W3C
XML 1.0 Recommendation [XML] is highly recommended.
document type
a class of documents sharing a common abstract structure.
The ISO 8879 [SGML] definition is
as follows: "a class of documents having similar characteristics; for
example, journal, article, technical manual, or memo. (4.102)"
document model
the effective structure and constraints of a given document type.
The document model constitutes the abstract representation of the
physical or semantic structures of a class of documents.
markup model
the markup vocabulary (ie., the gamut of element and attribute names,
notations, etc.) and grammar (ie., the prescribed use of that
vocabulary) as defined by a document type definition (ie., a schema)
The markup model is the concrete representation in markup syntax
of the document model, and may be defined with varying levels of
strict conformity. The same document model may be expressed by a
variety of markup models.
document type definition (DTD)
a formal, machine-readable expression of the XML structure and syntax rules
to which a document instance of a specific document type must conform; the schema
type used in XML 1.0 to validate conformance of a document instance to
its declared document type. The same markup model may be expressed by a
variety of DTDs.
reference DTD
a DTD whose markup model represents the foundation of a complete document type.
A reference DTD provides the basis for the design of a "family" of related DTDs,
such as subsets, extensions and variants.
subset DTD
a DTD whose document model is the proper subset of a reference
document type, whose conforming document instances are still valid
according to the reference DTD. A subset may place tighter restrictions
on the markup than the reference, remove elements or attributes, or
both.
extension DTD
a DTD whose document model extends a reference document type (usually
by the addition of element types or attributes), but generally makes
no profound changes to the reference document model other than required
to add the extension's semantic components. An extension can also be
considered a proper superset if the reference document type is a
proper subset of the extension.
variant DTD
a DTD whose document model alters (through subsetting, extension,
and/or substitution) the basic data model of a reference document type.
It is often difficult to transform without loss between instances
conforming to a variant DTD and the reference DTD.
fragment DTD
a portion of a DTD used as a component either for the creation
of a compound or variant document type, or for validation of a
document fragment. SGML nor XML current have standardized methods
for such partial validation.
content model
the declared markup structure allowed within instances of an element
type. XML 1.0 differentiates two types: elements containing only
element content (no character data) and mixed content
(elements that may contain character data optionally interspersed with
child elements). The latter are characterized by a content
specification beginning with the "#PCDATA" string (denoting
character data).
semantic component
a unit of document type specification corresponding to a distinct type
of content, corresponding to a markup construct reflecting this distinct
type.
element type
the definition of an element, that is, a container for a distinct
semantic class of document content.
element
an instance of an element type.
generic identifier
the name identifying the element type of an element. Also, element
type name.
tag
descriptive markup delimiting the start and end (including its generic
identifier and any attributes) of an element.
markup declaration
a syntactical construct within a DTD declaring an entity or defining a markup
structure. Within XML DTDs, there are four specific types:
entity declaration
defines the binding between a mnemonic symbol and its
replacement content.
element declaration
constrains which element types may occur as descendants within
an element. See also content model.
attribute definition list declaration
defines the set of attributes for a given element type,
and may also establish type constraints and default values.
notation declaration
defines the binding between a notation name and an
external identifier referencing the format of an unparsed entity
entity
an entity is a logical or physical storage unit containing document
content. Entities may be composed of parseable XML markup or character data,
or unparsed (ie., non-XML, possibly non-textual) content. Entity content
may be either defined entirely within the document entity ("internal entities") or
external to the document entity ("external entities"). In parsed entities,
the replacement text may include references to other entities.
entity reference
a mnemonic or numeric string used as a reference to the content of a
declared entity (eg., "&" for "&", "<"
for "<", "©right;" for "Copyright 1999 Sun Microsystems, Inc.")
instantiate
to replace an entity reference with an instance of its declared content.
parameter entity
an entity whose scope of use is within the document prolog (ie., the external
subset/DTD or internal subset). Parameter entities are disallowed within the
document instance.
module
an abstract unit within a document model expressed as a DTD fragment,
used to consolidate markup declarations to increase the flexibility,
modifiability, reuse and understanding of specific logical or semantic
structures.
modularization
an implementation of a modularization model; the process of composing
or de-composing a DTD by dividing its markup declarations into units or
groups to support specific goals. Modules may or may not exist as
separate file entities (ie., the physical and logical structures of
a DTD may mirror each other, but there is no such requirement).
modularization model
the abstract design of the document type definition (DTD) in support
of the modularization goals, such as reuse, extensibility, expressiveness,
ease of documentation, code size, consistency and intuitiveness of use.
It is important to note that a modularization model is only orthogonally
related to the document model it describes, so that two very different
modularization models may describe the same document type.
driver
a generally short file used to declare and instantiate the
modules of a DTD. A good rule of thumb is that a DTD driver
contains no markup declarations that comprise any part of
the document model itself.
1.5 Availability
This specification and the formal XML declarations for XHTML 1.0 described
herein of this specification are protected by copyrights held by the IETF,
the W3C, and Sun Microsystems.
Permission to use, copy, modify and distribute the XHTML 1.0 DTD and
its accompanying documentation for any purpose and without fee is
hereby granted in perpetuity, provided that all copyright notices found
in the original documents appear in all copies. The copyright holders
make no representation about the suitability of the DTD for any purpose.
It is provided "as is" without expressed or implied warranty.
Please also note the Status of this Document
section above.
1.5.1 Current status:
The XHTML 1.0 Strict DTD is complete and valid, and mirrors the element content
models of HTML 4.0 Strict at a child level. The XHTML 1.0 Transitional DTD is
complete and valid, and apart from desired differences, matches HTML 4.0 Transitional
suitably for an XML transformation. The XHTML 1.0 Frameset DTD is basically complete,
although prose text describing it does not exist. The MathML DTD awaits resolution
of naming conflicts on one attribute and two elements.
^
2. Modularization Concepts
2.1 What is DTD Modularization?
The gamut of element types and attributes found in a document type are often
described in object-oriented terms, such as "classes" and "subclasses", "global" and
"local" scoping, "inheritance", etc. Despite the common use of such buzzwords, SGML
and XML describe markup languages, and as such, these terms are somewhat misplaced.
What is recognized is that document models usually contain informational constructs
that may be grouped into common categories. These are categories of what are referred
to by Eve Maler and Jeanne El Andaloussi in Developing SGML DTDs: From Text to
Model to Markup [DEVDTD] as
semantic components. These distinct "units of specification"
represent containers for distinct types or classes of information (ie., data or human
knowledge). So while the markup itself is not object-oriented, the classifications of
content it describes may be. Use of the terms "class" and "subclass" in this document
therefore refer more to "classification" and "subclassification" respectively. By
modeling the document type definition on these common categories of semantic components,
the commonalities and divisions of the document type allow a modularization model to be created.
Maler and El Andaloussi further describe a division of semantic components into three
categories. The following descriptions borrow heavily from Section 4.1.2.1 Recognizing
Content, Structure, and Presentation [DEVDTD]:
Structural components often are based upon common
typesetting or publishing concepts of document division, such as abstracts,
bibliographies, chapters, glossaries, headings, lists, paragraphs, sections,
tables, etc. Markup containers (such as elements or attributes) resulting
from an implementation of this category usually say less about their actual
contents, more about their context within the organization of the document model.
Content-based components indicate what the information
represents, such as an author name or address, product price or part number, software
function name, chemical formula, etc. Markup containers resulting from an
implementation of this category of components are often called "semantic"
types because they are based on a classification of the content's meaning. In
this specification, "content-based" and "phrasal" are synonyms ("semantic" was deemed too
overloaded a term).
Presentational components indicate how the contained
information should be processed or rendered, absent any notion of attachment to
conceptual meaning. Markup containers resulting from an implementation of this category
are typically broken into two subcategories based on common typesetting notions:
block-level and inline. Some examples of presentational
components include indications of a line or page break, a phrase rendered in a specific
font, color or point size, the indentation of a region, the inflection of a
spoken sentence, etc.
When a document model is fairly simple, design and delivery constraints usually
don't warrant modularizing the markup model. But when the document model is complex,
when network constraints warrant, when a customization is desired without modification
of the reference DTD, or perhaps even when components
of the DTD are delivered from different locations, breaking the DTD into fragments or
modules is a good solution. Perhaps the best reason is to
help implement the inherent structures of the document model in the markup model (since
SGML nor XML have any such features), which helps in design, maintenance and documentation.
Also, software applications are often designed based on common modules. For example,
programming code already exists for rendering CALS or HTML tables, so use of an existing
module may lead to a general improvement in interoperability, documentation, and
understanding within a user community.
At first glance the added overhead and syntax complexity associated with modularization
may seem daunting, but many years of industry experience would suggest that its benefits
usually outweigh the costs.
While it is convenient to categorize information, in practice such categorization
must be considered carefully, as the same information can often be marked up in different
ways, depending on the intention and processing expectations associated with the content.
For example, since HTML is strongly presentational, whether an element type is content-based
or presentational is often less important than if it is a block or inline element. In
some markup languages, presentation issues are minimal, left entirely to stylesheets, or
even completely absent.
2.2 Facilitating Customization
So if one were to divide a document model into parts, the dividing lines would occur at
the semantic component level, and be implemented in the markup model by creating
DTD fragments, or modules.
Modules are often used to encompass the markup declarations of a specific semantic
component or "feature", from higher-level components like tables, forms, to lower-level
ones like specific elements or element groups. Modules can contain modules, creating a
hierarchical structure mirroring the document model. Modules are abstract structures,
so they can be implemented in various ways, such as a simple designation using comment
delimiters, using marked sections, or using entities (see Use of
Marked Sections, Files vs. Modules below).
If there is an expectation that the DTD may be commonly modified or used as a source of
DTD fragments (such as the TEI DTD [TEI]), many such
methods have been employed by the markup community over the years, and studying existing
DTDs often yields many ways of solving complex problems.
While the idea of "plug and play" with DTD modules is very attractive, in practice
this isn't quite so simple. Because complex document models often resort to
classification of semantic components to facilitate understanding, markup reuse,
extensibility and maintenance (through use of parameter entities), seldom are DTD
modules completely self-contained, so there is usually a fair amount of "rewiring"
involved in adding or removing a DTD module. A compromise must be made between ease
of maintenance or extensibility and complexity of the DTD, and this is where good
design of the modularization model (and good documentation) can make all the difference.
Some of the expressive power of SGML DTDs useful for this classification (eg.,
name groups) is unavailable in the simplified syntax of XML, but many other markup
features (and well-written documentation) can go a long way in creating a
straightforward and effective modularization.
DTDs are written for humans as much as for machines, and in fact act as an
interface between structures of human information and a machine representation.
Some representations are more explicit than others, some rely merely on human
understanding and do not impact processing directly. If a DTD makes sense to
its intended audience and represents an appropriate modelling of its document
type (being as loose or restrictive as necessary for its intended application),
then it is a success.
To this end, parameter entities are often used to represent various structures.
These are described below in more detail.
[creation of PEs for use as common element classes; eg., %flow;,
%block; and %inline; in HTML; use of various naming conventions for parameter entities.]
.module
description of .module parameter entities...
.content
description of .content parameter entities...
.class
description of .class parameter entities...
.mix
description of .mix parameter entities...
.attrib
description of .attrib parameter entities...
2.2.1 Content-Type or Common Strings
When a semantic component represents a specific data or content type, its
representation within the DTD may be handled by creating a parameter entity as a
content-type label. The HTML 4.0 DTD uses such parameter entities extensively.
This can be seen clearly in the element declaration for the anchor element below:
<!ATTLIST A
%attrs; -- %coreattrs, %i18n, %events --
charset %Charset; #IMPLIED -- char encoding of linked resource --
type %ContentType; #IMPLIED -- advisory content type --
name CDATA #IMPLIED -- named link end --
href %URI; #IMPLIED -- URI for linked resource --
hreflang %LanguageCode; #IMPLIED -- language code --
rel %LinkTypes; #IMPLIED -- forward link types --
rev %LinkTypes; #IMPLIED -- reverse link types --
accesskey %Character; #IMPLIED -- accessibility key character --
shape %Shape; rect -- for use with client-side image maps --
coords %Coords; #IMPLIED -- for use with client-side image maps --
tabindex NUMBER #IMPLIED -- position in tabbing order --
onfocus %Script; #IMPLIED -- the element got the focus --
onblur %Script; #IMPLIED -- the element lost the focus --
>
All of the above attribute types (%Charset;,%ContentType;, etc.)
resolve to "CDATA", "NMTOKEN)", or "NMTOKENS)", all
essentially unparsed string containers.
As a specific example, while within the DTD itself a URI container is just
another string container, but obviously has a specific meaning to humans and
applications. In HTML 4.0, URIs are represented within the DTD by the parameter
entity %URI;, and declared within the DTD as:
<!ENTITY % URI "CDATA"
-- a Uniform Resource Identifier,
see [URI]
-->
Because the syntax of comments has been simplified in XML to those found only in comment
declarations, the above comment must be rewritten. Since the comment is no longer contained
within the declaration, it is common practice for comments to precede their declarations,
such as:
<!-- a Uniform Resource Identifier, see [URI] -->
<!ENTITY % URI "CDATA" >
While use of such content-type parameter entities doesn't impact the document model,
they can be valuable in making a DTD easier for both authors and application developers
to understand.
2.2.2 Element Classes (.content, .class, .mix)
[creation of PEs for use as common element classes; eg., %flow;,
%block; and %inline; in HTML; use of various naming conventions for parameter entities.]
<!-- %Inline.mix; includes all inline elements -->
<!ENTITY % Inline.mix
"%Inlpres.class;
| %Inlphras.class;
| %Inlspecial.mix;
| %Formctrl.class;"
>
<!-- %Block.mix; includes all block elements -->
<!ENTITY % Block.mix
"%Blkpres.class;
| %Blkphras.class;
| %Blkspecial.mix;"
>
<!-- %Flow.mix; includes all text content, block and inline -->
<!ENTITY % Flow.mix
"%Heading.class;
| %List.class;
| %Block.mix;
| %Inline.mix;"
>
2.2.3 Attribute Classes (.attrib)
[creation of PEs for use as common attribute classes]
While there is no feature in XML for "global" attributes (ie., an attribute that
applies to all element types), parameter entities may be used to create classes
of attribute type specifications that may be reused within the DTD.
Here's an example from the DTD:
<!ENTITY % Core.attrib
"id ID #IMPLIED
class CDATA #IMPLIED
style %StyleSheet; #IMPLIED
title %Text; #IMPLIED"
>
<!ENTITY % I18n.attrib
"lang %LanguageCode; #IMPLIED
xml:lang %LanguageCode; #IMPLIED
dir (ltr|rtl) #IMPLIED"
>
[the renaming of attribute classes (such as %Coreattrs; to %Core.attrib;)
hasn't been implemented in this version, but is planned. Changes to %Core.attrib;, %I18n.attrib;,
%Common.attrib;, %Alink.attrib;, %Events.attrib;, maybe others]
2.3 Precedence Order of XML Declarations
[Note the precedence order of declarations vs. redeclaration of variables in a
programming language and show why this makes good sense. Discuss both external
and internal DS.]
[modularization changes via: module replacement, predeclaration, parameter entity
replacement, module amendation (eg., later, using ATTLISTs), marked sections, etc.]
2.4 Use of Marked Sections
[use of marked sections to create module boundaries and 'switches']
<!-- Tables Module .................................... -->
<!ENTITY % XHTML1-table.module "INCLUDE" >
<![%XHTML1-table.module;[
<!ENTITY % XHTML1-table
PUBLIC "-//Sun Microsystems//ELEMENTS XHTML 1.0 Tables//EN"
"XHTML1-table.mod" >
%XHTML1-table;
]]>
2.5 Files vs. Modules
Note that a DTD module does not necessarily imply a separate file entity. For example,
the DocBook 3.0 DTD is delivered as a single driver file,
comprising about three hundred lines of code (about half of which are comments). The
driver declares and instantiates four file "modules", which themselves are made up of over
three hundred internal modules (ie., the entity boundaries are unimportant: the same DocBook
DTD could be delivered as one, four, or three hundred files.
See: DTD normalization.). After the parameter
entities comprising the file modules have been instantiated, the DTD is over 7,600 lines long.
When network performance is an issue, decisions over how to deliver a DTD may come into
play. When network bandwidth is limited or packet delivery overhead is high, delivery of
a single file is faster than numerous small network accesses, but under some conditions
(such as when delivering over an unreliable connection where redelivery is common) smaller
files may be preferred. In either case, if the DTD is large, delivery may be a consideration
in the entity design. But because DTDs are text files (and therefore even large DTDs
are smaller than most GIF images on the Web), delivery performance is usually less of
an issue; convenience and utility are greater factors.
2.6 Indirection and Public Identifiers
[use of public ids and catalog files vs. system ids; mention URNs?]
2.7 XML External and Internal Subset Differences
[parameter entities allowed only where declarations may
occur in internal subset and impact]
^
3. Differences Between SGML and XML
[briefly describe relationship between SGML and XML, describe
this section as a general issues list for those familiar with SGML or involved
in document conversion...]
3.1 Restrictions imposed by XML
name clashes between name and id on anchors
case sensitivity on all names
parameter entity references in internal subset only where declarations can occur
no conditional (ie., "marked") sections in internal subset
no name groups for element and attlist declarations
character entities redeclared
content models for mixed content have restricted form, requiring #PCDATA as first token
use of namespaces discussed?
change to XML style comments: no comments inside declarations; comments can't be bound to
a markup declaration
how will the DTD be documented?
the SGML declaration must be implied and cannot be explicitly present in the document entity
mention whitespace, expected behaviour of all HTML elements (except PRE)
processing instruction close changed from '>' to '?>'
3.2 Relaxation of previous SGML rules
capacities and quantities relaxed
certain attribute types not allowed
(NAME, NAMES, NUMBER) NAME to NMTOKEN,
NAMES to NMTOKENS, NUMBER to CDATA
no inclusion or exclusion exceptions
so attempt to maintain element content model at child level where possible,
adding the included elements only where truly appropriate
3.3 Other changes imposed by XML
XML documents must be well-formed and aware of internal subsets, so the
processing model is radically different than HTML. Parsers may be more
likely to attempt instantiation of external entities (such as the DTD),
so proper syntax and usage of the DOCTYPE declaration will be more important.
duplicate character entity declaration
Five of HTML's character entities are predeclared in XML (lt,gt,amp,quot and apos).
While not an error, declaring them twice may signal an optional warning in some parsers,
so they have not been declared in this specification.
empty anchors in document instance problem
any other place that empty elements (or the ambiguity between an element
declared EMPTY and an element with no content) will cause a problem?
empty elements in document instance must have a space before the '/>'
in order to work in backlevel browsers, so conversion tools must be aware
of this.
^
4. HTML 4.0 Document Model
The introductory description of an HTML 4.0 document found in Section 7.1 of
the W3C HTML 4.0 Recommendation [HTML40]
is confusing and somewhat misleading. This may be an attempt to simplify the SGML
terminology elaborated upon later in the specification, or perhaps account for markup
minimization which in HTML allows much of the higher-level document model to be
implied when absent from a document instance. Nevertheless, this deserves remedy,
particularly when HTML is transformed into XML where such types of minimization
are not allowed.
4.1 Document Structure Summary
The three "parts" of an HTML document as described in the HTML 4.0
Recommendation:
a line containing HTML version information,
a declarative header section (delimited by the HEAD element)
a body, which contains the document's actual content. The body may
be implemented by the BODY element or by the FRAMESET element.
4.1.1 Document Prolog
The first item above is of course the DOCTYPE declaration,
which represents part of the SGML prolog, corresponding
to Production 22 of the
XML 1.0 specification [XML]. The
DOCTYPE declaration is not so much a "version label" as a declaration
of the document element type name ("HTML"), followed by an external reference (in
this case, a Formal Public Identifier) to an HTML DTD. For more information
on external identifiers, see Section 4.2.2, External Entities, [XML].
NOTE: an XML prolog also includes the XML declaration
(a special processing instruction) and optional miscellaneous content
(processing instructions, comments and whitespace), but for purposes of
this discussion this will be ignored. Also, for better compatibility with
Web usage, XML further requires the external reference to include a Uniform
Resource Identifier [URI].
In current Web practice, the significance of the DOCTYPE declaration
is almost nil. Mainstream HTML browsers ignore its presence and are unable to process
any portion of the document prolog. XML 1.0 requires conformant applications to at
least be able to parse the declaration and any internal subset. Validating parsers
are expected to be able to instantiate and parse external references in the external
and internal subsets. This will be elaborated further below.
4.1.2 Document Element
Missing from the above list is the existence of the root
or document element, which represents the outermost
container for all document content. Another way of stating this is that the
document element contains all content between the <HTML> start tag
and </HTML> end tags, which serve as delimiters.
The HTML document element has two required children, the HEAD
and BODY elements respectively.
NOTE: Whereas HTML 4.0's markup minimization rules allow
document authors to omit the tags for the HTML, HEAD
and BODY elements (curiously, the only required element in HTML 4.0
is TITLE), they are nevertheless always implied (ie., actually present
in the document model).
4.1.3 Document HEAD Element
The HTML 4.0 specification describes the HEAD element as "declarative",
containing information about the document. This document metadata
is typically not rendered as document content, but strictly speaking, it is of
course part of the HTML document.
Within the document HEAD, HTML prescribes no particular structure,
merely an unordered container for the element types TITLE, BASE,
SCRIPT, STYLE, META, LINK, and OBJECT.
Of these element types, the document's TITLE element must occur once,
its optional BASE element may occur only once. The rest may occur zero
or more times within the HEAD element, in any order.
Please refer to Section 7.4 of the HTML 4.0 specification [HTML40] for detailed descriptions of these element types.
4.1.4 Document BODY Element
Following the HEAD element is the BODY element, which contains
all document content typically rendered by an HTML user agent. It is within the
BODY element that most of the structure of an HTML document is found.
The naming scheme for many of HTML's elements is seemingly borrowed from
the ISO 8879:1986 General Document DTD, Annex E of [SGML], such as BODY, H1 to H6,
P, ADDRESS, and TITLE, and all of its list element types:
DL, DT, DD, UL, OL, and LI.
The BODY element contains basically no higher-level structures such
as chapters or sections. An HTML document consists of a shallow stream of elements,
some requiring a slightly deeper structure. Unlike many other industry DTDs that prescribe
deep structural nesting (DocBook inline elements commonly begin at a seventh or eighth
nested level and may reach a depth of a dozen or more), HTML rarely requires more
than two or three levels.
The DIV and SPAN elements allow for recursive containership,
which could be used to create a deeper structure within an HTML document. However,
because they are a generic elements and optional, their use in this regard is
rather limited.
4.1.5 Element Classes
Unlike HTML 3.2 [HTML32],
which contains relatively unstructured content anywhere within BODY,
Section 7.5.3 of the HTML 4.0 specification [HTML40] makes a clear distinction between two classes of element types:
block and inline:
inline elements
all character-level elements
block elements
all block-like elements (eg., paragraphs and lists)
While the parameter entities that enabled this delineation existed in
HTML 3.2, HTML 4.0 is more disciplined in constraining block and inline
elements, although there are plenty of holes in both document models.
4.2 Rendered Content Structure
4.2.1 H1-H6 Heading Elements
The flat structure of BODY contains six numbered headings, from
H1 to H6. These, however, do not serve as nested structures
but rather as a hierarchy of section titles for a nonexistent section structure.
There is no enforcement of order or occurrence. The ISO/IEC 15445:1998 HyperText
Markup Language (HTML) DTD [ISO-HTML]
attempts to remedy this by creating a nested structure of implied B1
to B6 element types. Because XML does not allow for such markup
minimization, this solution is unfortunately not available in an XML-based
HTML document type.
4.2.2 Structural Elements
[HEAD, BODY]
4.2.3 Block Elements
[DIV, P, BR]
4.2.4 Inline Elements
[SPAN, B, EM, STRONG, etc.]
4.2.5 Phrasal Elements
[most inlines in Strict]
4.2.6 Presentational Elements
[most of those relegated to Transitional only]
4.2.7 Special Case or 'Feature' Elements
[tables, forms, etc.]
^
5. Modularization of HTML 4.0
In looking back over the description of how semantic components may be
categorized (see Section 3), we must acknowledge that HTML,
unlike many (or even most) existing markup languages, is strongly presentational.
This has influenced the precedence given to the groupings of element types, favoring
an early branching of "block" vs. "inline" over "phrasal" vs. "presentational",
particularly since upon analysis HTML in practice makes a stronger differentiation
between block and inline rather than whether an element type represents a semantic
distinction or is merely a presentational effect: people use HTML tags to achieve
desired effects.
The semantic components of HTML are classified by the delineating categories
below. (Note that because H1 through H6 act as heading titles,
not nested containers, they are classified as block phrasal, not
structural):
structural elements
includes all element types that create the overall structure of an
HTML document.
block elements
elements that (according to the HTML 2.0, 3.2 and 4.0 specifications)
should cause a line break.
inline elements
elements that (according to the HTML 2.0, 3.2 and 4.0 specifications)
are displayed inline to an existing block.
phrasal (aka "content-based") elements
elements whose presence denotes a content-based distinction.
presentational elements
elements whose presence indicates a desire on the part of the author
for a specific presentational effect.
special case (or "feature") elements
a general category for elements that provide HTML with special
features, such as linking, forms, tables, etc.
Giving priority to "block" vs. "inline" (as described above) we find
the following result:
a. document structure
a1. normal structure
a2. frames
a3. lists
b. block elements
b1. block structural
b2. block phrasal
b3. block presentational
c. inline elements
c1. inline structural
c2. inline phrasal
c3. inline presentational
d. special cases:
d1. meta information
d2. linking
d3. external "binary" inclusions (images, movies, etc.)
d3.1. img
d3.2. object element
d3.3. client-side image maps
d4. scripting
d5. stylesheets
d6. tables
d7. forms
5.1 Parameter Entity Containers
The DTD uses many parameter entities to create various classes of names,
attribute declarations, etc. to further the modularity, reuse and understanding
of its declarations.
The "Common Names", "Common Attributes" and "Document Model Hierarchies" modules
are declared near the beginning of the DTD, enabling use of parameter entities within
each of the DTD modules as encountered. These are called "preliminary declarations"
below, and includes common names, attributes, and also the long list of ISO character entities.
5.1.1 Common Names
[description of Common Names]
5.1.2 Attribute Classes
Based on the parameter entity attribute class naming scheme, the set of
parameter entities for XHTML attribute classes are as follows:
Core.attrib;
attributes on almost all elements: id, class, style and title.
(Curiously, style is considered 'core')
I18n.attrib;
internationalization attributes for language and text direction
Events.attrib;
attributes for support of intrinsic events
Common.attrib;
a collection of 'Core', 'I18n' and 'Events'
attributes used on many elements
Alink.attrib;
additional attributes for XLink simple anchors
Align.attrib;
alignment attributes
IAlign.attrib;
alignment attributes for images
CellHAlign.attrib;
used in tables for horizontal cell alignment
CellVAlign.attrib;
used in tables for vertical cell alignment
Reserved.attrib;
unused
5.1.3 Element Classes
[Description of classes]
%Heading.class;
heading elements H1-H6
%List.class;
list elements
%Inlphras.class;
inline phrasal elements
%Inlpres.class;
inline presentational elements
%Blkphras.class;
block phrasal elements
%Blkpres.class;
block presentational elements
%Formctrl.class;
form control elements
5.1.4 Element Mixes
[Description of mixes]
%Inline.mix;
a mix of all inline elements
%Inline-noa.mix;
a mix of all inline elements excluding anchors
%Inlspecial.mix;
a mix of inline elements ( a|img|object|script|map )
that are special-case language 'features'. [Extension elements
that are considered 'inline' will probably go here...]
%Block.mix;
a mix of all block elements
%Block-noform.mix;
a mix of all block elements excluding form and
form control elements
%Blkspecial.mix;
a mix of block-level elements ( noscript | form | table | fieldset )
that are special-case language 'features'. [Extension elements
that are considered 'block' will probably go here...]
%Flow.mix;
a mix of all heading, list, inline and block elements
5.1.5 Element Contents
[Description of contents]
%Html.content;
the contents of the html document element (an HTML document)
%Head.content;
the contents of the head element
%Noframes.content;
the contents of the noframes element
(XHTML 1.0 Transitional elements in italic. Transitional modules use the
same base name as the Strict version, but add "-t" to the module name
(eg., "XHTML1-attribs.mod" changes to "XHTML1-attribs-t.mod")
5.1.6 Preliminary Declarations
[description of preliminary declarations, including
common names, attributes, leave content model to next section]
preliminary declarations
common names (XHTML1-names.mod)
common attributes (XHTML1-attribs.mod)
common attributes (Transitional) (XHTML1-attribs-t.mod)
common event attributes (XHTML1-events.mod)
character entities (XHTML1-charent.mod)
5.1.7 Content Model Module Declarations
[description of content model module and role in
declaring classes of elements]
content model declarations
content model hierarchies (XHTML1-model.mod)
content model hierarchies (Transitional) (XHTML1-model-t.mod)
5.1.8 Module Declarations
[description of module declarations...]
a. document structure
a1. normal structure (XHTML1-struct.mod)
body, head, html
a2. frames (XHTML1-frame.mod)
frame, frameset, iframe, noframes
a3. lists (XHTML1-list.mod)
dd, dir, dl, dt, li, menu,
ol, ul
b. block elements
b1. block structural (XHTML1-blkstruct.mod)
div, p
b2. block phrasal (XHTML1-blkphras.mod)
address, blockquote, pre,
h1, h2, h3, h4, h5, h6
b3. block presentational (XHTML1-blkpres.mod)
center, hr
c. inline elements
c1. inline structural (XHTML1-inlstruct.mod)
bdo, br, del, ins, span
c2. inline phrasal (XHTML1-inlphras.mod)
abbr, acronym, cite, code, dfn, em,
kbd, q, samp, strong, var
c3. inline presentational (XHTML1-inlpres.mod)
b, basefont, big, font, i, s, small,
strike, sub, sup, tt, u
d. special cases:
d1. meta information (XHTML1-meta.mod)
isindex, meta, title
d2. linking (XHTML1-linking.mod)
a, base, link
d3. external "binary" inclusions (images, movies, etc.)
d3.1. img (XHTML1-image.mod)
img
d3.2. object element (XHTML1-object.mod)
object, param
d3.3. client-side image maps (XHTML1-csismap.mod)
area, map
d4. scripting (XHTML1-script.mod)
applet, noscript, script
d5. stylesheets (XHTMl1-style.mod)
style
d6. tables (XHTML1-table.mod)
caption, col, colgroup, table, tbody, td, tfoot,
th, thead, tr
d7. forms (XHTML1-form.mod)
button, fieldset, form, input, label, legend,
optgroup, option, select, textarea
^
6. Packaging and Delivery
In its short history, Web browsers have promoted a model of document
delivery that makes little or no effort at checking the validity of
documents. While it is beyond the scope of this specification to address
these issues, it is implicitly understood that the value of a DTD is in
its ability to check the structure of a document instance against a
specific document model. Validation may occur during authoring, delivery
or reception.
[introductory paragraph to following sections...]
6.1 Referencing and Instantiating Entities
Before beginning to discuss the specifics of HTML, an explanation
of how objects may be referenced and instantiated is in order.
Strictly speaking, the means of associating a document with a DTD
has been part of HTML since the beginning, but is rarely used.
6.1.1 External Identifiers
[describe external identifiers...]
6.1.2 SGML Catalog Files
[Reference [CATALOG] as specification for catalog files.]
6.2 DTD Packaging
[describe packaging issues...]
6.3 DTD Drivers
[describe what a driver is and does...]
<!-- DTD for HTML 4.0 Strict -->
...
<!-- end of strict DTD -->
6.3 DTD Normalization
Rather than deliver a modular DTD as separate files, in certain environments
where multiple file accesses may be a burden on network resources, the entire DTD
may be consolidated into one file through a normalization process, which
expands all external parameter entity references. James Clark's freeware SGML
toolkit [SP] includes the application
spam that may serve as a normalization tool. Certain changes must be
made in order to work correctly with XML files. These are described below.
% spam -p -p -c XHTML1.cat test-s.xml
The -c parameter is followed by a reference to the SGML catalog file
for XHTML 1.0, which includes an SGMLDECL statement providing the parser
with the correct SGML declaration for XML. The -p -p parameters direct
the parser to expand all parameter entities.
Included with the distribution are several Unix ksh scripts. Each
automatically creates a normalized version of a DTD upon invocation. These are
named "_flat-s" (Strict), "_flat-t"
(Transitional), and "_flat-f" (Frameset). Availability of
SP on the host machine is required.
^
7. Extending XHTML
7.1 Fragment Usage Guidelines
...
Note that this is unrelated to the proposed products of the W3C XML Fragment
Working Group, or upon SGML Open Technical Resolution 9601:1996 Fragment
Interchange, both of which are concerned with interchange of fragments
of document content, not the reuse of DTD fragments in composing variant or
compound document types.
7.2 Extension Guidelines
[discussion of subsets, extensions, etc.]
...
7.3 An Example Extension: Adding a Single Element
[describe the changes to XHTML1-model.mod, the catalog file, and the driver]
7.3.1 Adding a New Module
...
7.3.2 Modifying an Existing Module
...
7.3.3 Modifying the Document Model Module
...
7.3.4 Modifying the DTD Driver
...
7.3.4 Changing Identifiers
...
7.3.4 Modifying the Catalog File (Optional)
...
7.4 An Example Extension: HTML + MathML
[more complex example of changes required to add MathML]
^
8. XHTML as an Architecture
8.1 A Brief Introduction to Architectures
intro...
The optional XHTML1-arch.mod module includes declarations that
enable XHTML to be used as a base architecture according to the
Architectural Forms Definition Requirements (Annex A.3,
ISO/IEC 10744, 2nd edition).
For more information on use of architectural forms, consult Part Four of
David Megginson's Structuring XML Documents [STRUCTXML], or browse the HyTime web site at:
http://www.hytime.org/
8.2 The XHTML Base Architecture Module
XHTML1-arch.mod ...
<!-- Architecture Base Declaration -->
<?IS10744 ArcBase html ?>
<!-- Architecture Notation Declaration -->
<!NOTATION html
PUBLIC "-//Sun Microsystems//NOTATION AFDR ARCBASE XHTML 1.0//EN" >
etc.
8.3 Using The XHTML Architecture
...
^
Appendix A. XML Files (Normative)
To reduce the size of this document, the actual files composing
the normative content of this specification have not been included inline, and are
shown below as hypertext links. The entire package of files are available in both
tarred, gzipped or zipped archives at:
Tarred, gzipped archive
http://www.altheim.com/specs/xhtml/xhtml1-19990201.tar.gz
Zipped archive
http://www.altheim.com/specs/xhtml/xhtml1-19990201.zip
NOTE: The DTD and associated files use file extensions such as .mod,
.dtd, etc. and may not display correctly in all browsers. If you're
having difficulty viewing the files, or are planning to use the DTD, it is
recommended that you download the archive rather than the individual files.
Please note the current status of the DTD.
A.1 Catalog File
[Reference [CATALOG] as specification for catalog files.]
SGML Catalog File
XHTML1.cat
A.2 DTD Drivers
...
XHTML 4.0 Strict DTD Driver
XHTML1-s.dtd
XHTML 4.0 Transitional DTD Driver
XHTML1-t.dtd
XHTML 4.0 Frameset DTD Driver
XHTML1-f.dtd
XHTML 4.0 Strict + MathML Extension DTD Driver
XHTML1-m.dtd
A.3 DTD Modules
...
XHTML1-applet.mod
XHTML1-applet.mod
XHTML1-arch.mod
XHTML1-arch.mod
XHTML1-attrib-t.mod
XHTML1-attrib-t.mod
XHTML1-attrib.mod
XHTML1-attrib.mod
XHTML1-blkphras.mod
XHTML1-blkphras.mod
XHTML1-blkpres.mod
XHTML1-blkpres.mod
XHTML1-charent.mod
XHTML1-charent.mod
XHTML1-csismap.mod
XHTML1-csismap.mod
XHTML1-events.mod
XHTML1-events.mod
XHTML1-form.mod
XHTML1-form.mod
XHTML1-frames.mod
XHTML1-frames.mod
XHTML1-image.mod
XHTML1-image.mod
XHTML1-inlphras.mod
XHTML1-inlphras.mod
XHTML1-inlpres.mod
XHTML1-inlpres.mod
XHTML1-linking.mod
XHTML1-linking.mod
XHTML1-list.mod
XHTML1-list.mod
XHTML1-math.mod
XHTML1-math.mod
XHTML1-meta.mod
XHTML1-meta.mod
XHTML1-model-t.mod
XHTML1-model-t.mod
XHTML1-model.mod
XHTML1-model.mod
XHTML1-names.mod
XHTML1-names.mod
XHTML1-object.mod
XHTML1-object.mod
XHTML1-script.mod
XHTML1-script.mod
XHTML1-struct.mod
XHTML1-struct.mod
XHTML1-style.mod
XHTML1-style.mod
XHTML1-table.mod
XHTML1-table.mod
A.4 Normalized DTDs
[describe and reference section above on DTD
normalization...]
Below are links to normalized, "single-file" versions of the XHTML 1.0 Strict,
Transitional, and Frameset DTDs. They are identical in function to the modular
DTDs but have been normalized using James Clark's
spam application,
part of the SP toolkit.
XHTML1-s-flat.dtd
XHTML1-s-flat.dtd
XHTML1-t-flat.dtd
XHTML1-t-flat.dtd
XHTML1-f-flat.dtd
XHTML1-f-flat.dtd
XHTML1-m-flat.dtd
XHTML1-m-flat.dtd
^
Appendix B. Document Model Changes (Non-Normative)
B.1 Element Type Content Models
The following element type content model changes have been made
in transforming HTML 4.0 to XML:
...
B.2 Element Type Attributes
The following attribute changes have been made
in transforming HTML 4.0 to XML:
Element Type
HTML 3.2
HTML 4.0
XHTML 1.0
Voyager
HTML
xmlns
xmlns
HEAD
profile
profile
PRE
xml:space
xml:space
Additionally, the %i18n; attribute class has been augmented by
the xml:lang attribute, affecting all element types that
include this parameter entity in their attribute definition list
declarations.
B.3 Other Changes
Other changes made in transforming HTML 4.0 to XML:
...
^
Appendix C. References
C.1 Normative References
[XML]
Extensible Markup Language (XML) 1.0: W3C Recommendation,
Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, 10 February 1998.
See: http://www.w3.org/TR/REC-xml
[HTML40]
HTML 4.0 Specification: W3C Recommendation,
Dave Raggett, Arnaud Le Hors, Ian Jacobs, 24 April 1998.
See: http://www.w3.org/TR/REC-html40
[SGML]
Information Processing -- Text and Office Systems -- Standard
Generalized Markup Language (SGML), ISO 8879:1986.
Please consult http://www.iso.ch/cate/d16387.html for information about
the standard, or http://www.oasis-open.org/cover/general.html#overview
about SGML.
[MATHML]
Mathematical Markup Language (MathML) 1.0 Specification:
W3C Recommendation,
Stephen Buswell, Stan Devitt et al, 7 April 1998.
See: http://www.w3.org/TR/REC-MathML
C.2 Other References
[remove unused references upon completion of document...]
[CATALOG]
Entity Management: OASIS Technical Resolution 9401:1997
(Amendment 2 to TR 9401)
Paul Grosso, Chair, Entity Management Subcommittee, SGML Open, 10 September 1997.
See: http://www.oasis-open.org/html/a401.htm
[DEVDTD]
Developing SGML DTDs: From Text to Model to Markup,
Eve Maler and Jeanne El Andaloussi.
Prentice Hall PTR, 1996, ISBN 0-13-309881-8.
[STRUCTXML]
Structuring XML Documents,
David Megginson. Part of the Charles Goldfarb Series on Information Management.
Prentice Hall PTR, 1998, ISBN 0-13-642299-3.
[SGML-XML]
Comparison of SGML and XML: W3C Note, James Clark, 15 December 1997.
See: http://www.w3.org/TR/NOTE-sgml-xml-971215
[HTMLXML]
Reformulating HTML in XML: W3C Working Draft,
D. Raggett, F. Boumphrey, M. Altheim, T. Wugofski, 24 November 1998.
See: http://www.w3.org/Markup/Group/WD-html-in-xml
[XLINK]
XML Linking Language (XLink): W3C Working Draft,
Eve Maler and Steve DeRose, 3 March 1998.
A new XLink requirements document is expected soon, followed by
a working draft update.
See: http://www.w3.org/TR/WD-xlink
[DOCBOOK]
DocBook DTD, Eve Maler and Terry Allen.
Originally created under the auspices of the Davenport Group,
DocBook is now maintained by OASIS. The Customizer's Guide
for the DocBook DTD V2.4.1 is available from this site.
See: http://www.oasis-open.org/docbook/index.html
[DUBLIN]
The Dublin Core: A Simple Content Description Model for Electronic
Resources, The Dublin Core Metadata Initiative.
See: http://purl.oclc.org/dc/
[HTML32]
HTML 3.2 Reference Specification: W3C Recommendation,
Dave Raggett, 14 January 1997.
See: http://www.w3.org/TR/REC-html32
[ISO-HTML]
ISO/IEC 15445:1998 HyperText Markup Language (HTML),
David M. Abrahamson and Roger Price.
See: http://dmsl.cs.uml.edu/15445/FinalCD.html
[RDF]
Resource Description Framework (RDF): Model and Syntax Specification,
Ora Lassila and Ralph R. Swick, 19 August 1998.
See: http://www.w3.org/TR/WD-rdf-syntax
[CSS2]
Cascading Style Sheets, level 2 (CSS2) Specification,
Bert Bos, Hakon Wium Lie, Chris Lilley, Ian Jacobs, 12 May 1998.
See: http://www.w3.org/TR/REC-CSS2
[CCPP]
Composite Capability/Preference Profiles (CC/PP): A user side framework
for content negotiation, Franklin Reynolds, Johan Hjelm, Spencer Dawkins,
Sandeep Singhal.
See: http://www.w3.org/Mobile/Group/IG/ccpp-paper.html
[SMIL]
Synchronized Multimedia Integration Language (SMIL) 1.0 Specification,
Philipp Hoschka, 15 June 1998.
See: http://www.w3.org/TR/REC-smil
[TEI]
The Text Encoding Initiative (TEI),
(TBD)
See: http://www.xxx.yyy/
[URI]
Uniform Resource Identifiers (URI): Generic Syntax,
T. Berners-Lee, R. Fielding, L. Masinter, August 1998.
See: http://ds.internic.net/rfc/rfc2396.txt.. This RFC updates RFC 1738
[URL] and
[RFC1808].
[URL]
IETF RFC 1738, Uniform Resource Locators (URL),
T. Berners-Lee, L. Masinter, M. McCahill.
See: http://ds.internic.net/rfc/rfc1738.txt
[RFC-1808]
Relative Uniform Resource Locators, R. Fielding.
See: http://ds.internic.net/rfc/rfc1808.txt
^
Appendix D. Acknowledgements (Non-Normative)
The following have contributed to this document:
Joe Alfonso, Sun Microsystems
Jon Bosak, Sun Microsystems
David Brownell, Sun Microsystems
Eduardo Gutentag, Sun Microsystems
Bill Smith, Sun Microsystems
^
Appendix E. Revisions (Temporary)
Revisions to this draft:
1999-01-29
Restructured some block and inline element types: created new modules
for 'b.1 block structural' and 'c.1 inline structural', renumbering in
the draft and DTD comments accordingly (see DTD modules for specifics).
1999-02-01
Implemented changes required for HTML 4.0 errata. Fixed some bugs in
content models and finished most testing of Strict and Transitional DTDs.
Added minor notes about normalization.
^
Wyszukiwarka
Podobne podstrony:
DSL Modulation TechniquesModulacjea note on islamic?onomicsXHTML CSS i JavaScript Pierwsza pomoc twowppNote for SMTP?buggingMathcasting MathML with XHTMLDeath Note 2 The Last Name [2006] [XVID] [ENG Subbed] [SARS]XHTML i CSS Dostepne witryny internetoweC Note Different kind of loveC Note Love Of All TimeC Note ?els so good3 PodTel wyk? Modulacja K taI2C Atmel Aplication Notewięcej podobnych podstron