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