RE: [dita] Re: Discuss list processing expectations

From
Michael Priestley <>
Date
2008-04-14T18:39:36+00:00
ID
Thread
RE: [dita] Re: Discuss list processing expectations
Semantically the following two constructions
are equivalent:

<p>There are three things: one,
two, three.</p>

<p>There are three things:

<ul>

<li>one</li>

<li>two</li>

<li>three</li>

</ul>

</p>

If the segmentation rules don't work
with the second case, shouldn't that mean the segmentation rules need updating?
This won't be unique to DITA.

Michael Priestley

Lead IBM DITA Architect 



http://dita.xml.org/blog/25

"JoAnn Hackos"
<> 

04/14/2008 02:04 PM

To

"Rob Frankland" <>,
Michael Priestley/Toronto/IBM@IBMCA, "Gershon L Joseph [Yahoo]"
<>

cc

"DITA TC List" <>,
"Robert D Anderson" <>

Subject

RE: [dita] Re: Discuss list processing
expectations

We have discussed some of the
list processing issues in the context of translation. The segmentation
rules that are supported by XLIFF create segments where tags begin and
end, unless a tag is explicitly defined as an inline element. The inline
element requires no separate segmentation so that <uicontrol> in
line in a sentence does not create three segments, one before, one after,
and the word itself. Generally the translator can mouse over an inline
word to see what the markup is.

 

However, including the list
within the paragraph tag does create segmentation problems because the
<p> segment does not close until after the <li> segments. For
that reason, translation best practice leads to the following (as we have
discussed):

 

<p>blah blah:</p>
[this represents the stem sentence for the list]

<ul><li>bullet
1</li>

<li>bullet2</li>

</ul>

 

If the writer places the <ul>
or <ol> inside the <p> tags, the segmentation rules do not
break the sentence parts correctly. Remember that many stem sentences are
complete sentence rather than phrases (generally the subject of the sentence
this is completed by the list items). The <li>s can also be complete
sentences.

 

JoAnn

 

JoAnn T. Hackos, PhD

President

Comtech Services, Inc.

710 Kipling Street, Suite 400

Denver, CO 80215

303-232-7586



joannhackos Skype

www.comtech-serv.com

From: Rob Frankland [mailto:]

Sent: Tuesday, April 08, 2008 11:27 AM

To: 'Michael Priestley'; 'Gershon L Joseph [Yahoo]'

Cc: 'DITA TC List'; 'Robert D Anderson'

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

 

Michael’s second point is exactly the one
I was trying to make on the call today. I have had clients with house styles
that require such mixed content. I want DITA to be able to be used by the
widest possible community. To that end, Michaels’ advantage and disadvantage
approach lets the user decide the course of action most desireable for
there situation.

 

Rob

 

Rob Frankland

Sock Monkey Consulting, LLC

12408 Kallgren RD NE

Bainbridge Island, WA 98110

 

 

 

From: Michael Priestley [mailto:]

Sent: Tuesday, April 08, 2008 9:52 AM

To: Gershon L Joseph [Yahoo]

Cc: DITA TC List; Robert D Anderson

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

 

In what sense is that list "inline"? It defines the start of
a new block. It does so within the context of an existing block. You can
also nest lists inside other lists, or inside table cells.

And to reiterate, I am against any best practice that says users "should"
avoid mixed content models. I am ok, per Jeff's suggestion, with a best
practice that lays out the advantages and disadvantages of each approach.

Michael Priestley

Lead IBM DITA Architect 



http://dita.xml.org/blog/25

"Gershon L Joseph \[Yahoo\]"
<> 

04/08/2008 11:51 AM

To

Robert D Anderson <>,
DITA TC List <>

cc

 

Subject

Re: [dita] Re: Discuss list processing expectations

 

 
 

This time hopefully without the Yahoo junk...

I'm still against using the same element in both block and inline contexts.
If DITA provided an <inline-ul> (or whatever) for use in the example
Paul gave I'd be OK with it. I still feel that block elements should be
used only in block contexts, and inline elements in inline contexts. Paul's
example would then be marked up as follows:

<p>In order to install Acme Pro Plus Plus, your system must

meet the following requirements:

<inline-ul>

 <li>Pentium 4 CPU or later</li>

 <li>1 GB RAM or more</li>

 <li>At least 350 MB free disk space</li>

</inline-ul>

unless you are running the Limited version of the product.

</p>

Obviously we're not going to change the DTDs for 1.2, but perhaps we could
consider an inline unordered list element for a future release, when we
can improve on the current situation where <ul> functions as both
block and inline.

For 1.2, maybe we should provide Paul's example as an exception to the
general rule, and maybe even state that a future DITA release may provide
a different inline element for this purpose?

Note also I said the spec should encourage the best practice via "should",
so users using mixed markup are not going against the spec.

Gershon

----- Original Message ----

> From: Robert D Anderson <>

> To: DITA TC List <>

> Sent: Tuesday, April 8, 2008 5:18:01 PM

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