dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Re: Discuss list processing expectations
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Gershon L Joseph \[Yahoo\]" <gljoseph@yahoo.com>
- Date: Tue, 15 Apr 2008 08:51:32 -0400
DocBook allows list inside paragraph,
just like DITA.
HTML allows a mix of blocks and paragraphs
in other contexts like inside a list item.
So this is not unique to DITA.
If the current segmentation rules are
at odds with the rules of many major markup languages and a large body
of users disagrees with them, whose interests are being served by protecting
the existing segmentation rules?
Which is easier to update, several major
authoring markup languages plus all authoring community best practices,
or XLIFF?
Note: I would say *all* the major markup
languages, but I only checked two besides DITA.
Michael Priestley
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"Gershon L Joseph
\[Yahoo\]" <gljoseph@yahoo.com>
04/15/2008 05:23 AM
|
To
| Michael Priestley/Toronto/IBM@IBMCA,
JoAnn Hackos <joann.hackos@comtech-serv.com>
|
cc
| DITA TC List <dita@lists.oasis-open.org>,
Robert D Anderson <robander@us.ibm.com>, Rob Frankland <robf@sockmonkeyconsult.com>
|
Subject
| Re: [dita] Re: Discuss list processing
expectations |
|
Actually, this is largely unique to DITA.
When I worked with DocBook and proprietary DTDs, we never allowed this
sort of markup. The authors had an easier time (the DTDs were stricter,
so it was obvious how they should mark up their content) and translation
worked as expected. If DITA had a different element for the "embedded
list" or whatever you want to call it, then translation tools could
be configured to treat the list embedded in the paragraph as an in-line
element (assuming marking up an embedded list inside a paragraph is good
practice, which I don't believe it is). But when the same elements are
used in so many contexts, as is the case with DITA, the translation tools
can't accommodate every case correctly, and the result is increased localization
costs and inferior translations. So many companies are not realizing the
ROI on their DITA migrations, largely because of issues that arise during
translation. Considering that many of these companies move to DITA to save
translation costs, the team leaders end up looking stupid when the promised
ROI is not there and they have to explain why.
So long as you are working in a single language,
you can mark up however you wish. When you start translating, bad markup
comes back to bite you... (So does incorrect use of variables and conditional
text...)
Gershon
----- Original Message ----
From: Michael Priestley <mpriestl@ca.ibm.com>
To: JoAnn Hackos <joann.hackos@comtech-serv.com>
Cc: DITA TC List <dita@lists.oasis-open.org>; Gershon L Joseph [Yahoo]
<gljoseph@yahoo.com>; Robert D Anderson <robander@us.ibm.com>;
Rob Frankland <robf@sockmonkeyconsult.com>
Sent: Monday, April 14, 2008 9:37:22 PM
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]