OASIS Darwin Information Typing Architecture (DITA) TC

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:

  
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).
  
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

Wait for 1.3.



paul









From: Bruce Nevin
(bnevin) [mailto:bnevin@cisco.com]

Sent: Thursday, 2009 August 20 12:24

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:




 
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).
 
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

On 8/20/09 12:24 PM, "Bruce Nevin (bnevin)" 

Good day, Bruce.



I think I am a little confused by what is being proposed. The
concept of “packages” is not crystal clear to me. Why can packages
not share common information types? Surely I could reuse concept and glossentry
definitions in multiple packages.



Assuming that we have base abstract information types in DITA
1.3, there will still be a need to have glossentry topics and book maps in all
packages. We may want to resituate glossentry as a peer specialization to
concept rather than as a specialization of concept itself. I wouldn’t
imagine that the glossentry topic would be part of the abstract layer.



Unless I am missing something, I would recommend that we leave the
DITA 1.1 topic types where they are until we have had a chance to introduce the
abstract layer in DITA 1.3.



I apologize if I have misunderstood or I am taking the thread
back to points covered in previous conversations.



Cheers,

Rob Hanna









From: Bruce Nevin
(bnevin) [mailto:bnevin@cisco.com]

Sent: August 20, 2009 1:24 PM

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:




 
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).
 
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

Rob,
 
I may be misusing the word 
package.  There is a grouping of TechDocs-specific parts of DITA in 1.2 and 
that is what I am referring to.
 
    /B



  

  

  From: Rob Hanna [mailto:rob@ascan.ca]
Sent: Thursday, August 20, 2009 2:09 PM
To: Bruce Nevin 
  (bnevin); 'DITA TC'
Subject: RE: [dita] problem with packaging of 
  glossaries


  

  

  
Good 
  day, Bruce.
  

  
I 
  think I am a little confused by what is being proposed. The concept of 
  “packages” is not crystal clear to me. Why can packages not share common 
  information types? Surely I could reuse concept and glossentry definitions in 
  multiple packages.
  

  
Assuming 
  that we have base abstract information types in DITA 1.3, there will still be 
  a need to have glossentry topics and book maps in all packages. We may want to 
  resituate glossentry as a peer specialization to concept rather than as a 
  specialization of concept itself. I wouldn’t imagine that the glossentry topic 
  would be part of the abstract layer.
  

  
Unless 
  I am missing something, I would recommend that we leave the DITA 1.1 topic 
  types where they are until we have had a chance to introduce the abstract 
  layer in DITA 1.3.
  

  
I 
  apologize if I have misunderstood or I am taking the thread back to points 
  covered in previous conversations.
  

  
Cheers,
  
Rob 
  Hanna
  

  

  

  

  
From: Bruce Nevin 
  (bnevin) [mailto:bnevin@cisco.com]
Sent: August 20, 2009 1:24 
  PM
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:
  

    
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). 
    
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

Isn’t what we ended up with was just “convenience”
packaging. The real OASIS standard includes everything and there is an “everything”
package. 



I don’t think that it is possible to come up with any one
set of packages that will meet all needs. Some use will require multiple prerequisite
or “base” packages (base+Technical Content in this case).



The idea behind convenience packaging was to break things down
into smaller more understandable and more manageable groupings of related files
that would be convenient for many users. But we understood that there will be dependencies
between packages and that some existing and some new specializations will
require multiple prerequisite packages. Or some organizations may choose to
repackage the material as it comes from OASIS into new packages of their own that
work better for their purposes or with their specializations. 



Given this I don’t see a need to move glossentry. 
And I certainly don’t want to move concept, reference, and task.  If
you move them all,  what is left in the Technical Communication package? 



    -Jeff 









From: Bruce Nevin
(bnevin) [mailto:bnevin@cisco.com]

Sent: Thursday, August 20, 2009 2:53 PM

To: rob@ascan.ca; DITA TC

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







Rob,

 

I may be misusing the word package.  There is a grouping of
TechDocs-specific parts of DITA in 1.2 and that is what I am referring to.

 

    /B











From: Rob Hanna [mailto:rob@ascan.ca]

Sent: Thursday, August 20, 2009 2:09 PM

To: Bruce Nevin (bnevin); 'DITA TC'

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

Good day, Bruce.



I think I am a little confused by what is being proposed. The
concept of “packages” is not crystal clear to me. Why can packages
not share common information types? Surely I could reuse concept and glossentry
definitions in multiple packages.



Assuming that we have base abstract information types in DITA
1.3, there will still be a need to have glossentry topics and book maps in all
packages. We may want to resituate glossentry as a peer specialization to
concept rather than as a specialization of concept itself. I wouldn’t imagine
that the glossentry topic would be part of the abstract layer.



Unless I am missing something, I would recommend that we leave
the DITA 1.1 topic types where they are until we have had a chance to introduce
the abstract layer in DITA 1.3.



I apologize if I have misunderstood or I am taking the thread
back to points covered in previous conversations.



Cheers,

Rob Hanna









From: Bruce Nevin
(bnevin) [mailto:bnevin@cisco.com]

Sent: August 20, 2009 1:24 PM

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:




 
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). 
 
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

  


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:
72E2EA99C8FA4F4B930539BF7939C6DF01B83B6C@CSI001.Comtech.local" type="cite">
  
  

  

  
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
  

  

  

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:
  
  

    
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).
    
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
  
  

On 8/20/09 6:05 PM, "Ann Rockley" 

I haven't actually used it for a submission and the regulatory requirements
may preclude it anyway with the eCTD, but it is an example of a large
document that is very book like.

Bookmap definitely has its problems but it does make sense in some cases.
Just because it is broken doesn't mean we shouldn't use it, rather we should
fix it. We are constantly creating workarounds (not from an architectural
perspective if we can help it, but from a content mapping perspective) as we
try to map the current structure into a logical structure for BusDocs. DITA
maps really don't work well in the book paradigm. 

I still think bookmap should stay part of the standard spec, there are too
many potential uses of it outside of Tech Docs.



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Thursday, August 20, 2009 7:21 PM
To: rockley@rockley.com; Kristen James Eberlein; 'JoAnn Hackos'
Cc: 'Bruce Nevin (bnevin)'; dita
Subject: Re: [dita] problem with packaging of glossaries

On 8/20/09 6:05 PM, "Ann Rockley" 

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

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 

On 8/21/09 9:37 AM, "Ann Rockley" 

You write:

> Concept, task and reference are not "universal". There are many uses of
DITA for which they
> are completely irrelevant.

Some examples, please?

> That particular breakdown is specific to a particular technical
communication practice
> and philosophy and even that philosophy is not universal among technical
communicators. 

I would agree that the breakdown emerged from a particular practice and
philosophy, but that does not automatically disqualify it from broad
applicability. Speaking from own experience authoring hundreds of documents
of many different types, including mainstream business document types, I
have yet to find one that could not be modelled semantically, at high level,
as one or more concept, task, or reference topics. Others on the BusDocs SC
disagree with me; their experience indicates that additional, more specific,
topic types would be more suitable. But I believe I can say we have
consensus on the broad applicability of the concept, task, and reference
topic types, albeit in simpler, less constrictive versions than the ones we
currently have in DITA 1.2.

Tim.



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: ekimber [mailto:ekimber@reallysi.com] 
Sent: Monday, August 24, 2009 11:07 AM
To: rockley@rockley.com; 'Michael Priestley'; 'JoAnn Hackos'
Cc: 'Bruce Nevin (bnevin)'; dita; 'Michael Boses'
Subject: Re: [dita] problem with packaging of glossaries

On 8/21/09 9:37 AM, "Ann Rockley" 

On 8/24/09 10:31 AM, "Tim Grantham" 

> In traditional publishing content, such as trade books or novels
> or magazines, the distinction between "concept" and other stuff
> is not one that is generally recognized or useful.

Traditional publishing content is not topic-based nor is it
semantically-structured. I don't believe that we can use this as a basis for
discussion pertaining to the usefulness of core information types. Any
environment where topic-based content is used to explain, describe, or
instruct will be able to leverage the semantics contained within the DITA
archetypes. I would think that the majority of DITA adopters would fall into
this category.

Cheers,
Rob Hanna

On 8/24/09 11:44 AM, "Rob Hanna" 

> So you're saying all the work I've done over the last two years
> to use DITA to implement Publishing workflows and DITA-based
> management of content is somehow wrong?

I apologize for any misunderstanding. I didn't mean to discount your work
with the publishing specializations.

Once you have successfully described the mark-up for the publishing industry
we will be able to take what was traditionally unstructured narrative
content and blend in structured technical content with ease. I see a lot of
potential for this. There is obviously a large user base that will also be
able to take advantage of the mechanics that have been built up around DITA.

Once it is complete, I wouldn't think that it will drive a lot more
derivative specializations from it. Without semantic markup, we knock the IT
out of DITA. Without real information typing, we lose a lot of the potential
that DITA has promised. Much of our work in the BusDocs subcommittee has
been to identify real semantic information contained in what we've thought
of as traditionally narrative, unstructured content.

My comments were simply meant to say that you've got the publishing use case
covered. Most new use cases will benefit from semantic, topic-based
information development that can readily take advantage of core information
types.

Cheers,
Rob

I think we need to take a deep breath here and everyone calm down. I agree
that the market for publishing use cases is greater than that of TD and so
is BusDocs. And yes they are all topic oriented in some way or another and
there are many advantages of using DITA vs custom or DocBook as you have
indicated in your response. 

The concern BusDocs has in relegating task, concept, reference and glossary
to TD ONLY when there are potentially other uses in materials outside of TD.



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: ekimber [mailto:ekimber@reallysi.com] 
Sent: Monday, August 24, 2009 12:57 PM
To: rob@ascan.ca; dita
Cc: 'Bruce Nevin (bnevin)'; 'Michael Boses'; tgrantham@timgrantham.com;
'Michael Priestley'; 'JoAnn Hackos'; rockley@rockley.com
Subject: Re: [dita] C/T/R Not Universal (was problem with packaging of
glossaries)

On 8/24/09 11:44 AM, "Rob Hanna" 

On 8/24/09 12:35 PM, "Ann Rockley"