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] 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 T. Hackos, PhD
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver CO 80215



From: Dana Spradley [mailto:dana.spradley@oracle.com]
Sent: Tuesday, January 23, 2007 5:04 PM
To: dita@lists.oasis-open.org
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.


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.



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