OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] problem with packaging of glossaries


We were planning to work with concept, task and reference. Concept, task and reference are key in numerous types of business documents. It would be an incredible amount of work to go back to topic and recreate concept, task and reference. We are working towards making a recommendation of “simplification” to these so that it is easier for other industries to specialize from them.

 

I also agree with Bruce that they should remain as part of the base architectural specification. And I agree with JoAnn that bookmap is relevant to multiple industries, eg pharma could use it for submissions, we just finished working with a book publisher and we used it there, it would make sense for medical devices etc.

 

We would be very much appreciative if these could be restored to the base arch spec.

 

Ann

 


From: Kristen James Eberlein [mailto:keberlein@pobox.com]
Sent: Thursday, August 20, 2009 6:25 PM
To: JoAnn Hackos
Cc: Bruce Nevin (bnevin); dita@lists.oasis-open.org
Subject: Re: [dita] problem with packaging of glossaries

 

I am curious to know what the Enterprise Business Documents folks are planning. Are they planning to specialize from topic, or are they planning to work with concept, task, and reference?

Kris

JoAnn Hackos wrote:

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]