Re: [dita] Why There are Constraints on Conref

[ekimber <ekimber@reallysi.com>]

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>