Re: meta information

Hi,

Here's another two cents worth more on this topic.


[ You wrote: ]

> The discussion about META has turned into much more than a simple
> disagreement over the desirability of a META element...
> 
> I guess it's a question of what do we want to use HTML for. The
> constraints are clear: we want *document* to express arbitrarily many
> different things along many different dimensions, but we want *HTML*
> to remain simple (and SGML conformant). Assuming the equality
> 
> 		     MARK-UP = META-INFORMATION,
> 
> a few of the roles that mark-up can have are:

Actually, I'd have to say that even this assumption needs
to be looked at closely before it is accepted as gospel.

How about if we say that:

		     MARK-UP <= META-INFORMATION

This implies that we can have metainfo about a document
that is not necessarily included in the view of the
document provided to Internet-based clients for rending or
display.

By extension this implies that we will need alternate
mechanisms (presumably at the protocol level) to allow us
to extract this info. In many cases this seems the better
route to take and one that seems not to be getting enough
attention in this discussion.

> 1) Lay-out
> 
>    HTML provides lightweight, display-oriented markup. When more
>    visual aspects are needed, style sheets are the way to go.

Fair enough to say "Keep It Simple", but I think it also
opens up the possibility of using alternate approaches for
display formatting to allow us to have the greater
complexity which we sometimes need.

For example, PDF clearly needs work to be successful in
the Internet environment, but Adobe has tackled fairly
successfully many of the problems people are now wrestling
with here.  Maybe we should aim to HTML simple, reserve it
for simple display applications and beat on Adobe a bit to
finish making PDF "net literate". then we can profit from
their efforts and not spend our time inventing yet another
page description formatting language. 

.  .  .
> 
>    f) Don't try to use SGML at all: use
> 
> 	<link rel="semantics" href="semantics.sem">
> 
>       and define a language for expressing semantics (in Prolog? Scheme?)

This certainly seems like the better long term approach.
Frankly I'd rather query a server for certain other kinds
of info when I need it, not pile it all into the document
where it will be excess baggage most of the time. This
looks like a nice way to do it.

I've a real aversion to piling lots of metainfo into a
document for all sorts of reasons. It certainly makes the
document larger. I suspect it also makes it harder to
maintain and harder to keep multiple copies consistent.

The way I see it, what is delivered to Internet-literate
clients should be merely one view of a document (based
upon the degree of output formatting control we want,
etc). I think as a model, the server should be responsible
for managing the various info we might have on a document
and let the client indicate what it needs or can handle at
any particular time.

Assuming people buy this model, I think it implies we
probably need to provide the equivalent of a "COPY"
command, which would pack up and include the meta info
when delivering a document so that its total state can be
preserved when needed. Meanwhile we should focus on
keeping both the transfer protocol and basic display
markup simple, with equally simple extensions for getting
to more complex formats when needed. At that point, we can
profit from the efforts of others where appropriate.

-- 
-----------------------------------------------------------------------------
	"Tonight on `It's The Mind', we study deja vu..."
-----------------------------------------------------------------------------

Received on Tuesday, 7 June 1994 16:09:13 UTC