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

Good questions. I have some thoughts on the motivations/causes of the complaints from the user community, but I'd like to hear from others on this issue first.

Regarding the impact of number of element types on tool vendors: I think it might be difficult for tool vendors to take a public position on whether they think there are too many element types in DITA. However, I can say that supporting more element types *with an optimal user experience* requires a substantial amount of work for tool vendors. Supporting a particular set of element types well can require understanding the needs of a particular market segment, and the vendor might not even be interested in in selling to that segment.

On the other hand, supporting DITA element types poorly is really cheap and easy to do. If we force every vendor to support the same large package of special-purpose element types in order to say they support DITA, what we will generally encourage is that vendors deliver tools with poor or uneven support for a wide range of market segments. It would be better for the DITA community as a whole if we create an environment that encourages vendors to deliver excellent tools for targeted market segments.

Cheers,

Su-Laine

Su-Laine Yeo
Solutions Consultant

JustSystems Canada, Inc.
Office: 1 (778) 327-6356
syeo@justsystems.com

XMetaL Community Forums: http://forums.xmetal.com

For partners only: http://www.justpartnercenter.com

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Monday, December 06, 2010 8:16 AM
To: Bruce Nevin (bnevin)
Cc: dita@lists.oasis-open.org; dita-adoption@lists.oasis-open.org
Subject: [dita-adoption] 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

From:	"Bruce Nevin (bnevin)" <bnevin@cisco.com>
To:	<dita@lists.oasis-open.org>, <dita-adoption@lists.oasis-open.org>
Date:	12/06/2010 11:01 AM
Subject:	[dita] who complains about complexity of DITA?

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

dita-adoption message