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