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

At 07:06 PM 8/9/96 GMT, Gavin Nicol wrote:

>In both cases, I cannot see why anything that can actually *use* the
>structure shown by the CLASS attribute for anything beyond style
>selection, cannot also use a form that uses GI's. Internally, the
>application would need to be quite sophisticated to make good use of
>attributes like CLASS, so they would more than likely contain more
>than enough functionality to handle arbitrary GI's.

I agree. There must be some deeper confusion on the part of those who like
CLASS so much. 

There are good reasons to promote the extension of standardized markup
through GIs, and there is no conceivable difficulty in implementing the
recognition of GIs vs. attributes; these two goals compete only in the
marketplace and in the minds of implementors who rely on (or ally with)
commercial agents who have already come down hard against extensibility.

The structural approach is a well elaborated methodology that facilitates
the development and use of structure controlled systems, reducing certain
costs in some situations and increasing the shelf-life and value of the
data. In simple cases, there are real advantages to using the GI approach
instead of attributes. More generally, using a DTD to specify the structural
rules for an application has significant advantages for some applications,
but this is not a high priority for most browser developers. 

The only conceivable reason to prefer the attribute syntax to distinguish
elements is to work around the limitations of user agents that cannot (or
will not) allow some other means of extensibility, i.e. where there are two
separate processing systems and the second one wants to hide its information
within the data controlled by the first. This is what we see in cases like
CSS or plug-ins that work with HTML that need to infer additional meaning
from element classes. This tension is a serious problem for users of
browsers from vendors that want to lock in a proprietary syntax. (I'm not
naming any names here.)

Implementors and customers allow themselves to be pushed around by vendors
who claim it is difficult to support extensibility when in truth the vendors
simply don't want to. As SGML implementors know well, it is *not* necessary
to use a big hairy validating SGML parser, it is not even necessary to use a
DTD, to develop a processing system that makes use of SGML data in a way
that conforms to a reasonably well specified application domain. As you say
it is no harder, it may even be easier to add processing semantics for
<SECTION> than for <DIV CLASS=SECTION> or whatever. The mechanism for
extending the system, if not through DTDs etc., need only involve human
communication, the exchange of email and standards documents etc.  An even
better concession to extensibility through GIs is support for style sheet
language(s) to separate format from content.

Ironically, CSS may get us out of the HTML extensibility trap, but only if
we're willing to adopt the GI approach in combination with standard HTML
elements for non-conforming browsers. For many applications the combination
of HTML and CSS will allow for a reasonable decoupling of browser semantics
and generic identifiers without resorting to attributes.  I suspect we will
see HTML user communities inventing their our own (slightly baroque) tag
languages that work in all browsers. Consider as a slightly wacky example:

<RECIPE>
<HTML>
<TITLE>Hot pudding</TITLE>
<BODY>
<INGREDIENTS>
<UL>
<INGREDIENT><LI>cumin powder, 2g
<INGREDIENT><LI>tapioca, 5g
<CAUTION style="color: fuscia">
<EM>Do not put in too much tapioca!</EM></CAUTION></UL>
</UL>
 ...

I'm no language designer, I'm quite sure a better recipe DTD that
incorporates HTML could be invented.  A recipe processing plug-in for
Netscape would surely be a big hit. (We all know what those home computers
are really doing.)

Alas many browser writers and users are needlessly intimidated by even the
simplest SGML concepts, and this is one of the simplest concepts behind SGML.

Taking the high road requires "discipline" and "sharing" and "cooperation"
and stuff like that.  On the plus side such applications get to call
themselves "open" and "extensible" etc.

/kmc

Received on Friday, 9 August 1996 18:10:16 UTC