My problems with 'process' are rooted in the semantics of 'generic task'. A task is just one type of action-sequence. Instead, I prefer to think about the proposed 'generic task' as an abstract action topic; concrete implementations of which would be types such as task, process, and performance-oriented scenario. Like topic, best practices would advise against using the abstract-action topic for writing content.
A simple table construct could also be introduced to abstract-action to support checklists and worksheets. In such a construct, cells in column 1 could be called 'action' with 'action' containing a 'cmd' element. Column 2 would be white-space for the user to check-off upon completion of the action.
Bob Thomas Tagsmiths, LLC +1 720 201 8260
--- On Thu, 11/13/08, Alan Houser
<arh@groupwellesley.com> wrote:
From: Alan Houser <arh@groupwellesley.com> Subject: Re: [dita] Revised content model options for #12011 - Generic Task Type To: "JoAnn Hackos" <joann.hackos@comtech-serv.com> Cc: "Bob Thomas" <bob.thomas@tagsmiths.com>, "Michael Priestley" <mpriestl@ca.ibm.com>, dita@lists.oasis-open.org Date: Thursday, November 13, 2008, 7:39 AM
Hi Folks,
Apologies for being off the radar recently.
The <process> element was designed to accommodate at least two
use cases:
- Those who find the current <step> content model to be to
unnecessarily complex or constraining (particularly the required
<cmd> element).
- Those who wish to represent tasks that don't fit into the
declarative, single-procedure model that the current <task>
presumes (e.g., trouble-shooting procedures, tasks with branches,
if-then scenarios).
I acknowledge the name conflict issue with a future <process>
specialization. However, I would object to removing this feature, or
(at minimum) support for these use cases, from DITA 1.2. It was vetted
and approved by the TC.
-Alan
---
Alan Houser, President Group Wellesley, Inc. 412-363-3481 www.groupwellesley.com
JoAnn Hackos wrote:
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
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
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
-----
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
|
|