Namespaces allow output documents to be built with topics from different instances of Skynet.

At the moment the content spec uses a single implicit namespace, that of the server it is running on.

Now, using the REST interface, the content spec processor can interact with multiple instances of Skynet.

In the first instance, we should make the namespace of the content spec explicit:

So, in the post-processed spec we need to declare the namespace in the header.

For example: 

DEFAULT_NAMESPACE: https://skynet.cloud.lab.eng.bne.redhat.com:8443/TopicIndex/

Then, all topic IDs without an explicit qualifier are implicitly assigned this name space.

To declare an additional namespace, the header can include:

NAMESPACE: fedora = http://fedora-skynet.openshift.com

Now when a topic is specified in the content spec it can be done like this:

Chapter: Something from Fedora
  A topic from Fedora's Skynet [fedora:1553]

A topic from the default namespace would be:

  A topic from the default Skynet [760]

This achieves two things:

1. With an explicit namespace, Content specifications can be built by any content spec processor instance, which will retrieve the topics from the correct repository
2. With explicit namespaces, Content specifications can mix material from different repositories



Each Content Specification must now include a NAMESPACE declaration. If a content specification is pushed to the server with no NAMESPACE declaration, then the server will write its own namespace as the DEFAULT_NAMESPACE value for the post-processed Content Spec.