It's way too late to do something like deprecate ditabase
in 1.1.
paul
From: JoAnn Hackos
[mailto:]
Sent: Wednesday, 2007
January 24 06:16
To: Yas Etessam;
Subject: RE: [dita] Policy Decision: Loose
or Not
I certainly agree that a loose structure has a practical
value for some activities, but it is being seriously corrupted by people who
have convinced others that DITA "does not work." They use ditabase to turn
DITA into a sequential book structure. They eliminate DITA map because it is
inconvenient and means less money for them to maintain the mess they've
created.
As Yas suggests, it might be quickly deprecated to allow
those who want intertwined bookish structures to move to
Docbook.
JoAnn
JoAnn T. Hackos,
PhD
President
Comtech Services,
Inc.
710 Kipling
Street, Suite 400
Denver CO 80215
303-232-7586
From: Yas Etessam
[mailto:]
Sent: Tuesday, January 23, 2007
6:01 PM
To:
Subject: RE: [dita]
Policy Decision: Loose or Not
Implementors
can already constrain users to
single typed topics by changing the doctype to use the appropriate
concept/task/concept/reference DTD.
In terms of conversion, there could be cases where legacy
conversion to DITA would result in a single topic with mixed
information type sub-topics.
In terms of specialization, ditabase is
intentionally lax to serve as an appropriate base for specialization.
I agree with JoAnn that authoring with ditabase might not
follow the best practice but I don't see the justification for eliminating it
for DITA 1.1.
Lets consider leaving ditabase loose and encourage
implementors to use the single-typed DTDs for the appropriate information
type. Providing a ditabase DTD for composite documents might be an
option that some users, conversion vendors and specializers might
want to keep.
Finally, this feels like a large
change given the timeline for DITA 1.1's release. If the rest of the TC
members feel strongly that it should be eliminated, I'd hope that we'd
start with deprecation rather than
elimination.
Yas Etessam
From: JoAnn Hackos
[mailto:]
Sent: Tuesday, January 23,
2007 4:10 PM
To: Dana Spradley;
Subject: RE: [dita] Policy Decision: Loose
or Not
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.
