When asking around the contacts I have in the semiconductor industry about DITA, one other person willing to go on the record was Colin Maudry from NXP. He works for NXP out of its Eindhoven office in The Netherlands, and is a DITA Specialist overseeing the migration of their documentation team over to DITA XML. His associate John Walker (who helped with the specifics of some of the responses) is a Business Analyst who is implementing processes and tooling for product information management for NXP’s publications.
Colin also gave me some further background as to how they use DITA in general at NXP:
NXP uses DITA mainly for managing what they call “value proposition” (i.e. marketing) content. This content is published on the NXP public website on their product pages, and category pages. It is also used for their mobile applications. What I found interesting was that he told me that a significant proportion (almost half) of NXP’s data sheets use DITA not as the final output format but as an intermediate rendition format, so some of their topics (like the “value propositions”) are managed in DITA, while others are generated on-the-fly from their product information database (which is not stored in DITA). The rest of their technical documents continue to be done using either Framemaker or Word.
Their DITA setup: Componize 1.5 for Alfresco and they XMetal XMAX for their XML editor, though they intend to replace it with the web-based version on oXygen. XTM Suite is used to handle their translation process, and FOP is their XSL-FO processor of choice. What I also found interesting was the fact that they have done some minor specializations as well, primarily so that they can add internal metadata and constrain the content model—they have gone public with this information, and their DTDs can be found here.
With all of that in mind, I was looking forward to hearing what they had to say about their experiences of using DITA. Here are their responses:
DITAWriter: From a semiconductor industry perspective, what are the chief benefits of using DITA?
Colin Maudry: Using a standard format gives access to a market of standard tools (authoring, CMS, translation) and to a user community that is eager to share experience. This greatly decreases the effort in R&D, we basically just have to customize it to our small specializations and branding. NXP makes chips, we don’t develop techdoc formats, CMS or publishing tools!
To us a standard equals lots of people who have the same problems as we have plus lots of software companies who are anticipating our needs without us even asking them.
DITAWriter: Are you looking to implement the DITA Semiconductor specialization when it is released alongside DITA 1.3?
Colin Maudry: The SIDSC only covers the registers domain so far, and a limited part of our portfolio uses registers. We use IP-XACT extensively for these products and, although the author there is a DITA enthusiast, she didn’t see the migration to DITA SIDSC as a must have. She did play with it though and we definitely keep an eye on the progress made by Freescale.
When we joined OASIS, the plan was that NXP would start developing a new domain, electrical parameters. However, we were also discussing internally the future of our product data management, and the decision was made to use an XML ISO standard called OntoML (Wiki at eCl@ss, Wikipedia). It made perfect sense as our dictionary is based on IEC 61360 and OntoML is a valid serialization format.
Last but not least, our position regarding the usage of DITA is very clear: DITA is a good fit for natural language in semi-structured content, not for structured content such as product data. Since our ‘golden’ document is a data sheet, that gives some indication of the type of content to expect.
We are currently thinking of ways to touch base with fellow semiconductor companies and, rather than working on a standard format in a format organization, working on a common abstract data model and good practices.
DITAWriter: Have you had the opportunity to import DITA XML from a firm you do business with?
Colin Maudry: No, never. I heard certain distributors might be interested in getting our content, but that’s all. To be honest, we’re mostly a source of content, I don’t think we import much content from other companies. This is mostly down to the change in focus of NXP over the past years from “vibrant media” technologies (with lots of IP blocks) to “high-performance mixed signal with a strong standard products foundation”.
The only situation we had that comes close is when the author mentioned above generated some SIDSC register spec DITA and we were able to load it straight into the CCMS and output some basic renditions.
DITAWriter: Not all semiconductor firms have taken on DITA. Why do you think that is?
Colin Maudry: Switching to DITA requires introducing new tooling and new concepts, in an area, technical documentation, where you usually don’t find many IT enthusiasts who will play with the DITA OT for fun. This is one of the reasons why the software industry is keen on adopting DITA.
I also think many companies don’t see benefits in investing in an area that doesn’t generate direct revenue or give a fast ROI.
Finally, I’m too young to have known the old times (26 y.o.), but since keyboards have been used to produce documentation, the final document has always been in the writer’s mind. Switching to a topic/map structure and considering reuse at authoring time is a tough challenge for a population that has often been working for decades with a document-centric approach.
I can’t find reasons that are specific to the semiconductor industry and would not also apply to any other industry.
DITAWriter: What is your best experience using DITA? What is your worst experience using DITA?
Colin Maudry: My best experience happened in 2008, I was an intern localization quality engineer at Translations.com, and I remember perfectly that preparing XML content for translation and delivery could be a nightmare (encoding, broken markup, content to be translated or not, etc.)
Last year, when I created the first translation project in XTM Cloud. I only had to upload a zip with DITA content: it was segmented and analyzed without anything to configure, translators could start working right away. The @translate attribute was obviously supported. It really felt like I was in 21st century!
As for the worst experience I have had with DITA, that happened shortly after I arrived at NXP (December 2010), when I had to use an existing set of stylesheets to render PDF data sheets. It had to be done in two steps:
- Integrating them in Componize (thanks for their help!)
- Fine tuning them to include the latest improvements (XSL-FO, be damned!).
I had not received proper training from Componize at that time, and though I knew the theory, I had never developed much in XSLT. These were the longest working days…
Friday: answers to these same questions from people working with DITA in the semiconductor industry who wanted their answers to remain anonymous…
Thanks Keith for gathering the current status of the semiconductor industry in one place, great initiative.
If you, reader haunted with questions, want to know more about our DITA setup, ping me on Twitter! @colinmaudry