My response to the dita-users e-mail about <othermeta>/Need to tweak "Reconciling topic and map metadata elements" topic

[Kristen James Eberlein <kris@eberleinconsulting.com>]

Responding to the poster makes me think that we need to tweak the "Reconciling topic and map metadata elements" topic.

The table in that topic addresses the following questions for each element that can be contained in <topicmeta>:

1. How does it apply to the topic?
2. Does it cascade to child <topicref> elements?
3. What is the purpose when set on the <map> element?

What I think we need to refine is the third column. Here's a sample of what that column contains for specific elements:

• <audience>: Specify an audience for the entire map
• <data>: No stated purpose
• <othermeta>: Define metadata for the entire map
  
• <shortdesc>: Provide a description for the map

I think what's implicit in the above text is the following (which I don't think is obvious on first glance):

• <audience> elements apply to all topics referenced in the map
• <data> elements have no effect on the map or the topics referenced in the map (unless specialized and custom processing is implemented)
• <audience> elements apply to all topics referenced in the map
• <shortdesc> applies to the map but not the topics referenced in the map

I think we've got too much implied in the difference between "for the entire map" and for the map" ...

Kris

-------- Forwarded Message --------

Subject:	Re: [dita-users] Othermeta inheritance
Date:	Thu, 24 Feb 2022 08:50:14 -0500
From:	Kristen James Eberlein via groups.io <kris=eberleinconsulting.com@groups.io>
Reply-To:	main@dita-users.groups.io
To:	main@dita-users.groups.io

Hi, Gaspard.

I think we first addressed how metadata cascades in the DITA 1.2 specification. Then we made additional clarifications in DITA 1.3, where we added "Reconciling topic and map metadata elements". This topic contains a table that addresses the following questions:

1. How the metadata specified within a topicmeta element in a map interacts with the metadata that is specified in the referenced topic
2. Whether the element cascades to nested <topicref> elements
3. The purpose when the element is specified for the <map> element

For the <othermeta> element, here is the expected behavior as laid out in the DITA 1.3 (and forthcoming DITA 2.0) specifications:

1. If an <othermeta> element is specified both for a <topicref element AND in the referenced DITA topic, the effect should be the same if the topic contained both <othermeta> elements.
   
2. If an <othermeta> element is specified for a <topicref> element, it DOES NOT cascade to any nested <topicref> elements.
3. <othermeta> elements that are specified at the root of a DITA map, apply to all topics that are referenced in the map.

Plesae note that there is a distinction between what we state in the DITA specification and what is implemented for a specific processor. After talking with Robert Anderson, I learned that DITA-OT used to cascade <othermeta> to nested <topicref> elements, but does not do so currently. I suspect that when the DITA-OT team made this change, they also (incorrectly) turned off the process by which <othermeta> elements specified at the map-level would apply to the topics that are referenced in the map. If that is the behavior that your clients needs, I suspect opening a bug report for the DITA-OT, if that is the processor used.

Other possibilities are specializing from @props (which cascades) or specializing <data> and implementing custom processing that cascades. (The <data> element does not cascade by default; it only cascade when it is specialized and custom processing is implemented.)

You can stop reading here -- but if you want examples of DITA markup and the expected processing, it is below.

------------

Examples:

The DITA map contains the following markup:

<map>
ÂÂÂ <title>Cascading metadata</title>
ÂÂÂ <topicmeta>
ÂÂÂÂÂÂ <othermeta name="mapMetadata" content="foobar"/>
ÂÂÂÂÂÂ <!-- This metadata applies to the map as a whole. It should be applied to all topics referenced in the map -->
ÂÂÂ </topicmeta>
ÂÂÂ <topicref href="">
ÂÂÂÂÂ <topicmeta>
ÂÂÂÂÂÂÂ <othermeta name="a" content="foo"/>
ÂÂ ÂÂ </topicmeta>
ÂÂÂÂÂ <!-- Other nested topicref elements, to which the othermeta element highlighted in red DOES NOT cascade -->
ÂÂÂ </topicref>
ÂÂÂ <!-- ... -->
</map>

The map-cascading.dita topic contains the following markup:

<concept id="map-processing">
ÂÂÂ <title>Metadata cascading</title>
ÂÂÂ <shortdesc>Metadata cascading is the process by which metadata elements and attributes specified
ÂÂÂÂÂÂÂ for a map or for a topic reference cascade to nested references. This allows metadata
ÂÂÂÂÂÂÂ properties to be set once and apply to an entire map or branch of a map.</shortdesc>
 <prolog>
ÂÂÂ <metadata>
ÂÂÂÂÂ <othermeta name="b" content="foobar"/>
ÂÂÂ </metadata>
 </prolog>
</concept>

Expected processing

1. The effect of specifying <othermeta name="a" content="foo"/> on the topic reference to map-cascading.dita" is the same as if the map-cascading.dita topic cotnained both <othermeta name="a" content="foo"/> and <othermeta name="b" content="foobar"/>
2. The <othermeta name="a" content="foo"/> element DOES NOT cascade to nested topicref elements.
   
3. The <othermeta name="mapMetadata" content="foobar"/> applies to all topics that are referenced in the map.
   

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 2/23/2022 12:45 PM, Gaspard BÃbiÃ-ValÃrian via groups.io wrote:

Hello DITA experts!

I have a client who extensively uses <othermeta> at the map level and expects to see it cascaded for topics, or even submaps. It seems that it was possible with DITA 1.1. However, according to this page, it isn't anymore with the 1.3:
https://www.oxygenxml.com/dita/1.3/spec ... adata.html

Would there be any weak to make it work nonetheless?

Additionaly, I saw that the lockmeta attribute won't be available in DITA 2.0. I wonder if a replacement solution will exist?
Thanks for any feedback or advice!

_._,_._,_

---

Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#46721) | Reply To Group | Reply To Sender | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [kris@eberleinconsulting.com]

_._,_._,_

.