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] Proposal for Consideration: Default Behavior for List Items

Hi Andrzej,

I think the idea of providing a constrained environment per 1) and 2) is fine, and we can figure out the best way to do this for 1.3, as I proposed earlier. My gut reaction is that we won't be using the constrained environment here at IBM (our translation processes may not be perfect, but they are working with the current design). But we're talking a valid package of constraints that could be applied to a core set of DITA content types, which is explicitly one of the goals of the new constraints mechanism proposed for DITA 1.2. So as long as you can find two people who will use it (and I'm sure you can), I can see a case for getting it on the slate for DITA 1.3.

That said, I have serious concerns about your proposed 3 and 4 (eliminating conrefs and specialization).  

Re conrefs: I can certainly see a constraint package being used to selectively reduce conrefs (eg only allowing them on certain element types). But eliminating DITA's standard reuse mechanism and replacing it with another would break interoperability between the proposed constrained type and the rest of DITA: it would no longer be constrained DITA, it would be an alternative to DITA. Note that just because I am rejecting your proposed solution (using xrefs) doesn't mean I am rejecting your reasons - I would like to understand your reasons, so I can help us arrive at a solution that is acceptable to as many people as possible.

Re specialization: People don't have to specialize if they don't want to. But creating a content type that couldn't be specialized by those who do want to would certainly break the current definition of DITA. If you really wanted to do this, I would think it could be created as a parallel standard that borrows heavily from DITA, but I would resist calling it DITA, or endorsing it in any way through this group. Specialization is too central to the definition of the standard. It doesn't need to be exercised by every user, but it needs to always be an option.

Michael Priestley
Lead IBM DITA Architect

Andrzej Zydron <azydron@xml-intl.com>

06/15/2008 01:22 PM

Erik Hennum <ehennum@us.ibm.com>
"Bruce Nevin (bnevin)" <bnevin@cisco.com>, dita@lists.oasis-open.org, Michael Priestley/Toronto/IBM@IBMCA
Re: [dita] Proposal for Consideration: Default Behavior for List Items

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
3) Conrefs - replaced by xrefs for linguistically complete phrases or
4) Specialization past the basic Topic, Concept, Task and Reference - no

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,


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.

[attachment "azydron.vcf" deleted by Michael Priestley/Toronto/IBM]

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