I know that some TC members are not on the DITA Adoption TC, so I wanted to bring these notes to their attention. There are a number of places where people suggested things that they'd like OASIS to do; I've highlighted them below in bold. (I'll also attach the TXT file from Kavi.) =========================================================== Europe - Listening Session #1 =========================================================== --------------------- Alan Cropley (RSSB -
alan.cropley@rssb.co.uk ) 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 -
c.kaboth@steinberg.de ) 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 -
lacroix@antidot.net ) 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 -
frank.ralf@parson-europe.com ) 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
cgoolsby@ptc.com PTC Technical Writing - Sr. Technical Consultant Allen Ehlert
am.ehlert@rogers.com Enbridge Program Manager, Operation Digital Lindsey Olson
lindsey.olson@ni.com Product Documentation Group Manager ----------------------------- Rodolfo Raya (Maxprograms -
rmraya@maxprograms.com ) 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. -
john.kobishop@deltahawk.com ) 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 -
doug@simplyxml.com ) 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 -
JBaldwin@tweddle.com ) 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 -
ben@nutanix.com ) 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 -
julie.bettis@gmail.com ) 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. -- Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting
www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) =========================================================== Europe - Listening Session #1 =========================================================== --------------------- Alan Cropley (RSSB -
alan.cropley@rssb.co.uk) 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 -
c.kaboth@steinberg.de) 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 -
lacroix@antidot.net) 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 -
frank.ralf@parson-europe.com) 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
cgoolsby@ptc.com PTC Technical Writing - Sr. Technical Consultant Allen Ehlert
am.ehlert@rogers.com Enbridge Program Manager, Operation Digital Lindsey Olson
lindsey.olson@ni.com Product Documentation Group Manager ----------------------------- Rodolfo Raya (Maxprograms -
rmraya@maxprograms.com) 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. -
john.kobishop@deltahawk.com) 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 -
doug@simplyxml.com) 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 -
JBaldwin@tweddle.com) 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 -
ben@nutanix.com) 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 -
julie.bettis@gmail.com) 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.