Re: [dita] Groups - The Case for Aggregated Editing (The Case forAggregated Editing.doc) uploaded

[Eliot Kimber <ekimber@reallysi.com>]

On 3/10/09 2:23 PM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:

> Is the following contradiction resolvable?
> 
> Eliot:
>> *all* users of DITA should ... as a matter of standard
>> practice ... [be] creating local shell DTDs as the
>> *first step* of any production use of DITA.
> 
> Tim:
>> Why should we force users to design these shell DTDs?
> 
> Is it a matter of different perceptions of who the DITA adopters are,
> and their expected skill & knowledge level? (With the attendant
> usability/adoption questions.)

I think there's a disconnect here: adopters of DITA are not *individuals*
(at least not in the context we are discussing here), they are
*enterprises*.

In that context, it is no more unreasonable to expect an *enterprise*
provide appropriate support for that enterprise's users of DITA-based
documentation systems then it is to expect that enterprise to support the
time keeping system or any other information support system.

If the expectation is that *individuals* can for example buy an
off-the-shelf product that provides DITA-based authoring that would be
expected to be used in the context of a larger enterprise's documentation
environment, that simply seems naïve.

Note too that I am not suggesting that individual *writers* create shell
DTDs, I suggesting that the information system support groups within
enterprises do that.

By the same token, the Business Documents SC can of course provide a set of
shells that provide appropriate defaults for topic nesting to address
exactly this concern.
 
> Is CM the only motivation & usefulness for ditabase, as Eliot suggests
> (below)? (CMS/elements vs. filesystem/documents.) Is there a reason that
> ditabase should not be considered an out-of-the-box shell DTD?

Note that I said nothing about ditabase having anything to do with CMS
systems--ditabase is a convenience for legacy conversion (where it is
convenient to convert content to topics without initially breaking the
topics into separate documents that reflect some considered topic nesting
policy) and for the specific case I mentioned: filesystem-based management
of multiple topics in a single storage object (because access control is
applied to storage objects (files) not elements.

In a CMS one would normally expect access control to be applied to elements
and/or for the composition of topics into (apparent) storage objects to be
transparent, so in that context there should be no need for anything like
ditabase.

Ditabase is *absolutely not needed* to enable authoring of nested topics of
any type, as I've already explained.
 
>> CMS systems, ... will
>> (must) have the infrastructure [for] e.g., generating a
>> single-instance document for editing and then breaking it
>> back up into individual topics.
> 
> And then using the single-instance wrapper to persist that particular
> higher-level organization of the topics?
> 
> I like saying the CMS vendors have the responsibility to do all the
> magic. I don't like depending on them to do it. As an alternative would
> it be easier for them to support round-tripping between a map (for
> publishing and to persist the higher-level organization into documents)
> and ditabase (or a wrapper using a custom shell DTD) for authoring? We
> have talked about the issue of persisting map-only attributes into a
> ditabase document so they can be picked up on the return trip.

I think this is getting down into the weeds of implementation--there are too
many variables to have a very productive general discussion.

I don't see a general reason to not store the topics their primary (or
often, only) storage organization as nested topics without requiring that
there be a corresponding map that reflects the same hierarchy. That just
adds complexity to no obvious purpose. You don't need ditabase for that,
only an appropriately-configured shell for the root topic (which might, in
the most general case, be as relaxed as ditabase).

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>