Re: [dita] Mixed content in DITA

[Don Day <dond@us.ibm.com>]

"Paul Prescod" <paul.prescod@blastradius.com> wrote on 04/08/2005 07:11:13
PM:

> I wonder if the powers that be are open to the idea of adding a section
> element that is not such a mixed content free-for-all. I'm not clear on
> the rationale for sections as they are today but they are certainly
> inconvenient for authoring application vendors trying to help authors
> stick to rational document structures. It isn't clear how we should
> render a section like this:
>
>   <section>
>    This little command copies
>    things.<p>Blah Blah</p> And so does this.
>    <title>Purpose</title>
> </section>
>
> Should we allow the author to create that?

This is a reasonable question, Paul.  Part of the answer is rooted in XML's
inability to constrain sequence in mixed content, hence the ability of
authors to create such constructs--that is, in the absence of other
constraints.  But there is a design reason behind why that is even allowed
in topic.

When planning for specialization, the content model of section was given
particular thought. It was realized that specializers could easily remove
the PCDATA and thereby enable new constraints on the optionality and
sequence of the remaining block content.  The only other option was to
introduce a "sectionbody" subcontainer after section title, and this was
felt to be overloading the design.  If you specialized the title away, you
would end up with a required sectionbody that is the only child of
section--an odd vestigial structure for subsequent specializations.

Part of the best practice answer to writers would be to encourage the use
of typed topics whenever possible.  Topic is so generic as to be untyped.
By using the concept, task, or reference infotypes, at least there are
content constraints that are typical for these first-level infotypes.  Even
in these, section is not fundamentally altered because you don't want to
introduce artificial rules early in the type hierarchy... your business
rules might not be the same as those wished for by someone else deriving
from a too-restrictive ancestor.  Constraints applied early affect all
downstream derivations, so a best practice is to choose the appropriate
place in the hierarchy for best benefit/least annoyance within the taxonomy
of infotypes.  You can always constrain, but you can't let it out any more
than what you have to start with.

These considerations for an appropriately loose archetype cause a number of
headscratching cases besides section (li and dd come to mind too). If you
have a client who has a particularly allergic reaction to the behavior of
section in concept, specialize a "hypoconcept" that removes PCDATA and use
a content model declaration somewhat like (title, (p|dl|table|ul|ol|lq)*)
to really nail down section content. All subsequent specializations from
that parent will inherit that constraint model.

One case for introducing a particular specialized behavior early in the
type hierarchy might be for the user who needs to produce Section
508-compliant content.  For one thing, he'd likely make the alt element of
image required, and then all concepts, tasks, and reference derived from
this alternate proto-topic would inherit that authoring constraint.

Regards,
--
Don Day <dond@us.ibm.com>
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
11501 Burnet Rd., MS 9037D018, Austin TX 78758
Ph. 512-838-8550   (T/L 678-8550)

"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
        --T.S. Eliot