Something like ditaval, but for topics or smaller?


despopoulos_chriss
 

Hi all...  We have a need to filter a superset list in different ways for different topics in the same book.  Is there some construct in DITA to do this?

EXAMPLE:

<ul id="superset>
<li audience="FOO">AAA</li>
<li>BBB</li>
<li audience="BAR">CCC</li>
</ul>

<topic id="FOO_Topic">
...
<!-- Should hide FOO and show BBB and CCC -->
<ul conref="supersetList"><li/></ul>
...
</topic>

<topic id="BAR_Topic">
...
<!-- Should hide BAR and show AAA and BBB -->
<ul conref="supersetList"><li/></ul>
...
</topic>

I know I could do it this way (below), but that's so much work!  At scale it can be hard to maintain.  Does DITA give us anything easier?


<ul id="superset>
<li id="A_Item">AAA</li>
<li id="B_Item">BBB</li>
<li id="C_Item">CCC</li>
</ul>


<topic id="FOO_Topic">
...
<!-- Hide FOO and show BBB and CCC -->
<ul>
<li conref="supersetList/B_Item"/>
<li conref="supersetList/C_Item"/>
</ul>
...
</topic>


Kristen James Eberlein
 

Branch filtering

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
OASIS Distinguished Contributor
Principal consultant, Eberlein Consulting LLC
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)


On 5/11/2021 4:22 PM, despopoulos_chriss via groups.io wrote:
Hi all...  We have a need to filter a superset list in different ways for different topics in the same book.  Is there some construct in DITA to do this?

EXAMPLE:

<ul id="superset>
<li audience="FOO">AAA</li>
<li>BBB</li>
<li audience="BAR">CCC</li>
</ul>

<topic id="FOO_Topic">
...
<!-- Should hide FOO and show BBB and CCC -->
<ul conref="supersetList"><li/></ul>
...
</topic>

<topic id="BAR_Topic">
...
<!-- Should hide BAR and show AAA and BBB -->
<ul conref="supersetList"><li/></ul>
...
</topic>

I know I could do it this way (below), but that's so much work!  At scale it can be hard to maintain.  Does DITA give us anything easier?


<ul id="superset>
<li id="A_Item">AAA</li>
<li id="B_Item">BBB</li>
<li id="C_Item">CCC</li>
</ul>


<topic id="FOO_Topic">
...
<!-- Hide FOO and show BBB and CCC -->
<ul>
<li conref="supersetList/B_Item"/>
<li conref="supersetList/C_Item"/>
</ul>
...
</topic>


Chris Papademetrious
 

Hi Kris, Chris, (!!)

Our team has been using DITA for almost two years. Our writers are just now getting comfortable working with maps via Oxygen's GUI. The creation and use of DITAVAL files is well beyond their comfort level. (We do use DITAVAL files for @product filtering, but I maintain those and the writers don't know the details.)

I have wished for a more ad-hoc form of filtering that (1) uses attributes instead of files to locally impose a condition, and (2) works for both map and topic elements. For example, something like this:

<profiling audience="foo">
  <ul conref="supersetList"><li/></ul>
</profiling>

where the attribute values of a <profiling> element *apply* conditions, rather than being affected by them. (I don't claim to have thought through all the details...)

About six months ago, I had a user who wanted to reuse the same table in two places in their book, but a subset of rows in each location (just like Chris's question). Asking the writer to use DITAVAL was not an option. There wasn't even an obvious profiling attribute to use. Maybe @audience="table1" and @audience="table2"?

So although DITA was mechanically capable of the request, the writer mechanics weren't feasible. They ended up duplicating and modifying the table. It made me sad.

 - Chris


despopoulos_chriss
 

First, thanks to Kris for cluing me in. 

If ignoruntz is bliss, I have blissfully been using as little as possible of DITA these past 7 or so years.  In fact, we use close to the equivalent of LwDITA.  Which makes me wonder, does LwDITA support branch filtering?  (I'm guessing not...  Just wondering, no implications.)

@Chris, I feel your pain.  I was kind of hoping for something similar to your idea of internal profiling.  Maybe something like
<div profileBase="audience" exclusions="foo bar baz">
  <ul conref="supersetList"><li/></ul>
</div>

For us, it would be a bit of a hassle to use branch filtering, because we implement our own DITA rendering.  But I could pretty easily build a data object that maps individual topics to their branched filters, and add that data to the params we pass as we transform each topic. 

One thing I'm wondering is where the ROI threshold is for this.  Assuming a superset that needs to be sliced and diced into subsets, is there some threshold where it would just be easier to conref the individual items rather than filter the superset list?  Also, how does this work if the filtering requirements change...  Does that make it even more complicated?  We support groups of "technologies" that each have different subsets of "features".  We want to track the superset list, and present it when we discuss the "category" of technology.  But each instance needs a correct list.  What happens when the support for one instance changes?  What happens when we add a new instance?  Is there a threshold where tracking this via metadata will become unsustainable?  That will be what determines how we do this...

Anyway, thanks for the info.


Chris Papademetrious
 

@despopoulos_chriss, you make a good point about ROI.

We like DITAVAL for book-wide profiling, as product conditions are group-wide and stable. But this would not be true for ad-hoc usage. If I make DITAVAL files for "tableA" and "tableB" for one specific book, then later rewrite the content to remove those tables, now I have a dangling DITAVAL file to be noticed and removed.

DITA is mechanically capable of many, many things. Many features are readily accessible to writers in a DITA editor (Oxygen). Perhaps the more mechanically involved features require a CMS to orchestrate the moving pieces. I think what we're discussing here is, could DITA somehow support ad-hoc conditionalization via the former instead of the latter?

 - Chris

P.S. We also use a small fraction of DITA. We specialized it to match the elements in our previous format (structured FrameMaker). We use variables and profiling. We are just starting to explore con[key]ref. We don't use subject schemes, branch filtering, or anything like that.


Nicholas Mucks
 

Hi!

At this granular of a level, isnt this more of a use case for keys and conkeyref  in the topics than conditions? You can define a warehouse topic or keymap at your rootmap and apply your conditions there, not in the topics.

Take care,
- Nick

Sent from mobile

On May 15, 2021, at 4:55 AM, Chris Papademetrious <chrispitude@...> wrote:

@despopoulos_chriss, you make a good point about ROI.

We like DITAVAL for book-wide profiling, as product conditions are group-wide and stable. But this would not be true for ad-hoc usage. If I make DITAVAL files for "tableA" and "tableB" for one specific book, then later rewrite the content to remove those tables, now I have a dangling DITAVAL file to be noticed and removed.

DITA is mechanically capable of many, many things. Many features are readily accessible to writers in a DITA editor (Oxygen). Perhaps the more mechanically involved features require a CMS to orchestrate the moving pieces. I think what we're discussing here is, could DITA somehow support ad-hoc conditionalization via the former instead of the latter?

 - Chris

P.S. We also use a small fraction of DITA. We specialized it to match the elements in our previous format (structured FrameMaker). We use variables and profiling. We are just starting to explore con[key]ref. We don't use subject schemes, branch filtering, or anything like that.


despopoulos_chriss
 

Hi Nick...

I'd say it depends.  Again, it's a question of ROI.  It might be more efficient to maintain separate referenced lists where all the items are pointers to the superset.  But that can also get to be a headache, where setting categories in the supersets, and then referencing the superset with a given categorical filter would be much easier.  In fact, category vs individual variation might be the criterion to focus on when deciding whether to use branch filtering vs reference.  Gotta think about that...

cud