Alan,
I need an example of process as you describe it for the
lang spec and the article that the Adoption TC is preparing
Let me know if you have something that I can
use.
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
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:
72E2EA99C8FA4F4B930539BF7939C6DF0196925A@CSI001.Comtech.local
type="cite">
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
|
|