RE: [dita] problem with packaging of glossaries

[Michael Priestley <mpriestl@ca.ibm.com>]

There are groups who have no interest
in C/T/R, and have failed to notice that they can use topic/map on their
own. And there are others who have chosen not to use DITA, or create tools
that support it, because the spec is too large and there are too many elements
and it's intimidating. Creating a truly basic base package addresses these
concerns.

I sincerely hope that creating a base
package does not suggest that you can only specialize from it. Certainly
anyone who reads the specialization sections of the spec will know better,
and they will need to read those sections before they know how to create
a specialization. Even if it did - then would we want to move everything
into the base package? Otherwise, by that logic, anything not in the base
package is presumably not specializable, and since everything is specializable,
everything must be in the base package.

I'm fine with creating simplified versions
of the existing information types, and putting them in an appropriately
named package. That's not happening in 1.2, and in any case doesn't affect
the case for having the simplest possible base package, for the reasons
above.

Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect 
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Ann Rockley" <rockley@rockley.com>

08/21/2009 10:37 AM

Please respond to
<rockley@rockley.com>

To	Michael Priestley/Toronto/IBM@IBMCA, "'JoAnn Hackos'" <joann.hackos@comtech-serv.com>
cc	"'Bruce Nevin \(bnevin\)'" <bnevin@cisco.com>, <dita@lists.oasis-open.org>, "'Michael Boses'" <mboses@QUARK.com>
Subject	RE: [dita] problem with packaging of glossaries

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: Bruce Nevin (bnevin); dita@lists.oasis-open.org
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

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