I am in
favor of Bruce’s second
recommendation. What is the problem with stating that concept, task,
reference are key specializations in the DITA standard? Why should they
relegated to technical communication only? I just don’t see the point
there is a All DITA package, we’re
not including information about task, concept, and reference
in the base architectural specification, but only in the arch spec for
been in favor of this
split and would strongly prefer that we include task, concept,
glossary in the base architectural specification. That would leave us
machine industry specialization, which is, of course, extremely
many outside the machine industry, and the various domains (software,
programming, machine industry, safety hazard). Also bookmap. Why is
considered relevant only for technical communication. It’s probably
relevant there and more relevant for DocBook aficionados.
writing the tech comm arch
spec content and the topic content, I’d be very happy to restore task,
concept, reference, and glossary to the base arch spec. I could include
statement that these may primarily relate to product documentation
really don’t think that’s true.
up in the spec authoring meeting today.
problem: <glossentry> is specialized from <concept>.
<concept>, and <reference> are in the TechDocs package.
<glossentry> etc. to be restricted to the TD package. But
non-TechDocs folks need glossaries, and support for them should be in
this. Present it as an unfortunate fait accompli for 1.2 -- if you want
a glossary, you have to use the TD package (or specialize your own).
<task>, <concept>, and <reference> back into the
base, sans TD-specific domain specializations, and include those
specializations in the TD package. Present this as an interim step
toward simplified topics being developed by the BusDocs SC.