[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Stan's notes on the DITA Listening sessions
|
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]