Lists Home |
Date Index |
- From: <Marc.McDonald@Design-Intelligence.com>
- To: <email@example.com>
- Date: Wed, 10 Feb 1999 16:05:49 -0800
I've been following this latest conversation on namespaces and
validation. My understanding of namespaces is as follows:
1. An element can define a namespace prefix which can be used to
distinguish element and attribute names via the xmlns:prefix="URI"
attribute. The prefixes are containment-scoped.
2. An element can defined a containment-scoped default namespace using
the xmlns="URI" attribute.
3. A URI is just a globally unique identifier for the namespace. It
need not correspond to any DTD.
4. An element or attribute name without a prefix is interpreted as
belonging to the default or to no namespace if a default has not been
5. An element or attribute name can have a prefix, prefix:localname,
which indicates its namespace
6. The prefixed form, a qualified name, is just a name to an XML
parser (':' is a legal name character)
7. Qualified names are identical if they refer to the same URI and
8. The method of processing namespaces is not defined by the
A document using namespaces can be conformance parsed using any
existing XML parser since any qualified names would appear to be
normal names and attribute declarations aren't validated so there are
no problems with any xmlns[:prefix] attributes.
However, validity parsing implies a number of changes:
1. Qualified names must be converted into unique names involving the
URIs associated with the namespaces. Different prefixes can refer to
the same URI.
2. Any DTDs containing elements referred to by a qualified name must
be modified to use qualified names themselves.
3. A DTD must be constructed for the document, this can be difficult.
A solution discussed in the thread involves creating a new document
and associated DTDs with these changes made and then doing normal XML
The DTD against which the document is validated is can easy to
construct because it matches the current document in which case the
only elements being validated are the elements from namespaces. On the
other hand construction can be quite complex due trying to synthesize
the more general combination of namespaces from a single example
I would argue any process that involves the modification of existing
documents and DTDs is flawed. As has been mentioned in another thread,
modification of 50 megabyte documents and megabyte DTDs can involve
significant space and CPU time.
I would suggest the following changes to the namespace recommendation
to address some of these problems:
1. Allow a DTD to declare the namespaces and prefixes it uses.
2. Allow a DTD to declare its default namespace (itself). This removes
the need to prefix elements and attributes in the DTD.
3. Allow a namespace declaration to optionally include a URL for a
DTD, just as documents do.
4. Enhance XML validation. When an element is not in the current
namespace, look at the namespace declaration. If it does not have an
associated DTD, only do well-formed parsing of the element. If it does
have an associated DTD, validate the element against the associated
DTD with the new namespace as the default. This would nest on each use
of a different namespace
Note: Change 2 is actually optional in view of change 3 since the
latter would set the default namespace to the namespace of the DTD. It
would be used to declare the standard URI and prefix for a namespace
in its associated DTD and part of validity checking could be to match
I would punt the problem of constructing the DTD for the document.
Only a human would be able to decide which elements from which
namespaces can be where.
If elements can be anywhere, the value of validation is vastly
reduced. The only elements validated would be those of different
namespaces. This is akin to using ANY in every element declaration, so
much is made legal that little is invalid.
Principal Software Scientist
Design Intelligence Inc.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)