Re: [dita] DITAbase for conversion

[Robert D Anderson <robander@us.ibm.com>]

> Does that mean, as I understand it, that an organization using both the
> strict and the general task could not conref between them?
> JoAnn

It means they cannot conref back and forth.

The constraints rules say that you cannot bring information from a more
general topic into a more constrained topic. The reason is that you may be
able to bring in invalid content. Using task as an example - say that I
have a strict task with this element:
<prereq conref="othertask.dita#task/prereq"/>

If othertask has the same constraints, everybody is the same and is happy,
conref works.

If othertask is *more* constrained - it is also happy. Anything in the more
constrained task is valid here.

If other task is *not* constrained - there is a problem. All a processor
knows is that the current task disallows some elements that othertask
allows. We do not know what those elements are or where they go; we only
know that the constraint tightens the task module. So if we allow conref,
we might bring in elements that would break the current constrained content
model.

Hopefully that makes sense. The result, for this discussion, is that a
constrained task (the default standalone task) cannot pull content from a
general task. If the default ditabase has general task, it means we cannot
pull content from that ditabase into the default task, because we may be
pulling in content we otherwise would not allow.

I think it's wise for a single organization to use constraints consistently
- trying to use both a constrained and unconstrained task at the same time
will cause conref issues and confuse authors. So, it seems like we should
do the same, and make our default ditabase task the same as our default
task.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit