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.
An unresolved issue with this proposal is how entities are specified / stored / localised for non-Content Spec processor builds of topics.
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.
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.
Then topic 7210 would be cut-and-paste reusable for all internal documentation initially, and then everything out in Fedora Land as well.
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.
*** Bug 827767 has been marked as a duplicate of this bug. ***
Extra note: Misty brought up that adding XML Entities brings up issues with translations.
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.
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.
This can be done using BZ#1013882 so marking it as CLOSED.