RE: Ajax revised

Hi,

The public-appformats mail list is primarily intended to facilitate
discussion and information flow regarding the W3C's Web Application
Formats (WAF) WG [1]. The WAF WG does not include any explicit AJAX-like
deliverables in its Charter [2]. 

However, the W3C's Web APIs WG [3] does include related deliverables -
see its Charter [4] for more information. 

I have CC'ed the Web API WG's Public Mail List (archive available at
[5]); there is no need to cross-post to the appformats mail list in
follow-ups.

Regards,

Art Barstow
Chair of WAF WG

[1] http://www.w3.org/2006/appformats/
[2] http://www.w3.org/2006/appformats/admin/charter.html 
[3] http://www.w3.org/2006/webapi/
[4] http://www.w3.org/2006/webapi/admin/charter.html
[5] http://lists.w3.org/Archives/Public/public-webapi/


________________________________

	From: public-appformats-request@w3.org
[mailto:public-appformats-request@w3.org] On Behalf Of ext Maxim Sloyko
	Sent: Sunday, January 29, 2006 6:05 AM
	To: public-appformats@w3.org
	Subject: Ajax revised
	
	
	Hello, w3c!
	
	I want to suggest something that seems to be missing from
appformats
	plans: AJAX revision. Since all browsers are implementing
XmlHTTPRequest object
	anyway, wouldn't it be great to somehow describe this
interaction with HTTP server
	without custom client code, but, instead, with some XML
language? This will make web clients
	and users less vulnerable (no custom code), so there will be
less security issues.
	
	The interaction can go like this:
	1. Some event occurs -- mouse click, mouse move etc. Browser
looks through the table of events,
	and if event is handled, asynchronously submits respective form
and continues it's work.
	
	2. Browser receives responce to some event. First, it looks at
the type of responce:
	whether it is "change" responce, which describes some changes to
the page, or 
	"complete" responce. If the responce is of type "complete",
browser renders new page 
	(i.e. it works old way). Now, the interesting part is "change"
responce. If browser receives this kind
	of responce, it just renders received changes to the page.
	
	First thing we need is some language for event-table
specification. It can be something like this:
	
	<event id="register">
	
	<form-ref id="name_form" />
	<form-ref id="details_form" />
	
	</event>
	
	If this event occurs, two forms are submitted: name_form and
details_form.
	
	Than, somewhere in the document:
	
	<span... >
	Hello, 
	<slot  event-ref="register">
	Unknown user!
	</slot>
	</span>
	
	If we receive some "change"  type responce from the server,
which can be a document,
	containing some XSLT, like this:
	
	<xsl:stylesheet ...>
	<xsl:template match="/text()">
	<xsl:text>Maxim Sloyko</xsl:text>
	</xsl:template>
	</xsl:stylesheet>
	
	So browser sees, that this responce is a responce for event
"register" (somewhere in the header
	maybe) and looks for the slot for this event in document. Than
applies XSLT transformations,
	as if <slot...> element is the root element.
	
	Actually, "event" element may be redundant, because <xform> can
take its place, but overall process
	remains the same.
	
	
	Currently I'm trying to implement this interaction scheme in my
example application,
	however it is not complete yet.
	
	It would be great if you can give some feedback on this topic!
	
	Thanks for your attention!
	
	--
	Maxim Sloyko
	SWsoft Inc.(http://www.swsoft.com), Developer

Received on Tuesday, 31 January 2006 12:11:26 UTC