| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Re: [dita] RE: [dita-adoption] RE: [dita] who complains about complexity ofDITA?
- From: Michael Priestley <firstname.lastname@example.org>
- To: email@example.com
- Date: Thu, 9 Dec 2010 13:43:35 -0500
There are some thoughts in here I want
to tease out.
> This discussion has been interesting and the points raised show an
> interesting diversity of situations where problems do and don't
> occur. My work in relation to DITA has primarily been in the
> education sector which demonstrates some particular differences but
> also some approaches in relation to corporate training. In either
> case, however, there have not been any significant adoptions of
It may depend on how you define significant, and also
the case studies are. There are plenty of organizations
using DITA for training materials, and at least one
publically using DITA for publishing (I suspect there
publishers using DITA - Eliot may be able to say more).
>The experiences I have had are consistent with
> comments but I would like to make a couple of distinctions and draw
> attention to some particular issues that I believe are relevant.
> 1. DITA itself is complex. It is not useful for the more
> technically minded, let alone those with substantial XML expertise,
> to say that DITA itself is simple or comparatively simple relative
> to other XML standards. DITA has rich functionality and the
> inheritance capability mean that non-technical content developers
> are intimidated by it.
I'm not sure that it's useful to make statements this
DITA is decidedly NOT complex for people using custom
doctypes that match
their needs. (Or whose needs match the out-of-the-box
And why would content developers ever care about inheritance?
have noted, car engines can be complex without intimidating
Would it be ok to make a more specific statement:
- existing default DITA doctypes are too complex for
some classes of author
- the specialization and customization process is
too complex for some developers
> 2. The richness of DITA is not relevant to all content authors.
> More importantly, even with simplified, customized applications and
> infrasructure a content will creator will need to know about the
> implications of the choices they make during authoring and how they
> relate to later stages in the content lifecycle, especially in
> relation to reuse across different contexts. Simplification
> is hampered, I believe, by individual topics being overly heavy in
> metadata and "smarts" that require more detailed knowledge
> really trying to single source content across an organization. From
> my experience, individual content items should be as dumb and light
> as you can make them and aggregations should provide the smarts.
Since you're talking about a simplified, customized
wouldn't the simplification include moving control
of the metadata to
the map? It's an absolutely standard DITA behavior,
so all you'd
really be doing is removing the prolog from topics.
DITA 1.0 by creating a two-element specialization,
or do-able in 1.2
with a constraint module).
> 3. The value is not just in the authoring but also in the
> processing. For non-technical users it takes a bit of time for
> to sink in. For use cases where users in the same organization
> relatively automous with respect to authoring and output choices
> (incl. destination formats and styles) it is much harder to tame the
> relationship between authoring and output. There is no simple,
> cost-effective way for small scale content developers to create and
> process content. Not that I have found, anyway. You can
> moderate simplicity from some authoring tools but defining output
> styles, formats etc remains highly problematic unless there is a
> very large system providing the smarts behind the simple interfaces.
To some degree I think this is a basic aspect of any
XML system that
separates content and presentation. That said, there
are tools that
make it easier for authors to style their content
without resorting to
programming, using the existing styling capabilities
of Word or
So while I think there is a tradeoff between robust
and ease of one-off customization, there are tools
both ends of the spectrum. Regardless, this is a tough
one for the
spec to fix.
> 4. <quote>Moving to structured, topic-based
authoring is not
> business-as-usual. It represents a paradigm shift for any author.
> can and should hide as much of the complexity as possible but in the
> end we need to produce something akin to structure in something
> resembling topics otherwise it is most probable that we've selected
> the wrong architecture.</quote> (Rob Hanna). Absolutely
> however, doing this with DITA requires a large scale commitment to
> build an infrastructure within an organization that will meet the
> requirements of the varied users in that organization.
The scale of the commitment should match the scale
of the implementation.
There are organizations using DITA out of the box,
in tech comm organizations, with only processing customizations.
And there are an increasing number of out-of-the-box
aimed at the starter or standalone market, which is
nice to see.
> Organizations that "get it" will not have a problem in making
> investment (probably in the normal sequence of "pilot" to
> to "enterprise-wide". The organizations that fit this
> normally have highly structured approaches to content, authorization
> of content, tightly controlled output guidelines etc. I have
> doubt that DITA can be made reasonably simple for professional
> content developers.
It can, and has been, made simpler for many kinds
of content developer.
We had a case study within IBM of a group using Quark
working on short-term projects to create specialized
So I do think we have proof points outside the realm
content developers - the question is how to best apply
the lessons from
them to make it easy for others to follow.
> Implementing DITA in a learning context is highly
> While on the surface of it it would seem of high value for an
> institution to capture the value of enterprise-wide, single-source
> publishing, bu the reality is that the autonomy of individuals in
> the organization and the lack of professionalized content creation
> resources (in most cases) mean that DITA is often not a good fit.
There are many learning organizations that discourage
autonomy when it comes to content styling - I think
to tech comm organizations in that respect. I would
though that it's definitely easier to implement a
solution with a centralized organization.
> have been using alternative content formats in the education sector
> because they have been more successful, not because they are better,
> and sometimes because choice has been removed in the short term. In
> the medium and longer terms some of the issues will be the same but
> without the added richness of DITA inheritance. (I hope that
> additional efforts in the near future might bring some alignment
> with DITA where it makes sense.)
> From my experience the complexity issue comes down to a single statement:
> There is no suitably simple end-to-end process for non-technical,
> relatively autonomous content authors to achieve the single-source
> publishing objectives that are useful to them.
> If such use cases are not in scope for DITA then
> should be made and communicated. If they are, the gaps in the
> simplification of tools (end-to-end) at suitably low cost needs to
> be addressed.
Now I need to tease this out into two different sets
- what the standard can do
- what a tool must do
The standard can't deliver a solution, but we can
deliver a process.
What we could (conceivably) do, for DITA 1.3:
- define starting doctypes for the simple authoring
case (ie pre-constrain)
- define a simpler mechanism for simple specialization
On the processing front, I'm not sure what we on the
TC can do to simplify
- that's up to the vendors. The market has already
brought us a lot of
options, so maybe this is a specific requirement against
the DITA Open Toolkit?
> None of the points above argue that DITA itself is too complex. It
> needs to be complex to achieve the stated objectives. Very few
> people should be exposed to that complexity and they should all be
> techies who ensure that the system being used is *appropriately*
> simple for the content developers in their specific context.
> Areas where I believe DITA itself will face challenges stem from the
> 'dumb and light' topics with smart aggregations and those parts of
> DITA that are anachronistic and relate to its origins not its
> future. There will also be a need to change the approach to
> metadata and shift to a model where less metadata is embedded in
> individual topics to more associative model for metadata (maybe
> something that might also accommodate Contextualized Attention
I'm not familiar with this term, but DITA already
metadata being managed by the map.
>In the current model where large amounts of metadata
> embedded in topics there could easily be an accumulation of metadata
> as content is reused in different contexts and increasingly there
> will be rendering and functional issues arising from that metadata.
The current model allows metadata in both places,
and my rule of thumb
is to manage metadata at as high a level as possible
(but no higher).
We could easily create some starting doctypes, though,
(some) metadata to the map. I'm not sure that all
be map-managed though - the author element, and the
for example, are tied pretty closely to the topic.
> Also, content that is used in highly controlled environments and
> that requires tightly controlled authorization processes will fall
> foul of those processes if reuse in other contexts does not stricty
> adhere to the authorization process.
In general I'd say that we get in trouble when tools
store their own
metadata that cannot travel with the content into
Thanks for raising these concerns - I hope my contributions
in the spirit intended, which is to help shape the
concerns into specific
DITA 1.3 work items.
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]