Maybe a particularly good discussion to have, given the issue Paul raised today about the long term roadmap for DITA...
Yes, it would be a mistake for DITA to introduce a new document validation language. What with DTD, XML Schema, RelaxNG, and Schematron, we have lots of options for validating document instances. So, one way or another, a constrained content model has to be implementable in existing validation languages.
DITA specialization doesn't add a new method for implementing a content model but, instead, defines relationships between types and maps types to XML syntax. In particular, DITA specialization has some key aspects:
* Design discipline: Mandates that any valid instance of a specialized type must also be a valid instance of its base type.
* Pluggability: In accordance with a design pattern, organizes the elements for specialized types into pluggable schema modules and integrates those schema modules through substitution of specialized types into base positions.
* Processing: Using a pragmatic method that's agnostic with respect to schema language, associates each element with a type to enable processing instances based on types.
* Generalization: Declares the relationships and integration of types to enable type conversion of instances (for example, as part of conref inclusions).
While it makes sense to implement a constrainable content model with a predefinable parameter entity in DTD modules or with a redefinable xs:group in XML Schema modules, that's only part of the battle. We still need to address the impacts (distinct from the implementation of the content model) on the key aspects of specialization:
* Design discipline: A constraint applied to a base type probably has to apply to all specialized types in the same document type. As a consequence, the document type probably cannot include any specialized types with required subelements that would be invalid under the constraint. Otherwise, a document could have an instance of a specialized type with content that's invalid for an instance of the base type, which would break a generalizing conref within the same document.
* Pluggability: The design pattern must define constraints in pluggable modules with clear dependency relationships with type modules and other constraint modules.
* Generalization: Operations must be able to check for impacts of constraints on compatibility. For example, an unconstrained instance of a specialized type is not guaranteed to be valid within a document type that applies a constraint to its base type. As a result, generalization has to be disallowed for the constrained document type though allowed on the unconstrained document type.
In short, unless we enhance DITA specialization to track and manage constraints, a constrained document type sits outside of the DITA architecture. We'd have to say, "it's no longer DITA." That's not what the adopters on the user group have requested.
The same need to address impacts exists for contextual domains (though the impacts seem much simpler).
Thanks,
Erik Hennum
ehennum@us.ibm.com
"W. Eliot Kimber" <ekimber@innodata-isogen.com>
