Re: [dita] More on structured sections

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

Hi, Yas:

I'd like to clarify a point about the constraints proposal. Organizations should be able to create and share constraints in much the same way that they can create and share specializations. That includes the OASIS DITA Technical Committee.

If the constraints proposal is adopted, the Technical Committee might want to define a constraint for simplified content for DITA 1.1 (both to illustrate the principle and because of requests for the specific restrictions). The simplified content constraint might include:

• Restricting <section> to a <title> followed by block elements.
• Restricting block elements to phrase-level elements and text.

That is, DITA 1.1 could provide both topic.xsd, task.xsd, and so on (the base loose models) and topicSimple.xsd, taskSimple.xsd, and so on (the constrained simplified models). 

The limitation on trying to simplify <section> through specialization is that the specialization doesn't alter other specializations of <section> such as the <context> element in task.  You'd have to create a separate specialization of every <section> specialization even though the semantic of those elements hasn't changed.

The goal of the constraints proposal is to address that problem by declaring and implementing restrictions on the existing <section> and its specializations like <context>.

Right now, we can't automate cascading the constraint implementation from a base element to its specializations.  Thus, for those who know Java, think of the constraint as similar to an interface -- that is, as a name that identifies a set of requirements for conforming implementations.

The unambiguous syntactic definition of a constraint (like specialization) is given by the delta between the unconstrained base elements and the constrained elements in a document type that implements that constraint and no others.  A design tool could compare the base and constrained definitions and work magic. In the absence of such tooling, as with specialization, the constraint depends on discipline by the designer.  In other words, in themselves, constraints don't make life easier for designers but instead give designers a way to make life easier for their users.


Hoping that's interesting and clarifies,


Erik Hennum
ehennum@us.ibm.com


"Yas Etessam" <yas.etessam@blastradius.com> wrote on 10/31/2005 01:10:15 PM:
> If everybody sets their own constraints for sections, 
> interoperability would still be a problem.
> 
> I'm going to modify the proposal to consider the use of structured-
> section as a specialization.