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.
|