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


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

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

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

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

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