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
http://dita.xml.org/blog/25
Andrzej Zydron <>
06/15/2008 01:22 PM
To
Erik Hennum <>
cc
"Bruce Nevin (bnevin)" <>,
, Michael Priestley/Toronto/IBM@IBMCA
Subject
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
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
>
>
--
email -
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]
