Topics

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,

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, @l3arn4life 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?
Your help is much appreciated!

@l3arn4life
 

We’re using DITA-OT 2.5.4. I will try to provide a sample project later today.

Thanks!

Radu Coravu
 

Hi,

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, @l3arn4life wrote:
We’re using DITA-OT 2.5.4. I will try to provide a sample project later today.
Thanks!

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,

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, @l3arn4life wrote:
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

@l3arn4life
 

Hi Radu,

thank you for your help. Somehow though, when running a transformation on your modified sample, the output came up empty.
Changing the root map to any of the submaps containing the reference to "topicKeys.ditamap" didn’t help.
Could it be that once the publishing engine sees a .ditaval it will attempt to do its branch filtering but will pretty much abort the entire process in the absence of a direct topicref?
In any case, the processing order of the publishing engine seems to forbid the combination of branch-filtering and keyrefs, which I find a pity.
Or am I missing something?

Sincerely,
Ed

Radu Coravu
 

Hi Ed,

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, @l3arn4life wrote:
Hi Radu,
thank you for your help. Somehow though, when running a transformation on your modified sample, the output came up empty.
Changing the root map to any of the submaps containing the reference to "topicKeys.ditamap" didn’t help.
Could it be that once the publishing engine sees a /.ditaval/ it will attempt to do its branch filtering but will pretty much abort the entire process in the absence of a direct topicref?
In any case, the processing order of the publishing engine seems to forbid the combination of branch-filtering and keyrefs, which I find a pity.
Or am I missing something?
Sincerely,
Ed

@l3arn4life
 

Hi Radu,

that did the trick, thanks.

Regards,
Ed

@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,
Ed

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:

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,
Ed


-- 

@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:
https://dita-users.groups.io/g/main/message/45330

Regards,
Ed

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:

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:
https://dita-users.groups.io/g/main/message/45330

Regards,
Ed



  

@l3arn4life
 

Hi Radu,

thanks for taking the time to test this. I created a bug report:
https://github.com/dita-ot/dita-ot/issues/3551

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,
Ed

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">
        <ditavalmeta>
            <dvrResourceSuffix>C</dvrResourceSuffix>
        </ditavalmeta>
    </ditavalref>

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.


Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 7/27/20 2:50 PM, schmidt.eduard@... wrote:

Hi Radu,

thanks for taking the time to test this. I created a bug report:
https://github.com/dita-ot/dita-ot/issues/3551

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,
Ed