So correct me if I am wrong, moving
everything out of the base package suggests to any specific group means that
they have to begin specialization from the base and cannot take advantage of
the existing work done to date. The concept, task, and reference are universal
content structures but they are a little more specialized to Tech Docs at this
time. This is one of the reasons we are suggesting a simplification of the
existing info types so they can easily serve as a basis for any future work. I
can’t imagine any group not needing these core structures. We need an
interim step where Tech Docs can begin to specialize the existing info types
further, but the rest of us can take advantage of the core of DITA and begin
our own specializations. And if the TC agrees to the suggestions we are making
for simplification, it should hopefully be easier for these specializations to
happen.
Let’s not “throw out the baby
with the bath water!”
From: Michael
Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Friday, August 21, 2009
10:20 AM
To: JoAnn Hackos
Cc:
Subject: RE: [dita] problem with
packaging of glossaries
The point of a separate base package is to provide the
bare minimum of DITA support - just topic, map, basic utility domain.
So
absolutely everything else gets relegated out to another package - and since
we've only got two other packages, that means they either go into tech docs or
learning and training.
I'm
fine with renaming the tech doc package to something else, if it helps - even
"key specializations" if that would do the trick. But if we move any
specializations into the base package, we undermine the point of having it.
Michael
Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
|
"JoAnn Hackos"
<joann.hackos@comtech-serv.com> 08/20/2009 05:40 PM |
|
I am in favor of Bruce’s second
recommendation. What is the problem with stating that concept, task, and
reference are key specializations in the DITA standard? Why should they be
relegated to technical communication only? I just don’t see the point of
that.
Even if there is a All DITA package, we’re not
including information about task, concept, and reference information types in
the base architectural specification, but only in the arch spec for technical
communication.
I’ve never been in favor of this split and would
strongly prefer that we include task, concept, reference, and glossary in the
base architectural specification. That would leave us with the machine industry
specialization, which is, of course, extremely relevant for many outside the
machine industry, and the various domains (software, ui, programming, machine
industry, safety hazard). Also bookmap. Why is bookmap considered relevant only
for technical communication. It’s probably less relevant there and more
relevant for DocBook aficionados.
Since I’m 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 a statement that these may
primarily relate to product documentation although I really don’t think
that’s true.
JoAnn
JoAnn Hackos PhD
President
Comtech Services, Inc.
joann.hackos@comtech-serv.com
Skype joannhackos
From:
Sent: Thursday, August 20, 2009 11:24 AM
To: dita@lists.oasis-open.org
Subject: [dita] problem with packaging of glossaries
This came up in the spec
authoring meeting today.
The problem: <glossentry>
is specialized from <concept>. <task>, <concept>, and
<reference> are in the TechDocs package. This forces <glossentry>
etc. to be restricted to the TD package. But non-TechDocs folks need
glossaries, and support for them should be in the base.
Two solutions:
1.
Accept 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).
2.
Move <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.
Comment? Action?
/Bruce