OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

Subject: RE: AW: [dita] Revised content model options for #12011 - Generic Task Type

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

From: Bob Thomas [mailto:bob.thomas@tagsmiths.com]
Sent: Monday, November 17, 2008 10:29 AM
To: dita@lists.oasis-open.org
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.


Bob Thomas
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


SeicoDyne GmbH
Eichenstrasse 16
CH-6015 Reussbühl
Tel: +41 41 534 66 97
Mob: +41 78 790 66 97
Skype: seicodyne
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.

JoAnn T. Hackos, PhD
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver CO 80215



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.


Bob Thomas
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

"JoAnn Hackos" <joann.hackos@comtech-serv.com>

11/12/2008 12:06 PM

Michael Priestley/Toronto/IBM@IBMCA, <dita@lists.oasis-open.org>

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 Hackos PhD
Comtech Services, Inc.
Skype joannhackos

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Tuesday, November 11, 2008 9:22 AM
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

----- Forwarded by Michael Priestley/Toronto/IBM on 11/11/2008 11:21 AM -----

Alan Houser <arh@groupwellesley.com>

12/11/2007 11:01 AM

[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

- 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:
(steps | steps-unordered | process),
(Issue: allow <section> before and after <steps>?)

Support <section> between steps:
(section?, step)+

Support optional, repeatable <note> before cmd:
(info | substeps | tutorialinfo | stepxmp |  choicetable | choices)*,
Issue: allow <itemgroup> in <step>?

(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

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