W3C home > Mailing lists > Public > www-style@w3.org > August 1996

Re: Generic Markup

From: Marc Salomon <marc@ckm.ucsf.edu>
Date: Wed, 14 Aug 1996 11:33:35 -0700
Message-Id: <9608141133.ZM9839@gaia.ckm.ucsf.edu>
To: www-html@w3.org
Cc: www-style@w3.org
|>karben@interactive.wsj.com wrote
|>Generic Markup Solutions for browsers won't be useful if the competition
|>centers around just how content looks. Generic Markup's strengths lie in how
|>readers -- and not just authors -- could make that content act.

Its nice to hear someone from the commercial content provision corner--
especially one whose product, at least in print, is differentiated by
presentation--say this.

Any chance of saying this on the WSJ print editorial page? :)

|Gavin Nicol <gtn@ebt.com> replies:
|This is one point I've been trying to make, the other is that people
|who create content should be allowed to use whatever representation
|they think is best.

I don't think that any of this discussion or HTML's evolution over the past two
years has prevented anyone from representing their information in the format of
their choosing, at least behind the server.

This thread began addressing how the Cougar proposal's class mechanism tied
presentation and structure together too tightly for my tastes, and then moved
on to talk about larger issues of how arbitrary structure effects
interoperability and interchange.  Content providers will not be able to serve
content in whatever representation they see best, since a metastandard for
interchange representations will not be deployable on the WWW until at least
the next 6-18 months.

For the mid-term, content originators will have to translate to a common
interchange language, HTML 3.Cougar if they want to make their content
available to the widest audience with the least loss of information.

Returning to this example:

>        <div class="FrontSection">
>                <div class="EconomyPage">
>                        <div class="Summary">
>                                <p>Greenspan announced ...

In this example, you can derive context through heirarchy by parsing out
[FrontSection[EconomyPage[Summary]]] and know how to render a Summary that
occurs on an EconomyPage within a FrontSection.  But if one searches for
term=greenspan and gets back a set of CLASS=SUMMARYs from various financial
publications, each with its own rendering style, you are going to need more
information than its structural class to render properly.

Structural classifications, be they expressed through GI's (in a DTD or not) or
through attributes on generic GI's should be standardized, not presentation
classes which will differ by institution.

-marc

-- 
Received on Wednesday, 14 August 1996 14:34:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:45 GMT