Re: [dita] Proposal for Consideration: Default Behavior for ListItems

[Andrzej Zydron <azydron@xml-intl.com>]

Hi Eric and Michael,

Thank you both for your replies and for bearing with me. The thing that 
bothers me with spanning is that in tha vast majority of technical 
literature it is unnecessary. Allowing it, provides users with the 
ability to unintentionally completely mess up a document structure 
making it nigh on impossible to translate properly. It assumes that text 
is translated in the same order in different languages - this is 
unfortunately not the case. All this adds to the cost of composition and 
translation. It also adds considerably to the cost of implementing 
composition engines.

We have had recent evidence of the type of horror story that can arise 
during translation from the injudicious use of conrefs. Conrefs work 
fine in morphologically impoverished languages such as English and 
Chinese, but can deliver ungrammatical gibberish when you try and 
translate the text into any inflected language.

I would be so bold as to propose a definitive subset of DITA, lets call 
it for arguments sake EDEN (Electronic Documentumentation Essential 
Norm) as a 'creationist' counterpoint :). EDEN would be a completely 
valid DITA form but would not allow the following constructs:

1) Recursive elements - no recursion
2) Block spanning elements - only inline elements allowed within block 
elements
3) Conrefs - replaced by xrefs for linguistically complete phrases or 
sentences
4) Specialization past the basic Topic, Concept, Task and Reference - no 
specialization

The analogy of EDEN to DITA is the same as SGML to XML. EDEN would be a 
low complexity and low cost way of implementing DITA for organizations 
that do not require the full current armory.

In my extensive and (over-)long experience in the authoring and 
localization of very complex documents in the automotive and light 
engineering industries there has been a marked tendency towards 
simplification - very short granular documents with lots of graphics and 
little text. The granularity of DITA lends itself to short simple 
documents with no need of the aforementioned mechanisms. Keeping things 
simple keeps down the cost and speeds up implementation and tool delivery.

The most effective DITA implementations that I have seen to date have in 
fact followed the EDEN principle. Lets leave the whole panoply of DITA 
to those who need it, but for 95% of implementations EDEN would suffice.

The easier and less complex that we make it, the more acceptance it will 
gain. When you strip everything away the main benefit of DITA has been 
to provide a standard set of DTDs for technical documentation.

Best Regards,

AZ

Erik Hennum wrote:
>
> Hi, Andrzej, Bruce, and Michael:
>
> Not to protract the thread, but Jim Early and Scott Hudson (I think) 
> had the insight based on their mapping work that the DITA block 
> elements are correctly understood as block containers.
>
> That is, the start tag and end tag declare block boundaries, but the 
> element itself can contain multiple blocks, as in:
>
> ... <section>
> ....... First block.
> ....... <p>
> ........... Second block.
> ........... <lq>
> ........... Third block
> ........... </lq>
> ........... Fourth block.
> ....... </p>
> ....... Fifth block.
> ... </section>
>
> From a processing perspective, there's nothing ambiguous about that. 
> The processor can find the block boundaries without issue.
>
> From an authoring perspective, it is attractive to be able to avoid 
> unneeded markup (extra noise) when a list item has a single block.
>
> ....... <li>Single block.</li>
>
> but take advantage of additional markup for multiple blocks:
>
> ....... <li>First block.
> ........... <p>Second block</p>
> ....... </li>
>
> People have been doing without issue in HTML for ages.
>
> So, the big question is whether authors are significantly more likely 
> to abuse the markup as follows:
>
> ... <section>
> ....... A sentence spanning
> ....... <p>A paragraph.</p>
> ....... before finishing.
> ... </section>
>
> Than as follows:
>
> ... <section>
> ....... <p>A sentence spanning</p>
> ....... <p>A paragraph.</p>
> ....... <p>before finishing.</p>
> ... </section>
>
> The markup itself can no more prevent the second case than the first.
>
> Neither usage would occur to me. Are there are a significant number of 
> users who would create the first but not the second example?
>
>
> Hoping that's useful,
>
>
> Erik Hennum
> ehennum@us.ibm.com
>

-- 
email - azydron@xml-intl.com
smail - c/o Mr. A.Zydron
	PO Box 2167
        Gerrards Cross
        Bucks SL9 8XF
	United Kingdom
Mobile +(44) 7966 477 181
FAX    +(44) 1753 480 465
www - http://www.xml-intl.com

This message contains confidential information and is intended only for
the individual named.  If you are not the named addressee you may not
disseminate, distribute or copy this e-mail.  Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses.  The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.  If verification
is required please request a hard-copy version. Unless explicitly stated
otherwise this message is provided for informational purposes only and
should not be construed as a solicitation or offer.


begin:vcard
fn;quoted-printable:Andrzej Zydro=C5=84
n;quoted-printable:Zydro=C5=84;Andrzej
email;internet:azydron@xml-intl.com
tel;work:+441494558106
tel;home:+441494532343
tel;cell:+447966477181
x-mozilla-html:FALSE
version:2.1
end:vcard