What edits was Eliot suggesting?
I thought he was suggesting making ditabase normative as our compound
document model.
As for edits, I would suggest making it clearer in the spec that the
dita element in ditabase is an element like required-cleanup: a stop
gap, and not the normative compound model.
This is already implied in the spec through the language about it
ditabase having no output implications, and not being suitable for
specialization.
But apparently this was ambiguous enough for even Eliot to be confused
about its normative nature.
Can we make it more explicit that the dita element is non-normative?
--Dana
Don Day wrote:
>Time to move the conversation back to Eliot's suggestion for edits that
>improve how the compound document type is represented in the 1.1 Spec.
>
>As Eliot points out, a generalized specification offers multiple paths of
>opportunity for knowledgeable users, which is the historical reason why it
>was in IBM's original donation for the Spec. It has been incredibly useful
>as a migration staging ground, a storage BLOB, for writing the original
>developerWorks articles that defined DITA, as a single container for many
>kinds of conref targets, and surely much more. Implementors who care
>deeply about using schemas to constrain the authoring options (truly making
>the system "damnfoolproof" if that were possible) can easily banish the
>ditabase.dtd from their systems, specialize their DTDs to eliminate nesting
>options, and more--that is the power of a sufficiently generalized system.
>Insofar that the compound document type is already a widely deployed aspect
>of DITA's approved design, let's keep the focus on getting to Committee
>Draft.
>
>Regards,
>--
>Don Day
>Chair, OASIS DITA Technical Committee
>IBM Lead DITA Architect
>Email:
>11501 Burnet Rd. MS9033E015, Austin TX 78758
>Phone: +1 512-838-8550
>T/L: 678-8550
>
>"Where is the wisdom we have lost in knowledge?
> Where is the knowledge we have lost in information?"
> --T.S. Eliot
>
>
>
