[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [docbook] Re: (don't) Allow Task as a sibling of sections
I'm going to have to miss the call today, but I would vote against adding task at all to DocBook. paul > -----Original Message----- > From: Norman Walsh [mailto:ndw@nwalsh.com] > Sent: Wednesday, 2009 January 21 9:35 > To: docbook@lists.oasis-open.org > Subject: [docbook] Re: (don't) Allow Task as a sibling of sections > > "Grosso, Paul" <pgrosso@ptc.com> writes: > > >> DocBook Technical Committee Meeting Agenda: 21 January 2009 > >> ============================================================= > > > >> RFEs to be considered > >> 1097183 Allow Task as a sibling of sections > > > > What is the latest thinking on this? > > > > I know we've discussed it in the past, and I know > > I've said that I don't see the point of trying to > > dita-ize DocBook. Sections are fine things to have > > in DocBook--why do we need a sibling division called > > task? That just makes a mess of the hierarchy. > > (What follows is my personal opinion, NOT the opinion of the Chair of > the TC) > > I think that RFE, and the others related to topics, have all just been > left on our list because they're part of that nexus of task-related > issues that we decided to tackle post-5.0. > > I'm really ambivilant about tasks. > > On the one hand, the DITA cheerleaders argue that they're a > fundamental unit of modern, technical documentation. Setting aside my > reservations about DITA, I hate to see DocBook losing mind share > because it doesn't compete feature-for-feature with DITA and it's > marketing machine. > > On the other hand, our existing task element seems over-engineered. I > worry that it's too prescriptive and doesn't satisfy the needs of a > topic-based documentation approach. I look at task and I think, "oh, > that's msgset's less complicated cousin." > > So, it seems like there's a fair bit of pressure to make some > topic-based structures at another level of hierarchy. But proposals to > do so always look isomorphic to sections, or nearly isomorphic, to my > eyes. > > > Since this RFE is still on our list, I assume we > > didn't have consensus to just say no, so can someone > > outline the arguments for why we'd want to do this > > and how it can be done without trashing the hierarchy > > and unnecessarily complicating both the markup and the > > processing of such documents? > > I find the idea of mixing tasks and sections as siblings utterly > repulsive. > > I'm not opposed to a task element of some sort (though I see its > merits as almost entirely political/psychological and I prefer to make > markup decisions on techical merits). > > I could even be persuaded (probably) that tasks should be allowed as > an alternative to some existing hierarchies (a book/part/chapter that > has *only* task children, for example). > > But mixing tasks and sections as siblings makes a mockery of the > structure of the document. I don't see any rational way to explain the > processing expectations of the elements in such a document. At worst, > there isn't any rational explanation, at best, the explanation is > hideously complex. > > At the end of the day, I'd be a lot happier about tasks if someone > could explain technically how they're not just a funny name for > section (or simplesect, perhaps). > > Maybe, just maybe, the funny name has such important political and > psychological overtones that it's important to have it. > > Be seeing you, > norm > > -- > Norman Walsh <ndw@nwalsh.com> | A hen is only an egg's way of > http://www.oasis-open.org/docbook/ | making another > egg.--Samuel Butler > Chair, DocBook Technical Committee | (II) >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]