OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] Re: Discuss list processing expectations


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:troy.klukewich@oracle.com]

> 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: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

> >

>

>

>

>

>

>

> ---------------------------------------------------------------------

> 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

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]