Add the ability to specify tags for a topic being reused, like this: A Reused Topic [67, +My Book, +Release 5.3] This way when topics are reused they are tagged into whatever release / book / product is reusing them.
Added in 0.22.0 You can now add tags to existing topics in the same format as you previously could. You can't set the Writer, add Urls, Descriptions unlike New or Cloned Topics. Duplicated topics still will refuse to take additional tags, urls, etc...
A couple of thoughts in consideration in favor of requiring "+tag" for adding tags to existing topics. 1. A New Topic [N, Concept] [tag1, tag2] A Reused Topic [54] [tag1, tag2] Although the two lines above look similar, they do not have the same consequences. Assuming no global tags in the spec, the first one will create a topic with exactly two tags. The second one will modify the Reused Topic, but it will have two tags plus any existing tags. So the first one will have *at most* two tags, the second one will have *at least* two tags - something that is not immediately apparent. The two declarations look the same, but one is exclusive while the other is additive. A New Topic [N, Concept] [tag1, tag2] A Reused Topic [54] [+tag1, +tag2] Makes it clear that tag1 and tag2 are *added* to the existing tags of Topic 54, rather than replacing them. 2. What about the ability to globally apply a tag to all new topics in the Content Spec, but not to the existing ones? For example, if I want to route them into some custom workflow through a filter on a tag. If existing topics require a +tag to add a tag, then I can do this: #Global tags [needs_writing, +thisbook] If +tag can be used on new or existing tags, then all new tags in my content spec would have "thisbook" and "needs_writing" tags, whereas the existing topics would only be tagged with "thisbook". If +tag was exclusively for existing topics, then you would achieve the same effect with: [needs_writing, +thisbook, thisbook] Making "+tag" and "tag" equivalent removes the ability to apply differential tags to new and reused topics in a content spec using the global tags. I'm finding this an issue now because I have a bunch of reused topics and a bunch of new ones in a content spec, and there is no way for me to differentially tag them to sort them in a filter. I didn't mark the written ones as written previously, so now I'm going through the filter and marking the written ones "written". I'm sure there will be other routing requirements that this would support - but obviously they have no weight until we encounter and identify them.
I found a way around the "tag existing topics as written" thing: Filter on the tags for the content spec + Topic XML ~ <section> This returns all topics in the content spec that have xml content. Then do "Bulk Tag: Written"
Time to document this.... Lee, can you clarify how this works? If I have a global tag in my book for the product that I'm documenting, will all topics that i reuse in that book inherit that tag? Or do I need to use the +tag syntax?
All topics will inherit that tag. So if you use a tag at the global level it will filter down through all the topics and levels. If you do it on a Level it'll filter down through everything in that level. If that's not clear I'll provide an example.
I just tested this and by adding a tag to the square brackets after the existing topic ID in a content spec file. i.e., Exporting the Repository [10064] becomes: Exporting the Repository [10064, BRMS 5.3] By adding ', BRMS 5.3' to each topic, all of the topics were successfully tagged. It DID NOT work when I tried: Exporting the Repository [10064] [BRMS 5.3] The CSProcessor gave the error message: Duplicate bracket types found. (If only I'd seen your comment before I tagged them individually)
Yeah, that second syntax isn't correct and as far as I can recall it's always thrown an error.