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: [dita] Machine Industry Task question


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> 



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