RE: [dita] Groups - Proposal 12008 - vocabulary and integration constraints(HTML) (IssueConstraints12008.html) uploaded

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Paul:

DITA is an architecture populated by a vocabulary. The DITA architecture has always augmented schema languages with the syntax and semantics of specialization (by which we derive new vocabularies from existing vocabularies) and pluggability (by which we integrate those vocabularies to make document types). Those capabilities -- extensibility without sacrificing interoperability -- are responsible for much of DITA's success.

The constraints proposal expands the capabilties of the architecture. Like any change, that has both benefits and costs as you note. I would point out that DITA adopters have been asking for this capability from the start. Examples of some common constraints that people want to apply:

* Requiring <shortdesc>.
* Disallowing text and phrase elements in <section> and <example> and their specializations.
* Disallowing nesting of blocks.
* Replacing <prolog> with a specialization without specializing the topic.

Constraints would also give the TC a straightforward way to resolve the tension around task. The existing task usefully enforces best practices for some content but isn't flexibile enough for other content and users. The TC could relax the content models of task but refactor the task document type to restore the existing restrictions via a constraint. In this respect, task provides an example of the design tension between flexibility for specialization and best practices for authoring and of how constraints can offer a resolution.

I'd also point out that, because constraints are optional, the proposal raises the ceiling with little burden on designers who aren't using constraints. The main cost for those designers is in the DTD implementations, where designers have to provide entities for each element content model and element attribute list. (Many non-DITA vocabularies use that design pattern anyway as a best practice.) The other cost in both DTD and Schema implementations is the constraints attribute on topic and map, but if you aren't taking advantage of the capability, that attribute is empty.

So, from my perspective, the benefits vastly exceed the cost, but that of course is something to discuss.


Thanks,


Erik Hennum
ehennum@us.ibm.com


"Grosso, Paul" <pgrosso@ptc.com> wrote on 08/21/2007 06:25:30 AM:

> If I'm reading this correctly, it sounds like we are augmenting DTD
> constraints with some home brew syntax and semantics that users will
> need to learn and understand and implementors will need to implement.
>  
> It sounds to me like some of these more complex proposals are just
> piling completely new concepts on top of an already complex
> application.  Am I the only one somewhat concerned with the
> complexity we are adding to DITA?