MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] Groups - Issue 34: Constraints - restriction withoutspecialization (was replacement domains) (Issue34.html) uploaded
Hi, JoAnn:
Yes, that's one important use -- simplifying content models. The Use Cases section has a few other important uses.
The proposal would declare and manage these restrictions within the DITA architecture so you can get consistency across your topic types and even agree with partners on a set of common restrictions.
One beneficial side effect would be in simplifying the type hierarchy because you would specialize only for semantic reasons and not because you want to simplify the content model.
The limitation is that we can't provide any special magic to propagate restrictions (any more than we can define specializations by delta). To restrict the content model for an element, you would have to redefine the entire content model for the element. If the system recognizes that you've done so for a purpose, however, it can validate that you've done so consistently and check whether other content conforms to your restrictions.
Thanks,
Erik Hennum
ehennum@us.ibm.com
joann.hackos@comtech-serv.com>">"JoAnn Hackos" <joann.hackos@comtech-serv.com>
Erik et al.
One of the most common use cases we encounter is to reduce the elements
allowed at various points in the DTD. Do I understand correctly that
this proposal would provide us with a mechanism essentially to "hide"
certain elements that we don't want authors to use without creating a
specialization?
JoAnn