RE: [dita] Constraints and Inheritance

From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Tuesday, November 01, 2005 12:17 PM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] Constraints and Inheritance

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>.

[Paul] But how is this a problem? Generalization is a way of maintaining compatibility with "generalized" processors. These generalized processors should use unconstrained standard DITA doctypes, not constrained authoring doctypes.

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.

[Paul] Once I understand the use case I may well agree that it should be an option. Would you agree that it should not be a requirement?

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.

[Paul] I don't entirely follow yet. There is a thing called topic/section in the doctype "standard DITA". For the purposes of communication, let's call that object DITA/topic/section. Let's say I constrain it in my doctype. There is logically a new object in the universe called mydoctype/topic/section. Now the question is: does mydoctype/topic/example need to conform to the constraints from DITA/topic/section or those from mydoctype/topic/section? I claim that I usually want them to inherit from the unconstrained standard (which is what all of my downstream tools will be programmed to deal with) rather than the constrained local version (which is primarily applicable to my authoring tool).

dita message