Dear Sir/Madam,  I am writing this mail because I've recently studied your Web Applications 1.0 specifications, and have found a rather strange point in it. As the 'event-source' element is embedded in the Markup itself, it makes little sense. It is for the simple reason that, assuming there be more than one event-source handlers, then one has to be defined first and another one, next. In that case, there is no significance of the order in which the 'even-source' elements appear. Here are my suggestion:

SEMANTIC PROBLEMS In HTML, or any markup for that purpose, the order of elements has a special significance. As for example, if there are two  tags, then th once coming first is rendered first in the inline display and the one coming next is displayed next (the relative positioning can be changed using CSS is a different matter, however).

<br><br>HTML as such is a static language (without a scripting backend). Hence, dynamic elements within the flow of an HTML element, isn't proper semantics.<br><br>SUGGESTION (CLIENT SCRIPTING OBJECT)<br><br>To keep the semantics in place, I'd recommend that that the event-source be rather specified as a JavaScript/DHTML object, just as the XMLHttpRequest object is. A major part of event-source seems to fulfill the the shortcomings of XMLHttpRequest object. In the same way the object 'event-source' can have following methods/properties:

<br><br>Property: src (same as for the HTML element)<br>Method: connect (initiate the initial connection)<br>Method: disconnect (disconnect the connection or abort)<br>Property: onrecieve (function call. execute function when data is recieved)

ADVANTAGES (BANDWIDTH LOAD REDUCTION) At the same time, this method also will enable developers to reduce the bandwidth load on both sides by allowing the script to initiate and abort the connection as and when required. There are various probelms when doing so with an HTML element.

ADVANTAGES(COMPATIBILITY) On top of it, it is more backword compatible than the HTML method. A simple check (with client scripting) would be: window.eventSource In case JavaScript/Browser scripting is disabled, nothing would ever be executed and event-source can't really be used without a Client-scripting technology.

There is no way to check it using HTML methods, and if we were to specify one, we still lose support of all the browsers that exist as of now. At the same time, older browsers may not recognize the event-source element and display something that would either obstruct the flow of the document or it may abruptly quit.

<br><br>ADVANTAGES(ADHERENCE TO EXISTING STANDARDS)<br><br>Also, if it is completely scripting based, it can even be validated using current W3 validation services. (Since WHATWG currently doesn't have a validation service, more developers will be encouraged if they can use existing DTDs while at the same time using new technologies)

<br><br>This is just a suggestion and hence I haven't worked much on it, but am ready to contribute more inputs, once this suggestion finds higher attention. I hope to hear from your side.<br><br>Rohan Prabhu,<br>Vadodara,

<br>India<br clear="all"><br>-- <br>{Ro}h(a)[n]_-_[P]{rab}(h)u 