A couple of reasons why you might want to implement a constraint on the specialized element:
1. So content models are consistent for writers across all information types.
2. So you can generalize to the constrained base element.
On the second point, let's say I constrain <section> in the topic document type to title followed by one or more blocks. The unconstrained task cannot generalize to the topic because the <context> could contain some text or phrases that won't be valid in the block-only <section>.
So, I should have the _option_ to implement the section constraint on the <context> element so I can generalize my task content to my working topic document type.
My write up may have created some confusion between the designer's obligations within a constrained document type and the designer's obligation to create a constrained document type.
If I assemble a new document type from the design modules and declare a constraint, I am obligated to implement the constraint over all of the elements in the new document type that specialize the constrained base elements. I don't have an obligation, however, to create that new document type.
Again, I'd make the analogy with Java interfaces. If I declare that a class implements an interface, I must write it to conform to the requirements identified by the interface. The decision to implement the interface, however, is entirely up to me. By declaring conformance to the interface, I can indicate the design conformance for processing and interoperability. So even though it doesn't help me with the implementation, it gives we a way to achieve consistency within my adoption and with other adopters.
Hoping that's useful,
Erik Hennum
ehennum@us.ibm.com
"Paul Prescod" <paul.prescod@blastradius.com>
