DITA-OT normalization plugin behavior


Alan Houser
 

Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan

--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532


r.roggen
 

I can’t say whether the behavior is by design or not, but I’ve experienced it. In my case, to make a submap‘s metadata available for further processing, I wrapped its topics in a topicgroup and put the metadata in the topicgroup instead. That metadata didn’t get dropped.

-Reece

On May 20, 2021, at 11:27 AM, Alan Houser <arh@groupwellesley.com> wrote:

Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan

--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532






Alan Houser
 

Reece,

Thank you for confirming this behavior and suggesting a work-around. Much appreciated!

-Alan

On 5/20/21 4:39 PM, r.roggen wrote:
I can’t say whether the behavior is by design or not, but I’ve experienced it. In my case, to make a submap‘s metadata available for further processing, I wrapped its topics in a topicgroup and put the metadata in the topicgroup instead. That metadata didn’t get dropped.

-Reece

On May 20, 2021, at 11:27 AM, Alan Houser <arh@groupwellesley.com> wrote:

Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan
--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532


Alan Houser
 

A follow-up to this question, about which I acknowledge that I've done zero research ...

What's the level of difficulty of writing a plugin that does "just filtering", or "just conref resolution"; producing clean DITA source files that mimic the originals (modulo filtering and/or conref resolution)? Use case would be to hand off DITA source to a partner or to another processing chain.

-Alan

On 5/20/21 12:27 PM, Alan Houser wrote:
Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan
--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532


Nicholas Mucks
 

Hi Alan,
Easy. You can extend the dita normalization plugin but skip certain modules in processing by initializing build parameters based on the steps you don’t want to perform.

Take care,
- Nick

Sent from mobile

On May 22, 2021, at 8:44 AM, Alan Houser <arh@groupwellesley.com> wrote:

A follow-up to this question, about which I acknowledge that I've done zero research ...

What's the level of difficulty of writing a plugin that does "just filtering", or "just conref resolution"; producing clean DITA source files that mimic the originals (modulo filtering and/or conref resolution)? Use case would be to hand off DITA source to a partner or to another processing chain.

-Alan

On 5/20/21 12:27 PM, Alan Houser wrote:
Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan
--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532






Alan Houser
 

Hi Nick,

Thank you! I actually know what these things mean.  :-) Appreciated!

-Alan

On 5/22/21 1:51 PM, Nicholas Mucks via groups.io wrote:
Hi Alan,
Easy. You can extend the dita normalization plugin but skip certain modules in processing by initializing build parameters based on the steps you don’t want to perform.

Take care,
- Nick

Sent from mobile

On May 22, 2021, at 8:44 AM, Alan Houser <arh@groupwellesley.com> wrote:

A follow-up to this question, about which I acknowledge that I've done zero research ...

What's the level of difficulty of writing a plugin that does "just filtering", or "just conref resolution"; producing clean DITA source files that mimic the originals (modulo filtering and/or conref resolution)? Use case would be to hand off DITA source to a partner or to another processing chain.

-Alan

On 5/20/21 12:27 PM, Alan Houser wrote:
Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan
--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532


Radu Coravu
 

Hi Alan,

Maybe you can take a look also at this older Oxygen forum thread:

https://www.oxygenxml.com/forum/post61981.html

Regards,

Radu

Radu Coravu
Oxygen XML Editor

On 5/20/21 19:27, Alan Houser wrote:
Colleagues,

I'm trying to figure out whether behavior I'm seeing from the DITA-OT normalization plugin is by design.

I have a parent map, with maprefs to other maps. The referenced maps include map-level metadata in <topicmeta>.

After DITA-OT normalization, the maprefs are resolved, and the parent map references all resolved topics directly (as expected). But since the parent map no longer references the child maps, the map-level metadata on the child maps is essentially unavailable for further processing. (The child maps are also normalized and copied to the output folder, but there's no longer a relationship between the original "parent" and child maps).

Of course, I need the map-level metadata on the child maps. And I don't see a normalization option for "don't resolve maprefs".

If I'm missing an option, approach, or explanation, I would be grateful to hear it.

-Alan