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: [no subject]

If DITA adds support for extended narrative with division, statements a=
those benefits would have to be qualified with caveats and provisos.
Wouldn't that hurt the appeal of DITA?

I know of adopters who moved their narrative content to DITA, produced
their existing outputs, and later reworked the narrative content to fit=
topic paradigm.  The topic markup was awkward for their narrative conte=
-- but that was good.  They _wanted_ to get to the topic paradigm
(otherwise, why migrate in the first place?). The awkwardness encourage=
rework, which they wanted to do because they wanted the benefits.  The
requirement during the first phase of the migration was to continue to =
existing commitments during the transition but not to provide good
accomodations for narrative content.

If we could get users to the topic paradigm more quickly so that they s=
real value faster, wouldn't that provide greater stimulus for adoption?=

That is, I'm wondering whether we might look for ways to

*  Manage the rework for the topic paradigm.
*  Improve interoperability between DITA and other, narrative markups s=
people can have pragmatic success during a phased adoption.

Java offers an analogy.  Undoubtedly, the Java cultivators considered
whether they should add support for procedural programming.  They decid=
instead to keep a strong object orientation, and, ultimately, Java was =
successful because of it.

On the particular use case, could the user's requirements for grouping =
met through output processing?

Or, could the grouping be providing through a <topichead> in the DITA m=
The SCORM learning standard takes a similar approach. A SCO (Shareable
Content Object) is a completely standalone content object -- SCORM requ=
that navigation be maintained outside of the SCO to maximize reuse.
Grouping is provided by heading items within the SCORM manifest, which
resembles the DITA map in some respects by providing organization.

Or, would DITA benefit from a grouping construct for subtopics?  We mig=
make the <dita> element a specializable alternative to nested topics.  =
would parallel the nestable <linkpool> / <linkgroup> structure.  That i=
you could have specializations with a structure like:

<topic ...>
    <topic ...> ... </topic>
        <topic ...> ... </topic>
        ... nested topic or dita list ...
    ... other topic or dita list ...

While I'm delighted and encouraged by the positive comments on constrai=
my thought is that contraints offer fine tuning for a shared understand=
of content expressed by the specialization.  The reason for the hesitat=
about the recursive <section> element isn't because of structural issue=
but, instead, because recursive sections seem to belong to a fundamenta=
different model of content (divided narrative).

Hoping that's interesting,

Erik Hennum

Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

<p>Hi, DITA Cultivators:<br>
I'd like to second the statement that JoAnn made earlier in this thread=
<tt>&quot;JoAnn Hackos&quot; &lt;joann.hackos@comtech-serv.com&gt; wrot=
e on 10/28/2005 09:52:10 AM:<br>
&gt; One of the goals of instituting a new way of authoring and often a=
&gt; content management system is to begin with sound content. It would=
 be a<br>
&gt; better decision to leave legacy content out of the new system. You=
&gt; refer to it, include it in maps, but otherwise acknowledge that it=
&gt; not meet the new standards. <br>
&gt; <br>
&gt; If you spend much time and energy simply converting legacy content=
&gt; does not comply with a topic-based model, what have you accomplish=
We all want to increase adoption of DITA.  What's driving that adoption=
?  What's making people consider DITA?<br>

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