namespcae nesting

[martin mollema]

I'm stuck with the following problem:
I want to develop a namespace that consists of two (later possibly
more distinct namespaces)
These subnamespaces are the DC element set and a private extension.
The naming convention is DC:elementName and OVERHEIDtherElementName.
In order ease the processing of these two element sets,
I would like to create a new namespace, say METADATA this would lead
to tagnames like
METADATAC:elementName or METADATA:OVERHEIDtherElementName.

Is this syntax valid for XML element names?
How do I define the namespace?
Do I have to use METADATAC and METADATA:OVERHEID as two seperate
namespaces,
or is it possible to create a namespace METADATA that consists of
namespace DC and OVERHEID

Thanks in advance for your help

Martin Mollema

 

[David Carlisle]

I'm stuck with the following problem:
I want to develop a namespace that consists of two (later possibly
more distinct namespaces)

You can't. XML Namespaces are all the same (apart from their name) and
consist of the set of names legal for XML elements that don't have a
colon.

These subnamespaces are the DC element set and a private extension.
The naming convention is DC:elementName and OVERHEIDtherElementName.

In order ease the processing of these two element sets,
I would like to create a new namespace, say METADATA this would lead
to tagnames like
METADATAC:elementName or METADATA:OVERHEIDtherElementName.

Those names would not be accepted by an XML Namespaces conformant system
(like Xpath or XSLT) although they are well formed XML 1.0 names.

Is this syntax valid for XML element names? No.

How do I define the namespace?
Do I have to use METADATAC and METADATA:OVERHEID as two seperate
namespaces,

You could do that.

or is it possible to create a namespace METADATA that consists of
namespace DC and OVERHEID

This is technically possible, and trivially easy, you just do it,

<otherElementName xmlns="http://purl.org/dc/elements/1.1/"/>

see, I just did

However it may be considered bad form as the intention behind namespaces
is essentially that the you can tell who "owns" an element definition by
looking at who owns the namespace

An alternative if you don't want to burden the user with lots of
namespaces is to define elements in your own namespace but you define
them as having the same meaning as dc. This is a common technique
and is most useful if you have a large compound document format
that is mainly going to be used by a specifc tool that needs to know all
all the components. The downside is that the "dc" elements will then
look like dc elements but as they are in the "wrong" namespace they would
not be recognised as such by generic dc tools, and your documents would
have to go through a simple transformation that pulled the dc elements
out of your namespace and put them in the public dc one.

We do this in house at nag. We have an internal document format which
has mainly our own elements, but also uses parts of xhtml, mathml and
xlink. internally we don't use namespaces at all, but the XSLT that
generates any public files "knows" that various elements should be
switched to appropriate publicly defined namrespaces, so builds that in
to the transform.

Thanks in advance for your help

Martin Mollema

David