[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/24/09 10:23 PM, "Rob Hanna" <rob@ascan.ca> wrote: >> They might be making content outside >> their environment unusable *by them* >> but they would not be making their >> content unusable to others who use fewer >> constraints. > > What if instead of having fewer constraints, they have different constraints? > This is not simply a matter of just two task variations. Over time the > variations of standard topic types introduced through constraints will grow. This is why you have the domains attribute at all: so you can analyze the constraints at use in two DITA documents to determine if they are compatible. This at least lets you detect this situation early, rather than late (such as after a publication has been published). > For example, consider one possible scenario I see where this might present a > problem: > > "Over the course of several years a department's style guide changes several > times through reorgs and acquisitions - each time enforced with a different > set of constraints introduced. There is no budget to convert the older > content. Over time reuse opportunities are lost and content must be duplicated > to suit different doc sets written to adhere to separate constraints." > > As it stands now, constraints do not deprecate gracefully as would domain > specializations. Even substructures within structurally specialized content > can generally be reused safely. Note that it is *easy* to remove constraints: you simply update your shells to stop including the constraint modules. No need to modify the documents involved. That means that given two sets of content that have incompatible constraints you can make them compatible by changing their governing shells to be less constrained. But in fact I think what you are expressing is a problem inherent in any interoperation situation. DITA isn't changing the fact that two interchanging communities might have divergent rules over time such that there may be data and processing interoperation problems: that's an unavoidable fact of life. What DITA is saying is "we're giving you a way to detect that case early, rather than late" and make an informed decision about how to react. In practice I think most DITA users will tend to avoid constraints simply because any constraint, by its nature, tends to impede bidirectional interchange. The only reason we're having this discussion at all is because DITA 1.0 inherited an over-constrained task model from IBM, something we should have fixed in 1.1 but didn't. It's only now that we have the constraint mechanism that we can fix the problem (overconstrained tasks) in a way that allows backward compatibility without having to define a completely different task base type and specialization. > This is an issue that can only get more complex over time. In my opinion, > processors must be designed to handle the base (or call it general or loose) > structures with warnings to ensure seamless exchange of content. But it's not that easy: there may be processing cases where it would be at best wrong, at worst impossible, to properly process and render unconstrained content in a constrained context, because the constraints are there, in that case, to enable or ensure a particular presentation. So you can't simply say "processors have to be able to process any combination of stuff". 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]