[dita-adoption] who complains about complexity of DITA?

[Mark asked me to 
forward this reply. During this time while his company's membership renewal is 
getting sorted out, his email to the alias bounces, and the server declines to 
send him anything sent to the alias. He asks that we please retain his email 
address in the cc of any replies, as above. Thanks!]

  

  
  From: Mark Poston 
  [mailto:] 
Sent: Wednesday, December 08, 2010 
  5:37 PM
To: Bruce Nevin (bnevin)
Cc: 
  ; 
  
Subject: Re: [dita-adoption] who 
  complains about complexity of DITA?

  

  

  

  

  

  

  

  
From my perspective as a consultant speaking to customers about DITA in 
  non tech doc areas there is a common theme of not wanting to push knowledge of 
  XML onto users at all.

  

  
It's easy for us to suggest that DITA will solve all sorts of problems, 
  but when it comes down to it, the practicalities of doing so are always a lot 
  more complex.

  

  
A big challenge to start with is convincing an organisation that XML is 
  the way to go. Without the tools and infrastructure in place there's always 
  going to be a difficult road ahead. For wider corporate use there are 
  challenges from IT departments to accept such changes unless they already fit 
  into an existing IT system - quite often based on Microsoft 
technologies.

  

  
Tech docs teams have generally been a little easier to provide solutions 
  for as their requirements have previously fallen outside of any corporate 
  systems and are for only a smaller closed group of users. This is becoming 
  less the case now.

  

  
Overcoming these challenge means that solutions need to be provided that 
  will address the different types of user's needs - considering their user 
  personas if you like.

  

  
The work of the BusDocs sub committee is taking a step towards this, and 
  that is likely to introduce more types of content that meet specific needs of 
  different areas in the business. This is very useful work but when it comes 
  down to it, it still ends up being about the tools that are used and the 
  education that is required to adopt them.

  

  
For me, for DITA to become successful outside of tech pubs, the focus 
  needs to be on tool vendors taking away the need to know anything about XML 
  and using DITA as the hidden enabler of a content architecture. This brings 
  about the need for DITA-aware tools where XML is never seen - of course there 
  are some of these already (for example Quark XML Author springs to 
mind).

  

  
For many users, features such as conref, keyref, constraints, reltables 
  are too technical for them - these need to described in a context that is 
  appropriate to them and their particular use case, or not described at all as 
  it doesn't actually matter. As a vendor, architect or system integrator they 
  are, again, the enabler - just like a programming language is an enabler to 
  providing a software solution to a customer.

  

  
These user friendly descriptions are what the DITA Adoption committee can 
  help with, along with their work on defining benefits of DITA for different 
  audiences.

  

  
My concern is that as DITA grows, and it will only continue to grow, it 
  becomes such a complex standard that it will gain a reputation as being as 
  such and perceived as an expensive thing to implement. This is, of course, 
  completely the opposite to the original reason for recommending DITA as an 
  option to tech pubs team, as vendors were able to quickly support and 
  therefore provide a more cost effective solution with, quite often, easily 
  identifiable return on investment.

  

  
As the DITA standard grows so to are the requirements for vendors to 
  support it, making XML authoring tools and other systems do more than they 
  were originally intended to do. I am not a tool vendor but I can imagine that 
  implementing the new con ref and key ref features (for example) aren't that 
  straight forward. I just hope that there is still the interoperability between 
  tools now that DITA is not just about parsing XML but also has requires a 
  complex application layer on top of it to implement its features.

  

  
Personally, I would like to see an open source DITA interop framework 
  that allows tool vendors to use a common library that implements features in 
  the standard. This can then be integrated into tools in a consistent manner. 
  As the standard grows, this framework would provide the processing logic for 
  DITA's features. It's partly there in the DITA Open Toolkit already ... Which 
  is developed hand in hand with the standard itself.

  

  
A long-winded response but I hope provides some useful discussion 
  points.

  

  
Kind regards

  

  
Mark Poston

  
Mekon Ltd.

  

Sent from my iPad

  

On 6 Dec 2010, at 15:59, "Bruce Nevin (bnevin)" <> 
  wrote:

  

  
    

    

    
Are we entirely clear about the use contexts 
    in which users find the number of elements onerous or confusing? Obviously, the authoring environment is 
    one.  But do architects also object? Do the tools vendors object? This 
    seems less likely to me, but it's not something to guess, we should find 
    out. And is that (the number of 
    elements) the only complexity that they object 
    to?

    
The 
    constraints mechanism can neatly address the perceived complexity in the 
    authoring environment. (Be it noted that 
    existing mechanisms provided by [some?] authoring tools to hide elements 
    from authors apparently do not reduce these complaints, maybe because the 
    complaints come from users who don't make use of them.) But creating and 
    managing constraints is another layer for architects and designers to deal 
    with.

    
    
    /Bruce