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] RE: Definitions in the DTD

Deborah Aleyne Lapeyre <dalapeyre@mulberrytech.com> wrote on 02/01/2005 11:50:57 AM:

> 2) I think that having
>   - an expansion of the element type name
>   - a basic definition in the DTD
> *aids* reading the DTD, rather than the reverse. I, for example,
> had not idea what a "vrmlist" was.
> But we should debate that.

I would agree that a long name, at least, might be helpful. The
potentially global aspect of DITA uptake might be one reason to
limit the amount of embedded English prose, and maximize how we
use the translateable assets of our Language Reference topics.

> I also feel that base definitions to not change when edge cases
> get added or the usage migrates slightly. I have almost never needed
> to update DTD "definitions" even when the content model and context
> changed 180 degress..

Erik Hennum and I often use "element" as the quintessential semantically-
differented word in discussions like this. Do you mean the name of the XML
node, the chemistry usage, the database usage, or the stove part, among
others?  Not that the base definition would change--these are all domains
based mainly on keyword, I presume.  My point is that they cannot all point at
same definition, yet each one, qualified by its domain attribute, can link
to a unique definition. Here are some other examples:

Some Java-based XML editors provide F1 bindings from their element
selection menus to JavaHelp based reference topics.  This provides nice
contextual help for writers. Schemas as XML documents might have very
much this same behavior, only lacking the expanded view of content models
implied by model group references.

The "type" attribute in the language reference has 6 or 7 different
definitions. I maintain all of them in one document--the commonLRdefs
file--and conref the appropriate one wherever it is needed. I had to
give each row of definition a different id qualified by its parent
element name, which gives unambiguous lookup from the topics.

Don Day <dond@us.ibm.com>
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
11501 Burnet Rd., MS 9037D018, Austin TX 78758
Ph. 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

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