Need Clarification on Implications of Different List Markup Patterns

[Eliot Kimber <ekimber@reallysi.com>]

I'm trying to do a little implementation work on the DITA2InDesign 
processor and worked yesterday on implementing the mapping of list items 
to the appropriate InDesign paragraph styles.

Because InDesign has a weak notion of containment, each level of a list 
has to be mapped to a different paragraph style that defines the 
formatting details for that level (e.g., 2nd-level numbered item within 
1st-level numbered item).

In trying to work out the rules I realized that the 1.1 spec is silent 
on what the implications of these two markup patterns are:

<ol><li><ol>

and

<ol><li><p><ol>

Both are allowed.

The question is: should the intervening <p> element establish a new list 
sequence or should the list sequence continue from the nearest 
containing list element?

In a similar vein, there is inconsistent implementation behavior for the 
presentation of list items that do and don't start with nested <p> 
elements between the Toolkit's built-in HTML renderer and the PDF2 
renderer. This has been discussed before on this list.

But I think a formal decision needs to be made about what the intended 
implications, if any, of nested <p> elements within <li> are, even if 
the intent is "rendering effect is implementation defined".

My personal opinion is that the current HTML formatting implementation 
is incorrect and that <li> should always be rendered the same regardless 
of whether it has an initial <p> or not. If there is a requirement to 
distinguish compact from non-compact lists (which is the practical 
effect of the HTML behavior [but not the PDF behavior]) that would be 
better handled with either a new attribute for lists (analogous to 
expanse or width or other format hints) or as a conventional value for 
outputclass=.

It's too late for DITA 1.2 but I'm also finding that it would be really 
handy to have a base type underlying all the lists (e.g., topic/list) 
that would make it easy to implement a check for whether an element is 
or is not a list.

Cheers,

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