Conditional processing
Thu, 12/24/2009 - 7:39am — jvazquez
I just finished reviewing the information on conditional processing and I'm a little concerned about the implementation. While you start with the .ditaval file, I think that it's erroneous to specify conditional processing within the DITA2Go configuration. This removes the condition specification from the context of the content and causes a situation where processing on another system could cause incorrect output because the .ditaval does not reflect the actual processing for the content. I suggest that you internalize this processing and do not surface reconfiguration through DITA2Go. It simplifies your processing and removes confusion from the user.
Alternative conditional processing
Actually, if you specify a .ditaval file, that is all we use; any settings in the DITA2Go configuration are ignored. So we already do what you suggest in that case.
The conditional settings in the configuration files are an alternative that provides enhanced conditional processing for those more concerned with getting their job done right than with possible portability to other processors later. Purists can feel free to ignore them, but those who need a bit more than .ditaval offers will probably be grateful.
We've followed this policy in many places. We always support the spec behavior, but we often offer alternatives that go farther where the spec falls short of real-world requirements in our estimation. You never have to add anything to your DITA files to use these features (except, in some cases, PIs), so they do not result in vendor lock-in. In truth, we think the only real justification for a commercial DITA processor, besides performance, is that it does go beyond what the spec defines and the DITA-OT offers, to give users what they really need.
PIs
I have noticed the information on PIs and I can see why some of it is necessary. However, I would like to discourage using PIs to replace specific DITA functionality because it adds complexity and may cause inconsistency in presentation outside of DITA2Go. One of the main reasons DITA exists is to provide a common interchange language for technical communications and PIs that override base DITA constructs can lead to not using those constructs and losing some of the information needed by all processors. I can understand PIs to manage page breaks and the like, but once you start replacing metadata you could remove some of the richness needed for CMS, faceted browsing, and the like. If you believe that there are some deficiencies in the specs, I recommend bringing those forward to the appropriate DITA Technical Committee.
Julio J. Vazquez
SDI Global Solutions
The reasons for PIs
We agree with you about not "using PIs to replace specific DITA functionality", which is why we absolutely never do that. If you read User's Guide par. 34.1.3, " Deciding when to use PI markers", the first sentence is:
PI markers are to be used for things that cannot be specified for DITA, but need to be specified for the output type you are producing. They complement the DITA code, and under no conditions alter its meaning.
In some cases, PIs are present because they provide similar functionality to FrameMaker markers in Mif2Go. We included this group because we have quite a few enterprise customers who are transitioning from FrameMaker to DITA, and we wanted to retain features with which they were familiar to aid that transition. It's rather like providing crutches, instead of insisting that somone walk unaided; the crutches may be needed initially, but you expect them to be discarded with increasing practice.
You also suggested, "If you believe that there are some deficiencies in the specs, I recommend bringing those forward to the appropriate DITA Technical Committee." We have always done so. A large percentage of the TC is in fact in this beta program. Regarding the PIs specifically, the DITA Adoption TC is following our progress here.