Re: [dita] Content model options for #12011 - Generic Task Type

[Deborah_Pickett@moldflow.com]

Eliot Kimber <ekimber@reallysi.com> wrote on
28/11/2007 04:53:38 AM:
> Key use cases here are tutorials and 
> troubleshooting, where you want to have some discussion that encompasses
> all the foregoing or all following steps in a group (e.g., talking
about 
> where you've gotten after 4 steps of a 6-step atomic process within
a 
> tutorial).

(I just pulled that bit out because that's the one
use case I have which <task> doesn't currently give me. Consider
that sentence the context of my reply.)

> - Should a single task allow multiple <steps>
elements? [...]
> - Should there be a way to group steps within a single <steps>
element 
> that is not substeps within steps? [...]

As Eliot said, both of these could satisfy my use
case (I do the former as a specialization of <topic>).  The
latter is probably cleaner, though it requires more architectural upheaval.

I'd been hoping to avoid the philosophical question
of "what is a task?" but perhaps I can't.  Are my worked-examples-with-interspersed-discussion
tasks?  I think they are, but I am prepared to admit that I am looking
at them through legacy-topic-coloured glasses.  They might have been
refactorable as straight tasks, probably with some splitting.

> With regard to the specifics in Alan's note, my feeling is:
> 
> For the content model of <step>:
> - I see the value of allowing <itemgroup> to enable arbitrary
> specialization that is not based on <info>. However, I would
be OK with 
> not allowing <itemgroup> if we agree that <info> is sufficiently
> generic.

Agreed, though I do note that we don't have a perfect
track record in forecasting how generic is "sufficiently generic".
 Read on...

> For the content model of taskbody:
> - I don't understand the value of allowing <ol> or <ul>
in place of 
> <steps> in any of these options. What is the motivation there?

That idea was mine.  Like <itemgroup> in
<step>, it is intended as a specialization extension point for things
that are neither <steps> nor <steps-unordered>.  (At the
time it was acting as a surrogate for <simple-steps> or whatever
it has morphed into.)  Like <itemgroup>, the plan was for all
shell DTDs to restrict the unspecialized version away.  (Back to "sufficiently
generic" again...)

I assume that there will be two normative restrictions
of <task>: Strict <task>, which is a replica of DITA 1.1 <task>,
and Loose <task>, which is just loose enough to cater to everyone's
new requirements.  Importantly, Loose <task> is *still a restriction*
of the true content model of <task>.  Arguing the content model
of general <task> based on the requirements of Loose <task>
is certain to underestimate the amount of genericity required.  For
that, we need to ask "what will specializers need from a generic <task>?"
 That's my argument for <itemgroup> and <ol> and <ul>
(and also for Alan's <taskbody> model #3).  I hope that <itemgroup>
in <step> is uncontroversial, and the fact that people are questioning
even that it's needed I take as a sign that this is exactly the kind of
unobtrusive thing that specializers want.  <ul> and <ol>
in <taskbody> I expect to be more controversial.  Good; let's
hash out exactly what constitutes the most abstract and generic possible
task, and then restrict it for Strict <task> and Loose <task>.
 If specializers want something more generic than <task>, then
it's time to fall back to <topic>.  

There might be an argument for a topic type that goes
between <topic> and <task> in the inheritance tree (perhaps
<procedure>), but I don't want to cloud the issue at hand, so I won't
elaborate here.

-- 
Deborah Pickett
Information Architect, Moldflow Pty Ltd, Melbourne
Deborah_Pickett@moldflow.com