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?
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Su-Laine Yeo" <su-laine.yeo@justsystems.com>
- Date: Tue, 7 Dec 2010 22:36:42 -0500
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]