Re: [dita] Machine Industry Task question

[Robert D Anderson <robander@us.ibm.com>]

Hi Eliot -

> I would object in general to any policy that limited the semantics one
may
> choose to apply to ones specializations (when those semantics are not
> otherwise at obvious odds with the semantics of the base types).

I may have sounded overly general in my comment. I don't think we can or
should insist that nobody specialize their own version of task, unrelated
to the OASIS module. However, I'm uncomfortable creating our own task based
domains without creating a relationship to the task.

For this specific issue, I am most concerned that we are creating
semantically identical elements with no actual relationship - this seems
like the sort of problem that specialization was designed to address. If
something is a more specific <prereq>, the DITA architecture should lead
you to specialize from <prereq>.

I'm uncomfortable saying that we should break with the architecture because
we expect these two task elements to be used in tasks that have no
relationship to the rest of our task. These are all task based elements
coming from OASIS, so shouldn't they be related? I think the reason for the
separation is that the OASIS task may be too constrained for some users,
who will rebuild task from scratch. Do we know if there are such users? And
if we know of any, isn't the proper solution to make task more general so
that they can use it? I thought we had addressed this specific problem by
doing just that - making task more general - in DITA 1.2.

Does that make sense?

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)

Eliot Kimber <ekimber@reallysi.com> wrote on 06/26/2008 07:57:19 AM:

> On 6/25/08 9:44 AM, "Robert D Anderson" <robander@us.ibm.com> wrote:
>
>
> > So, Chris and I would like to discuss these questions:
> > 1. Should our designs anticipate support for specialized tasks that are
not
> > specialized from task, or does the TC disapprove of specializing
alternate
> > tasks with no relationship to the OASIS task?
>
> I would object in general to any policy that limited the semantics one
may
> choose to apply to ones specializations (when those semantics are not
> otherwise at obvious odds with the semantics of the base types). In
> particular, disallowing the creation semantic task specializations from
base
> topics would seem to be unduly restrictive (although the relaxed task
model
> in 1.2 would reduce the general need to *not* use task as a base for any
> task-like content).
>
> But this is an inherently slippery area because obviously there has to be
> some generally recognized practice/guidelines/restrictions on semantics
in
> specialization if it is to have much meaning beyond simple processing
> utility.
>
> > 2. If so, is the TC also OK with specializing closereqs from example,
when
> > it is not an example? Given the close semantic relationship between
> > prelreqs/prereq and closereqs/postreq, are we OK with having no defined
> > relationship?
>
> I certainly object to specializing from example in this case--it seems to
be
> a clear misuse of example as a base. I would certainly be very surprised
> when I got the default presentation effect for <example> in my machine
> industry tasks.
>
> Why can't closereqs be a specialization of section?
>
> > 3. If the domain is designed to be used outside of the OASIS DITA Task
> > module, I have some discomfort with calling it the OASIS "mitask"
domain,
> > because it implies a relationship to the OASIS task - do others share
this
> > discomfort?
>
> I do.
>
> Cheers,
>
> Eliot
>
> ----
> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
> email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
> office: 610.631.6770 | cell: 512.554.9368
> 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
> www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
> <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>

>