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 Robert, all,

 

Many thanks to you and the TC for taking the time to discuss my question.

 

I shared some background information with Eliot off-list that I'd like to share here.

 

We have an elaborate internal infrastructure that our writers use to build collections of books, then publish them through ePublisher/Reverb. It consists of a MySQL database, web portals, and utilities written multiple languages. It checks out files from revision control per the MySQL database, publishes the collections, pushes output to a test server, sends notification emails, etc.

 

This infrastructure was built over years for our FrameMaker environment. The FrameMaker .book file is the building block we show in the book collection GUI, how we index the mySQL database, and so on.

 

As it turns out, ePublisher/Reverb accepts DITA as input, and we were able to adapt all this machinery for DITA .ditamap books too - the collection-building GUI, the MySQL indexing, review tracking, the whole shebang! Huzzah!! But now our writers want to use DITA's excellent profiling features to publish multiple flavors of a book from a single source map.

 

Long-term, we want to use DITA-OT project files as our DITA-standard deliverable description format that drives our production process.

 

Short-term, I am experimenting to see if I can get these "wrapper maps" working well enough to get by. This is what caused me to raise the question. I was hoping to find out if the concept philosophically fell into "use" (I could file bugs) or "abuse" (be happy with whatever I get).  ð

 

Thanks again!

 

  • Chris

 

 

From: Robert Anderson <robert.dan.anderson@oracle.com>
Sent: Tuesday, January 26, 2021 11:30 AM
To: Chris Papademetrious <chrispy@synopsys.com>; dita-comment@lists.oasis-open.org
Subject: [dita-comment] 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]