Bug 752710
| Summary: | RFE: Topic Map topic type | ||
|---|---|---|---|
| Product: | [Community] PressGang CCMS | Reporter: | Joshua Wulf <jwulf> |
| Component: | CSProcessor | Assignee: | Nobody <nobody> |
| Status: | NEW --- | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.x | CC: | sgordon |
| 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: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 752997, 751295 | ||
A couple of observations: The Topic Map topic should be validated when it is pushed. Any relationships that are declared in the Topic Map should be in the Topic Map, so no dependencies outside the Topic Map are allowed. See the interactive demo here: http://downtown.englab.bne.redhat.com/download/videos/2011-11-10-jwulf-The_Zen_of_Relationships.zip Each of the "topics" being remixed in that demo will be Topic Maps. Is this made obsolete by the direction the csprocessor is going in now? (In reply to Misty Stanley-Jones from comment #3) > Is this made obsolete by the direction the csprocessor is going in now? For those of us playing along at home, what direction is that? :). I came across this when looking to file a similar request. My use case is a common OpenStack introduction, I would prefer to be able to maintain it in a map that is included in each guide rather than split out another RH-based brand (and the overhead that comes with that) or copy pasting the structure to each spec. Lee Newson can speak to this more, but the goal is for the CSProcessor map to be an object, not a flat text file. This will enable us to build an interactive UI around the topic map creation and editing process (collaborative drag-drop to reorganize, among other things). We would probably still include a way to represent the map as a flat text file, but that wouldn't be its internal structure. One implication of that change is that specs won't be stored just like topics, as they are now. The way it is done now was always a temporary measure. I'll have to talk to the Team on this one before I can provide an accurate answer sorry Misty and Steve. But the idea behind this should still be valid and do-able. It would actually tie in fairly nicely with BZ#833289. +1 for this request.
The RHEV and OpenStack use case is that we are sharing topics across both suites. It's easy enough to update a topic and have the changes applied across both suites, but what if we need to add a new topic into the sequence? We'd have to rely on manually adding the topic into all affected content specs.
So to take Josh's example map:
Chapter: Install Proxy Server
The Proxy Server [56]
Section: Getting the Proxy Server
Red Hat Network [34]
Red Hat Network and Software Delivery [78]
RHN Channels [55]
Required RHN Channels for the Proxy Server [678]
Download Software [80]
If we wanted to add a new topic, like "Required Red Hat Subscription Manager Entitlements", which applies for both RHEV and RHOS (albeit with conditionals) we could add the topic into the topic map. Here the topic maps in each content spec will automatically pull down this added topic.
This will help us greatly in keeping content synced across different suites without having to keep manual checklists.
Moving this back to NEW, since there hasn't been any activity on this bug for some time and we currently don't have anything scheduled. *** Bug 1088056 has been marked as a duplicate of this bug. *** |
A new topic Type, a Topic Map. A Topic Map is a reusable section of a Content Spec. It maps roughly to a docbook Chapter, and is written as a Content Spec. The Content Spec processor will process content specs to resolve and expand all nested Topic Maps until it has a Content Spec composed purely of non-map topics, then it will build the output. For example: Topic ID 567; Topic Type: Topic Map; Topic Title: Install Proxy Server Topic content: Chapter: Install Proxy Server The Proxy Server [56] Section: Getting the Proxy Server Red Hat Network [34] Red Hat Network and Software Delivery [78] RHN Channels [55] Required RHN Channels for the Proxy Server [678] Download Software [80] Section: Installing the Proxy Server Install the Proxy Server [455] ======================================== So a Content Spec that contains: Install Proxy Server [567] Chapter: Configure Proxy Server Configuration tools [577] Configure the Proxy Server [31] ===================================== becomes, when the Topic Map topic ID 567 is expanded: Chapter: Install Proxy Server The Proxy Server [56] Section: Getting the Proxy Server Red Hat Network [34] Red Hat Network and Software Delivery [78] RHN Channels [55] Required RHN Channels for the Proxy Server [678] Download Software [80] Section: Installing the Proxy Server Install the Proxy Server [455] Chapter: Configure Proxy Server Configuration tools [577] Configure the Proxy Server [31] ============================================== and then gets processed. So all topic maps are expanded, then the Content Spec is processed.