Re: Standards, Work Groups, and Reality Checks: A Radical Proposal.

On Sat, 23 Sep 1995, Steve H Rose wrote:

> > Things like proper MIME content negotiation are being totally ignored 
> > simply because people are using MIME types that simply don't exist, and 
> > not paying attention to the parameters for MIME types (like "version=" 
> > for "text/html").
> 
> I would like to make a point at my own expense.  I teach HTML, and I 
> don't know anything about MIME types.  What I do teach, as best as I can, is 

Perhaps my comment above was somewhat unrelated to "direct HTML" 
discussion, that's why it may seem out of place.  Allow me to explain 
what I meant:

   When a Web client requests a URL from a server, the server tries to
   determine the "type of content" in the URL, and report this accordingly
   to the client.  If this cannot be determined, the server will either use
   a default or will leave the issue to the client to handle.

   The client will generally try to guess content type based upon "file
   extension" (loose use of term) - for example, when using Netscape
   have a look in the "Helper Applications" section of the preferences
   setup and you'll see all the MIME types (like "video/quicktime").

   Here's the not-so-HTML-related bit (of which I was primarily
   complaining about, above):  when people have a file type (eg., Excel)
   which they wish clients to detect and automatically start some
   application, they'll create their own MIME types instead of following
   either the IANA standard types, or the standard of prepending "x-" to
   the subtype.

   Here's the HTML-related bit - MIME type "text/html" specifies a
   particular language;  there are variants thereof, and that's why
   parameters like "version=" exist (so that clients can use content
   negotiation to get the variant that they want/understand).

   If this feature was being used more extensively, then vendor-specific
   HTML may not be causing so many complaints and/or problems because
   the browsers would request some other variant (and the vendor's
   browsers would quite happily accept the vendor-specific stuff).

> the expertise to pay attention to the parameters for MIME types is a 
> stretch -- considering that most users of HTML have probably never heard 
> of MIME, and many have probably never heard of "parameters."

"text/html" refers to a specific language - if the users are being taught 
(and are using) that language, then there's no problem, "text/html" 
remains quite explicit.

What irks me is when people write textual resources that are served up as 
"text/html" (without any further qualification) when they're *not* 
(strictly speaking) HTML.

To me, "HTML" refers to the *standard* language, whereas anything else is 
a variant and requires some qualification (that's why "2.0" and "3.0" are 
appended to differentiate between the two major variants of HTML being 
standardised by the IETF).

It's when "HTML" (no qualification) is being used to refer to some 
vendor-specific variant that I get rather annoyed.

> > To ensure that browsers who claim to support this language are in fact 
> > not butchering it themselves, can/should W3C trademark the name of the 
> > language and only permit those browsers who pass a validation test to 
> > claim support for the language?  If BigBusiness wants to play dirty and 
> > screw-up the Web (as it has done), then it should be aware that two can 
> > play that game.
> 
> Oh, but BigBusiness can play it SO WELL.  It sounds like you are 

Basically, what I *want* is for "HTML" to refer to some standard language 
so that there is no ambiguity when that term is used;  what I *want*, is 
for HTML as standardised by IETF to be that language (and variants 
thereof).  What I *want* is for vendor-specific variants to be designated 
as such, and to either pick a different MIME type, or to add some 
qualification to "text/html" (rather than using it verbatim).

Will that ever happen?  Not bloody likely.  Vendors are creating terrible 
ambiguity when referring to "HTML", because people not aware of the 
different variations are using tags thinking they are using "HTML" and 
that everyone will be able to view the information as the author 
intended, which is just not true.

I would *like* to see HTML remain the lingua franca of the Web, but as a 
standard language it must be just that - *standard*.  That's not to say 
that innovation shouldn't continue, just that differences shouldn't claim 
to be the same as the original.

Since I don't see BigBusiness bending to what is logical and fair, then 
the only other alternative is to, as has already been suggested, get the 
hell out of the way - take "standard HTML" elsewhere and rename it (so 
that no ambiguity may result).

> considering inventing a new language (when there are hundreds of 
> thousands of users of an existing language), inventing a new name for 

No, I'm not thinking of an entirely *new* language - but a *standardised* 
language whose title instantly indicates who/what it is;  "HTML" is no 
longer enough to explicitly indicate what tags are in use.

> that language (when there are even more people who know the name "HTML"), 
> and then engaging in trademark and legal battles (which cost a lot of 

That was a second suggestion to ensure that should a "new language" 
(mainly in terms of name) emerge, then the same thing that has happened 
to HTML will not happen to it, also.

I don't know if such a thing is viable, or even possible (or even 
desirable), which is why it's open for discussion.

> Is it conceivable that there is something better to do with one's time?

If the vendors would stop overloading "HTML", then there would be no 
need.  Do *you* think there is any chance of this happening?  Sadly, I do 
not.

Cheers..


dave

Received on Sunday, 24 September 1995 23:51:46 UTC