Re: deprecated tags in Wilbur & Cougar -Reply -Reply

I don't know if any of you remember my SPAM DTD:

<!DOCTYPE spam [
<!ELEMENT spam - - (#PCDATA|SPAM)*>
<!ATTLIST spam   ID    ID     #IMPLIED
                 RID   IDREF  #IMPLIED
                 CLASS CDATA  #IMPLIED>
    <SPAM CLASS="TITLE">This is a title</SPAM>
    <SPAM CLASS="P">This is a paragraph</SPAM>

I often use this when teaching people about DTD design and what is
good markup. This DTD has uses, but I think we all agree that this is
*not* the best way to markup important documents.

The point with this DTD is that you can represent the structural, and
presentational markup in a very large number of ways. At the purest
level, the information structures represented are the same, or at
least contain the same amount of information (ie. you can translate
between them, though in practise, it may be non-trivial to do so).

The real point of good markup is to <EMPH>select the data
representation most appropriate for the task at hand</EMP>, and as
people, and needs differ greatly, the choice of representation should
be in the hands of people creating the documents.

People snickered when I suggested last year in Boston that tag
explosion might just be the best thing that could ever happen to the
WWW. My point was that a single DTD, combined with a simple
stylesheet language like CSS, can never meet the needs of *all* WWW
users. As Jeff Yemin and others have pointed out, that road just leads
to the tag set becoming static, and the stylesheet language being
extended over and over again.

The bottom line for my thought on HTML is that SGML must come to the
WWW. However, I think that *full* SGML is probably too much burden on
browser writers (ie. even though James Clark has an excellent parser,
I'd hate to have to require that all browsers use it). This is the
reason why I have suggested that the WWW support something like the
TEI subset, which offers a great deal of functionality, *and* can be
implemented using yacc and flex. Even if TEI is not used, the W3C
should perhaps come up with an *application profile* for SGML, that
restricts it to something like minimal SGML with an extended character
repertoire, and removing some of the hairier peices (for example, some
of the silliness with marked sections and entities).