Re: New tags. (fwd) -Reply (fwd)

F. E. Potts (fepotts@fepco.com)
Thu, 16 Jan 1997 13:17:42 -0700


Date: Thu, 16 Jan 1997 13:17:42 -0700
From: fepotts@fepco.com (F. E. Potts)
Message-Id: <97Jan16.130003mst.18434@gw2.fepco.com>
To: papresco@calum.csclub.uwaterloo.ca
Subject: Re: New tags. (fwd) -Reply (fwd)
Cc: www-html@www10.w3.org

On Thu, 16 Jan 1997 08:57:56 -0700, F. E. Potts wrote:
> > I sometimes wonder about this debate over structure vs.
> > presentation.  For those who are of the opinion that the
> > popularization of the web was a "Good Thing," there is no denying
> > that had the SGML application HTML not been a presentation DTD, and
> > treated as such by the UA vendors, the web would have remained a
> > toy and tool of the scientific, educational, and Unix communities,
> > rather than the popular "success" it now is.

Shortly thereafter, Paul Prescod replied:
> Sorry. I deny that. If, by some miracle of technical-purity zeal, 
> Netscape had implemented stylesheets in Netscape 1.1 instead of
> <FONT>, the Web would still be a success and most people would
> "understand" why structure should be more central than presentation.

I wonder.  I have tried to get those who come to me requesting help with
their web documents to understand the value of validation, and generally
their initial response is, "Why bother?  It looks good in Netscape."  I
might note that in my experience those who do eventually take up the
practice of trying to write good markup, and validate their pages,
usually end up with very attractive, successful sites; perhaps this just
comes about because they are trying harder, but there it is.

> The Web might actually be a BIGGER success than it is. Surely one
> thing that is going to hurt these WebTV's (if not kill them) is that
> most web pages are designed for VGA resolution as a minimum. I would
> really love to see what the Web looks like at typical television
> resolutions.

WebTV is absurd.  The net is a packet network; animation and movies and
all that type of thing works best over broadcast.  Also, the web is
"pull," not "push," and does push poorly.  Why try to emulate a totally
different technology?  Why not focus on what the web does well, rather
than what it does poorly?

> > There is also no denying that for many short documents (as MegaZone
> > pointed out), as well as for those of Joe and Jane Homepage, this
> > "Master HTML in A Week" markup language has served a useful purpose.

> You can't really master the presentational features of HTML in a
> week.  Getting the right layout, in particular, (typically using
> tables or frames) takes some time. I do not believe that style sheets
> are much harder to learn than <FONT> for the simple things.

You missed the point, Paul. "Master HTML in A Week" (or is it "Learn
HTML in A Week"?) is a book title, and one that very clearly
demonstrates the market's attitude towards these matters.  Joe and Jane
Homepage are not the least bit interested in learning anything that
takes the slightest bit of effort -- which is why so many people resist
validation and structured documents: they can't be bothered.

> > If I had my way, as I have stated before on this list, we would
> > stop messing with HTML (which is basically a silly application,
> > considering how easy it is to work in SGML),

> In *real* SGML? I don't think so. First you have to get a DTD, set up
> your catalog, learn the DTD, etc. etc.

It ain't so bad, Paul.  You've been there, you know that if these
things are set up properly (which is what would happen were the web to
really become open to SGML) there would evolve simple, webish DTDs and
FOSIs (or DSSSL-o), along with the associated tools to use them.  It
would end up being no more difficult to use than, say, something like
HotMetal (at least I assume HotMetal is easy to use; in my HTML work I
use vi on a Unix box and the now-slightly-dated sgmls).  And the
advantage would be that those who have serious content they need to put
on the web (such as large databases with thousands of documents) would
be freed from the necessity of having to down-translate everything into
HTML 2.0 or whatever.

> > forget XML (mostly a marketing ploy, as far as I can determine) 

> "Mostly?" Rather hard to decide. Depends on who you talk to. 

Yep.  See http://www.sil.org/sgml/XMLSanDiego.html

> I tend to think that XML is a useful tool independant of the Web.
> People have long used non-validated tagged markup languages that look
> suspicously like SGML (I know *I* have). Why shouldn't we standardize
> the processing of such documents?

Well, some of the best minds in the SGML community are working on XML,
so it will probably turn out okay.  Still, I would rather we focused
> > our efforts on getting the infrastructure in place so we can post
> > our native SGML instances on the web without having to down-convert
> > them into some lower-level markup language.

> I think that is about as likely to happen in the short term as
> Netscape having supported style sheets in version 1.1. There are so
> many barriers, including politics, client implementation difficulty,
> network performance, parsing performance, etc.

I agree that native SGML on the web is unlikely to happen in the short
term.  And with the focus now on XML it becomes even less likely that
native SGML will ever become common on the web.  And that is why I have
a problem with XML.

> Anyhow, in what sense ix XML a "lower-level" markup language? It is
> an SGML subset optimized for Web delivery. XML documents are "native
> SGML" and can use the full generality of "generic markup". I see no
> reason you couldn't or wouldn't write your book in it. What do you
> think it is missing?

ISO.  UAs.  An infrastructure.  The test of time.  

Keep in mind that the planet has millions and millions of documents
already in SGML, and converting those documents so they can be viewed
on the web is a very large, and expensive, task.  It would be a lot
better, and far more economical, were we to build an infrastructure
that could use them as they are.

-fep

--
fepotts@fepco.com
http://www.fepco.com/
http://www.ajana.com/