This is my position exactly. Let's eliminate ditabase. I'm
attending a meeting this week battling with a "consultant" who has used ditabase
to recreate docbook inside a dita topic.The entire book is in one topic. It's
infuriating that people want to corrupt the entire concept.
JoAnn
JoAnn T. Hackos, PhD
President
Comtech Services,
Inc.
710 Kipling
Street, Suite 400
Denver CO 80215
303-232-7586
From: Dana Spradley
[mailto:]
Sent: Tuesday, January 23, 2007
5:04 PM
To:
Subject: Re: [dita]
Policy Decision: Loose or Not
Then the most logical choice would be to eliminate
ditabase from the standard - and let implementors do their own ditabases as a
practical measure, if they want to give authors a way of writing non-conformant
topic collections prior to splitting them up into conformant
topics.
--Dana
W. Eliot Kimber wrote:
Dana
Spradley wrote:
This would be a rather extreme change of policy,
wouldn't it?
As I understand it, ditabase is expliticly
*non*-normative, and as the spec currently says any nesting or other
arrangement of topics in it "has no particular output implications; it
simply allows you to create multiple topics of different types at the same
level in a single document."
Unless I've completely
misunderstood the implications of how things are delivered, all the
declarations are normative. That is, the DITA standard consists of the
architecture specification, the language reference, and the accompanying DTD
and XSD declarations, all of which are normative.
That is, the very
fact that we need to have language in the language reference about when
different containment rules apply indicates that we have two different but
normative rules.
If it wasn't normative then we wouldn't have the
language in the spec.
Cheers,
E.
