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" 

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.

  • 6
    Question #500!!
    – Nuno Linhares
    Jun 5, 2013 at 16:43
  • I have to ask why on earth you would want to make them all the same rather than leaving the default UUID namespaces that Tridion makes for you. Is there a reason to change them? Jun 5, 2013 at 19:01
  • @chris you'll have to ask michelov :)
    – johnwinter
    Jun 5, 2013 at 19:15

3 Answers 3


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.

  • Great thinking Dominic, I totally agree. In Tridion we are used to put a unique namespace on every schema, but that is not nesseseraly an XML best practice I would say. It all depends on how granular the schema is designed. On the other hand, in Tridion we have no way to collect all the XSD definitions from the schemas to check if we don't specify the same thing twice. So unless you do XSD first design, I would consider to go with unique schema URIs for every Tridion schema.
    – Jan H
    Jun 5, 2013 at 22:36
  • Well then you'll still have to know what's in the other schemas to avoid repeating it, or stick with the assigned guid. Jun 6, 2013 at 5:36

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


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

  • 1
    Surely if your schemas have different root elements this can provide the context that you need to differentiate? Restaurant/Name, Sandwich/Name
    – Will Price
    Jun 5, 2013 at 18:38
  • Hence why I said that is an overly simplified sample - Consider something like <xsl:template match="Name">... Jun 5, 2013 at 19:00
  • 3
    Then you have the best of both worlds. If you want to create a template to generically handle both, use <xsl:template match="Name">, if you want to have a template that operates only on restaurant name, use <xsl:template match="Restaurant/Name">
    – Will Price
    Jun 5, 2013 at 19:11
  • If you needed to use sandwiches and restaurants in the same document on the output side, you would transform the elements to be in the namespaces dictated by your design for the output XML. There's no reason why that would have to be the same as the namespace in the Tridion Component. Jun 8, 2013 at 8:22

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.

  • 3
    Why do we specify a root element name then? I would have thought the combination of namespace and root element would uniquely identify the document...
    – Will Price
    Jun 5, 2013 at 18:39
  • 1
    Given Namespaces were created to uniquely identify XML documents based on a schema, why would we do it differently from what everyone else does?
    – Nuno Linhares
    Jun 5, 2013 at 18:50
  • 3
    Fair point, although I think the nature of Tridion (embedded schemas for example) can lead to parts of a schema being semantically the same as parts of other schemas, thus perhaps better represented as being part of the same namespace.
    – Will Price
    Jun 5, 2013 at 19:12
  • Nuno - any chance you can get more concrete information on the Content Porter problem, and whether it was ever fixed? Jun 5, 2013 at 21:43
  • 1
    Answer #111 from Mr. Linhares!!! Jun 6, 2013 at 0:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.