> Re the organization
below - I'm not sure about the order but the split looks right.
In Kris's display, the order is
alphabetic within each part. I don't think this signifies anything. In the
deliverable, it's by an imposed logic. We could discuss what that logic is or
should be, but it's a different issue.
From: Michael Priestley
[mailto:]
Sent: Friday, August 21, 2009 11:51
AM
To: Kristen James Eberlein
Cc: DITA
TC
Subject: Re: [dita] problem with packaging of
glossaries
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
http://dita.xml.org/blog/25
Kristen James Eberlein
<>
08/21/2009 10:33 AM
To
DITA TC
<>
cc
Subject
Re: [dita] problem with packaging
of glossaries
Two
key issues:
1.
Who do we anticipate being the potential users of
the base package?
2.
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?
Best,
Kris
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
http://dita.xml.org/blog/25
"JoAnn Hackos"
<>
08/20/2009 05:40 PM
To
"Bruce Nevin
\(bnevin\)" <>, <>
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.
Skype
joannhackos
From: Bruce Nevin (bnevin)
[mailto:]
Sent: Thursday, August 20, 2009 11:24 AM
To:
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
