Namespaces !

Ron Bourret rbourret at dvs1.informatik.tu-darmstadt.de
Tue Aug 4 15:35:58 BST 1998


Patrice Bonhomme wrote:

>  3/ Implementation.
> 
> If i understand the new WD, it's possible to have everywhere within the 
> document (in each Element start tag) a Namespace declaration. Hum, i agree 
> with James Clark that it is easy to implement but we have to provide for each 
> Element object an 'xmlns' attribute and make inherited each one of its 
> descendants.

Actually, DTD designers can't provide an xmlns attribute for each element in the 
way I think you mean.  This is because the attribute name itself carries 
instance-specific information (the instance-specific prefix), which the DTD 
designer can't know ahead of time.  Thus, if an instance wants to use a 
different prefix, it must declare its own attribute in the internal subset:

<!ATTLIST foo xmlns:myprefix CDATA #FIXED "myURI">
--OR--
<!ATTLIST foo xmlns:myprefix CDATA "myURI">
--OR--
<!ATTLIST foo xmlns:myprefix CDATA #IMPLIED>

(In the last case, the instance must actually use the attribute on the 
appropriate element.)

If no DTD is being used, the instance author simply adds the xmlns attribute of 
their choice to the element of their choice.  

<Aside>
xmlns attributes are backwards from the way attributes usually work.  Normally, 
the attribute name is fixed (by the DTD designer) and the instance supplies 
information in the attribute value.  With the xmlns attribute, the value is 
essentially fixed (the whole point of the namespace URI is that, for a given 
namespace, it doesn't change), while the attribute name carries the changing 
information (the prefix).

Unfortunately, there is no reasonable way to flip this around.  You can't just 
use xml:prefix and xml:ns attributes because this would limit the number of 
namespace declarations to one per element.  It also wouldn't work for these to 
be NMTOKENS attributes (allowing multiple declarations) because URIs don't match 
the Nmtoken production.
</Aside>

This is not really different from the old spec, except for more flexibility in 
the scoping of namespace prefixes.  If you (as an instance author) want to 
duplicate the old PI, just add your prefix attribute to the root element.  If 
you want more limited scope, add it to the appropriate nested element.  The 
other (minor) advantage of the new spec is that (depending on the parser used 
and where the DTD resides), the namespace prefix can be declared by in the DTD, 
which means that instance authors do not need to remember to include the PI.

One last thing to remember is that most people are not going to spend a lot of 
time changing prefixes anyway.  There is simply no point.  The DTD designer 
designs a DTD and assigns a prefix to be used for the new elements (or sets a 
default namespace, which is the most sensible thing).  If the DTD designer then 
uses elements from another namespace, he/she/it checks for collisions with 
existing prefixes and assigns a new prefix accordingly.  The instance author 
then just uses the prefixes already in the DTD and spends their time creating 
instance files (which the understand) instead of changing prefixes (which they 
don't).

(Beware not to assume any magic about namespaces.  I used to imagine that they 
would automatically merge XML files and their corresponding DTDs.  While it is 
certainly possible to build the software to do this, using namespaces to resolve 
collisions, it is not (yet) a common operation.  Most people are going to create 
documents from fixed DTDs in which all namespace collisions have already been 
resolved by hand.)

-- Ron Bourret

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/
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