Bug 812704

Summary:	RFE: Support for entities in Content Specs / Topics
Product:	[Community] PressGang CCMS	Reporter:	Joshua Wulf <jwulf>
Component:	Web-UI	Assignee:	Matthew Casperson <mcaspers>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	1.x	CC:	cbredesen, jwulf, lcarlon, lnewson, mcaspers, topic-tool-list
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:	2014-01-13 06:19:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Joshua Wulf 2012-04-16 02:33:17 UTC

If you take a look at http://skynet.usersys.redhat.com:8080/TopicIndex/TopicEdit.seam?topicTopicId=7677

the topic is completely reusable except for one thing: the specific content spec ID.

One way around this is to write: "insert the appropriate Content Spec ID", and have a reference topic before the task topic, called "The Content Spec ID of this Book".

Another way to do it would be to insert a Docbook entity like this:

csprocessor checkout &CSPROCESSORID;

and in the Content Spec do this:

  Get the Very Latest Version of This Guide [7677, &CSPROCESSORID=7210]

The builder would then substitute the entity into the topic as it was building the book.

To enable reuse of the same entity across a book, there could be an entities section at the top of the Content Spec, to enable them to be defined globally for the Content Spec.

They would be localised (when appropriate) in the same way that Chapter and Section titles are localised.

Comment 1 Joshua Wulf 2012-04-16 02:34:07 UTC

An unresolved issue with this proposal is how entities are specified / stored / localised for non-Content Spec processor builds of topics.

Comment 2 Joshua Wulf 2012-04-16 02:35:41 UTC

Perhaps Skynet could present a report: 

Here are all the entities that need to be defined for the topics that you've selected for the build.

Comment 3 Joshua Wulf 2012-04-16 02:37:45 UTC

Actually, the Content Spec ID of the current Content Spec being built could be a reflexive. Since the builder knows what it is building, it could be a system-supplied entity.

So on encountering an entity:

&CONTENTSPECID;

The Content Spec processor could automatically replace the entity with the Content Spec ID of the Content Spec being built.

Comment 4 Joshua Wulf 2012-04-16 02:39:39 UTC

Then topic 7210 would be cut-and-paste reusable for all internal documentation initially, and then everything out in Fedora Land as well.

Comment 5 Lee Newson 2012-04-16 02:43:34 UTC

As with Bug #809334 any injection related data must be handled by both Skynet
and the CSP. So moving it to the correct queue and i'll look at the rest of the
content later.

Comment 6 Lee Newson 2012-07-24 22:19:06 UTC

*** Bug 827767 has been marked as a duplicate of this bug. ***

Comment 7 Lee Newson 2012-08-01 03:45:41 UTC

Extra note:

Misty brought up that adding XML Entities brings up issues with translations.

Comment 8 David Ryan 2013-05-14 03:14:25 UTC

I believe Josh is referring only to entities in terms of content spec IDs, not for content in the copy itself. We don't do the latter for reasons you've already touched on in Comment 7.

Comment 9 Lee Newson 2013-05-14 03:37:10 UTC

Yes that is his direct use case, but the RFE never mentions only using it for that. I also can't see an entity just for injecting a PressGang ID to have much use outside of this use case. Also from my perspective, it would be weird to allow some entities and not others (we can only allow entities that won't affect translations).

To do the latter, it would require a fair bit of research and even then I suspect it would be very hard to come up with a rule that would work in all cases.

Comment 10 Lee Newson 2014-01-13 06:19:28 UTC

This can be done using BZ#1013882 so marking it as CLOSED.