OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Constraints and Inheritance

Hi, Paul:

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

Inactive hide details for "Paul Prescod" <paul.prescod@blastradius.com>"Paul Prescod" <paul.prescod@blastradius.com>

          "Paul Prescod" <paul.prescod@blastradius.com>

          11/01/2005 09:49 AM


Erik Hennum/Oakland/IBM@IBMUS, <dita@lists.oasis-open.org>



[dita] Constraints and Inheritance

I am not confident that organizations will want their constraints to be applied to specializations. In the case where a constraint is really an "authoring" guideline, there is no reason to apply the constraint to specializations: the content models for specializations created by the organization are inherently at the right level of specificity for the task.

As Erik said during the call: there is no current way, given limitations of our implementation technologies, to have constraints "automatically" inherit down the specialization hierarchy. So there is no efficiency benefit to be had in saying that constraints apply down the specialization hierarchy. In fact, it just creates work for specialization/constraint maintainers, trying to maintain consistency up and down their specialization hierarchy.

Paul Prescod

GIF image

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]