Good stuff on XHTML modularization

Tim Bray tbray at
Fri Nov 12 18:52:42 GMT 1999

I saw the posting included below on another mailing list where they worry
about XHTML.  It struck me as the best explanation of the XHTML 1.1
modularization thinking that I had run across and asked the author, Sebastian 
Schnitzenbaumer of Stack Overflow, a member of the HTML WG, why he didn't
post it on XML-DEV.  Turns out he'd found the flame content a little high
around here (he has a point) but asked me if I'd mind relaying it.  I 

He asked me to point out that this is *not* a statement on behalf of the
HTML WG, and this is definitely work-in-progress, but I gather represents
some of the thinking going on over there. 


> There are some integration issues to be worked out for namespaces.  For
> example if a user customizes a DTD to be a conformant subset, is the
> namespace the same?  If the user customizes a DTD but makes some changes
> that affect names, how does the user indicate a variant?  Is is useful
> to indicate the variant?   

This is something the HTML WG has explored in great detail.

Modularization of XHTML is the framework for the HTML WG and 
other parties to organize the development of XHTML, that's why I 
sometimes use the nickname "XHTML Development Kit".

The subsets, extended subsets and variants versus namespace 
issue was a problem the HTML WG needed to solve.

One might ask, why modularization in the first place? I guess this 
is similar here at the Web3D consortium, we have a lot of different 
implementors who address specialized domains and the times of 
"one size fits all" are over. It is desirable to allow innovation, and
allowing innovation means allowing variants. But how do you let 
others create variants in a safe way?

Here is the model the HTML WG is currently developing:

Basis is HTML 4.0, a monolithic, stand-alone ML.

XHTML 1.0 is just the same thing in XML clothing, same 
functionality but XML notation, still one big thing.

XHTML 1.0 introduces the XHTML namespace, without implying 
versioning (NS URI is now "http://www.w3.ort/1999/xhtml" BTW).

Modularization slices XHTML 1.0 into a dozen "modules". Think of 
a markup language as a cake. If you are sure that someone won't 
take the whole cake but only some slices, then it is better to define
"default cuts" instead of letting everyone randomly cut the thing into
pieces. If Vendor A says I'm using slices X, Y, Z and Vendor B 
says Y, Z, P, then Author C will now the Y and Z is the same in 
both Vendor A's and Vendor B's implementation.

Modularization of XHTML is the "module repository". In the module 
repository, there are more modules than a single version of XHTML 
can use, for instance, there are two forms module (HTML 3.2 forms 
and HTML 4.0 forms) and two tables modules, etc.

XHTML 1.1. is the same as XHTML 1.0, but the DTD is not 
monolithic, rather a specific combination of modules taken from the
module repository that aims to be a close match to XHTML 1.0.

Now comes the interesting part. The document "Building XHTML 
Modules" is the tutorial for any party (not only W3C) to create 
"XHTML conforming modules", a how-to guide on creating new 
modules similar in design to the those modules found at W3C's 
module repository.

To answer the namespaces question, let's play through a scenario:

Consortium releases module repository together with a specific 
combination known as StandardML. StandardML uses 12 of 15 
modules of the module repository. StandardML's 12 modules 
include 8 *mandatory* modules. All 15 modules of the module 
repository belong to the "StandardML namespace". Consortium is 
in control over StandardML namespace.

Vendor A thinks StandardML is nice, but rather than providing a 
strictly comforming StandardML implementation, Vendor A wishes 
to implement something different.

Subsets done by either Vendor A or Consortium:

Vendor A isn't capable of fully implementing StandardML. Vendor A 
creates a new StandardML "family member" by creating the 
specifc combination of just the 8 mandatory modules known as the 
Markup Language "StandardML-Basic". Since StandardML-Basic 
is a strict subset, it still belongs to the StandardML namespace.

Extended Subsets or Supersets done by Consortium only:

Consortium creates new modules, adds them to the module 
repository, creates a new specific combination of both old and new 
modules called StandardML 2.0. Consortium may either:

- hereby extend the StandardML namespace by the new modules
- introduce a wholy new namespace "StandardML 2.0", if the 
outcome is a completely new markup language where the names 
used in StandardML 1.0 are used in a complete different way in 
StandardML 2.0 (<p> suddenly meaning "parrot").

Extended Subsets or Supersets done by Vendor A:

Vendor A takes a set of module out the module repository, at least 
the 8 mandatory modules. Vendor A then creates one or many new 
modules after the guidelines set forth by Consortium. Vendor A 
now has five new StandardML-conforming modules. These five 
modules collectively define the MyML namespace being under 
control of Vendor A. The specific combination of modules (or family 
member) using both the 8 mandatory modules from Consortium 
plus the 5 new ones from Vendor A is called "StandardML-MyML".
The markup language StandardML-MyML has the StandardML 
namespace as the default namespace covering the StandardML 
modules, while the MyML modules in StandardML-MyML belong to 
the MyML namespace.

As an example, here is a sample file of XHTML-FML, an XHTML 
family member using XHTML 1.1 without the HTML 4.0 Forms 
module but instead with an additional namespace of five new 
Forms Markup Language modules:

<?xml version="1.0"?>
<html xmlns="" 
<meta name="generator" content="Mozquito Factory 1.0" />



Check to see the implementation.

For those of you who have access to the W3C website, check: 
for the links to the latest versions of the specs.

Otherwise, please see the public drafts:

XHTML 1.1 - Module-based XHTML 

Modularization of XHTML 

Building XHTML Modules 



Stack Overflow AG
Phone: +49-89-767363-70

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list