• Replies 6 replies
  • Subscribers 137 subscribers
  • Views 2512 views
  • Users 0 members are here
Options
Related

Expected behavior when no conditions are specified for a publication

Kendall Shaw

Hi,

There is a publication that includes a topic that has an element with conditional text. I'm told that the element with the conditional text used to be excluded when no conditions were specified on the publication.

For example, there is a topic with markup:

<p ishcondition="this=that">Conditional text</p>

The publication specifies no conditions. What they expect is that that paragraph will be excluded.

After a recent style changes, the element is no longer being excluded. I've experimented and sometimes this happens and other times it doesn't happen and I haven't found the pattern.

When it happens, DITA-OT filters out the element prior to styles being applied (during topic merge). When it doesn't happen, DITA-OT doesn't filter out the element, prior to styles being applied.

What is the expected behavior when no conditions are set on the publication?

Kendall
Rate translation
×
Suggest better translation
×

  • Hi Kendall,

    Not sure what version of the software you are using. In the Web Client, locate the publication, view the properties at the "version" level. At the bottom of the properties, there's a Publishing Context area. What you have selected there can affect the conditions behavior in the published output. 

    Pam Noreault | Knowledge Center Solutions Architect

  • in reply to Pam Noreault

    Hi,

    We're using Knowledge Center Build 12.0.3725.3. What is the expected behavior when no conditions are applied (nothing is selected)?

    I should also ask what is expected if you specify a condition that doesn't occur in markup?
  • in reply to Kendall Shaw

    Best practice is to add that condition to publication manager to provide context for the publication, and then you can either enable it or disable it (show\hide content with that setting). That determines the behavior. The default behavior can be mixed without giving the publication any context.

    Pam Noreault | Knowledge Center Solutions Architect

  • Hi Kendall,

    Just to make sure, @ishcondition is done by an SDL component called ConditionFilter, not by DITA-OT.

    When specifying value for your condition context through the various user interfaces, it eventually gets saved in on the publication version in field FISHPUBCONTEXT. That field can technically have three options:

    1. Field is empty, literally has no value. In this case the ConditionFilter component will consider all @ishcondition entries as valid, so their "Conditional text" will appear.
    2. Field holds <features/>, so a root tag without children. Then ConditionFilter cannot make any of your @ishcondition Boolean logic statements valid, so all those elements will be filtered out.
    3. Field holds <features><feature name="this" value="that"/></features>. Then Condition Filter will try all provided <feature> entries to try to make your @ishcondition valid. See API details on https://docs.sdl.com/LiveContent/content/en-US/SDL%20Tridion%20Docs-v1.1.2/GUID-DE80C8C1-E125-48AD-A54C-A374DA7819FE

    You are probably having situations 1 and 2 mixed. Meaning that once you selected a <feature> but then you removed the <feature> again you end up with <features> as declared in situation 2.

    The product version matters, as UX already spend quite some brain power to get to a more predictable situation without breaking backward compatibility.

    Hope this helps,
    Dave
  • in reply to Dave De Meyer

    I think it is situation 1. I've never seen a product definition XML file before. People select which "ishcondition" expressions should be used for filtering, by selecting condition name/value pairs in publication manager, on the publication objects.

    However, when no condition name/value pairs are specified ("no context" might be the term for that), sometimes elements with ishcondition specified are filtered out and sometimes they are not. Since that appears to happen outside of DITA-OT, I was wondering what the expected behavior was. The reply made me think it is essentially "unpredictable" unless you specify which condition name/value pairs are to be considered for filtering.
  • in reply to Kendall Shaw

    As you can imagine, a lot of people rely on this product feature, so breaking changes are not really an option.

    What I have seen some customers do is setup up a default <feature> entry on all of their PublicationOutput Editor Templates. So in essence, every time you create a new Publication, the field FISHPUBCONTEXT is already initialized with "<features><feature name="this" value="that"/></features>" so always scenario 2 or 3.