[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= bout 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= the topic paradigm. The topic markup was awkward for their narrative conte= nt -- but that was good. They _wanted_ to get to the topic paradigm (otherwise, why migrate in the first place?). The awkwardness encourage= d rework, which they wanted to do because they wanted the benefits. The requirement during the first phase of the migration was to continue to = meet 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= aw 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= o 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= ed instead to keep a strong object orientation, and, ultimately, Java was = more successful because of it. On the particular use case, could the user's requirements for grouping = be met through output processing? Or, could the grouping be providing through a <topichead> in the DITA m= ap. The SCORM learning standard takes a similar approach. A SCO (Shareable Content Object) is a completely standalone content object -- SCORM requ= ires 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= ht make the <dita> element a specializable alternative to nested topics. = That would parallel the nestable <linkpool> / <linkgroup> structure. That i= s, you could have specializations with a structure like: <topic ...> <title>...</title> <body> ... </body> <topic ...> ... </topic> <dita> <topic ...> ... </topic> ... nested topic or dita list ... </dita> ... other topic or dita list ... </topic> While I'm delighted and encouraged by the positive comments on constrai= nts, my thought is that contraints offer fine tuning for a shared understand= ing of content expressed by the specialization. The reason for the hesitat= ion about the recursive <section> element isn't because of structural issue= s but, instead, because recursive sections seem to belong to a fundamenta= lly different model of content (divided narrative). Hoping that's interesting, Erik Hennum ehennum@us.ibm.com= --0__=07BBFA3DDFEC33908f9e8a93df938690918c07BBFA3DDFEC3390 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <p>Hi, DITA Cultivators:<br> <br> I'd like to second the statement that JoAnn made earlier in this thread= :<br> <br> <tt>"JoAnn Hackos" <joann.hackos@comtech-serv.com> wrot= e on 10/28/2005 09:52:10 AM:<br> <br> > One of the goals of instituting a new way of authoring and often a= new<br> > content management system is to begin with sound content. It would= be a<br> > better decision to leave legacy content out of the new system. You= can<br> > refer to it, include it in maps, but otherwise acknowledge that it= does<br> > not meet the new standards. <br> > <br> > If you spend much time and energy simply converting legacy content= that<br> > does not comply with a topic-based model, what have you accomplish= ed?</tt><br> <br> We all want to increase adoption of DITA. What's driving that adoption= ? What's making people consider DITA?<br> <br>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]