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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Stefan Seefeld <seefeld@sympatico.ca> was heard to say:
| 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.

The initial proposal and motivations are archived:

  http://lists.oasis-open.org/archives/docbook/200302/msg00050.html

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

I'm uncomfortable with prerequisites. Adding post conditions would
push us even farther towards modeling which I try very, very hard to
avoid. All of our existing experience with modeling (msgset and
funcsynopsis, to name the two most obvious examples) suggests that
it's difficult to invent, hard to maintain, and usually not quite
exactly right for most users.

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

Taskinfo would include a leading "blockinfo" meta, though I failed to
note that. Unlike traditional meta information, tasksummary and
taskprerequisites are always displayed. They straddle the line between
metadata and modeling, I guess.

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@nwalsh.com>      | It is so comic to hear oneself
http://www.oasis-open.org/docbook/ | called old, even at ninety I
Chair, DocBook Technical Committee | suppose.--Alice James
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+ylVSOyltUcwYWjsRAhBBAJ46ck2aSsX7z+6S+jS8QhR14D+AWgCfbShb
Jy9b4qmq9DdZYPh69I/MzAU=
=om3O
-----END PGP SIGNATURE-----


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