Custom Schema Namespace

18

1

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.

johnwinter

Posted 2013-06-05T16:41:34.773

Reputation: 12 086

6Question #500!! – Nuno Linhares – 2013-06-05T16:43:01.313

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? – Chris Summers – 2013-06-05T19:01:48.697

@chris you'll have to ask michelov :) – johnwinter – 2013-06-05T19:15:23.087

Answers

12

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.

Dominic Cronin

Posted 2013-06-05T16:41:34.773

Reputation: 14 997

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 – 2013-06-05T22:36:11.527

Well then you'll still have to know what's in the other schemas to avoid repeating it, or stick with the assigned guid. – Dominic Cronin – 2013-06-06T05:36:26.490

12

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.

Chris Summers

Posted 2013-06-05T16:41:34.773

Reputation: 7 657

1Surely if your schemas have different root elements this can provide the context that you need to differentiate? Restaurant/Name, Sandwich/Name – Will Price – 2013-06-05T18:38:32.213

Hence why I said that is an overly simplified sample - Consider something like <xsl:template match="Name">... – Chris Summers – 2013-06-05T19:00:12.533

3Then 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 – 2013-06-05T19:11:23.833

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. – Dominic Cronin – 2013-06-08T08:22:38.510

10

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.

Nuno Linhares

Posted 2013-06-05T16:41:34.773

Reputation: 27 884

3Why 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 – 2013-06-05T18:39:26.073

1Given 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 – 2013-06-05T18:50:09.693

3Fair 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 – 2013-06-05T19:12:38.903

Nuno - any chance you can get more concrete information on the Content Porter problem, and whether it was ever fixed? – Dominic Cronin – 2013-06-05T21:43:56.587

Right. It wasn't Content Porter :( it was Translation Manager. We needed to be able to distinguish the documents by their namespace, since the schema is not available in the Translation Manager side of the equation. – Nuno Linhares – 2013-06-05T21:47:21.697

1Answer #111 from Mr. Linhares!!! – Glenn Stevens – 2013-06-06T00:11:32.697