Filter on Topics Reused with Keys #keys #branch-filtering
@l3arn4life
Hi, I have a number of topics describing almost identical content in the context of three different scenarios. Some of the content only exists in, say, scenario A, but not in B and C. So I thought it’d make most sense to create one topic that holds the content for all scenarios and use profiling combined with branch filtering to show only relevant content in each respective instance of that topic. Each scenario has its own submap. When I reference the said topic using the common topicref, my output looks just as expected. As soon as I reference that topic with a keyref, my filtering goes out the window and all content is displayed in all instances. I guess the question is: is the combination of branch filtering and keyref on a topic not feasable atm or is there something I’m doing wrong? Your help is much appreciated!
|
|
Radu Coravu
Hi,
toggle quoted messageShow quoted text
What DITA OT version are you using? It would be helpful if you could put together a minimal sample project exemplifying the problem. But in general when using keys and branch filtering I thing you should also try to define a keyscope on the topicref which has the ditavalref element. Regards, Radu Radu Coravu <oXygen/> XML Editor http://www.oxygenxml.com
On 3/16/2020 1:24 PM, schmidt.eduard@gmail.com wrote:
Hi, I have a number of topics describing almost identical content in the context of three different scenarios. Some of the content only exists in, say, scenario A, but not in B and C. So I thought it’d make most sense to create one topic that holds the content for all scenarios and use profiling combined with branch filtering to show only relevant content in each respective instance of that topic. Each scenario has its own submap. When I reference the said topic using the common topicref, my output looks just as expected. As soon as I reference that topic with a keyref, my filtering goes out the window and all content is displayed in all instances. I guess the question is: is the combination of branch filtering and keyref on a topic not feasable atm or is there something I’m doing wrong?
|
|
@l3arn4life
We’re using DITA-OT 2.5.4. I will try to provide a sample project later today. Thanks!
|
|
Radu Coravu
Hi,
toggle quoted messageShow quoted text
Also please try the same thing with the latest DITA OT 3.4.1. Maybe the problem was fixed in a more recent DITA OT version. Regards, Radu Radu Coravu <oXygen/> XML Editor http://www.oxygenxml.com
On 3/17/2020 10:09 AM, schmidt.eduard@gmail.com wrote:
We’re using DITA-OT 2.5.4. I will try to provide a sample project later today.
|
|
Pieterjan Vandenweghe
Hi Eduard,
I had a similar problem not so long ago. The combination of keys, scoped keys and branch filtering did the trick for me. Please find attached a sample how it works for me now. I am using DITA-OT 3.4.1. Kind regards, Pieterjan
|
|
@l3arn4life
Good morning, thank you Pieterjan for providing a sample, I will look at it. Sorry for the delayed response, an approaching deadline kept me from getting back earlier. Radu, I attached a sample project and included responsive webhelp output that demonstrates the problem. I yet have to test this with the current DITA-OT. Regards, Ed
|
|
Radu Coravu
Hi Ed,
toggle quoted messageShow quoted text
Thanks for the samples. The publishing engine first does the branch filtering and then the keyref processing so the only way to make this work was to refer to the "topicKeys.ditamap" in each ditavalref context. This is not necessarily a bug in the publishing engine, I don't think the specification says precisely how such cases, branch-filtering in combination with keyref should be handled. I'm attaching a modified project, you can compare it with your own using Oxygen's Compare Directories tool. Regards, Radu Radu Coravu <oXygen/> XML Editor http://www.oxygenxml.com
On 3/19/2020 10:38 AM, schmidt.eduard@gmail.com wrote:
Good morning,
|
|
@l3arn4life
Hi Radu, thank you for your help. Somehow though, when running a transformation on your modified sample, the output came up empty. Sincerely,
|
|
Radu Coravu
Hi Ed,
toggle quoted messageShow quoted text
In order to run the sample I gave you I used Oxygen 22.0 and DITA OT 3.4. I did not test with older DITA OT distributions. Regards, Radu Radu Coravu <oXygen/> XML Editor http://www.oxygenxml.com
On 3/19/2020 3:00 PM, schmidt.eduard@gmail.com wrote:
Hi Radu,
|
|
@l3arn4life
Hi Radu, that did the trick, thanks. Regards,
|
|
@l3arn4life
Hi Radu, I find no pleasure in reviving this discussion, but due to the its relevance in our current situation I feel compelled to: I revisited the sample project you modified and upon closer inspection made the discovery, that everything went fine for Product A and Product B, but filtering went haywire for Product C. I have no explanation for this, as I see no difference between productA.ditamap, productB.ditamap and productC.ditamap. They all have their ditavals and use keyrefs to point to the same topic. A and B come out fine, C is botched. Any ideas? Many thanks,
|
|
Radu Coravu
Hi Ed, Please attach a small sample project and I will try to take a look at it. Regards, Radu Radu Coravu Oxygen XML Editor On 7/23/20 4:08 PM,
schmidt.eduard@... wrote:
--
|
|
@l3arn4life
Good morning, I attached a sample project and included output generated via cmd using --format=html5 with dita-ot 3.5.2. I wanted a result completely detached from Oxygen to see whether the problem was with Oxygen or dita-ot, unfortunately, the latter seems to be the case.
The attached sample should be more or less identical to the one posted earlier in this thread: Regards,
|
|
Radu Coravu
Hi Ed, From what I investigated, this looks like a bug to me. Can you add a new issue on the DITA OT issues list? https://github.com/dita-ot/dita-ot/issues attach your samples there, maybe also give some details about the expected behavior. Regards, Radu Radu Coravu Oxygen XML Editor On 7/24/20 8:44 AM,
schmidt.eduard@... wrote:
|
|
@l3arn4life
Hi Radu, thanks for taking the time to test this. I created a bug report: Branch filtering and indirect referencing are, as far as I understand, core functionalities in dita 1.3. Bugs affecting this functionality will hopefully be quickly resolved. Regards,
|
|
Radu Coravu
Hi Ed, I think I found a workaround for the problem: https://github.com/dita-ot/dita-ot/issues/3551#issuecomment-666979121 Using dvrResourceSuffix inside all ditavalref elements like:
<ditavalref href="productC.ditaval"> gives you control over the suffix appended to all HTML file names
in the context but the filtering problem for the "C" context also
seems to disappear.
Radu Radu Coravu Oxygen XML Editor On 7/27/20 2:50 PM,
schmidt.eduard@... wrote:
|
|