From: Erik Hennum [mailto:]
Sent: Tuesday, November 01, 2005 12:17 PM
To: Paul
Prescod
Cc:
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).
