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

Gavin Nicol <gtn@ebt.com> wrote:
|In the down translation process:
|1) Why do you need to preserve the SGML structure?

Gavin,

Because at this time its easier for indexers to read data in THE well-known
DTD, HTML, and derive any structural information (mapped from an arbitrary rich
DTD into HTML's generic structural elements) through a (hopefully) standard set
of structural attribute values.

|2) If you need to preserve the structure, why not just send the SGML?

In the future, yes.

But right now, the task of reading an arbitrary DTD and determining the
semantics of the structural elements consistently across multiple DTD's is a
very large one.  It is desirable to collect data from various sources, perhaps
with different DTD's, and combine them into a collection presented to a user
that hides those original structural differences.

How can you establish structural context amongst objects encoded in various
DTDs, and how can you do this earlier than six months after Cougar is
finalized?

|3) Given an application that can derive structure from attributes,
|   don't you think it would be a trivial matter (indeed, in some ways
|   easier!) to derive the structure from GI's?

When/if conforming SGML systems become ubiquituous (and the HTML-2.0 spec sits
roped off and archived next to the info.cern.ch box at some future WWW
conference) yes.  But how do you establish equivalence classes between GI's
from multiple different DTD's, assuming that HTML's tagset is to stay static
(see HTML evolution considered harmful)?

Isn't it easier, given current realities and constraints, to downtranslate into
HTML using standardized structural classes (that may or may not coincide with
the style classes) than to attempt to distill the structural semantics of the
latest product from Jeff & Akbar's DTD Hut into some other form that can be
compared with other DTD's?

|4) Given the interaction between GI and attribute selectors, doesn't CLASS
|   complicate stylesheet writing as compared to pure GI's?

I haven't written a style processing language, so I can't say for sure, but
powerful functionality usually implies a higher level of complexity.  When the
content provider$ demand functionality, they usually get what they want
first...

In response to part of your msg from last night, I'd gathered the notion of
grafting relevant parts of a "real" DTD onto HTML was off the table as far as
Cougar was concerned.  I can, however, see a nice migration path towards that
more ideal solution if standardized structure and presentation can be separated
in Cougar's proposed classing scheme.

>From another msg:
|How many attributes did you propose?

The debate earlier on STYLE attributes proposed one.  CLASS proposed a second.
Both of these attributes are included in the Cougar DTD.  ROLE that I propose
would be a third.

STYLE="css: blah"      - inline style modifications
CLASS="as specified"   - class for style
ROLE="new"             - class for structure

|I have a fundamental problem with this. People hsould be allowed to
|use the structures most applicable to the task they wish to
|accomplish.

You can do that right now, but nobody will be able to read your data on the
network for several years.

For now, store richer, serve poor(er).  Use complex structural markup behind
the server and serve for maximum interoperability using a common subset such as
HTML enriched with structural hints alongside the style hints.

|They question is "what is the most readily comprehensible, and usable
|representation of the information?".

Depends on the applications that will process the data before it gets served,
the nature of the data, the set of devices the resource will be rendered to...

The new W3C SGML ERB, though, is a Very Good Thing.

-marc

--

Received on Thursday, 8 August 1996 18:49:50 UTC