OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: instantiating a shared bookmap from multiple profiled wrapper maps


Hi Chris,

We discussed this at the TC meeting today, and the short answer is that no, DITA does not have explicit support for this sort of wrapper map.

DITA 2.0 is introducing the ability to specify a <ditavalref> element inside of a bookmap, which applies to that entire map. That is not possible today. However, that is not quite what you've shown below, which is a single unmodified book map, processed once with a single ditaval, and then processed separately with another ditaval. All DITA applications that I've worked with support this by specifying the bookmap and the condition set as separate parameters when processing the map.

The closest I can think of is something like the DITA-OT project file, which is not a map itself, but allows you to specify a map + ditaval combination.

Thanks,
Robert

From: Chris Papademetrious <Christopher.Papademetrious@synopsys.com>
Sent: Thursday, January 14, 2021 1:07 PM
To: dita-comment@lists.oasis-open.org <dita-comment@lists.oasis-open.org>
Subject: [dita-comment] instantiating a shared bookmap from multiple profiled wrapper maps
 

Does DITA support “wrapper maps” that can instantiate a bookmap with DITAVAL profiling applied?

 

For example, I tried something like the following:

 

productA.ditamap:

<map>

  <ditavalref href="" style="color:black; background:#FCD116">A.ditaval"/>

  <mapref href="" style="color:black; background:#9ED267">shared.ditamap"/>

</map>

 

productB.ditamap:

<map>

  <ditavalref href="" style="color:black; background:#FCD116">B.ditaval"/>

  <mapref href="" style="color:black; background:#9ED267">shared.ditamap"/>

</map>

 

where shared.ditamap is a bookmap with full frontmatter/chapter/appendix structure, etc.

 

My hope was for the top-level wrapper map to apply its DITAVAL, then “dissolve away,” leaving a regular bookmap structure in place for processing. It mostly worked (yay!!), but there were a couple rough edges with missing bookmap metadata and an extra level of output directory structure. Maybe I’m missing some kind of attribute on the mapref to do the dissolving away…

 

I can supply the above testcase if anyone is interested in having a look. This is something that we badly need a solution for.

 

I am also exploring the use of DITA-OT project files (setting outputFile.base to each deliverable name as needed), but I’m starting with the mapref-oriented machinery first. Both could be useful in different situations. I need to assess writer ability to create/self-service conditional books (will a nontechnical writer glaze over when looking at a DITA-OT project file?), Oxygen support and how it presents controls to the writer, how they work with XSLT refactoring scripts and our in-house perl processing utilities, and so on.

 

Thanks!

 

-----
Chris Papademetrious

Tech Writer, Synopsys Implementation Group

(610) 628-9718 home office

(570) 460-6078 cell

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]