Home

• explain
• command-line
• schemas
  • b: ms: base
  • c: msc: concept
• contact

Namespaces, version and prefix

The Meshy Space Interfaces are build on various components, probably written by different people and going through many versions over time. How do we manage these definitions? Especially, how should we use our (XML) tool-set to make this work best.

Cooperative Interface Design, OO style

When projects are large and many people involved, you really benefit from techniques from Object Orientation (OO). We have chosen to model data in XML Schemas: How does OO design compare with features which XML Schemas offer?

Abstraction

Use namespaces to keep data and types which are maintained together clearly grouped together. For instance, one specification contains everything about "contracts" in one schema with one namespace.

Encapsulation

Real OO programming languages enforce functional and data abstraction. There are many ways to break through abstractions with XML schemas:

• namespace-less elements;
• second XSD with same targetNamespace;
• overruling targetNamespace per element;
• xsi:type attributes;
• use of any elements;
• use of any*Type types;

We SHALL not use any of those.

Inheritance

Other specification components can build upon base specifications. For instance, the base specification defines the generic structure of a message and the extension specification builds on that.
In XML, types have the extension and restriction mechanism which can cross namespaces to achieve this.

Polymorphism

Code is able to handle anything derived from a base-type without the need to understand all the extensions. For instance, the layer which sends a message does not need to know which extensions exist.
In XML, the best way create this mechanism is via substitutionGroups.

Dynamic Binding

This is the reverse relation of Polymorphism: getting to specific data of functions based on a base object. In programming, this is achieved by pluggable extensions.

Namespaces

Only serializations which support namespaces are ready for cooperation and long-term maintainability. Lower level specifications may introduce names which are already in use on higher levels. Those accidents may be detected very late and hard to solve. Besides, when elements use definitions which origin from different sources, it can be a pain to find-out which documentation you need. Also for the software.

By default XML, does not use namespaces on attributes. Probably because the intention was that elements rarely carry attributes. However, in real schemas, the number of attributes is often not small and from various sources.

It is a matter of taste, which rule to take:

  <shop:product id="123" product-id="342">  <!-- unqualified attributes -->
  <shop:product db:id="123" shop:id="342">  <!--   qualified attributes -->

Meshy Space requires qualified attributes.

Versions for Specification

In the beginning of XML, the namespace had three roles:

• create a value space which only you can use, because the namespace MUST be a URL using a hostname which you own;
• the URL contains a version number in the path;
• that URL is expected to point to a place where the schema and/or documentation can be found;

Although the version number is in the path, it is only a numbering scheme that people can interpret: namespace URL have no required structure besides being a value URL. When two namespaces differ 1 single letter, they are simply unrelated in the technological sense. As work-around, people started to use a version attribute to the <schema> root element.

In Meshy Space, the namespace points to a unit which contains the latest version. This way, it gets the default life-cycle handling of units. One unit may contain the same specification in multiple specification formats, like XML-Schema, JSON Schema, and Swagger. As long as they are compatible.

Meshy Space schemas avoid the requirement to upgrade to the latest version of a schema whenever possible. The consumer of the messages tells the server which version of a schema it understands: the server may adapt its output based on that.

Meshy Space Concept "Operations" specify which minimal version of each sub-specification they support. The user always has the newest version of the schemas, however only important is what the software support. No need to upgrade the user's application to understand the newer schema version when the new features are not used and not required by the server.

Use of prefixes for namespaces

In a world without prefixes, we would not use long namespaces. In any serialization of messages (also JSON!), namespaces are used on all keys. Of course, the prefixes are not fixed.

You may decide to use (namespace, key, value) triplets inside your program, or use "prefix normalization", where the prefix as found in the input is translated via the namespace in a prefix which is convenient for you. For instance, which you prefer in your output.