OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[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

> 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

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,

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)

PGP signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]