Re: [dita] ITEM: Section div in LI

[Eliot Kimber <ekimber@reallysi.com>]

On 6/2/09 9:40 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> I'd be concerned about this for 1.2 because we don't have the time to
> think through all the implications. I'd suggest it as a change to consider
> for 1.3, where we can spend more time on the design.
> 
> As one immediate concern - currently block content is at least somewhat
> resistant to nesting because the content models explicitly exclude it. For
> example, the content model of p does not include p, lq does not include
> lq, fig does not include fig, etc. If we make sectiondiv available in all
> of those contexts, we will be making p able to nest almost directly (the
> intervening sectiondiv having no processing implications).

We wouldn't be making <p> nestable (because <p>'s content does not allow
%basic.block;), but your point is still valid: it would, indirectly, allow
an <lq> to have an (indirectly) nested <lq> with no intervening
block-context-establishing element, such as <ul> or <fig> (because
<sectiondiv> must necessarily allow <lq> [and fig, and table, etc.).

However, I think that trying to solve this problem at the DTD level is
simply not sustainable and not in the best service of DITA users.

The general need for a *single* specialization base to enable the creation
of arbitrary (untitled) containers is inherently at odds with the desire to
disallow, at the most general level, apparently inappropriate nesting, such
as <lq> with a descendant of <lq>. But that's an unavoidable aspect of a
standard that is necessarily as general as DITA is. It also runs into the
fact that DTDs (and schemas) alone are inherently insufficient to express
all possible useful constraints.

There comes a time where you just stop trying.

It is, ultimately, sufficient for the *prose* of the DITA spec to say
"structures that allow nesting of <lq> within <lq> without an intervening
block context establishing element (e.g., lists, figures, long quotes, or
tables) is not allowed". The fact that you can't express this constraint
declaratively in DTD or XSD syntax (but you almost could in SGML DTD syntax
and might be able to in RNG and definitely can using Schematron) is really
irrelevant--the DTDs are at most a convenience, but we cannot depend on them
as the primary definition of what is or isn't allowed (even though that is
how DITA has been largely defined to date).

So I agree that the standard should disallow direct nesting of <lq> within
<lq> [Actually I don't--I think that's a bug too because I can immediately
imagine having a long quote that is itself a quote of text that includes
another quote--I can't think of any absolute semantic reason to disallow
nested long quotes, now that I think about it.] but I disagree that the
mechanism for stating that rule is the DTD declarations--it should be the
prose of the specification, at least in the case where DTD syntax alone is
insufficient to express the constraint. There are already a number of such
statements in the DITA spec--It's hard to see how one more or less would
make much difference.

> An alternative would be to create a sectiondiv-equivalent for each of the
> block content model variants currently in the DTD. That would mean adding
> half a dozen new elements though, rather than just making the one
> ubiquitious. Which again reinforces the need to defer this to 1.3 for
> consideration.

That wouldn't satisfy the requirement, which is to be able to have a
*single* specialized element type that is allowed in all the places I would
expect to be able to have blocks. This would require me to have a bunch of
distinct specialized element types with exactly the same semantic when
otherwise a single specialized type would suffice.

The fact that there is already a difference between <sectiondiv> and
<bodydiv> is a problem, which is why it think it probably makes sense to
allow <sectiondiv> directly within body--without that I must have two
different variants of the same specialization, even if I have no need to
allow sections within my *div specializations, just so I can have the same
structure allowed within body and within sections. That seems like a bug to
me. 

If I wanted to take this to the extreme I could argue that really there
should only be one <*div> element and the spec can simply state that divs
within sections cannot contain divs, but that particular constraint is
important enough and it would be hard enough to implement that constraint in
specializations, that it probably does make sense to have the
sectiondiv/bodydiv distiction. But I can't see that the same argument
applies for e.g. <lq> or <fig>, where it's not about misusing <section> to
create titled hierarchy, but about avoiding (arguably) nonsensical
combinations of descendants.

That is, the DITA spec has drawn a particularly hard line on the non-nesting
of sections, for reasons of principle that are central to the basic DITA
design philosophy (title hierarchy is the exclusive domain of topics and
maps). That same principle does not, as far as I can see, apply to elements
within topic bodies.

Cheers,

E.

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>