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] Groups - The Case for Aggregated Editing (The Case for Aggregated Editing.doc) uploaded


This perspective is exactly what has to change if we wish to see DITA see
broad adoption in the world of business narrative documents.

Users *do not* have to create local shells (for better or worse, we made no
changes to the default ones for Thermo LAI user guides, precisely because it
was so difficult to do so), not do they *want* to. They want to create
*content*, first and formost; everything else is a barrier to achieving that
desire, a barrier which will be ignored, resisted, or circumvented unless
they see a very compelling and immediate benefit to dealing with it. Having
to deal with DTDs and content management systems are enormous barriers to
broad adoption. Suppose a user of Word had been *required* to design a
template before they could create a document. Do you think that would have
encouraged broad use of Word?

I'm sorry if my tone is a little, how should I say, unmodulated, but I'm
passionate about this subject. Bringing XML to the world of business
narrative information has enormous potential benefits, and DITA is the best
candidate. But it has to compete with technologies that are much more
accessible to most users. The world has seen many standards designed by
specialists that ended up being of no use to anyone except the specialists:
Dewey Decimal System, OSI networking protocols, Esperanto... I don't want to
see DITA suffer the same fate. Standards that get adopted are simple, easy
to implement, and provide relatively immediate benefits -- HTML, TCP/IP,
SMTP -- and even they can take many years to achieve widespread use. In the
world of structured business narrative information, it isn't DITA or
sophisticated content management systems people are rushing to use today,
it's what looks easy and familiar: HTML, wikis, folksonomies, SharePoint...

We definitely need tools that make it easy for someone to rapidly design,
deploy, and manage DITA compliant DTDs without having to hire an information
architect to do so. Those tools have to provide element and attribute name
aliasing, easy subsetting of the DITA vocabulary (aka constraints), embedded
guidance for authors, and easy styling of outputs. Those tools don't exist
yet. Having the content management systems provide aggregation of topics for
editing and delivery and automated disaggregation is fine, but only the big
organizations and/or those with critical processes that depend on rigidly
structured narrative information will see that as providing a compelling,
immediate, and significant return on investment.

Any change we can reasonably make to the DITA standard to make adoption
easier should be seriously considered.

Regards,
Tim.

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Tuesday, March 10, 2009 1:18 PM
To: tgrantham@timgrantham.com; manning@rockley.com; dita
Subject: Re: [dita] Groups - The Case for Aggregated Editing (The Case for
Aggregated Editing.doc) uploaded

On 3/10/09 9:56 AM, "Tim Grantham" <tgrantham@timgrantham.com> wrote:

> Hi, Eliot.
> 
> The current DTD schemas (other than ditabase) allow only aggregation 
> and nesting of same-type topics: i.e. tasks within tasks, concepts 
> with concepts, etc. Hence, the need to use ditabase for aggregration 
> of topics of mixed types. How would one use a shell DTD to allow some 
> arbitrary nesting of mixed topic types in a document? And, perhaps 
> more importantly, why should we force users to design these shell DTDs?

The base shells are simply conveniences and reflect a useful default. They
in no way represent a *normative* restriction.

Every topic type can be configured to allow whatever topic types it wants as
its children, as every topic type has it's own type-specific parameter
entity that defines what subtopics it allows (if any).

Users *already have to* create local shells simply because the if they
*ever* want to use any new specialization or *not use* any module included
by default, they *must* create local shells. Since it is a certainly that
*any* production use of DITA will need to do one or both of these things at
some point, it only makes sense to create local shells as the *first act* of
implementing a production use of DITA, even if those shells are only copies
of the TC-provided shells.

Doing this prevents having to change the DTD URI/Public ID or schema
location on *every topic* in your data set when you do realize you need to
change your configurations. That would be incredibly disruptive and in some
case prohibitively expensive.

So prevent it by not allowing the problem to occur by creating local shells
first thing.

This is how DITA works. Everyone who uses DITA for production *must*
understand this. If you don't do this it is only a matter of time before
having not done it will bite you, possibly quite hard.

DITA, like any powerful tool, requires some care and thought to how it is
applied to specific situations. The requirement to create local shells is
absolutely no different from the need to set up local components for any
other non-trivial information management system or technology.

Cheers,

Eliot

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals |
Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com>  |
http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com
<http://www.rsuitecms.com> 





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