Stan's notes on the DITA Listening sessions

===========================================================
Europe - Listening Session #1
===========================================================

---------------------
Alan Cropley (RSSB - )

CONTEXT:
- No translation
- Produces PDF and mobile apps

GOING WELL:
- CMS going well (after 2 years)
- Training for staff going well

WHY DITA?
- Was able to sell Management on the content reuse benefits.
- Adopting a publishing standard like DITA seemed to be a good fit for a transportation standards company.
- Ran into trouble with integrating non-DITA information; non-XML pipeline support in DITA is terrible

EXPENSIVE, DIFFICULT, OR STUPID:
- developing a useful information model that defines configuration, specialization, and customizations.

REQUESTS TO OASIS:
- ASK - should there not be a way to automate more of this modeling work? Why does it have to be 100% manual. 


-----------------------------
Christina Kaboth (Steinberg Media Technologies GmbH - )

CONTEXT: 
- In the role of writer and IA
- Has six writers producing PDF and WebHelp
- L10N into 8 languages

GOING WELL:
- Adoption of XML editor (Oxygen)
- Consultant contributions
- DITA information model

EXPENSIVE, DIFFICULT, OR STUPID:
- Customizations to DTDs
- Customizations to transforms
- Asked the consultant to do the first pass and then to teach others how to do it
- CONCERN - as soon as the team tries to do customizations in their own, it will fail.
- FOP = difficult to migrate to multiple languages 
  AI/Whitepaper topic???
- DITA requires expert knowledge of stuff like XSLTs, but you only discover that after you are in it.
 
INFORMATION SOURCES:
- DITA users group and Oxygen Support are useful
- Don't always get a detailed answer; should there have been 20 other people who have already solved these problems? Where are they?
- Example: To make a change to FOP, need to make a change in many places; the dependencies are not documented

-----------------------------
Fabrice	LACROIX (ANTIDOT - )

CONTEXT: 
- Dynamic delivery is their focus, putting DITA to some stress.

EXPENSIVE, DIFFICULT, OR STUPID:
- DITA Metadata = quite weak
  a. Designed for static output, not dynamic. Has not evolved
     to meet business needs.
     > Use case: Customers on a portal may need to roll back 
       one or more versions of what they are reaching. It
       ought to be possible for that sort of version-aware
       metadata to be available. 
     > Use case: Translation Management tools are acutely aware
       of how the content has changed from version to version, 
       but the tools cannot "push" that metadata back into DITA.
       DITA doesn't have the logic.
  b. DITA needs to evolve in conjunction with other standards, 
     not apart from them, e.g. DRF, SKOS, iiRDS.
     > DITA has no metadata "connection" or "exchange" logic.
      
REQUESTS TO OASIS:
- Redesign DITA metadata in collaboration with other metadata standards
  groups. Ratchet up the abstraction layer to make the metadata usable
  across implementations. 
  AI/Contact Fabrice to flesh out a proposal to the TC.

-----------------------------
Frank Ralf (parson AG - )

CONTEXT: 
- Consulting - DITA training - 
- Drivers for iiRDS (Intelligent Information Request and Delivery Standard)
- Active in the tekom standards development

GOING WELL:
- DITA is VERY powerful in the areas of reuse and referencing
- LW-DITA could be useful. A stripped down version of DITA could
  be a good thing, but it may not need their needs. 

EXPENSIVE, DIFFICULT, OR STUPID:
- The sophisticated concepts required for a writer to be successful in 
  DITA are a real challenge to many writers comfortable with the 
  Framemaker/Word worlds. Even learning how to get around in Oxygen 
  can be a challenge.  
- Customizing DITA DTDs for each customer is really expensive. They
  developed a base customization from which clients derive their 
  additional specializations.
- Metadata model is inconsistent and needs to be improved.
  > The metadata of all sorts is dropped into DITA at various 
    levels (map, topic, element). Processors do not know aht to do 
    with half of it.
  > subjectScheme and Classification are not useful; they do not
    leverage the other metadata that is embedded in maps and topics.  
    > "Fragmented"

REQUESTS TO OASIS:
- Promote the development of low-cost authoring tools, 
- Revisit the metadata options. Consider making big design 
  investments in map-level metadata. Topic-level metadata is not 
  that useful. 

===========================================================
North America - East - Listening Session #2
===========================================================

Chris	Goolsby		PTC	Technical Writing - Sr. Technical Consultant
Allen	Ehlert		Enbridge	Program Manager, Operation Digital
Lindsey	Olson		Product Documentation	Group Manager

-----------------------------
Rodolfo Raya (Maxprograms - )

CONTEXT: 
- Designs L10N tools for clients in 50 countries.
- Gets involved with many custom DTDs and schema.
- The XMLMind ditac environment is worth exploring. 

EXPENSIVE, DIFFICULT, OR STUPID:
- DITA is now too complex. It is useful for experienced XML writers, but
  others cannot use it effectively. 
- LW-DITA is too simple. 
  AI/Follow-up -- what is LW-DITA missing?
- Companies implementing DITA do not have good models for how to structure
  things. They produce bad structures in the absence of "best practice" 
  information in the DITA spec and other sources.
- We (collectively) need to teach companies how to organize their sources
  for translation (especially).  
  > AI/Follow-up on a whitepaper.
- The TC needs to develop a basic source file structure that can be 
  replicated by anyone anywhere across multiple layers.
  > AI/Follow-up on a TC feature proposal.


INFORMATION SOURCES:
- 
- 
- 

REQUESTS TO OASIS:
- If DITA 1.3 is too complex and LW-DITS is too simple, OASIS
  needs to focus on a middle ground -- "Average DITA". 
- 
- 

-----------------------------
John Kobishop (DeltaHawk Engines, Inc. - )

CONTEXT: 
- Small, but growing company with two writers. 

EXPENSIVE, DIFFICULT, OR STUPID:
- DITA is intimidating, people are scared of it. You may train them
  and get them writing, but they may do everything that they can do
  to got back to Framemaker and Word.  
- The back-end costs of customizing the transforms are not visible 
  when a company is making its initial DITA pitch. When senior
  management eventually gets the total cost, they feel like they 
  were gamed a bit. 
- Setting up the DITA-OT and sources for a Chinese translation effort 
  was expensive. DITA-OT defaults for PDF still have issues with fonts. 
- OOTB DITA reference topics do not support large-image aviation
  tables (themselves images). Forced to use the generic topic. 
  AI/Take this image placement issue back to the DITA TC.   
REQUESTS TO OASIS:
- DITA and its supporting tools need to be more friendly to 
  technical manuals and all the costs associated with publishing 
  them. The hidden costs of customizing PDF beyond the default
  DITA-OT stylesheets are significant.  

-----------------------------
Doug Gorman (SimplyXML - )

CONTEXT: 
- Produces solutions for organizations wanting to author DITA-compliant
  content in tools other than the traditional XML editor.  

REQUESTS TO OASIS:
- Finding ways to DITA more attractive to writers outside the 
  traditional technical communications silo is important.  


===========================================================
North America - West - Listening Session #3
===========================================================

-----------------------------
Jay Baldwin (Tweedle - )

CONTEXT: 
- L10N into 30-40 languages
- DITA 1,2 + SDL + some OEM integration tools 
- Publish mostly automotive service information collections. 

GOING WELL:
- The migration from DocBook has gone well. With DITA, they do 
  not need to maintain a unique environment for the many flavors
  of DocBook that they had to support. 
- 

EXPENSIVE, DIFFICULT, OR STUPID:
- Never found the right specialization for their diagnostics and 
  "theory of operation" content. 
  > AI/Follow-up to flesh out what's missing or unique.

-----------------------------
Ben Colborn (Nutanix - )

CONTEXT: 
- Developed all content in DITA from Day-1. 

GOING WELL:
- Using constraints
- Using GIT in lieu of a CCMS
- Developing/maintaining API content in Markdown. No plans
  to migrate that content to DITA.
- Have some successes transforming JSON in/out of DITA. See
  the blog post.  

EXPENSIVE, DIFFICULT, OR STUPID:
- The transition from constraints to specializations is daunting.
  No plans to risk things by developing specializations.
- DITA-OT PDF is bad. 
- Continuing to rely on PDFs as the medium for technical reviews feels 
  stupid given the abundance of online review tools. 

REQUESTS TO OASIS:
- Make specializations easier. Document the process in the
  spec. Provide support.  
- Document ways to get DITA content in and out of other markup 
  systems.

-----------------------------
Julie Bettis (Oracle Storage - )

CONTEXT: 
- Small team (5 writers + editor, IA, et al.)
- Successful content reuse within their immediate doc set; able
  to pick up topic authored by a team mate for another book.
- Oxygen + SDL

GOING WELL:
- Moved away exclusive reliance on PDFs and the book paradigm.
- Discussions about how to exploit content on portals are 
  productive.
- Finding ways to reuse CLI refenece content in multiple contexts 
  is going well. Plan to move on REST and figure it out there. 

EXPENSIVE, DIFFICULT, OR STUPID:
- Integrating non-DITA content is painful. The team would like to
  exchange content in JSON.
  > AI/Send Julie information about Interoperability TC and success
    stories with JSON and Markdown.