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.)
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?
> 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.
/B
> -----Original Message-----
> From: Tim Grantham [mailto:]
> Sent: Tuesday, March 10, 2009 11:57 AM
> To: 'Eliot Kimber'; ; 'dita'
> Subject: RE: [dita] Groups - The Case for Aggregated Editing
> (The Case for Aggregated Editing.doc) uploaded
>
> 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?
>
> Regards,
> Tim
>
>
> -----Original Message-----
> From: Eliot Kimber [mailto:]
> Sent: Tuesday, March 10, 2009 11:35 AM
> To: ; dita
> Subject: Re: [dita] Groups - The Case for Aggregated Editing
> (The Case for Aggregated Editing.doc) uploaded
>
> On 3/10/09 7:55 AM, "" <> wrote:
>
> > Here is the paper on Aggregated Editing for Electronic Business
> > Documents
> discussed in last week's meeting. We are seeking your feedback,
> > concerns,
> issues, etc.
> >
> > Would it be possible to get your feedback by the end of
> March, the 31st?
>
> While I understand the problem this document presents (the
> general need to be able to author DITA-based documents as
> collections of topics, something most of my DITA-using
> clients face) I don't entirely understand either the barriers
> presented or the solution proposed. I think the document as
> written reflects a common misunderstanding of how DITA works.
>
> In short, there is *nothing* in the DITA standard that
> prevents authoring DITA-based documents as sets of nested
> topics. There is not even a requirement to use maps. In
> addition, this ability does *not* require the use of the
> ditabase document type to do this sort of aggregate editing.
> [In fact, ditabase should only be used for authoring in the
> very narrow usecase of needing to manage a number of
> otherwise unrelated topics as a single XML instance in data
> management environments where access control is applied to
> documents and not elements (e.g., filesystem-based data).]
>
> By the same token, the storage organization of topics *in no
> way* prevents the individual re-use of any topic by any map.
>
> Therefore, I don't see that there is a need to modify the
> DITA standard *in any way* to enable the type of editing that
> is needed by business documents (and by many other types of
> non-techdoc documents).
>
> All that is needed is appropriate shell DTDs that allow
> whatever combination of topic types is appropriate for a
> particular community of use.
>
> For example, irrespective of any specializations it might
> need (and it does absolutely need some), the Business
> Document subcommittee could usefully provide, as a
> convenience, shell DTDs that enable exactly the sort of topic
> nesting that is appropriate for those documents (doing what
> *all* users of DITA should do as a matter of standard
> practice, namely creating local shell DTDs as the *first
> step* of any production use of DITA).
>
> But note that, just like the base DITA shells are in no way
> normative or mandatory, such shells would be a convenience only.
>
> I do agree that it would be a benefit to the community if
> editors allowed the composite editing of topics otherwise
> organized only by maps. But I see that more as a function of
> CMS systems, which have the task of understanding the
> relationships among the components they manage and will
> (must) have the infrastructure to manipulate data as it goes
> in and comes out of the CMS, e.g., generating a
> single-instance document for editing and then breaking it
> back up into individual topics. I'm not sure its appropriate
> to expect editors to provide that sort of functionality, at
> least not entirely on their own.
>
> Cheers,
>
> Eliot
>
>
> ----
> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
> email: <mailto:>
> 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>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS
> TC that generates this mail. Follow this link to all your
> TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS
> TC that generates this mail. Follow this link to all your
> TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php
>
>
