Hello Kris-san,
Yes, these are the things even with DITA advocates are talking.... Why do we need DITA 1.2 new features? Like we have already created specialized current 1.1 DTDs and we are happy with it.. Key-based mechanism is good but in order to implement the mechanism, we need to spend the time adapting new information architecture reflecting the features, and so on...
I am really looking forward to your article.
Best regards,
- Tetsuya
From: Kristen Eberlein [mailto:keberlein@sdl.com]
Sent: Tuesday, December 07, 2010 10:10 AM
To: tself@hyperwrite.com; dita@lists.oasis-open.org; dita-adoption@lists.oasis-open.org
Subject: [dita-adoption] RE: [dita] who complains about complexity of DITA?
Tony, I think that you’ve nailed it in a nutshell. This is exactly what I have been hearing from authors, developers, and even well-known DITA consultants!
I am going to try and address why writers might care about some of the more obviously useful DITA 1.2 features in an article for a March 2011 issue of Intercom.
Best regards,
Kris
Kristen James Eberlein l DITA Architect and Technical Specialist l SDL Structured Content Technologies Division l (t) + 1 (919) 682-2290 l keberlein@sdl.com
Please consider the environment before printing this e-mail
From: Tony Self [mailto:tself@hyperwrite.com]
Sent: Monday, December 06, 2010 7:37 PM
To: dita@lists.oasis-open.org; dita-adoption@lists.oasis-open.org
Subject: RE: [dita] who complains about complexity of DITA?
Greetings all
“Complaints” might be too harsh, but the disquiet that I have heard comes from authors. I believe the issue is one of perception, not of complexity, but that doesn’t necessarily make it a lesser problem. From chats that I was involved in (or overheard), there is some feeling that DITA was OK as it was, and that the drivers for the 1.2 changes and additions are unclear. (“Who decided there was a need for keyref or whatever?” “I’m going to stick with 1.1, because I don’t need any new features.” “I can see that keyref is very clever and so on, but I can’t foresee ever needing it.”)
A comparison with DocBook was also made, along with a view that the demise of DocBook was connected with the growth of its number of elements.
The question for us should be how do we address this perception of complexity? It is quite difficult to explain specialisation and conref to a novice, but we now need to also be able to explain constraints and keyref, subject schemes, etc.
Tony Self
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, 7 December 2010 3:16 AM
To: Bruce Nevin (bnevin)
Cc: dita@lists.oasis-open.org; dita-adoption@lists.oasis-open.org
Subject: Re: [dita] who complains about complexity of DITA?
I'm also curious about this. Even before we had constraints, we had basic DITA modularity, which lets you include or exclude whole domains of elements at a time. And the doctypes we package with the spec do exactly that.
Simple number of elements in the spec as a whole shouldn't be a measure of complexity for either authors or architects, since you only include or work with the elements that matter for your domain. For example, the learning and training specializations don't increase complexity for authors or architects in basic tech comm.
So do we really have a complexity problem, that is it's too hard to use DITA or create new DITA specializations? Or do we have a communication problem, about how to use DITA (start small, include what you need, don't try to use stuff you don't need)? Or are there other problems, outside the domain of the spec, like customizing processing flows, that get reflected back on the spec even though it's really something outside our control?
I don't mean to dismiss complaints about complexity, but like you I think we need to understand the actual motivations/causes of the complaints before we can usefully react.
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25