[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Why There are Constraints on Conref
I agree that we should have a formal proposal and some time to think it through. I'm sure that simply having MP take the time think through the language of a formal proposal would do a long way toward either making it reliably solid or determining that it's ill advised upon deeper consideration. Cheers, E. On 9/28/09 1:51 PM, "Ogden, Jeff" <jogden@ptc.com> wrote: > If we do implement weak constraints for DITA 1.2 or 1.3, what sort of > constraint would we include for task in ditabase (strict or weak-strict, > I assume that general is not an option) and what sort of constraint > would we include in task.dtd (strict or weak-strict)? > > > > Is a weak constraint something that is decided by the constraint author > or is it something that can be overridden in a customized doctype shell? > > > > Just writing the name weak-strict gave me the creeps, but I guess we > could pick a better name or perhaps task.dtd is always strict and strict > always implies weak, so the name remains task which is strict task or > weak-strict task. > > > > My main concern here is that adding weak constraints is going to make > something that is pretty complicated already even more complicated. It > seems that few people understand it now and so making things more > complicated isn't likely to help. But I guess if people are willing to > use the doctype shells on "faith" without really understanding and if > the information designers do a good job or are lucky, then people won't > run into problems and life will be good (as good as it was in DITA 1.0 > and 1.1 anyway). > > > > I also worry that making changes like this in a rush at the last minute > without a real proposal may cause us to doing something without really > thinking it through and we may come to regret it later. > > > > -Jeff > > > > > > From: Michael Priestley [mailto:mpriestl@ca.ibm.com] > Sent: Friday, September 25, 2009 2:05 PM > To: ekimber > Cc: dita; Ogden, Jeff; rob@ascan.ca; Su-Laine Yeo > Subject: Re: [dita] Why There are Constraints on Conref > > > > > Eliot, I think that's an eloquent description of the rationale for the > current situation, and it's certainly where my thinking is coming from > as well. > > I did have a thought on how we might be able to achieve a compromise of > sorts, preserving the strict validation that we both consider necessary > for robust processes, while allowing for broader reuse scope in some of > the cases Rob and others have been asking for (including task->general > task). > > Here's my thought: > > - if the doctype developer knows upfront whether a constraint is just an > authoring guideline or whether it's a strict business requirement, they > could annotate the constraint on inclusion > - constraints noted as "weak" would be ignored by conref validation, and > would be considered unreliable by processors, which would need to assume > the constraint wasn't there as well > > Example: > - group A introduces a constraint that makes title in fig required - > they have a figlist generator that depends on this, so they make the > constraint required - if someone tries to conref from a place that > allows title-less figs, they'll get an error, and will have to negotiate > with the other team to introduce the constraint in their shared content > - group B introduces a constraint that makes <ul> unavailable in <p>, > because they think it's simpler for their authors. But they don't depend > on it, the output looks the same whether they allow <ul> inside <p> or > not, and they may need to conref content from another team that doesn't > use the constraint. So they make the constraint "weak" instead of > required. > > Technical complexity: > - add a flag to constraints to indicate when they are included as "weak" > - eg - domains=" w(myconstraint) " > - add a check to conref validation that ignores weak constraints when > determining validity > > If we wanted to, we could then implement our strict task as a weak > constraint, so it would be able to conref from loose task. > > I think this might address the concerns of both sides - it gives us > strong constraints when there are business or processing requirements on > the constrained structure, but allows reuse in other cases. > > All that said, I'm very aware of how late in the cycle we are, and I > don't think the cross-constraint use case is actually going to come up > that often. So there's probably a few questions to ask: > > - is this a useful idea? > - does it address the use cases of both sides? > - if it is, is it useful enough to change in 1.2, or should it wait till > 1.3? > > Michael Priestley, Senior Technical Staff Member (STSM) > Lead IBM DITA Architect > mpriestl@ca.ibm.com > http://dita.xml.org/blog/25 <http://dita.xml.org/blog/25> > > > > From: > > ekimber <ekimber@reallysi.com> > > To: > > <rob@ascan.ca>, Su-Laine Yeo <su-laine.yeo@justsystems.com>, Michael > Priestley/Toronto/IBM@IBMCA > > Cc: > > dita <dita@lists.oasis-open.org>, Jeff Ogden <jogden@ptc.com> > > Date: > > 09/24/2009 11:52 PM > > 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 > <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://www.reallysi.com/> > > | http://blog.reallysi.com <http://blog.reallysi.com/> > <http://blog.reallysi.com <http://blog.reallysi.com/> > | > www.rsuitecms.com <http://www.rsuitecms.com <http://www.rsuitecms.com/> >> > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > <https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php> > > > > > ---- 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]