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] Why There are Constraints on Conref


On 9/27/09 9:55 AM, "Joann Hackos" <joann.hackos@comtech-serv.com> wrote:

> Su-Laine is asking the same question I'm concerned about. We need a simple
> answer. I'm having a hard time with the arcane details.
> 
> Is DITA 1.2 going to mess up all the conrefs we have set up in DITA 1.1
> between ditabase or topic and Task?

Not as long as ditabase in 1.2 includes the task constraint. In that case,
conrefs between two out-of-the-box task topics, whether governed by the
task.dtd or ditabase.dtd, will be allowed.

Conrefs from 1.2 unconstrained tasks to 1.1 tasks or 1.2 constrained tasks
will be allowed (because the conref is from less constrained to more
constrained).

This suggests to me that the best thing to do in 1.2 is to have both
ditabase.dtd and task.dtd use the same task constraint so that 1.1 users who
conref *from* standalone task topics to ditabase-based task topics will not
have to modify anything for those conrefs to continue to be valid.

I think we can assume that, in most cases, the direction of conref would be
from standalone topics to ditabase-based topics given that the primary
non-conversion use case for ditabase is organizing sets of topics intended
primarily or exclusively for re-use (especially since including any such
topic from a map gets you all the topics in the ditabase document in the
rendered result).

Conrefs from non-task topics to task topics are unaffected by the use of
constraint modules on task.

Users who have custom topic types specialized from task will have to decide
if they want to impose the constraints on task when migrating from 1.1 to
1.2, since their local shells will point to the unconstrained task when
using the 1.2 modules. But if you've stepped up to specialization you can
probably handle this change. But I think it would be useful to put together
a "1.1 to 1.2 migration guide" that captures this and the few other things
that Information Architects will need to think about when migrating to 1.2.

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]