Archive of UserLand's first discussion group, started October 5, 1998.

Re: HTML Refresh Language - from the Spec Author himself

Author:Ross Nelson
Posted:1/13/1999; 2:42:41 AM
Topic:HTML Refresh Language
Msg #:2070 (In response to 1969)
Prev/Next:2069 / 2071

Hi Guys.

This is Mr (Ross) Nelson (the author, as you put it in the previous post Mark :)!). I'd just like to say hi and fill you in on a few things with regard to the spec I have proposed. (People wanting to see the spec can catch up with it at http://search.ietf.org/internet-drafts/draft-rfced-exp-nelson-00.txt).

Background

This thing is not new. We have prototyped something similar back in Dec 1996/Jan 1997 with a pseudo browser written in Java that took the tags described in the spec and and used them to operate on fields defined by a previous limited HTML grammar. It worked fine and helped us think up a few new ideas. Then like all good ideas, we figured somebody else must have thought of it and we just sat on it. Then last October I finally put it up to the IETF as an EXPERIMENTAL RFC.

Other Options to HTML REFRESH

You talked in subsequent posts about other options instead of increasing HTML. Well firstly, if you want true heavy client server you might as well give up and use active X/ODBC or Java/JDBC right now. Theres one small problem. Very few serious organisations will let either in through there firewalls and definately not from unknown sites. Applet signing addresses some of these concerns however applets still tend to have huge initial download overheads in most cases and a lot of the world still uses slowish modems.

I am a team leader doing major web projects in high security environments and have been doing this since late 1995/early 1996. Again and again I have seen the need for something more than HTML forms can offer but with the same ease of transmission and coding.

This spec proposes something that can be generated with almost any existing dynamic web tool. These include ASP, Cold fusion, PERL and most of the DB vender specific web tools. It would get the ball moving quickly with existing technology. All that is need is some modest extensions to existing browsers to parse the new tags.

As well, conventional Client/Server products could also now effectively produce versions of their compiled application in both HTML and HTMLR for a better thin client/server oriented output on the web. You dont have to write in HTMLR, just produce it by some means.

Running the Spec past W3C

Well I tried and tried emailing different parts of W3C to see if somebody would respond. I tried their Notes email address and a raft of others. No replies, only one 3 weeks later that said we dont accept public notes any more. Joining the W3C is also not an option.

I don't know about you but I dont have the spare ten of thousands of dollars lying around to pay the membership and I don't work directly for any major computer firm that would shout me the membership. Sorry W3C, but I tried. I have since posted it on the www-html@w3.org list.

IETF and the RFC route was the only way to get my voice heard and I took it. The IETF will send all HTML/webish things past W3C for perusal anyway so I have been told.

As for putting the MIME type past IANA, well the RFC is EXPERIMENTAL, and that is how far it has gone. If it takes off, I'd be glad to register it.

The Spec Wont Get Implemented

Well maybe it wont. But then Im sure someone told Beners Lee that this simple text based HTML thing would not catch on in the world of GUI's and the 90's and client/server. And he should not bother. Hmmm.

If you don't try you will never get anywhere. And if it just raises the consciousness levels, I'll be happy. I agree the HTML standard is difficult to track across the current range of browsers, but so is going to be any other means of doing the functionality described in this spec across multiple browser types, whether it is in HTML or something else.

I think the problems with HTML compatibility are more of a problem of browser manufacturers not following or ignoring the W3C HTML spec, not the fact that the spec should never ever be allowed to expand. The HTML spec must be allowed to evolve.

Look at the complexities of Java or Active-X which need to be faced do similar GUI form data entry and the versioning issues involved. HTML REFRESH coupled with say some light javascript would be simple in comparison.

The sad truth is that there are only two major browser manufactures left, Microsoft and Netscape. And if neither wants to play ball then then its pretty hard to get an idea up and implemented. But you never know...

Further Comments

I would love to hear any and all comments that people have on the spec. Some I have so far involve allowing the resizing of images via HTML REFRESH for some interesting uses! But, please feel free to email me with comments or post them to the www-html@w3.org list.

As well, if anybody is interested in integrating HTMLR into a browser of any kind, I would love to know about.

All comments will be considered for a redraft at the end of February.

Cheers

Ross Nelson (Ross.Nelson@wizardis.com.au)

There are responses to this message:

This page was archived on 6/13/2001; 4:47:14 PM.

© Copyright 1998-2001 UserLand Software, Inc.