[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Nested Sections
In a previous discussion, Michael asked why nest sections when you can nest topics. My opinion is as follows. If topic-based authoring means anythng then it means that you don't arbitrarily shred everything with a title into a topic. Topics are things that have meaning ON THEIR OWN. A section that is inherently embedded in its context should not become a topic to fulfill an arbitrary requirement of a framework. Our customer is in the e-learning domain. He has "questions" that are directly related to the surrounding content. The questions are richly structured like sections. The set of questions needs a wrapper element to supply a title and organize the authoring experience. Reusable Learning Object Information Information Questions Question title Para Para List Para Question Para List Table Para Question Para Table Para So in this case I'm not looking for infinitely nested sections. I just need two levels hard-coded into the specialized topic type. I don't think that this design is controversial, innovative or unique. If I turn "Question" into a topic type then I also need to turn "Questions" into a topic type and its only purpose is to wrap up other topics. Plus I cannot default the title. Plus there are content management and policy implications, because the customer wants all topics to be content managed objects and all content managed objects to be topics (in the sense of being inherently designed for reuse). (which seems quite reasonable to me) My other use case is wrapping up multiple elements to supply a single conditional attribute on them. Para Section audience="expert" Para Para Section product="" Para Para Para Para I would also use this mechanism to conref more than one element at a time. (I personally prefer this to a range-start/range-end model). > -----Original Message----- > From: Eliot Kimber [mailto:ekimber@innodata-isogen.com] > Sent: Wednesday, November 02, 2005 12:00 PM > To: Michael Priestley > Cc: Paul Prescod; dond@us.ibm.com; ehennum@us.ibm.com; Jerry > Silver; joann.hackos@comtech-serv.com > Subject: Re: [dita] Thoughts On Sections > > Michael Priestley wrote: > > > > What is it about nested sections in particular that makes them more > > suitable for your purposes than nested topics? > > The distinction is that the sections do not meet the > requirements for topics, namely that they are not suitable > for standalone use, that they cannot stand by themselves. > > This is not just a semantic distinction for information > content but could have content management implications. For > example, a likely content management scenario is that all > topics are managed as separate storage objects. Using topics > simply to get the effect of nested sections would interfere > with this as it would require either additional business > rules based on something like an outputclass attribute value > or other distinguishing metadata value or some other, > non-DITA-defined, way of distinguishing *real* topics (those > that are inherently re-usable) from "section" topics (those > that are not inherently re-usable and that should not be made > available for re-use by default). > > Again, I agree with Paul that in a standard as general as > DITA it is simply inappropriate to impose this degree policy > constraint--it is imposing an editorial policy that is not > universally accepted. > > And I do not agree that nested sections some how destroy the > essential nature of DITA. It simply requires, as DITA already > does, that you think clearly about what are topics and what > are not and what your editorial policies for them are. > > And as there are ample mechanisms for imposing constraints > (either through specialization or through the new constraint > mechanism) anyone who feels strongly that sections should not > nest can impose that constraint. > > In any application standard there is great temptation to > impose policy decisions. In standards with very specific uses > that can be appropriate, but the more general a standard is > the less appropriate it is. This is something we struggled > with in HyTime. > > My personal feeling is that at the lowest level an > architecture like DITA should impose almost no constraints, > serving primarily to establish the names of things with only > those context constraints needed to have a sensible base, > with all other constraints being imposed at higher levels of > specialization. This helps ensure the widest applicability in > the future and avoids unnecessary constraints. > > Cheers, > > E. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]