I'd like to use the demo version to test the dita2dita capabilities of DITA2Go. However, it seems the output-specific configuration file local_d2dita_config.ini is not included in the March 8 demo distribution. Is this an intentional omission?
Hi! You are the first person to want to use this conversion! We've found that for new outputs, it's best to work with someone who actually needs the process, rather than make something up based on our own idea of what someone might need. So if you could tell us about your use case, we'll be happy to work with you to set up the appropriate config files. You can contact us direct, or continue here, whichever you prefer.
Cool! My use case involves the Learning and Training specialization.
I started with unstructured FM9 files and have used MIF2Go to create Learning and Training-specialized DITA for use with FM9. Thanks for your support with that.
That process gave me a book-level map and chapter-level maps. The book-level map references the chapter-level maps via topicrefs. Within each chapter-level map
The first topicref is @type="learningOverview".
The next topicref is @type="learningAssessment".
Then there are multiple topicrefs of @type="learningContent", many of which have child task and concept topicrefs.
The last topicref is @type="learningAssessment".
Objectives
In each chapter-level map:
Change the first topicref to a learningObject and wrap the remaining topicrefs within it.
Change the second topicref to a learningPreAssessmentRef.
Change the last topicref to a learningPostAssessmentRef.
Change each topicref with @type="learningContent" to a learningContentRef unless (here is the tricky part) it has child task and concept topics. In that case, move the parent topicref and its child topicrefs into a new child map and replace them in the chapter-level map with a learningContentRef to the child map.
By the way, I saw your dita-users post in which you mentioned you are offering DITA2Go at half-price to MIF2Go users like myself. Nice! :-)
Very interesting! I don't know that DITA2Go is quite the tool for this task, but it would be good if such a tool existed for DITA.
Of course, you could do it with XSLT... if your name is Mike Kay. ;-) I confess, with 35 years programming experience, including using C++ from when Bjarne invented it, I still find most XSLT an opaque container. But others feel differently, I'm sure.
DITA2Go starts by reading all the maps, then all the topics they reference, and builds a single file containing the whole thing, much like the DITA-OT. While building that file, it assigns "formats" to every element, using rules that look at your settings. Then a second module processes that file to generate the desired output, using the formats to determine what elements and attributes to use in the output file or files.
Since you used Mif2Go to generate your DITA in the first place, you already know how to do the mapping for the second part. It's the same as the mapping you did from Frame formats. However, with DITA input, it's as though you had a single-chapter book, so you just get one ditamap or bookmap out for the whole thing.
For your case, you'd need to run each chapter map as a separate project to retain those maps as independent building blocks. And the @type attributes in the topicrefs would automatically be the same as the root elements of the topics, just as they are when you generate DITA from Frame. Your topics would also be re-created, but of course you don't have to use those; you can continue with your current ones.
So, given this model, DITA2Go could easily handle your changed types, provided they matched the roots of their topics, and could also provide the nesting. However, that last requirement is a showstopper, AFAICS:
Change each topicref with @type="learningContent" to a learningContentRef unless (here is the tricky part) it has child task and concept topics. In that case, move the parent topicref and its child topicrefs into a new child map and replace them in the chapter-level map with a learningContentRef to the child map.
Are the child topics represented by topicrefs, or are they just nested in the referenced topic itself? In the first case, with all the info present in the map, the task is really one of editing the maps, with a macro facility as in emacs real helpful. If it's also necessary to go into the topics and dig out the nested children, it's harder.
I'll think about this one for a bit, and let you know what I come up with. Thanks for an interesting challenge!
Thanks for the information -- and you're welcome for the challenge.
You asked:
> Are the child topics represented by topicrefs, or are they just nested in the referenced topic itself?
The child topics are represented by topicrefs -- and for that I have you (if "you" are Jeremy) to thank ...
In December in a framemaker-dita thread you cleared up confusion on my part regarding the Learning specialization. You described how the specialization documentation is misleading in the way it shows the nesting of concepts, tasks, and references within the learningContent topic type. I followed your advice and configured MIF2Go to write the nested topics to separate files and represent them in the chapter maps as topicrefs.
I'll wait to hear back from you. Let me know if you need more information.
I decided I didn't need to extract submaps from the chapter maps -- that was the difficult requirement.
I'm working with FrameMaker and I have automated the restructuring and retagging of topic references using the FrameMaker add-on FrameSLT by West Street Consulting.
DITA to DITA
Hi! You are the first person to want to use this conversion! We've found that for new outputs, it's best to work with someone who actually needs the process, rather than make something up based on our own idea of what someone might need. So if you could tell us about your use case, we'll be happy to work with you to set up the appropriate config files. You can contact us direct, or continue here, whichever you prefer.
Ditamap to ditamap -- spawn child ditamaps
Cool! My use case involves the Learning and Training specialization.
I started with unstructured FM9 files and have used MIF2Go to create Learning and Training-specialized DITA for use with FM9. Thanks for your support with that.
That process gave me a book-level map and chapter-level maps. The book-level map references the chapter-level maps via topicrefs. Within each chapter-level map
Objectives
In each chapter-level map:
By the way, I saw your dita-users post in which you mentioned you are offering DITA2Go at half-price to MIF2Go users like myself. Nice! :-)
Ditamap to ditamap
Very interesting! I don't know that DITA2Go is quite the tool for this task, but it would be good if such a tool existed for DITA.
Of course, you could do it with XSLT... if your name is Mike Kay. ;-) I confess, with 35 years programming experience, including using C++ from when Bjarne invented it, I still find most XSLT an opaque container. But others feel differently, I'm sure.
DITA2Go starts by reading all the maps, then all the topics they reference, and builds a single file containing the whole thing, much like the DITA-OT. While building that file, it assigns "formats" to every element, using rules that look at your settings. Then a second module processes that file to generate the desired output, using the formats to determine what elements and attributes to use in the output file or files.
Since you used Mif2Go to generate your DITA in the first place, you already know how to do the mapping for the second part. It's the same as the mapping you did from Frame formats. However, with DITA input, it's as though you had a single-chapter book, so you just get one ditamap or bookmap out for the whole thing.
For your case, you'd need to run each chapter map as a separate project to retain those maps as independent building blocks. And the @type attributes in the topicrefs would automatically be the same as the root elements of the topics, just as they are when you generate DITA from Frame. Your topics would also be re-created, but of course you don't have to use those; you can continue with your current ones.
So, given this model, DITA2Go could easily handle your changed types, provided they matched the roots of their topics, and could also provide the nesting. However, that last requirement is a showstopper, AFAICS:
Are the child topics represented by topicrefs, or are they just nested in the referenced topic itself? In the first case, with all the info present in the map, the task is really one of editing the maps, with a macro facility as in emacs real helpful. If it's also necessary to go into the topics and dig out the nested children, it's harder.
I'll think about this one for a bit, and let you know what I come up with. Thanks for an interesting challenge!
Ditamap to ditamap
Thanks for the information -- and you're welcome for the challenge.
You asked:
> Are the child topics represented by topicrefs, or are they just nested in the referenced topic itself?
The child topics are represented by topicrefs -- and for that I have you (if "you" are Jeremy) to thank ...
In December in a framemaker-dita thread you cleared up confusion on my part regarding the Learning specialization. You described how the specialization documentation is misleading in the way it shows the nesting of concepts, tasks, and references within the learningContent topic type. I followed your advice and configured MIF2Go to write the nested topics to separate files and represent them in the chapter maps as topicrefs.
I'll wait to hear back from you. Let me know if you need more information.
FrameMaker-based solution
Just following up ...
I decided I didn't need to extract submaps from the chapter maps -- that was the difficult requirement.
I'm working with FrameMaker and I have automated the restructuring and retagging of topic references using the FrameMaker add-on FrameSLT by West Street Consulting.