dita message

Subject: Need a div element that is allowed in abstract, body, or section
From: Eliot Kimber <ekimber@reallysi.com>
To: dita <dita@lists.oasis-open.org>
Date: Wed, 18 Jan 2012 17:54:12 -0600
In DITA 1.2 we have <bodydiv> and <sectiondiv>.

<bodydiv> differs from <sectiondiv> in that it allows <section> (and each
can nest itself). Otherwise bodydiv and sectiondiv have identical content
models. Their semantic is (at least by my intent) the same: an untitled
nestable container.

However, <sectiondiv> is not allowed in <body> or similar block contexts
(e.g., <abstract>).

This is a problem because it means at least two things:

1. There is no single div-type element you can use in both <body> and
<section>, which means you have to have two different element types for the
same semantic in many cases and you have to choose one or the other (or
change the tagname) depending on the context they occur. This is especially
annoying for data conversion where it may not be easy to know whether your
current output context is a body or a section.

2. There is no div-type element allowed in <abstract>. There needs to be.

For example, there's no way to have a div-type element in a glossdef, which
is a specialization of <abstract> (which I've always found odd but that ship
has sailed).

In my use of div-type elements I have never needed to include <section> in
them (and would never expect to), so I would be able to always use
<sectiondiv> if it were allowed in <body> (and <abstract>).

I can think of two solutions:

A. Allow <sectiondiv> in <body> and <abstract> (and any other place where
<p> is allowed but divs are not today allowed). This would make <sectiondiv>
the "generic" div allowed anywhere.

B. Define a new div element type, <basicdiv> or something, that has the same
content model as <sectiondiv> and is allowed in <body>, <section>,
<abstract>, etc.

Option (A) is obviously easier to implement but might raise questions as to
why <sectiondiv> is allowed in <body> based just on the name. Option (B)
avoids that potential confusion at the cost of a new element type.

Certainly my original intention for the div-type elements was to have a
generic wrapper thingy that would be usable anywhere. We kind of lost that
in the original implementation.

Cheers,

E.


-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com