W3C Workshop on Web Applications and Compound Documents

Position Paper

Author: Armando Peña. CTO. GoPix, Inc.

 

 

Company Background

 

GoPix’s focus is the development of consumer networked-enabled mobile imaging applications and services.

 

Our Needs

 

 

Compound ML Documents and Native Application interaction and interfacing

 

Although our company has extensive experience in developing online services and Web applications, we are currently focusing most of our new technology effort on the development of mobile clients tethered via small-footprint Web services to the network. Due to this focus I will not speak of our Web Applications needs but rather of our position in the compound documents area.

 

At a basic level, we have the need to embed text, media, and animation into our UI presentation layer. This is already achievable – be it through the use of native Symbian UIKON, MIDP GUI APIs, or XHTML Basic. Many folks participating in this event have made great contributions in defining a number of ways to deal with mixed XML namespace issues such as DOM event handling, access to native resources by components, and overall orchestration of application logic. So I will refrain from adding to that particular discussion at this point.

 

Beyond the idea of compound documents of mixed namespaces operating nicely with each other, I think there’s some discussion to be had about how compound documents will interface with the container application. Most of the time during discussion of ML documents, the container app is a Web browser. This tendency has lessened in the desktop world (i.e. iTunes) but definitely continues in the mobile space, where WAP browsers and the like are the usual suspects containing compound documents. I would like to draw the attention of the discussion to the interfaces (programmatic, event-driven, etc) between the compound ML document world and the containing native applications. Specifically, those in the mobile space such as Symbian and MIDP.

 

Mozilla with XUL [XUL] in the past and Microsoft now with XAML [XAML] in Avalon are doing very good work in defining a standard markup way in which to create user interfaces. On the Java front, Java Server Faces [JSF] has certainly begun an effort that begins to blur the lines between defining user interfaces in native Java applications and Web applications. These efforts are a good (and inescapable) reason to give thought to the interfacing of native application user interfaces and compound ML documents. In the mobile space, industry efforts have not yet moved in that direction. However, there is a definite need to address the issue starting with current technologies. There are companies out there like Animoi [ANIMOI] doing interesting things such as transforming Flash movies into Java MIDlets. There is also the SVG-Tiny support being built into MIDP thanks to JSR 226 [JSR226]

 

A quick Google search would probably find various other efforts attempting to bridge the worlds of native application interfaces and ML documents. What this means is that, as with many other technology initiatives, the mobile world is behind the desktop world by a few years. It is not unfeasible that, in the future, technologies similar to XAML and XUL will make their way into mobile operating systems like Symbian. Acknowledging this possibility and discussing the matter now will certainly help us avoid a few headaches later and help the mobile application development space advance at a faster pace than the desktop space simply by learning from the evolution of its desktop cousin. At the very least, efforts should be made to convince the Symbian group and the Java community process to address this issue head-on. Symbian 7.0 [SYMBIAN] has already made great progress by adding native support - through their application engine paradigm - to XHTML, Javascript, CSS by adding the Opera Web engine. In the future, it is foreseeable the Symbian resources could be declared to be XML documents and be laid out utilizing style sheet functionality. Eventually, the UI itself could be specified in a declarative fashion and sit on top of the AVKON UI engine. The same can be said for MIDP applications, and it would be recommended to extend efforts such as JSR226 to eventually cover the interaction between SVG and the native app as well as to begin efforts to define MIDP interfaces in a declarative fashion. Once upon a time, the XMLTalk [XMLTALK] project attempted this for the JFC layer in J2SE.

 

A note on mixing declarative style development with imperative development: This is in a way orthogonal but ultimately very key to the discussion at hand. Tools such as Ant, Struts, JSF, Hibernate, are very powerful, partly because they are well-designed and address specific issues and partly because they have begun to practically bridge the worlds of declarative and imperative development. This can also be said about XAML, XUL, SVG, and yet-to-be-developed technologies and their interfaces to C#, Java, etc. Although this brave new world gives developers the ability to create very powerful applications and specify very interesting programmatic interactions in a declarative way, it is still simply a very error-prone way of developing software. This is mainly due to 2 reasons: (1) The toolsets available to date do a very poor job at validating the interactions between declarative parts and imperative objects and helping with debugging, and (2) (even more fundamental) there is still a lot of work to be done in the area of interfacing between ML documents and native source code. This will eventually push us in the direction of defining object interfaces using markup languages and increasing the semantics conveyed through them. This is something I believe TBL himself has addressed in the past.

 

It is our position that the issues of (a) multi-namespace compound ML document interaction, (b) compound ML document and native application interaction, and (c) relationship between declarative ML and imperative code should be addressed concurrently and in concert so as to allow a smooth transition between current and future application development. The drive should be not just towards developing new ways of constructing applications but also towards a future where we have smarter debugging tools that reduce time-to-market and ease maintenance. After all, most time in software development is spent debugging, not coding.

 

 

Bibliography

 

[JSF] Java Server Faces

[JSR226] JSR # 226 – Scalable 2D Vectors Graphic API for J2ME

[XMLTALK] XMLTalk: A framework for automatic GUI rendering from XML specs

[ANIMOI] Animoi Mobile Flash Technology

[XUL] XML Based user interface language

[SYMBIAN] Symbian OS Technology