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

Hi Bruce,

That was the original thought behind
general task, but after investigation the design team decided to go with
a more-constrained and less-constrained task, using the new 1.2 constraints
mechanism, rather than introducing a whole new specialization. As part
of that looser model I believe we did introduce a <section> container
or two in the unconstrained version.

Alan Houser led the original discussion.
I think it would be very helpful to all concerned if Alan could gather
the hanging threads from the original discussions and forward them to the
group. 

Michael Priestley, Senior Technical
Staff Member (STSM)

Lead IBM DITA Architect 



http://dita.xml.org/blog/25

"Bruce Nevin (bnevin)"
<> 

11/17/2008 11:35 AM

To

<>

cc

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

/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