Refactoring a DITA Map considers the profiling conditions

[chrispitude]

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:

image.png

Here is a graphic showing our @rev-removing transformation with the @props map entries hidden:

image.png

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!

[Radu]

Hi Chris,

Thanks for the kind words, I hope your post will be useful for others as well.
Indeed the "Current DITA map hierarchy" takes into account all visible references in the DITA Maps Manager view, it does take into account also the faded out references, I'm not sure if this is a bad thing or not.
When invoked by right clicking in the DITA Maps manager the "Find/Replace in Files" also has a "Current DITA Map Hierarchy" scope which may again prove useful for similar use cases, to perform find/replace in files only on non-filtered-out topics. And the same scope is available for "Check spelling in files" invoked in the DITA Maps Manager.

Regards,
Radu