Refactoring a DITA Map considers the profiling conditions
Posted: Thu Sep 10, 2020 3:51 pm
Hi SyncroSoft folks,
I owe you a huge thank you for Oxygen being cleverer than I expected.
We just had our first major documentation release using Oxygen/DITA/Git. I needed to provide a way for our writers to remove the @rev attribute from their DITA content. But there was a catch - I needed to preserve @rev in any content hidden by @props, as some features were deferred at the last minute.
Easy enough, just have the refactoring XSLT skip any @rev elements with a @props in ancestor-or-self, right? Well yes, but this didn't cover the case where entire topics were hidden by applyiing @props to the topicref in the map -- there was no topic-level @props definition for the XSLT to "see".
SyncroSoft to the rescue! It turns out that when you choose "Current DITA map hierarchy" as the scope of an operation, it skips any map elements that are fully hidden by the current profiling conditions. This is enormously powerful, as it allows the full power of DITAVAL to control the XSLT scope. Or put another way - because the DITAVAL controls what content is publicly seen by customer eyeballs, we can use that exact same mechanism to know where @rev should be removed because the content is published.
Here is a graphic showing our @rev-removing transformation running with all map entries shown:
Here is a graphic showing our @rev-removing transformation with the @props map entries hidden:
In the second image, note that the "props_in_map.dita" topic is no longer affected by the transformation.
(I did find that "Show Excluded Content" had to be unchecked, which was slightly unintuitive to me. If map entries were shown but ghosted, they were still included in the transformation.)
Being able to run a transformation operation on the published entries of a map is a huge plus. Thank you, SyncroSoft!
I owe you a huge thank you for Oxygen being cleverer than I expected.
We just had our first major documentation release using Oxygen/DITA/Git. I needed to provide a way for our writers to remove the @rev attribute from their DITA content. But there was a catch - I needed to preserve @rev in any content hidden by @props, as some features were deferred at the last minute.
Easy enough, just have the refactoring XSLT skip any @rev elements with a @props in ancestor-or-self, right? Well yes, but this didn't cover the case where entire topics were hidden by applyiing @props to the topicref in the map -- there was no topic-level @props definition for the XSLT to "see".
SyncroSoft to the rescue! It turns out that when you choose "Current DITA map hierarchy" as the scope of an operation, it skips any map elements that are fully hidden by the current profiling conditions. This is enormously powerful, as it allows the full power of DITAVAL to control the XSLT scope. Or put another way - because the DITAVAL controls what content is publicly seen by customer eyeballs, we can use that exact same mechanism to know where @rev should be removed because the content is published.
Here is a graphic showing our @rev-removing transformation running with all map entries shown:
- image.png (67.08 KiB) Viewed 855 times
- image.png (61.36 KiB) Viewed 855 times
(I did find that "Show Excluded Content" had to be unchecked, which was slightly unintuitive to me. If map entries were shown but ghosted, they were still included in the transformation.)
Being able to run a transformation operation on the published entries of a map is a huge plus. Thank you, SyncroSoft!