dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] problem with packaging of glossaries
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "JoAnn Hackos" <joann.hackos@comtech-serv.com>
- Date: Fri, 21 Aug 2009 10:19:55 -0400
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
|
To
| "Bruce Nevin \(bnevin\)" <bnevin@cisco.com>,
<dita@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [dita] problem with packaging of
glossaries |
|
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: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]