Possible enhancements to Namespaces to allow valiadation

Marc.McDonald at Design-Intelligence.com Marc.McDonald at Design-Intelligence.com
Thu Feb 11 00:06:47 GMT 1999


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 
declared.
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 
localname.
8.	The method of processing namespaces is not defined by the 
recommendation.

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 
validation.

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 
document.

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 
URIs.

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.

Marc McDonald
Principal Software Scientist
Design Intelligence Inc.
www.design-intelligence.com


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)




More information about the Xml-dev mailing list