DTD power / features / extensions

   At least as long as we don't add power beyond SGML, we should allow a
free hand to make DTD definition more convenient (I will stick with the
conventional terminology, but I certainly endorese some kind of DSD).

   This means that we should have named attribute lists that can inherit
from each other, and that can be applied to any element. We should be able
to apply several attrinbute lists to one element.

   We should be able to have what you might call "reverse element
declarations":  we should be able to name contexts where an element might
appear, and add elements to these contexts without resorting to parameter
entity hackery.

   We should have a way to declare a "soup" type element that contains
character strings, and some number of other elements (that might use
reverse declarations). We should even consider, but not necessarily adopt,
(Liam's?) suggestion that all complex content models look like this. I
think that this is overkill, myself. It makes things like bibliographies,
database conversions, and other (semi-)rigid structures harder to define.
If we have tightly structured elements we also have a more elegant solution
to the program input problem: Why shouldn't a style sheet specify that some
elements are rendered by passing a parse tree to a specified lava program?
Pre-parsed input works great for lisp!

   I think we need exclsion exceptions because we need an easy way to make
footnotes work without hackery.

   These things are all easy to compile to SGML, so we should not let
SGML's lack of these features slow us down.

   -- David

   RE delenda est.

David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________