Validation of Related Links with Profiling Attributes to Topics with Other Profiling Attributes

[ckabstein]

Hi,
At the moment, the following option in the Validate and Check for Completeness dialog really helps identifying the conflicts between parent and child elements with profiling attributes: Identify possible conflicts in profile attribute values in DITA.
Would it be possible to add a similar but more complicated check that allows you to find conflicts between related-links profiling attributes and the profiling attributes of the topics to which the related links refer?
Example:
I have a topic X with product="productA productB" in the topic element.
In another topic Y, I have a related-link to topic X that should have the same product attributes so that when filtering for productA or productB takes place, the related link is put out. However, if you make changes in topic X and add productC and then filter for productC, the related link in topic Y will no longer be available, because there is no validation that helps identifying this issue.
I know that as a workaround, the DITA References View already helps identifying those issues. Unfortunately, it's a time-consuming task to always validate this "manually".
Maybe you've got another idea how to solve this issue. As far as I know, this cannot be solved with Schematron, can it?
Thanks,
Christina

[Radu]

Hi Christina,
The "Validate and check for completeness" settings dialog also has an "Use DITAVAL Filters" section. If you validate with all possible filters that you use also for publish, shouldn't the validation complain with a warning like "Topic referenced in other topics but not in DITA map" for that reference to topic X?
Regards,
Radu

[ckabstein]

Hi Radu,
Thanks for your quick reply.
I've had a try together with my colleague who has the issue and we found that I need to rephrase my example:
As seen from my technical perspective:
We have topic X with profiling attributes productA and productB. Topic X contains a related link to topic Y with profiling attribute productA. The related link in topic X was marked with productA.
Now, topic Y is extended to productB, which means that the related link in topic X should also be extended to productB - or productA should be removed to enable proper linking.
Setting all DITAVAL filters doesn't find the issue in this case.
We find all other cases, such as the warning that you mentioned and "Condition x set on y can never be effective...".
Is there an easier way to find the related link in topic X that is missing productB now?

My colleague describes from a different perspective, but maybe this helps you to understand the situation:
Version 1 of our product shipped in two versions: Big and Small. Small version excluded some features that were only available in Big.
However, in Version 2, the developers decided to expand Small – just a bit. One feature that before was only in Big, is now also available in Small. Feature X's documentation comprises 10 topics, and references to it are spread out all over the manual. Because there are lots of references in topics that were already in both Big and Small manuals, those existing references had "big-only" product markup.
We added Small product attributes to the relevant feature topics, so now those 10 topics are included in the Small 2 manual. Great.
However, we would like to be sure that all references to "feature X" everywhere else are also included in the Small 2 manual, so Small 2 users can benefit from all our careful cross-referencing. The fact that links to "feature X" still have "big-only" product markup doesn't cause any technical problems, so the validation doesn't pick them up.
It would be a nice-to-have for validation to identify references that are excluded by the current profiling filter, but which lead to topics that are included in the current profiling filter. Aka "Missed opportunity here!"

Thanks,
Christina

[chrispitude]

Hi Christina,

If you use DITA-OT project files, you might be interested in this similar request, to consider all DITA-OT project file contexts that apply to the root map:

Consider DITA-OT project file contexts in "Validate and Check for Completeness"

The goal is simlar - for every possible deliverable, detect issues such as unresolved keys or links. The value that DITA-OT project files provides is that they enumerate what profiling conditions are used with each map, so you do not have to manually specify it each time you validate.

[Radu]

Hi Christina,
How about if you create a small sample DITA project and send us an email (support@oxygenxml.com) with steps to reproduce the problem and the expected result?
Regards,
Radu