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
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)

PGP signature



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