It's been great to read the blog posts from CMS 2006 - I was there in 2005, when DITA had its first full track at a conference, and the excitement was building then. It's amazing how far we've come in just a year: from one or two CMS vendors with DITA support to all of them! Although I suspect that as with the editors, the level of support varies, and features will continue to improve over time: typically supporting topics first, then maps, and finally specialization. Still, the level of focus on DITA as a common standard across CMSs is amazing, and one year since the standard was published is a very fast time to achieve consensus in an industry.

Read more

a few more stray thoughts about my CMS 2006 experience...

Keep pushing topics

There's still a lot of need to keep pushing the topic-based paradigm. The book-oriented focus still reigns supreme for a lot of content developers and deliverers. Though more people "get" it than don't, there's plenty of pressure to relax the topic-based approach and allow for creating content with chapter-length topics with deeply nested sections and relaxed typing. We need to learn how to manage this, so that DITA *can* effectively extend its reach beyond technical docs, but also keep the virtues of topic-based, structured semantics in place.

Read more

For my first post, file this in the category of watching out what you wish for - what with all the new collaboration technology that lets you work with people without ever having to actually sit in the same room with them, I often yearn for the chance to travel and get to meet a lot of these people I work with.

Well, after just returning from the pretty amazing CMS 2006 conference in San Francisco, I head off tomorrow to attend the 14th annual WritersUA in Palm Springs.

CMS 2006 was an amazing experience. And has DITA arrived, or what? In the introductory remarks, Joanne Hackos reported a 68% increase in attendance this year compared to last, almost all of that due to DITA. Fully 27 out of the 42 sessions had DITA in their title, not including demos. At Andrea Ames' packed session on information architecture, a raise of hands showed that all but three people out of over the 100 there had come to the conference specifically to learn more about DITA. Each of the 20+ vendors in attendance had a major focus on DITA.

And the level of discussion about DITA generally went well beyond the basic intro level. Lots of lively and detailed discussions about the best collection-type attributes in map topicrefs, source-only vs. target-only linking, the structure of a task topic and how to extend it, and so on.

Read more

there are two use cases i'll currently seen in the field of DITA adoption:

1. using reference implementation of DITA OT out-of-the box
   this approach speeds up initial step in adopting topic oriented approaches for creating supported output formats
   
   if you look into existing task / reference / concept specialization you see that those data models are not suitable for each user in each domain and using the dita topic itself lacks of semantic and therefore only recommended in certain use cases.
   
2. using specialization to adopt DITA OT datamodel to user specific needs.
   this is one of the major advantages of DITA in general. beside issues related to information architecture (how to identify "best practices", requirements for specialization that works for me, .....) there is one technical issue you might be thinking of:
   
   "how to verify that a certain datamodel is DITA complaint"
   
   there is currently no way to make sure a "announced DITA complaint DTD / W3C Schema" conforms to what is described in the standard.
   

you might think that this is not a major issue, but the more DITA gets used the more "DITA aliens" are created and no one might ever know if the created content can or cannot be interchanged with other DITA complaint processing chains. even if there are currently still many good reasons to extend a DITA datamodel in a non complaint way you should even get the informed about that to estimate the implact.

because DITA currently lacks of a normative, formal specification this also helps to get more formalize specification in terms of requirements of a DITA complaint datamodel.
based on knowledge and best practices a set of rules should be creating describing the requirements of a datamodel to be announced as DITA complaint. therefore in my point of view it would be useful to create a "validation process" which can be used either:

• to express and validate the rules described in the standard against consistency and feasibility
  thus can be used to also verify extension to the standard in a formal, normative way
  
• to get rid of "validation by example" which is in general not a formal validation but also tricky and error prone

how to get this:

• as a basic infrastructure you need parser create a format independent structure of DTD / W3C Schema
  

  DTDinst (http://www.thaiopensource.com/relaxng/dtdinst/) might be a good infrastructure to provide unique XML representation of the datamodel.

  Read more