TopicMerge sets unexpected @xml:lang attribute to topic.

[ToshihikoMakita]

I'm facing a serious problem found in DITA-OT 1.7.3. The problem is that DITA-OT TopicMerge sets unexpected @xml:lang attribute to topic. Here is a example.

[bookmap: sample_ja.bookmap]

<bookmap xml:lang="ja" id="GUID-BC13DC41-C380-4E24-9047-B0E6018F4D86">
  <booktitle id="GUID-877192EE-6DCD-4695-AD85-E1F54ED545E5"> 
    <mainbooktitle>テスト</mainbooktitle> 
  </booktitle> 
  ...
  <chapter format="dita" href="sample.xml" scope="local" navtitle="サンプル"/>
</bookmap>

[sample.xml]

<concept id="concept_D941EF43C15A40D0BF155B7C5B8003F0">
  <title>コンセプトサンプル</title>
</concept>

[sample_ja_MERGED.xml]

<concept ditaarch:DITAArchVersion="1.2" domains="(topic concept)                            (topic hi-d)                             (topic ut-d)                             (topic indexing-d)                            (topic hazard-d)                            (topic abbrev-d)                            (topic pr-d)                             (topic sw-d)                            (topic ui-d)    " 
         class="- topic/topic concept/concept " xtrf="D:\DITA-OT1.7.3\samples\sample.xml" xtrc="concept:1;3:56"
         xml:lang="en" oid="concept_D941EF43C15A40D0BF155B7C5B8003F0" id="unique_1">
  <title class="- topic/title " xtrf="D:\DITA-OT1.7.3\samples\sample.xml" xtrc="title:1;4:8">コンセプトサンプル</title>
...
</concept>

As shown above TopicMerge sets topic/@xml:lang="en" as default value.

Until now we use DITA-OT 1.5.3 and our stylesheet honors bookmap/@xml:lang. The stylesheet inherit bookmap/@xml:lang to the topic and element level. So according to this situation, bookmap/@xml:lang="ja" should be honored.

Are there any TopicMerge option to avoid setting @xml:lang="en" as default value?

[jelovirt]

@robander, do you remember which issue covered this same case? The spec explicitly says xml:lang doesn't cascade from map to map, so I assume it doesn't cascade from map to topic. The spec also says

If the @xml:lang attribute on the document (outermost) element of a map or of a top-level topic has no value, the processor should assume a default value. The default value of the processor may be either fixed, configurable, or derived from the content itself, such as the @xml:lang attribute on the primary map file. As the default value of a processor may be fixed, it is strongly recommended that the @xml:lang attribute be set on each map and top-level topic.

@robander @drmacro, do you think the current behaviour is correct or not WRT the spec?

[jelovirt]

The behaviour changed in #415

[ToshihikoMakita]

Hi Jarno,

As you have quoted from specification, I think it is better to use bookmap/@xml:lang as defaut value. I'm making a DITA to PDF stylesheet for mutiple language in one set of DITA instance. So it is very important to adopt default value from the primary map (bookmap). Please tell me your opinion.

Regards,

[ToshihikoMakita]

Any progress on this issue?

This will not affect following user.

• CMS user (because CMS forces to specify topic/@xml:lnag explicitly.)
• English user
• PDF2 plug-in user (It only use map/@xml:lang only.)

But there are lot of DITA instances that does not explicitly specify topic/@xml:lnag. In this case user believes that map/@xml:lnag is used for topic/@xml:lang.

I'm developing multiple language stylesheet per user request. In this stylesheet the style is controlled by @xml:lang attribute of the element. So applying topic/@xml:lang="en" is very headache problem.

I'm waiting for your reply.

Regards,

[robander]

Just noticed the long-ago question on this. I think it would be appropriate, especially for PDF, if our processing default was "whatever language is specified for the map", and if nothing is specified on the map it can fall back to 'en' as today. I think this would mean updating the merged file so that it only adds a default to the map, and updating processing for any topic context so that it falls back to the value on the map.

[ToshihikoMakita]

Thank you for your comment. Anyway I am very appreciated if "TopicMerge" changes current behavior. This problem is not meaningful for commercial CMS users because CMS strictly controls @xml:lang attribute for every topic. But there are lots of user topics that have no explicit @xml:lang. In this case they want to treat map/@xml-lang as representative language.

[jelovirt]

Fixed in #2356

[ToshihikoMakita]

Thank you very much!