Associate ditaval file with a project instead of with a ditamap
Summary
Allow specification of a ditaval file in the Target Settings.
Detailed Description
The requirement that ditaval files have the same name as the ditamap is too restrictive. The whole purpose of ditaval files is to be able to filter content based on the setting of the attributes in the ditaval file. If I can only use one file then if I want different settings for the attributes I have to change the content of the ditaval file. What I would like to have is multiple ditaval files with the desired settings and choose the file I want to use for an ePublisher project in the same way that I can set conditional variables settings in a project.
Use Cases
Publish different versions of a map based on different attribute values in the ditaval files.
BenAllums | This is already possible by creating target specific "default.ditaval" files. |
2011-11-08 08:04:53 | ||
StephanieBodoff | I would like to explicitly specify the ditaval file for a map that does not have the same name as the ditamap, overriding the default which requires the ditaval file to have the same name as the map. |
2011-11-10 16:17:50 | ||
CatherineVolodko | +1 It seems that ePublisher does not support one of the main DITA reuse concepts - using one map with different ditaval files. I think that this is a ePublisher concept issue. Please address it the sooner the better. It is very inconvenient to generate one map with different ditavals that are stored in the source control system. |
2012-05-03 08:51:16 | ||
LiefErickson | +1 I have nothing to add to what Stephanie and Catherine wrote, except "me too!" |
2012-11-15 23:26:12 | ||
BenAllums | I would like to clarify a couple of points. First, ePublisher does allow you to apply a single ditaval file to an entire project. You can do this for the entire project, a particular format, or for a particular target. Further, you can vary ditamap's on a per input file basis if you need that level of flexibility. Project Level: <project folder>\Formats\Adapters\xml\scripts\dita\default.ditaval Format Level: <project folder>\Formats\<format name>\Adapters\xml\scripts\dita\default.ditaval Target Level: <project folder>\Targets\<target name>\Adapters\xml\scripts\dita\default.ditaval |
2012-11-21 10:55:32 | ||
LiefErickson | While I appreciate being able to put a ditaval for a project/format/target, those still don't provide enough granularity for me. I have several maps in my project and each one requires a different ditaval. For instance, I have a PDF XSL-FO project with two targets. Within each target I have numerous ditamaps (~20) that each require a different ditaval. I see two possible workarounds neither of which are viable solutions for me: 1) Create a separate project for each ditamap and process each one manually. 2) Create a separate project for each ditamap and use AutoMap to process them. We don't have a license for AutoMap and it's not in our budget at this time. |
2012-12-14 09:24:58 | ||
NadineMurray | Lief, does it work if you create a ditaval for each ditamap, name them the same and store them in the same folder? For example: m_product_a.ditamap m_product_a.ditaval m_product_b.ditamap m_product_b.ditaval |
2012-12-15 17:58:27 | ||
LiefErickson | Nadine, that's what I already do. The problem is that I need m_product_a.ditamap to be processed by two (or more) different ditavals and that's not currently possible. I have to process a project, change the values in the ditaval and save it, then process the second project. The problem as I understand is that we have these options: 1. The ditaval must be in the same directory *and* have the same name as the ditamap, which is currently how my environment is configured. OR 2. The ditaval may be in one of the three locations Ben metioned on 2012-11-21 10:55:32, but that file must be called default.ditaval and not m_product_a.ditaval. Setting aside the restriction of requiring that the ditaval name be the same as the ditamap, if I could put m_product_a.ditaval in one of the three directories that Ben mentioned, I could achieve my goal. I use the same ditamap for two different outputs (CHM and PDF). These are produced using different projects, but if they were simply different targets within the same project, I could still put m_product_a.ditaval in two different directories with different values in the ditaval and achieve my goal (albeit with the name restriction). In summary, if instead of looking for default.ditaval in the three locations Ben mentioned and instead (in addition?) it looked for <mapname>.ditaval, then I'd have the flexibility desired. |
2012-12-15 18:53:53 | ||
NadineMurray | @Lief: OIC. It hasn't been my practice to repurpose master maps (submaps yes, master maps no). I create separate master maps for different types of output. By reusing submaps, that is actually less work than it sounds. |
2012-12-16 20:52:09 | ||
LiefErickson | I have been thinking about this some more. I would like to see ditavals associated with a document or a group (I suppose in addition to what already exists from project/format/target). These three that are currently offered (as of 2013.2) don't provide enough granularity without needing to add several "master" map files as Nadine suggested, which by the way is how I currently solve the issue. I currently need 165 master maps and another 165 ditavals to create the output I require. If I were able to associate a ditaval with a group or document, I think my issue would be solved. Although the number of ditavals would not likely change, I could have significantly fewer maps (~65). I could process the same map in different targets using different ditavals (ones that aren't named the same as the map or default.ditaval) and that lived somewhere other than in Formats or Target. Here's how I see it implemented. In Designer & Express I right-click on a document and there would be a new menu option "Associate ditaval...". This opens a Windows dialog that allows me to go through my system and pick the ditaval I wish. The result is stored as a relative file path. That's my dream right now anyway. |
2014-04-10 10:23:12 |