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: [docbook] Task Markup (delinquent action item)

Norman Walsh wrote:

> We propose that a task consist of:
>  title
>  tasksummary?
>  taskprerequisites?
>  procedure
>  example*
>  taskrelated
> The tasksummary, taskprerequisites, and taskrelated are all wrappers
> around component.mix (think para+).
> The task element would become part of compound.class which would allow
> it to appear anywhere that procedure appears now.

I don't remember in detail in what context 'tasks' were first suggested,
though that may well be an advantage, as I can think of different places
where 'task' could be used.

Wouldn't it make sense to allow for 'postconditions' ? So if 'task'
describes homeworks or other assignments, that would express the 
teacher's expectations in terms of results (as opposed to the 
'procedure' that is already there). If 'task' is an activity
for example in a software development process, 'postcondition' could
be a milestone with a certain set of products/results.
May be there are better terms than 'postcondition', but it is somewhat
symmetrical to 'prerequisites', which made me first think of it.

Also, 'summary' and 'prerequisites' sound like metadata. Wouldn't it
make sense to group them into a 'taskinfo' element ? (and then allow
other optional elements such as 'author' similar to articleinfo,
sectioninfo, etc. ?)


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