Custom Schema Namespace

Question

The lead (Mr Mickolov Wroussakov) of the project I'm currently working on has specified a custom namespace for all content schemas:

<xsd:schema elementFormDefault="qualified" 
targetNamespace="http://www.clientdomain.com/tridion/schemas" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns="http://www.clientdomain.com/tridion/schemas" 
xmlns:tcmi="http://www.tridion.com/ContentManager/5.0/Instance">

I was always under the impression that is is recommended to create a unique namespace per schema, here all of these implemented using the item shown above.

I don't see any issues as such, i'm just wondering if this could open up some problems in the future.

Answer 1

There is no reason in principle not to use one namespace for multiple schemas, as long as those schemas don't attempt to define the same types.

A namespace is a mechanism to enable you to prevent name collisions. If you have some other factor helping to prevent such collisions, there's no reason why namespaces should do all the hard work.

The most important thing is that you have a design and that you follow it. If half your developers expect one namespace per schema, and the rest are also using root element names or whatever, you're in trouble.

A namespace is not supposed to uniquely identify a schema or a document. A "find schemas by namespace" feature might sound clever, but I'd suggest re-reading the recommendations before implementing it. It's certainly not what namespaces were intended for.

I do recommend replacing Tridion's default GUID-based namespace URIs. The main reason for this is that you will usually want to reference them in code, and GUIDs are a right bugger to type accurately and/or verify visually. Ideally, choose a scheme whereby you can reliably predict casing and the like - it just makes life easier. Using a meaningful name is also good. It might help if your component XML gets exported to an external system: people will know where it came from.

Another reason for specifying your own URIs is if you are importing data for a pre-existing schema.

Having said all of that, although I disagree that using the same namespace for more than one schema is a terrible idea, I'm not thoroughly convinced that it's a good idea. Judgement must be applied.

Answer 2

Using the same namespace on all your schema is a TERRIBLE idea. Especially if you ever use XML technologies to read values from the XML.

Imagine you have a Sandwich Schema and and a Restaurant Schema, both schemas have a field called "Name". Now for what ever reason you need to merge these resulting Component XMLs into one document. All the nodes in the combined document will be in the same namespace. So the following XPATH would match the "Name" nodes of the sandwich and the restaurant

<xsl:value-of select="//Name"/>

If you used namespaces correctly you could use the following XPATH queries to access specific nodes

<xsl:value-of select="//sandwich:Name"/>

and

<xsl:value-of select="//restaurant:Name"/>

This example is a very simple one (and a bad practice as it uses //), but illustrates the point. It will become more significant when you start using apply-templates etc.

Answer 3

Actually, yes, it will potentially cause issues in the future.

For one, we're looking into implementing "Find Schema by Namespace" functionalities on CM and CD - having the same namespace for all schemas will "confuse" Tridion, at the very least.

I have also seen problems with Content Porter Translation Manager (though there was other stuff going on in the same environment), and one of the things we did to fix this was to ensure each schema had its own Namespace URI.

A XSD Namespace URI is supposed to identify uniquely every document of this type. What you're doing may save you time now, but hurt you in the future.