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

[Michael Priestley <mpriestl@ca.ibm.com>]

Hi Allyn,

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 
> DITA.  

It may depend on how you define significant, and also
how well-publicized 
the case studies are. There are plenty of organizations
at 
http://dita.xml.org/book/list-of-organizations-using-dita
using DITA for training materials, and at least one
university press 
publically using DITA for publishing (I suspect there
are other 
publishers using DITA - Eliot may be able to say more).

>The experiences I have had are consistent with
previous 
> 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
general.
DITA is decidedly NOT complex for people using custom
doctypes that match
their needs. (Or whose needs match the out-of-the-box
doctypes).

And why would content developers ever care about inheritance?
As others 
have noted, car engines can be complex without intimidating
drivers.

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
of this
> is hampered, I believe, by individual topics being overly heavy in
> metadata and "smarts" that require more detailed knowledge
if you 
> 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
application, why
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.
(Do-able since
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
this
> to sink in.  For use cases where users in the same organization
are 
> 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
get 
> 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 
FrameMaker. 

So while I think there is a tradeoff between robust
repeatability
and ease of one-off customization, there are tools
available at 
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.
We
> 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
correct, 
> 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,
particularly
in tech comm organizations, with only processing customizations.

And there are an increasing number of out-of-the-box
end-to-end options
aimed at the starter or standalone market, which is
nice to see.

> Organizations that "get it" will not have a problem in making
that 
> investment (probably in the normal sequence of "pilot" to
"limited" 
> to "enterprise-wide".  The organizations that fit this
profile 
> normally have highly structured approaches to content, authorization
> of content, tightly controlled output guidelines etc.  I have
no 
> 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
for engineers
working on short-term projects to create specialized
DITA content.

So I do think we have proof points outside the realm
of professional
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
problematic.  
> 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
author
autonomy when it comes to content styling - I think
very similar 
to tech comm organizations in that respect. I would
agree
though that it's definitely easier to implement a
centralized 
solution with a centralized organization.

> I
> 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
some 
> 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
the distinction 
> 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
of requirements: 
- 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
cases

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.

Absolutely agreed.

> 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 
> Metadata). 

I'm not familiar with this term, but DITA already
accomodates all
metadata being managed by the map.

>In the current model where large amounts of metadata
are 
> 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,
that limit 
(some) metadata to the map. I'm not sure that all
metadata should 
be map-managed though - the author element, and the
keywords element
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
other systems.

Thanks for raising these concerns - I hope my contributions
are taken 
in the spirit intended, which is to help shape the
concerns into specific
DITA 1.3 work items.

Michael Priestley