I am still having problems with the semantics.
Here is why. According to common usage a task is a piece of work that gets
assigned to somebody (http://dictionary.reference.com/browse/task).
To accomplish a task, that person may decide to follow a procedure (http://dictionary.reference.com/browse/procedure).
This procedure is a process (http://dictionary.reference.com/browse/process)
that the person can perform. All tasks, except for impossible ones, have
one or more procedures that people can follow to achieve the desired results.
All procedures are processes that people follow to accomplish tasks. However,
not all processes are procedures; for example, photosynthesis is a process
and not a procedure.
I am not priggish enough to ask that we rename 'task' to 'procedure,' the
current semantics are close enough given the colloquial usage for task
among technical communicators. However, I would like to avoid contorting
DITA's semantics by suggesting that 'process' is somehow subordinate to
'task' when clearly it is the other way around. It might be convenient
to add process to generalized task, but the semantics would be counter
intuitive.
Regards,
Bob Thomas
President
Tagsmiths, LLC
+1 720 201 8260
--- On Sun, 11/16/08, SeicoDyne DITA <dita@seicodyne.ch>
wrote:
From: SeicoDyne DITA <dita@seicodyne.ch>
Subject: AW: [dita] Revised content model options for #12011 - Generic
Task Type
To: "'JoAnn Hackos'" <joann.hackos@comtech-serv.com>, "'Bob
Thomas'" <bob.thomas@tagsmiths.com>, "'Michael Priestley'"
<mpriestl@ca.ibm.com>
Cc: dita@lists.oasis-open.org
Date: Sunday, November 16, 2008, 1:31 PM
JoAnn, Bob,
As far as I remember, one of the
purposes of the new generic process element is to enable specializer to
create their own procedural specialization. The <process> element
offers full flexibility for specialization, steps has already limitations.
This ensures that specializer
will use <task> for any procedural specialized topics.
That was my understanding.
So I am a supporter of this proposal.
Best regards
Chris
SeicoDyne GmbH
Eichenstrasse 16
CH-6015 Reussbühl
Switzerland
Tel: +41 41 534 66 97
Mob: +41 78 790 66 97
Skype: seicodyne
www.seicodyne.com
christian.kravogel@seicodyne.com
Member of the DITA Technical Committee
Chairman of the DITA Machine Industry
Subcommittee
Von: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com]
Gesendet: Donnerstag, 13. November 2008 14:54
An: Bob Thomas; Michael Priestley
Cc: dita@lists.oasis-open.org
Betreff: RE: [dita] Revised content model options for #12011 - Generic
Task Type
Hi Bob,
I tend to agree with you. I cannot
find any rationale in the memos (so far) for the <process> alternative
in task. I can't think of what it's supposed to handle that cannot already
be handled by steps or steps-unordered. Haven't heard back from Alan Houser,
however, who originally proposed it.
Michael is also checking the email
archives.
I'd be in favor of your proposal
to chuck it at this point. I think it just creates confusion for authors.
Regards,
JoAnn
JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver CO 80215
303-232-7586
joann.hackos@comtech-serv.com
From: Bob Thomas [mailto:bob.thomas@tagsmiths.com]
Sent: Wednesday, November 12, 2008 1:02 PM
To: JoAnn Hackos; Michael Priestley
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] Revised content model options for #12011 - Generic
Task Type
Please pardon my intrusion (I'm a TC observer).
I have a couple of objections to adding 'process' as specified in #12011.
There really needs to be a rationale for this that includes the semantic
intent for 'process'. If allowing 'ol' and 'ul' inside of 'task' is the
only rationale, then you would be better off adding 'section' to 'taskbody'.
In any event, I would rather do neither.
My other objection is a bit more fundamental. In Information Mapping®,
process is considered to be an information type just like concept or task
(procedure). While I do not think that the TC necessarily needs to honor
that distinction, it ought not to lightly dismiss it. The notion of process
as an information type suggests that a section-level implementation of
'process' in DITA would be inappropriate. If the TC goes ahead and implements
'process', as proposed in #12011, it would preclude anybody else from creating
a topic-level specialization for process.
In the Information Mapping® compatible DTD that I worked on 10 years ago,
the content model for process was quite similar to the one for procedure
(task); the key difference being that a process had 'stage' elements rather
than 'step' elements.
Regards,
Bob Thomas
President
Tagsmiths, LLC
+1 720 201 8260
--- On Wed, 11/12/08, Michael Priestley <mpriestl@ca.ibm.com>
wrote:
From: Michael Priestley <mpriestl@ca.ibm.com>
Subject: RE: [dita] Revised content model options for #12011 - Generic
Task Type
To: "JoAnn Hackos" <joann.hackos@comtech-serv.com>
Cc: dita@lists.oasis-open.org
Date: Wednesday, November 12, 2008, 11:00 AM
Hi JoAnn,
The rationale below is to allow <ol> and <ul> into taskbody.
In other words, if someone wants to create a task with a simple <ol>
instead of the more prescriptive <steps>, the <process> element
allows them to do so.
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
| "JoAnn Hackos"
<joann.hackos@comtech-serv.com>
11/12/2008 12:06 PM
|
|
To
| Michael Priestley/Toronto/IBM@IBMCA,
<dita@lists.oasis-open.org>
|
|
cc
|
|
|
Subject
| RE: [dita] Revised content model options
for #12011 - Generic Task Type |
|
Hi Michael,
The email from Alan provides no rationale for the <process>, just
shows the syntax. Let me know if any of the minutes show the rationale
or any examples. I’ve written Alan but haven’t received a response as
yet.
JoAnn
JoAnn Hackos PhD
President
Comtech Services, Inc.
joann.hackos@comtech-serv.com
Skype joannhackos
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, November 11, 2008 9:22 AM
To: dita@lists.oasis-open.org
Subject: Fw: [dita] Revised content model options for #12011 - Generic
Task Type
Re discussion today about elements in general task - found this, which
provides a bit of background on process - will check meeting minutes from
around this time.
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
----- Forwarded by Michael Priestley/Toronto/IBM on 11/11/2008 11:21 AM
-----
| Alan Houser <arh@groupwellesley.com>
12/11/2007 11:01 AM
|
|
To
| dita@lists.oasis-open.org
|
|
cc
|
|
|
Subject
| [dita] Revised content model options
for #12011 - Generic Task Type |
|
I submit this message for possible discussion at today's
(11-December-2007) DITA TC meeting. Below is a summary of proposed
content models that will support proposal #12011 -- Generic Task Type.
These content models are the result of recent discussion on the DITA TC
list.
-Alan
-------------
Summary:
- Optional, repeatable <note> allowed before <cmd>
- <taskbody> allows only a single <steps> element
- New <process> element to permit <ol>/<ul> constructions
in <taskbody>
Proposed content models:
taskbody:
(prereq?,
context?,
(steps | steps-unordered | process),
result?,
example?,
postreq?)
(Issue: allow <section> before and after <steps>?)
steps/steps-unordered:
Support <section> between steps:
(section?, step)+
step:
Support optional, repeatable <note> before cmd:
(note*,
cmd,
(info | substeps | tutorialinfo | stepxmp | choicetable | choices)*,
stepresult?)
Issue: allow <itemgroup> in <step>?
process:
(section?, (ol | ul))+
Issue: this would allow multiple ol/ul elements.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|
|