Namespace Evolution Proposal

[Paul Prescod]

A very (very!) rough draft of a specification that allows us to reliably
interpret variants of a particular document type. I wrote this a few
months ago but never got time to clean it up and solicit comments. Now
seems like a good time even if I can't clean it up right now.

----

It is often the case that two namespaces will be very similar but not
quite identical. In this case "similar" means that the semantics and
structures associated with names might be "close enough" for all
processing associated with one namespace to also apply to the other. The
namespaces specification does not address this issue. 

This specification describes a convention for stating that namespaces
are similar and formally stating the nature of the similarlity.

The scope of these declarations is the directly containing element and
all of that element's children which follow the declaring element.

The <xmlns:evolution href=""> element states that the attributes on the 

The <xmlns:same-name newURI="" newName="" oldURI="" oldName=""> states
that the given name in the namespace "new" can be interpreted as
identical to the name oldName in the namespace oldURI. So HTML 4.0
strict's A element type would be the same-name as HTML 4.0 loose's A
element type.

The <xmlns:subset newURI="" oldURI="" exceptions=""> element states that
any name in the namespace "new" can be directly interpreted as a name in
the namespace "old" except for the names specified in the exceptions
attribute. So HTML 4.0 would be identical to HTML 3.0, except for the
APPLET tag and some other similar stuff.

The <xmlns:suppress newURI="" oldURI="" names=""> element states that
elements and attributes with the listed names in the new namespace
should be ignored by applications understanding only the old namespace.
It should be as if they did not exist. For instance, HTML BGCOLOR
attribute and BGSOUND element.

The <xmlns:suppress-unknown-content newURI="" oldURI="" names="">
element states that sub-elements of the element that are not known by
the application to be part of oldURI should be surpressed. For instance,
HTML APPLET or OBJECT.

The 

<xmlns:transform newURI="" newName="" oldURI="" oldName=""> 
  <xmlns:transformation lang="" uri=""/>
  <xmlns:transformation lang="" uri=""/>
</xml:transform>

element states that the name newName in namespace newURI can be
interpreted as equivalent to the name oldName in the namespace oldURI
after the application of any of the given transformations. The lang
attribute is a URI that identifies the transformation language. The lang
attribute is optional if the transformation is defined in prose (for
instance an "ignore elements that start with _" rule might be globally
understood).

Recommended transformation languages include XSLT, STTS, DSSSL, XML
architectural forms (with or without a meta-dtd) and a Javascript/DOM
program).

Using the built-in transformational elements is superior to referring to
an external transformation because they are guaranteed to be universally
implemented. 

Using an external transformation in a simple, standardized external
language is better than using an external transformation in a complex,
standardized external language but it increases the liklihood of
implementation.

Using an external transformation in a standardized language is better
than using one in an unstandardized language. The other option is
provided only because some applications may require the extra
flexibility of pointing (e.g.) to Java classes or an Active-X program.

 Paul Prescod

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