[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Why There are Constraints on Conref
Michael, I support implementing your proposal in 1.2. Consider the confusion in the field re: conref'ing, task, and general-task for folks who have not been in this conversation. There will always be a certain amount of confusion with a transition such as the one from DITA1.1 to DITA1.2 ... let's optimize for differentiation and clarity.
Stan
-----Original Message-----
From: "Michael Priestley" [mpriestl@ca.ibm.com]
Date: 09/25/2009 03:59 PM
To: "ekimber" <EKIMBER@REALLYSI.COM>
CC: "dita" <DITA@LISTS.OASIS-OPEN.ORG>, "Jeff Ogden"
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
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]