[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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" <jogden@ptc.com> 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: 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]