RE: [dita] Re: ITEM: Resumption of: task vs. general task, constraints, conref, and other related issues

["Ogden, Jeff" <jogden@ptc.com>]

Where Eliot said topic.mod in his note, I think he meant to say
task.mod.

Something like what Eliot proposes might work.  But what would the class
attribute values be?  "- topic/topic task/task " as they are now?  "-
topic/topic general-task/general-task " which would be right for a
general-task specialization of topic, but which would break lots of
existing stuff?  Some kludge like "- topic/topic
general-task/general-task task/task " which might work, but doesn't
exactly follow the rules?  Something else?

And where would the existing task.mod and taskMod.xsd Public IDs and
URIs point?  They would need to point at the old task.mod and
taskMod.xsd files that no longer exist. That would be OK for me.

   -Jeff

> -----Original Message-----
> From: ekimber [mailto:ekimber@reallysi.com]
> Sent: Tuesday, November 03, 2009 12:14 PM
> To: dita
> Subject: [dita] Re: ITEM: Resumption of: task vs. general task,
> constraints, conref, and other related issues
> 
> Could we finesse the module naming problem by saying that the element
> type
> that currently called "<task>" should have *always been* named
> "<general-task>" and that therefore renaming "task.mod" to
> "general-task.mod" is a bug fix that cannot be extended to the <task>
> element because of backward compatibility.
> 
> However, we could, in addition, declare the element type
<general-task>
> as
> an alternative to <task>, within the general-task.mod module.
> 
> This then makes general-task.mod nominally conform to the rules while
> maintaining backward compatibility.
> 
> By not having a topic.mod file in 1.2 we then break all existing
> specializations of topic, forcing specializers to re-evaluate their
> specialization and apply constraints or not as they choose.
> 
> We could then either now or in 1.3, list <task> as deprecated in favor
> of
> <general-task>.
> 
> Cheers,
> 
> E.
> 
> ----
> 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>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php