XML Namespaces and NAMM Standards

Submitted by dankessler on Wed, 08/19/2009 - 9:33am.

 

The issue: published NAMM Standard documents did not include namespace declaration and therefore become defined as part of the 'global' namespace.  This can lead to namespace collisions and parsing difficulties. This is not a 'Best Practice'.

The solution involves adding declarations to the <xs:schema> element.  This has been done 'un-officially' by some users of the documents for the reasons above.  We need to decide how we want to do this:

 

  1.  what should our namespaces be labled?

    I suggest that namespace be something like 'http://b2b.namm.org/2009'

  2.  should the namespace 'name' point to a real link?

    This is not required and can cause confusion, however we might as well do this if/when we can.  
     

  3. should we use one [homogeneous] namespace for the document set or one namespace for each document.

    I think that we should use just one namespace for the set.  This will force some consistency for elements that are used in multiple documents, for example the <address> complex type is used in multiple places and should be defined consistently for the sake of people parsing the documents.
     

  4.  should we try to handle 'versions' via namespaces?  

    I am inclined to think that we should not attempt that at this point since it might add undue complexity.  We are always trying to keep things as simple as practical so that implementation is easier.  Or perhaps only some level of version should be used.

Here is the result of my thoughts.  Something like this should be in each XSD document as the schema element:

 

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   targetNamespace="http://b2b.namm.org/2009"  <!-- same target namespace for document set -->
   xmlns="http://b2b.namm.org/2009/PO" <!--diffent for each individual xsd --> 
   elementFormDefault="qualified">

What do you think?  Can you take this back to your programmers and get some feedback to see if this works for you, and if they agree that this is a reasonable way to address our issues?  

 

 

Versioning

Submitted by ericc on Wed, 09/16/2009 - 10:55am.

Here are my thoughts on using versions in the namespace:

No version: This could cause problems when upgrading to a new version. A large number of node names changed between version 2007 and 2009, if someone missed a few, their validation methods wouldn't have caught it. Having the version in the namespace will prevent that.

Limited version (2009): Prevents the problems I mentioned in not having a version, but introduces some smaller problems. If I remember correctly, the 2009.1 or 2009.2 update fixed some spelling errors in a few node names. Technically speaking, that should cause a change in identifying the namespace. That doesn't mean we HAVE to adhere to that, but best practices would say that we should.

Full version (2009.1, 2009.2, etc.): As mentioned during the conference call, this introduces some complexity that could be a show-stopper for some companies. It does have the advantage of preventing the problems I listed for other options.

All that said, my personal opinion is that the method Dan suggests in this document would be best. Having the same namespace across all the documents in a set allows for consistency (for example: forcing us to use the same <address> node design across documents).

Thanks for the feedback

Submitted by dankessler on Wed, 09/16/2009 - 12:43pm.
This is exactly what I hope to hear from several of us on this topic. Please chime in!

©2010 NAMM, the National Association of Music Merchants