RE: Definitions in the DTD

[Deborah Aleyne Lapeyre <dalapeyre@mulberrytech.com>]

I admit I have gotten spoiled. I treat a DTD as I would a schemas,
embedding documentation in it and generating the equivalent
of the language spec from that documentation. That said:

1)  I too am against duplicative maintenance. I guess it has always
been my experience that nobody updates language specs and you trust
what is in the DTD, period. They had to change the code, so you
hope they changed the comment to match. Given that there will be
a committee  keeping the language spec current, that is my
silly prejudice and a non-issue.

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


3) However, I have no objection to removing ALL definitions from the DTD
If that makes it easier, cool.

4) What is the vote on Long element names?

--Debbie
-- 
======================================================================
Deborah Aleyne Lapeyre               mailto:dalapeyre@mulberrytech.com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9633
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
   Mulberry Technologies: A Consultancy Specializing in XML and SGML
======================================================================