I am an experienced Standardization participant with about 5 years W3C experience. I am currently an invited expert on the SYMM Workgroup working toward SMIL 3.0. I first became involved with Mobile Ajax while acting as the Sr. Director of Technology for ACCESS, a major embedded web browser manufacturer. Now I am working at Wake3, a stealth-mode startup company focused on mobile web technologies including Ajax and Ajax content authoring.
Coming first from the side of a browser developer, but now a content author gives me a unique perspective to understand both sides of the equation. I know what a web browser company wants out of standardization, but now I also know what it is like to sit in the camp of the content developer.
Mobile Ajax is different from desktop Ajax. Devices have less memory and less processing power. Yet still, there is a great opportunity to harness Ajax for mobile and leverage the web browser as the primary application container to deliver compelling content and services across a range of devices and platforms.
However, mobile Ajax should not simply be a subset of desktop Ajax like XHTML Basic is to XHTML or SVG Tiny is to SVG. This is decidedly the wrong approach. Instead the approach should be to provide a scalable framework for mobile compliance that lets mobile browsers conform to standards, while still allowing the browser vendors to progressively approach desktop functionality as technology improves.
Content authors need to have a consistent set of functionalities across a range of devices. The more individual application versions need to be maintained to run on different handsets or different browsers, the more complex and costly is the developer's task in building and maintaining applications. Lack of a consistent deployment environment was the undoing for Java and J2ME. Please don't let this happen to Mobile Ajax.
Furthermore, it is unrealistic to think that the desktop standards can be today applied to mobile. The device capabilities are obviously different. It is tempting to specify a subset of functionality and call that the mobile profile. This, though, will not meet the needs of the browser vendors.
Mobile browser vendors must constantly try to differentiate themselves from their competitors. To do this, they not only reach compliance with the mobile standard, but then go beyond it. Today, most mobile browsers go well beyond XHTML Basic to strive for desktop compliance. Once each vendor goes their own path to exceed mobile compliance, though, the uniform execution environment provided by standardization is lost.
Additionally, it is a problem where to set the bar for a mobile subset of functionality. Usually the technology is improving so quickly that by the time the standard becomes finalized, it is out of date. What was set as a comfortable objective that could be implemented by the mobile browser vendors is now easily passed by them. The mobile profile quickly loses relevancy.
What is needed instead is a well-defined progression from a basic functionality rising to full desktop functionality with fixed weigh points, or profiles, along the way.
That is, we should define a low water market for a reasonable subset of mobile functionality. In the past, this would be like a Basic profile. Next, we should group the remaining functionality in such a way that there is a set of profiles with increasing functionality that culminates in the full desktop specification.
In this way, browser vendor are free to compete on functionality. They can add more and more features until they fully meet desktop compliance. On the other hand, they are not off on a random walk to pick and choose random functionality to add. Instead there is some order placed on the process that give the content developers discreet functionality points to aim for.
The content developer can choose which profile to target his application for, or to build the application to target multiple profiles with multiple levels of complexity. The advantage is that the developer can target in a predictable way what functionality is available in the progression from basic to full desktop functionality.
Along with that, I would like to see a set of Best Practices for Mobile Ajax developed.
We are now at a significant point in time. Ajax is poised to become the next platform for application development. Perhaps it is the same situation that J2ME was in. J2ME, unfortunately, failed because there was too much variation among handsets. I hope this does not happen with mobile Ajax.
Additional things I would like to see in mobile Ajax: