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

>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.

If they can parse HTML and derive structure from attribute values, and
actually make use of that structure, they can do the same for GI's. In
fact, for indexing purposes, you'd probably get better indexes built
(you can search by containment and attribute values).

>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?

Using <META> (though this requires a bit more work), or some external
mapping specification (perhaps bring back <RENDER> for the external
mapping file).

I should note that your question is actually fundamentally deeper than
just HTML. The problem of DTD equivalency is a very difficult one,
though architectural forms can help.

>|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 this case, it's the opposite. The complexity is generally not
useful at all. Qualifying styles based on ancestry is useful, and
using attributes as selectors for the leafs is, but once you combined
them together, you need a quite sophisticated engine (ie. just
checking a tag stack vs checking a tag stack, and gi + attribute
values on all contained elements).

>|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.

Your example used COLOR...

>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. 

This is pretty much what DynaWeb does today.

My real point is this:

I can understand the desireability to map to HTML for some
purposes. However, the use of the mechanisms you are talking about
would head to HTML that looks like this:

    <BODY CLASS=BOOK>
       <H1 CLASS=TITLE>My Book</>
       <DIV CLASS=CHAPTER>
          <H2 CLASS=TITLE>My first Chapter</>
          <P CLASS=QUOTE>They were the best...</>
          <P>This is some text...
       </DIV>
    </BODY>

or perhaps

    <P CLASS=CHAPTER>
       <P CLASS=TITLE>...</>
       <P CLASS=QUOTE>...</>
    </>

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.

Received on Friday, 9 August 1996 15:08:44 UTC