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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

[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.


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