"Grosso, Paul" <[email protected]> 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 <[email protected]> | 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)
pgpZMmATwTb17.pgp
Description: PGP signature
