Among other things Troy wrote:
> If I remember
correctly, Arbortext Editor does not implement a style ....
You can configure Arbortext Editor to insert a <p>
within a list item if you want. It isn't the out-of-the-box default for DITA
documents. This is done in the ContextTransformations section of the .dcf
file. Because this isn't something that is specified in the DTD or
Schema, it isn't enforced and an author could delete the <p> after it is
inserted if they wish. So it is more of an authoring aid or shortcut.
-Jeff
> -----Original Message-----
> From: Troy Klukewich
[mailto:]
> Sent: Tuesday, April 08, 2008 12:06 PM
> To: DITA TC List
> Subject: RE: [dita] Re: Discuss list processing
expectations
>
> 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:]
> 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" <> wrote on
04/08/2008 09:01:54 AM:
>
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
