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

On Thu, 16 Jan 1997 13:34:30 -0700, Paul Prescod wrote:
> I think you're thinking of a different "WebTV" than I am. I am
> thinking about the service that delivers Web pages to your television
> screen. In other words it is just a Web-enabled computer attached to
> a television screen with a "passthrough" that allows you to watch
> regular TV when you don't want to surf. So it is "pull" technology
> and doesn't have anything in particular to do with animation or
> movies.
>
> My point was that delivering web pages to televsions sets would be a
> good idea if the web pages were not micro-engineered for VGA+.

As a general rule, when designing a web site, the first thing you need
to determine is, Who is your audience?  And where is it located?  If
your audience is a defined segment of the consumer market, part of the
couch-potato set, you will want to design your pages to appeal not only
to their interests, but as well to their notoriously short attention
spans.

This being the case, you would hardly expect your market audience,
sitting on their couch, six-pack and munchies close to hand, to be very
interested in, say, the book I currently have on my web site (though
the 46 color illustrations might interest them *slightly* in passing).
So you would not design your pages as I did, with large blocks of
scrolling text (i.e., chapters) and high quality graphics.

What you would design is a site with a lot of motion, color, sound, and
zero (if at all possible) scrolling.  You would also have to keep in
mind that your site would be viewed from across a room, and therefore
adjust your fonts and colors accordingly.

Also, as the strong popularity of PCN has demonstrated (as well as the
discussions on some of the firewall lists I monitor, where the goal is
to block PCN), a certain part of the market does want push.  This
market, I believe, overlaps the couch-potato consumer market, which is
WebTV's market.

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

> Over time. But in the short term there would be hundreds of error
> messages about entities not available and identifiers not found,
> elements undefined, etc. etc. SGML was designed for a system where
> somebody is in charge, not for the anarchy of the Web.

I am afraid you are right -- at least regarding the error messages.
For were one to take a look around the web with nsgmls in hand, they
would be astonished at how many sites -- even the large, multi-million
dollar team-built sites -- have invalid markup.  So, if large, well paid
teams of "specialists" are unable to write simple HTML correctly, it can
hardly bode well for "real" SGML.  For, you see, these large team
efforts *do* have someone in charge, and even there it is not working.

Perhaps the general mentality of the public is unable to cope well with
structure, though structure is found in most areas of life.  I kinda
have the feeling that things like SGML work best with those individuals
who are sometimes referred to as "self-starters."  Those for whom money
is a minor motivation, and interest in the subject rules.  Chuck
D'Antonio is partially right when he says:

	The other thing to remember is that the people to impress are
	not vanity home page publishers.  They're authors, designers,
	and publishers who intend to maintain their work as a
	contribution to the web and not their own ego.

These people will come to SGML (or stylesheets in HTML) if it suits
their artistic purposes; and, in fact, they are a fairly easy sale
because their very nature allows them to see the advantages of these
tools and methodologies *for their work.*

However, Chuck goes on to say:

	And they're the managers and executives who could care less
	about whether their documents conform to some technical
	standard but understand that structural markup saves their
	employees editing time and opens their message up to the last
	ten percent of the web audience who don't have the tools to
	view the hottest in presentational markup.  I'm not bold enough
	to call that competitive advantage, but many might.

This is the classic battle when trying to convince some large
corporation that the move to SGML would save them large sums of money
in the long term, though the upfront costs are high (studies show that
the "average" writer in a corporate environment spends about 40% of
his/her time tweaking presentation, and that if presentation questions
are moved to the FOSI, then that 40% goes into increased productivity
:-).  And it is the same thing with HTML style sheets *if* the document
environment is suited for this technology (for many environments will
actually do better with vanilla 3.2 HTML, just as is the case with our
friends Joe and Jane Homepage).

> Perhaps the ease of marketing XML is just a side effect of good
> language design. =) I'm being half faceitious, but only half. XML
> simplifies generic markup which is really the central concept of
> SGML.  Validation is important but secondary, in my mind, to the
> concept of generic coding.

TimB-L commented once in an interview, if I remember correctly, that 
he never thought the general public would ever have to deal with HTML
or URLs; I imagine he had in mind various tools that would do the dirty
work.  If so, what the tool uses (SGML, HTML, XML) shouldn't make much
difference to the user, not if the tools are designed well.  If the
user is going to use authoring tools, then a non-validating markup
language is a waste, for it will rapidly degenerate into what we have
today with HTML.  That was the first thing I noticed when Jon made the
announcement about XML, and I still feel true structured markup and
validation is important.  But it can be hidden in the tools, with the
only real result being that the vendors will have to design good tools,
not the sloppy tools the HTML community has today.  If we in the SGML
community have good tools (and we do, especially those for Unix), then
the HTML/XML community can have them too.  The thing is, we need to
encourage good operating practice, and we need to encourage good
mass-market tools.  Unfortunately, good tools go against the type of
marketing focus we are seeing today, where the UAs are deliberately
designed to conceal bad HTML for reasons of strategic marketing (and
yes, I understand the principles behind the "Be strict with what you
serve, lenient with what you receive," concept).  So it all probably
comes down to politics, as Paul noted, and that's where the decisions
will be made.

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

> I'm sure EBT will be producing a tool that will render your SGML as
> XML on the fly for you as soon as we have a spec that allows it.
> Considered in that way, XML is to SGML what GIF is to low-colour
> bitmaps or JPEG is to high-colour ones: an optimized format for
> network delivery. In particular XML optimizes network delivery by
> removing the need for parsing and using large "startup" files: DTDs.

Sure, but we are once again converting, which is the same thing we have
to do today using HTML.  And besides, as far as the UA having to read
the DTD and its associated files, SGML will mostly be used for long
documents (where it shines -- I mean, after all, we do have DTDs for
letters and memos, but give me a break :-), and once read, those files
will just remain in the cache waiting for their next moment of glory.

-fep

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

Received on Friday, 17 January 1997 20:30:57 UTC