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

Title: Re: [dita] problem with packaging of glossaries
Interesting --

If people are creating tools for simple content, shouldn’t they be reading the entire spec and understanding what it is that they’re doing? How can you simplify, if you don’t know what you’re simplifying from?

It’s the base content that strikes me as overwhelming. I believe that the base architectural specification will end up with the largest section of specialization. Many people still appear to believe that they must specialize to do anything. Perhaps we should remove specialization from the base and recommend it for advanced users only.

The way we’ve seen most people begin effectively and efficiently is simply with T/C/R and a map. We are using bookmap for many applications and quite successfully. I’d be more interested to know (for 1.3) what the plans might be to “fix” the bookmap.


On 8/21/09 9:51 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

Some potential users of the base package:
- people creating tools that work with simple content applications with minimal structure, like unstructured blogs, news feeds, web page components...
- people who would otherwise not read the spec because it's too big, and can now be seduced into reading just the first part, which provides a context that makes the rest less intimidating

Re the organization below - I'm not sure about the order but the split looks right.

Thanks for making this discussion concrete.

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect

Kristen James Eberlein <keberlein@pobox.com> 08/21/2009 10:33 AM


DITA TC <dita@lists.oasis-open.org>


Re: [dita] problem with packaging of glossaries

Two key issues:
Who do we anticipate being the potential users of the base package?
Michael, I want you to look at the current contents of the language reference material for both the base and technical content version. Is this as you have been envisioning it?



Michael Priestley wrote:

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 <mailto:mpriestl@ca.ibm.com>
http://dita.xml.org/blog/25 <http://dita.xml.org/blog/25>

"JoAnn Hackos" <joann.hackos@comtech-serv.com> <mailto:joann.hackos@comtech-serv.com> 08/20/2009 05:40 PM


"Bruce Nevin \(bnevin\)" <bnevin@cisco.com> <mailto:bnevin@cisco.com> , <dita@lists.oasis-open.org> <mailto:dita@lists.oasis-open.org>


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 Hackos PhD
Comtech Services, Inc.
joann.hackos@comtech-serv.com <mailto:joann.hackos@comtech-serv.com>
Skype joannhackos



Bruce Nevin (bnevin) [mailto:bnevin@cisco.com
<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?


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