Page 1 of 1

Finding Writers Affected by a Shared File

Posted: Sat Mar 09, 2019 8:14 am
by jmorales
Hi, We're using Oxygen with SourceTree for our source control, but no CMS. I'm trying to figure out the easiest way to find all the other writers who are affected when you make changes to a shared topic or graphic. We keep a current list of the writers assigned to each document (bookmap), so if I can determine which bookmaps depend on the shared topic or graphic, that will enable me to find the affected writers. The logistical difficulty is that this seems to require several searches. For example, suppose I'm making updates to a graphic. With Find > Find/Replace in files, I can locate all the topics that use that graphic. Then, for each of those topics, I would have to do an additional search to find out which ditamaps use those topics. And if the ditamaps are actually submaps, then for each one I have to do another search to determine which bookmap uses those ditamaps. It seems like this amounts to more searches than writers will really be willing to do. Can anyone think of an easier way to locate all the bookmaps that use a given graphic or topic, either directly or indirectly? Without buying a CMS, that is, because we don't have that option. Thanks for any suggestions!

Re: Finding Writers Affected by a Shared File

Posted: Tue Mar 12, 2019 3:03 pm
by Radu
Hi,

Oxygen has a "Hierarchy/Dependencies" view but it does not work for DITA, we had some plans to do this but somehow we did not find the time for it. I'll add your use case to the opened issue and when we manage to make this improvement we'll update this forum thread.
But Oxygen does have support for plugins, we have quite a large plugin API:

https://www.oxygenxml.com/doc/versions/ ... ugins.html

which would allow someone to implement a plugin (based on Java or Javascript) which could for example add an action in the Oxygen project view in the contextual menu, show the end user a dialog to ask for the name of the searched resource, then iterate all content in files from the project, using some regular expressions to search for the direct and indirect references to it.

Regards,
Radu

Re: Finding Writers Affected by a Shared File

Posted: Tue Mar 12, 2019 7:24 pm
by jmorales
Hi Radu,
Thanks for the response. The "Hierarchy/Dependencies" view sounds very promising and I appreciate your arranging to update this thread when it is implemented for DITA. The plugin API also sounds interesting, and though we don't have any software developers at our disposal currently, perhaps we'll be able to make use of it at some point.

Re: Finding Writers Affected by a Shared File

Posted: Wed Mar 13, 2019 12:08 am
by jmorales
Hi Radu,
As a followup to my previous reply, I've done some experimenting with the "Hierarchy/Dependencies" view. It appears to do what we need for topic files. I was able to right-click a topic in the Project pane and choose Resource Dependencies. When the "Hierarchy/Dependencies" view view opened, it successfully showed all the ditamaps that include the topic, and for those that were submaps, it showed which other ditamaps use those submaps.

Unfortunately, it appears the dependencies feature doesn't support graphics. When I right-click a graphic in the Project pane, Resource Dependencies isn't one of the available choices. So I have to do a Find/Replace in Files to locate the topics that use that graphic, and then I would have to query Resource Dependencies for each one of those topics in order to locate the ditamaps.

Also, if I have a file with a collection of components that I am using via conrefs in other files, it appears that the Resource Dependencies is going to show me all the files that depend on that collection, either directly or indirectly. If I want to find just the topics that depend on a single component in that collection, it seems I have to use Find/Replace in Files and do a search on the id value for that single component. Then, for each topic that I find, I would need to query the Resource Dependencies for that topic.

I'm not sure what you meant by saying that the "Hierarchy/Dependencies" view does not work for DITA. Are there other limitations aside from the ones I've noted above for graphics and components?

If the Resource Dependencies feature could be extended to work for graphics and for individual components, that would be outstanding.

Thanks again for your help!

Re: Finding Writers Affected by a Shared File

Posted: Wed Mar 13, 2019 11:12 am
by Radu
Hi,

Indeed the "Hierarchy/Dependencies" works for DITA but only for direct references (not for keys and conkeyrefs) so that's why I was skeptical in recommending it.
Actually you can also show dependencies for an image, the view has a "Show dependencies for..." toolbar action and you can choose the image for which you want to see the dependencies (after you change the filter in the file chooser dialog).

Regards,
Radu

Re: Finding Writers Affected by a Shared File

Posted: Thu Mar 14, 2019 2:51 am
by jmorales
Hi Radu,
Thanks for explaining about the keys and conkeyrefs. Regarding the graphics, I tried using the "Show Dependencies for..." icon, changing the filter in the browse dialog, and selecting a png file. The result was the message
"Unknown resource type <filename>. Supported resources are xsl, xsd, and rng." This was on <oXygen/> XML Author 20.1, build 2018122403. Did I do something wrong? If there's a workaround, that would be awesome.

Thanks!

Re: Finding Writers Affected by a Shared File

Posted: Thu Mar 14, 2019 3:40 pm
by sorin_carbunaru
Hello,

I can confirm that seeing the dependencies for an image does not work in oXygen 20.1. This began to work starting with version 21, which is also the latest. I just tried it on my PC and it worked just fine with this version.

All the best wishes,
Sorin Carbunaru
oXygen XML

Re: Finding Writers Affected by a Shared File

Posted: Thu Mar 14, 2019 6:32 pm
by jmorales
Thanks, Sorin! I have now upgraded to version 21, and as you say, the image dependencies are now working. This is going to make our lives a lot easier.

Going forward, it will be better still when you enhance the dependencies view to handle keyrefs and conkeyrefs. Keep up the good work!