Re: [dita] Need Clarification on Implications of Different List Markup Patterns

[Gershon L Joseph <gljoseph@yahoo.com>]

Hi Eliot,
 
I see no-one responded yet. I think what you're seeing is an issue I've been complaining about for ages -- the default topic types are too loose to use as-is, and authors tend to mark up using worst-practice XML instead of best-practice. I now recommend all my DITA clients to specialize the base topic types to remove mixed markup wherever possible, and to enforce best practice XML (and SGML for that matter) DTD modeling techniques.
 
The result is that table entries, list items, etc. all contain <p> or some other block content, since I don't allow #PCDATA directly in <li> or <entry>.
 
I still feel that the DITA spec should provide a loose set of DTDs for users to specialize from, but that it should also provide a tight set of DTDs that authors can use out of the box. IMO the current base topic DTDs are too loose to be useful. The sad fact is we see tons of users applying bad markup -- effectively marking up their DITA XML content the way they applied styles in Word or FrameMaker.
 
Maybe this is something the TC could (should?) take up post-1.2. I don't think the spec can address the issue via language alone -- formatting is largely an implementation issue that's beyond the spec. However, I do feel the spec should provide new DITA users a set of tight topic DTDs that force tight markup. This would actually make it easier for new users to migrate to DITA.
 
Gershon
 
Gershon L Joseph
Director of Technology and Single Sourcing
Tech-Tav Documentation Ltd. 
 
Secretary, OASIS DITA Technical Committee
Secretary, OASIS DITA Translation Subcommittee
Member, OASIS DocBook Technical Committee
 
+972-8-974-1569 (direct)
+972-57-314-1170 (mobile)
http://www.tech-tav.com 


----- Original Message ----
> From: Eliot Kimber <ekimber@reallysi.com>
> To: dita@lists.oasis-open.org
> Sent: Tuesday, February 5, 2008 5:36:54 PM
> Subject: [dita] Need Clarification on Implications of Different List Markup Patterns
> 
> 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:
> 
> 


> 
> and
> 
> 

> 
> Both are allowed.
> 
> The question is: should the intervening 
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 

> 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 
elements within 
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 
should always be rendered the same regardless 
> of whether it has an initial 
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
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>