RE: [dita] Re: Discuss list processing expectations

["Troy Klukewich" <troy.klukewich@oracle.com>]

For what it is worth, I've always found attempts to make lists "read:" 

* like a paragraph, 
* sometimes with punctuation interspersed,

odd.

:-)

I've even seen nested lists that attempt to maintain some semblance of paragraph grammar down the nesting. The usage is awkward.  Myself, I use lists purely for parallel constructs or sequential steps. I never attempt to construct a literal paragraph using a list. For kicks, I checked the Oracle Style Guide and it explicitly forbids it.

So the list processing problem really speaks to what Style Guide authors (not necessarily individual writers) consider best practice in the construction of lists. If processing enforces a strict practice per some (possibly arbitrary) style guide, a good number of implementations will be alienated because their style guide does not in fact support the specific list practice.

To support my own practice, I personally would prefer to have some required constructs around lists that would prevent paragraph usage of the list itself and require paragraph processing for textual elements within lists. But that's just me.

I've always thought of the <p></p> element itself a bit more abstractly as a container for certain permissible actions on general text, not so much as a literal expression of a semantic paragraph construct with syntax and punctuation. So I don't mind it being used to constrain text behavior within certain textual contexts, like a list element.

It seems to me that the current neutral or "weak" DITA processing that allows stylistic flexibility in lists may be the only real-world approach.

I see two potential solutions for more rigorous list processing:

* Do nothing. Let DITA editor applications optionally enforce a list style. If I remember correctly, Arbortext Editor does not implement a style, but Frame 8 inserts <p> (I think) inside each <li> element automatically (I guess after DocBook). So the editor implementation of lists is flexible. It would be nice if editors allowed flexible configuration of list styles outside the OT.

* Add an optional "strong" processing flag or mode to the OT per some style guide that requires lists of a certain construct. This would mean selecting some style guide as an authoritative reference. (Best of luck with that.) ;-) This could mean that list "style" is validated outside of schemas. Alternatively, it might be better to provide options in the schemas/DTDs themselves to turn on or expose strong validation of list structure if desired. 

Personally, I like the optional flag or mode idea. The OT could have an implementation neutral or implementation specific approach for certain elements. The trick, though, would be finding some authoritative style manual as a model of best practices, a kind of Chicago Manual of Style for DITA.

HTML Tidy is a useful technical reference. It has all kinds of settings depending on how strict or lax you want to be for processing HTML elements. Some of the settings are arguably purely a matter of style.

Troy Klukewich
Information Architect
Oracle

-----Original Message-----
From: Robert D Anderson [mailto:robander@us.ibm.com]
Sent: Tuesday, April 08, 2008 7:18 AM
To: DITA TC List
Subject: RE: [dita] Re: Discuss list processing expectations


I'd second what Paul says - I know a lot of users who would get upset if
the spec told them they could not include the samples Paul gives inside a
single paragraph.

To respond to one of Gershon's samples -- I would tend to agree that having
something like this
   <p>This list says: <ul>...</ul>[punctuation]</p>
or this
   <p>This here is <pre>MARKUP</pre>[punctuation]</p>
with only punctuation after the block is never going to format in a good
way. I don't mind people calling that bad markup, and I do not know anybody
who uses it intentionally. However, it's a necessary evil to allow that in
the DTD if you also allow paragraphs like this one. The two variations
should not be given the same weight in a Best Practice statement.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)

"Grosso, Paul" <pgrosso@ptc.com> wrote on 04/08/2008 09:01:54 AM:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>