Several questions have come up during the recent discussion of constraints. This is an attempt to answer some of those questions in a simple way.
Note that this is based on the proposal as already approved by OASIS, and does not include anything related to the recent "weak constraint" proposal from Michael.
What is the purpose of constraints?
The primary purpose is to restrict elements available within a document type, without the need to specialize. Specialization is intended for use when a module (such as task) provides more semantic information than its base (topic). When the purpose is simply to hide some elements, but not to provide additional meaning, constraints are more appropriate.
The approved proposal for task changes in DITA 1.2 called for maintaining the status quo using constraints, rather than a new generalTask specialization ancestor, because the <task> element has exactly the same meaning in the general task as it does in constrained task.
If another organization uses different constraints, can I still reuse their topics?
Yes. Sharing documents with different constraints works exactly the same as sharing documents with different specializations.
If I use the existing OASIS document types, will I be affected by constraints?
No, provided that the default ditabase and the default task include the same constraint.
Can I use conref to pull content from a constrained topic into an unconstrained one?
Yes. The constrained topic limits what is available, but the unconstrained one does not. So, anything in the constrained task is legal in the unconstrained one.
For example, general task allows multiple context elements, while the constrained task only allows one. If you try to pull a taskbody from the constrained task into the general task, there is no problem; you can only end up with one context element in the general task, which is legal.
Can I use conref to pull content from an unconstrained topic into a constrained one?
No. The constrained topic adds one or more of the following restrictions: it makes certain optional elements required, prohibits certain optional elements, limits the number of ways that elements can be sequenced, removes or requires certain optional attributes. So, processors will not allow you to pull unconstrained content, in order to ensure that your document continues to conform to its original constraints.
For example, general task allows multiple context elements, while the constrained task only allows one. Now assume that a specific general task has 2 context elements. If you try to pull the taskbody from that task into a constrained task, you will end up with two context elements, which is not allowed.
Who does the conref limitation affect?
The conref limitation specifically impacts groups that use two documents that include the same specialization module, when those specialization module have different constraints, and the groups wish to conref individual elements between those two documents.