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] appropriateness of <dita> root element

I don't really disagree with what Alan wrote below.  There are cases where using ditabases or nesting topics make sense. 


The problem I've seen is that users and organizations that are new to DITA often choose to use ditabases or deeply nested topics for what I consider the wrong reasons.  Often the reason is that ditabases and nested topics are "easy" since they are similar to what they have been doing in Word or in docbook or in some other “traditional” tool. So they adopt a practice of using a ditabase or deeply nested topics without having to confront the issue of possibly needing to rewrite some of their content into a topic oriented style or to sort out mixed content within the same topic (the differences between concept, reference, and task). And they duck having to learn how to really use and benefit from maps.


The challenge for us is how to find a way to explain best practices as compared with what is simply allowed.  And we have to do this without confusing new users who may already be overwhelmed with too much new information as they are getting started.


This makes me think that new users should be encouraged to start off using maps and avoid using ditabases or nested topics. As they gain more experience they can choose to use ditabases or nested topics. 


For similar reasons I think new users should initially avoid the use of conref in maps and possibly conref entirely. Later as they gain experience they can choose to add the use of conref in topics if they wish.  And later still and with even more caution they can choose to use conref in maps.




> -----Original Message-----

> From: Alan Houser [mailto:arh@groupwellesley.com]

> Sent: Tuesday, March 25, 2008 2:38 PM

> To: dita@lists.oasis-open.org

> Subject: [dita] appropriateness of <dita> root element


> I wanted to add a voice to the discussion towards the end of today's TC

> call about the effectiveness and appropriateness of the "ditabase"

> content model and approach to DITA adoption.


> Organizations deploy DITA for a variety of reasons. This may or may not

> include a need for topic-level content reuse. Not every organization

> will benefit from all of the capabilities of DITA.


> In deployments where topic-level content reuse was _not_ a driving

> factor, I've seen organizations struggle to map legacy content to DITA

> topic types, without a corresponding benefit. (Surely some benefit, but

> not clearly justified by the required effort to do so). I've also seen

> organizations compress migration time from years to months by mapping

> legacy content to the generic DITA "topic" type in nested structures.


> I'm troubled by the characterization that file structures which contain

> multiple nested topics are "not much better than Word."  The ditabase

> structure allows organizations to achieve multi-channel publishing,

> metadata- and output-based content filtering, and slashing of

> localizations costs through automated publishing, while minimizing the

> pain of legacy migration. As a TC, I think we need to take care not to

> belittle or discourage these benefits or this approach to migration in

> particular circumstances. Otherwise, we risk sending the message

> (implicitly or explicitly) that DITA is not appropriate except when

> substantial topic-level reuse is a requirement.


> -Alan


> --

> Alan Houser, President

> Group Wellesley, Inc.

> 412-363-3481

> www.groupwellesley.com



> ---------------------------------------------------------------------

> To unsubscribe from this mail list, you must leave the OASIS TC that

> generates this mail.  You may a link to this group and all your TCs in


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