This is interesting stuff particularly in light of the discussions that the Tech Comm SC was having last year. Scott Hudson had created a few new prototype domain modulesÂduring this process. One problem that we had identified was that the programming domain was often inadequate for marking up documentation relating to modern applications. Of course, the problem here is where do you stop? We had identified a few new domains related to programming that would be useful. But, stopping where we are in DITA 1.3 is not a good answer becauseÂthe industry has evolved from where it was when the programming domain was created, and you could argue that the programming domain omittedÂsemantics that should have been included when it was created. The point is that even within programming more domains are needed. These new domains will also not be of interest to a large portion of authors.
What do we do about domains that are preconfigured into the structural grammar files? Including all of them has already led to content model bloat. Chris's idea could serve as the basis for what gets preconfigured. Although, I have configured the grammar files that exclude one or more of the domains mentioned in the "utility" category.
Quibbles:
The equation domain and theÂmathMLÂdomain fit better into the "utility" category because Mathematics is at least as general as the other domains that were identified as "utility".Â
Here are some points of clarification about troubleshooting. DITA 1.3 Troubleshooting enhancements were implemented in the DTDs as follows:
- Adding @type value "trouble" to <note> in commonElements.mod
- Adding <steptroubleshooting> and <tasktroubleshooting> to task.mod
- Adding a the troubleshooting topic type to the technical content package.
Item 1 belongs to the base, and items 2 and 3 are defined within structuralÂspecializations that would fall into the "utility" category.
Best regards,
Bob