[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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]