OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-adoption message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



Su-Laine wrote:
Michael's comment, "DITA can be complex, if you need complexity. It can also be simple, if you need simplicity" is true, however the issue seems to be that the *default* state of DITA is complex. In practice there is a world of difference between "DITA has 100 elements and you can add up to 100 more via optional packages." and "DITA has 200 elements and you can hide up to 100 of them by configuration."
 
I totally agree. And that's one reason I was pushing for the simple topic type to be included in DITA 1.2, with no domains included except highlighting. So we actually do have a default doctype in DITA that has the proverbial 100 elements or less, which can then be added to (or further constrained, but you get pretty far just by eliminating all the extra domains).

We may have increased the number of doctypes in 1.2, and added to the core capabilities of the architecture to allow more fine-grained constraints, but for that basic starter user we have actually created a simpler starting default than they had in 1.0 or 1.1.

So I stand by my comment.

That said, there are things we can do to make it even easier:

- polish and promote Jarno's tool for web-based generation of custom doctype shells - and maybe hook in a spec generator that will automatically build a custom version of the spec as well, to only pull in the stuff needed for the new doctype
- for 1.3, create an additional package of specifically constrained topics, doing things like removing prolog in topic (like Allyn suggested), maybe getting rid of complex tables, etc. - prune to get to the simplest possible content format, and target the simple portable content scenarios - not sufficient for tech comm folks, but bulletproof for getting simple content into the DITA pipeline

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25


From: "Su-Laine Yeo" <su-laine.yeo@justsystems.com>
To: <dita@lists.oasis-open.org>, <dita-adoption@lists.oasis-open.org>
Date: 12/07/2010 08:44 PM
Subject: RE: [dita-adoption] Re: [dita] who complains about complexity of DITA?





Really interesting discussion so far with many insightful comments from the trenches.
 
Michael's comment, "DITA can be complex, if you need complexity. It can also be simple, if you need simplicity" is true, however the issue seems to be that the *default* state of DITA is complex. In practice there is a world of difference between "DITA has 100 elements and you can add up to 100 more via optional packages." and "DITA has 200 elements and you can hide up to 100 of them by configuration."
 
As a general  statement about technology, users overwhelmingly stick with defaults, much more than developers usually think  and in spite of what experts recommend. Here is one example: http://www.ingentaconnect.com/content/routledg/rics/2008/00000011/00000001/art00003 . There are a few reasons people tend to stick with defaults:
- Choosing what to change means reading a big pile of stuff
- Afraid that if they turn something off, turning it back on will be a huge hassle or impossible
- Not easy to get budget approval for taking features out of a product and putting them back in later
- Too busy with other critical tasks in getting the project off the ground
- Nobody ever got fired for sticking with defaults in software
 
In addition to the tendency of users to stick with defaults, I think another thing going on is unit bias (http://sciencethatmatters.com/archives/35). Many, although not all, vendors like to be able to say that they "fully support" something without a bunch of footnotes describing the 17% that isn't supported.
 
BTW, so far we've been focusing on the perceived complexity of the standard itself, but I'd guess that a lot of the complaints about "DITA" being complex refer to issues with tools, and particularly with customizing output. There isn't really anything we as OASIS committees can do about tool issues, but it's worth keeping in mind that people aren't always talking about the standard when they talk about DITA's complexity.
 
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:
Tuesday, December 07, 2010 5:50 AM
To:
Dick Hamilton
Cc:
dita@lists.oasis-open.org; dita-adoption@lists.oasis-open.org
Subject:
[dita-adoption] Re: [dita] who complains about complexity of DITA?

 

Hi Dick,


>The "DocBook is dead" undercurrent in this thread surprises me.

I hadn't noticed that undercurrent, and don't think it's relevant to the discussion in any case. Getting


But I do think that just saying "DITA is complex" is a complete mistake. DITA can be complex, if you need complexity. It can also be simple, if you need simplicity. There are plenty of case studies from both ends of the spectrum. Boosters of DITA tend to focus on the simplicity of the simple cases and the value of the complex cases, and detractors of DITA do the reverse. Both are misleading.


A big driver for the creation of the DITA maturity model was to bring some clarity to the discussion. At level 2 of the model, you're using just topics and maps, and only prepackaged specializations (if any). Many organizations adopt at that level and are quite happy with their ROI. You get the potential for substantial additional returns from higher up the model, along with increased cost - although over time, there is a trickledown effect, as specializations created by organizations at level 3 or higher are tested and contributed back to the community, allowing groups at level 2 to capitalize on that investment.


http://dita.xml.org/wiki/the-dita-maturity-model

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com

http://dita.xml.org/blog/25

From: Dick Hamilton <rlhamilton@frii.com>
To: "dita@lists.oasis-open.org" <dita@lists.oasis-open.org>
Cc: "dita-adoption@lists.oasis-open.org" <dita-adoption@lists.oasis-open.org>
Date: 12/07/2010 02:22 AM
Subject: Re: [dita] who complains about complexity of DITA?

 







The "DocBook is dead" undercurrent in this thread surprises me. DocBook is still alive and well in many applications, esp., open source.

Even with more elements (though if you include L&T, DITA 1.2 is bigger than DocBook 5.0:-), I'd argue that DocBook is much simpler for writers and will be until practitioners learn how to use the complex features of DITA to create simple applications that support the work that writers need to do.

(By "application" I mean a combination of specialization, features like keyref, content strategy, and writer training to create a custom solution that addresses a particular business need.)

I wonder if the correct "marketing" approach is to acknowledge that DITA is complex, but emphasize that when properly used, that complexity makes it possible for tools developers to create applications that are simpler and more capable for their target audience.

Dick Hamilton
XML Press

http://xmlpress.net






---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]