I agree that a process is not a
child of <task>, an alternative to (steps|steps-unordered), either
semantically or structurally.
If one of the objectives is to
provide a base element for specializing procedural elements as alternatives to
<task> then <process> should be specialized from <topic> and
<task> should be specialized from <process>. This wouldn't interfere
overmuch with existing investments in specializations from
<task>.
Aside from being a basis for
specialization, a more generic topic type is a boon for conversion of legacy
content. It is much easier in XML than in legacy formats to remediate
inconsistencies and migrate content to a more restrictive structure, not
least (but hardly only) because authors are better able to understand the
motivation and direction.
Many users would welcome a more
generic procedural element that permits more than one prerequisite and more than
one section of contextual information. If there's more than one, the grouping of
these under common headings like "Prerequisites" and "Before You
Begin" would be a task for rendering. Again, this could facilitate
migration to more focused minimalist content, where the complexity is due to
supporting diverse platforms or the like.
Maybe generalizing from
taskbody (prereq?, context?, (steps|steps-unordered)?, result?,
example?, postreq?)
might look something
like
procbody (prereq*, context*, (ol|ul)?, result*, example*, postreq*)
as an intermediate structure,
generalizing thence to
body (section|ol|ul|postreq|...)*
I wonder if there's
some way to admit alternative result-example-postreq paths for the
user. Grasping at straws
...
procbody (prereq*, context*, (ol|ul)?, (result?, example?, postreq?)*)
/Bruce
From: Bob Thomas
[mailto:]
Sent: Monday, November 17, 2008
10:29 AM
To:
Subject: Re: AW:
[dita] Revised content model options for #12011 - Generic Task
Type
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
<> wrote:
From:
SeicoDyne DITA <>
Subject: AW: [dita]
Revised content model options for #12011 - Generic Task Type
To:
"'JoAnn Hackos'" <>, "'Bob Thomas'"
<>, "'Michael Priestley'"
<>
Cc:
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
Member of the DITA
Technical Committee
Chairman of the DITA
Machine Industry Subcommittee
Von: JoAnn Hackos
[mailto:]
Gesendet:
Donnerstag, 13. November 2008 14:54
An: Bob Thomas; Michael
Priestley
Cc:
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
From: Bob Thomas
[mailto:]
Sent: Wednesday, November
12, 2008 1:02 PM
To: JoAnn Hackos; Michael
Priestley
Cc:
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
<> wrote:
From:
Michael Priestley <>
Subject: RE:
[dita] Revised content model options for #12011 - Generic Task
Type
To: "JoAnn Hackos"
<>
Cc:
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
http://dita.xml.org/blog/25
"JoAnn
Hackos" <>
11/12/2008 12:06
PM
To
Michael
Priestley/Toronto/IBM@IBMCA,
<>
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.
Skype
joannhackos
From: Michael
Priestley [mailto:]
Sent:
Tuesday, November 11, 2008 9:22 AM
To:
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
http://dita.xml.org/blog/25
----- Forwarded by Michael
Priestley/Toronto/IBM on 11/11/2008 11:21 AM -----
Alan
Houser <>
12/11/2007 11:01
AM
To
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
