← Prev in month ← Prev in thread
Next in thread → Next in month →

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

From
ekimber <>
Date
2009-11-03T18:17:32+00:00
ID
Thread
Re: [dita] Re: ITEM: Resumption of: task vs. general task,constraints, conref, and other related issues
On 11/3/09 11:33 AM, "Ogden, Jeff" <> wrote:

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

Yes, sorry.

> 
> 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?

I was thinking the @class value would be unmodified, for the same reason
<task> can't be renamed to <general-task>.

Really I'm just trying to find a way that I can support anything other than
not doing anything to the status quo.

Personally, I don't think the concerns about surprise are sufficiently
compelling to require us to do anything more than providing the constraint
module and task.dtd that we already have. I just don't see how anything we
do will make things any better for the relatively small number of users who
might see a problem from their tasks suddenly becoming less constrained. The
migration fix is easy to implement (just include the same constraint module
used by the TC-provided task.dtd) and no documents are harmed by the change.
 
> 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.

I would think they would go away: gone is gone and if we remove task.mod we
should remove any version-independent or version 1.2 catalog entries for it.

Alternatively, the entries could point to a
"this-module-has-been-deleted.mod" file, just to make the point clear.

Cheers,

E.

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:   <mailto:>
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>
← Prev in month ← Prev in thread
Next in thread → Next in month →