Re: Generic Markup [was:Re: deprecated tags in Wilbur & Cougar]

Paul Prescod (
Thu, 8 Aug 1996 09:33:40 -0400

Date: Thu, 8 Aug 1996 09:33:40 -0400
Message-Id: <>
From: Paul Prescod <>
Subject: Re: Generic Markup [was:Re: deprecated tags in Wilbur & Cougar]

At 10:21 PM 8/7/96 -0700, wrote:
>|Paul Prescod wrote:
>|>I wrote
>|><DIV CLASS="sidebar" ROLE="section">
>|>This construct uses the proposed CLASS attribute to invoke the CSS scheme for
>|>rendering according to class "sidebar" on this structural element that is
>|> semantically equivalent (ROLE=) to any other section.
>|I don't see why these roles (if you'll excuse the pun) must be separated.
>Presentation versus structure.  The yin and yang of presentation-focused
>structural markup.

Since when are we doing presentation-focused structural markup? I thought we
were trying to do generic, structural markup. Structural markup (in its pure
form) is about leaving presentation completetly out of the document. 

As I mentioned there, in the real world, pure generic markup is not always
economical and that is why some DTDs  add in a back-door for specifying
presentation directly (REND in TEI, STYLE in HTML).

>Standardize on structural classes (perhaps lifted from TEI) so that indexers 
>and document services can present search results or other amalgamations of 
>objects or their components in a common structural context.
>Use the presentation classes to give your pages your look and feel. 

If you have chosen your elements and classes correctly, presentation is just
a process that works on the completely structural document, in the same way
that indexing, generating a table of contents, printing and converting are
just processes. That's why it is generic: you don't put in special hooks for
ANY of the processes, even presentation.

Promoting presentation to a "special" process is a violation of the
principles of generic markup. We've already made concessions in that
direction with STYLE, but we don't have to make any more.

>There will probably be many cases with significant overlap between the two 
>classes of classes (metaclasses?), but this bifurcation relieves the 
>requirement that indexers and document management be held hostage to the 
>imperatives or the art department.

I explained how you can do this practictally in HTML in my last message. Do
you have any problems with my proposed mechanism? The art department will
have to be roped in and taught how to use structural markup or else how to
use the existant escape mechanism (STYLE).

 Paul Prescod