Bug 784858

Summary: RFE: Explicit Namespaces
Product: [Community] PressGang CCMS Reporter: Joshua Wulf <jwulf>
Component: CSProcessorAssignee: Lee Newson <lnewson>
Status: CLOSED DEFERRED QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 1.xCC: jwulf, lcarlon, misty
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-29 02:04:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Joshua Wulf 2012-01-26 13:56:57 UTC
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.

Comment 1 Lee Newson 2012-03-15 22:53:53 UTC
This isn't really feasible or needed at the current time. I'll come back to this at a later stage.