[ This is only marginally appropriate for this mailing list; sorry. ]
[log in to unmask] (Scott E. Preece) wrote:
> If you say "But, look, this construct can't be specified in SGML" they
> would probably say (or think) "Well, that's a pretty inadequate
> formalism you chose, then, isn't it?"
Yes, I meant to bring that up.
When designing new markup, if you start with a syntax
and then try to figure out how to make SGML accept it,
you're bound to meet with frustration and conclude that
"this SGML stuff is no damn good". Just ask Dan Connolly
or Dave Raggett if you don't believe me; they've both
hit this problem several times.
On the other hand, if you start with an idea of *what you
want to encode* instead of *how you want to encode it*,
and then try to figure out how best to express that in a DTD,
the benefits of SGML's formalism become much more apparent.
I've used SGML notation to describe all sorts of complex data
structures over the last couple years, and it really does help.
More often than not, SGML's restrictions have led me to find
a better abstraction than I would have come up with otherwise.
This is not unique to SGML, either: look at how hard it is
to come up with a LALR(1) (yacc) grammar for Fortran, C++,
or even C. This doesn't mean that "this LR parsing
stuff is no damn good"; newer languages like Haskell and Modula-3
which were defined from the beginning with an LR grammar
have an amazingly clean and intuitive syntax.
Anyway, (this is the part that's marginally relevant to html-wg),
when you design extensions to HTML, it's much easier to work
*with* SGML than to work *against* it. Defining the tags
first and then trying to reverse-engineer a DTD is working
[log in to unmask]