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] 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.



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]