Please see Michael’s comment on my
comment.
JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
303-232-7586
joann.hackos@comtech-serv.com
joannhackos Skype
www.comtech-serv.com
From: Michael
Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Monday, April 14, 2008 12:37
PM
To: JoAnn Hackos
Cc: DITA TC List; Gershon L Joseph
[Yahoo]; Robert D Anderson; Rob Frankland
Subject: 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
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"JoAnn Hackos"
<joann.hackos@comtech-serv.com>
04/14/2008 02:04 PM
|
To
|
"Rob Frankland"
<robf@sockmonkeyconsult.com>, Michael Priestley/Toronto/IBM@IBMCA,
"Gershon L Joseph [Yahoo]" <gljoseph@yahoo.com>
|
cc
|
"DITA TC List" <dita@lists.oasis-open.org>,
"Robert D Anderson" <robander@us.ibm.com>
|
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
joann.hackos@comtech-serv.com
joannhackos Skype
www.comtech-serv.com
From: Rob Frankland
[mailto:robf@sockmonkeyconsult.com]
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:mpriestl@ca.ibm.com]
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
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"Gershon L Joseph \[Yahoo\]"
<gljoseph@yahoo.com>
04/08/2008
11:51 AM
|
To
|
Robert D Anderson <robander@us.ibm.com>, DITA TC
List <dita@lists.oasis-open.org>
|
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 <robander@us.ibm.com>
> To: DITA TC List <dita@lists.oasis-open.org>
> 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