Kendall Clark's most recent XML-Deviant column highlights the debate of subsetting XML, JAXP and SAX in the J2ME Web Services Specification (JSR 172). At issue is the specification allowance of parsers to throw a SAXParseException when encountering a document type declaration, and to not support non-predefined entity references and interoperability with the full XML specification.

This is an excellent point. While I believe not all Web services should useful to a mobile device the current handling of such an occurrence is unacceptable.

In the article Michael Champion is quoted asking what's a cellphone supposed to do with an external entity reference, or a notation declaration? The answer is simply — nothing. In the tradition of the Web, I would suggest unknown data types be quietly ignored unless explicitly declared programmatically by the developer.

This recent debate has returned my attention to some comments I submitted to the JSR 172 group in December and another major failing of this specification that I have not seen discussed.

I've yet to completely review this draft, but I have scanned the change log and checked for what I thought was the one of the most crucial omissions the word asynchronous.

There are zero occurrences of the word in this draft. As I wrote in my comments to the JSR 172 group, if there is one place where asynchronous messaging is most needed its with the unreliable low-bandwidth mobile networks that mobile phone and PDAs operate.

One of WAP's leading failings (and there where so many) was that applications were useless if a connection was not available or lost. In the US we know how common this occurrence is. Sun lists J2ME's local execution of applications (MIDlets) as a key advantage over WAP applications on mobile devices. However without there will not be a standardize way in this specification for a developer to cope with a loss of connectivity. Without the ability to deal with the loss of connectivity Web service-enabled MIDlets will be useless as a WAP application. That's why I find it remarkable that this specification does not support this vision.

I'm sometimes taken aback as to how little we the developer community seem to understand the realities for developing for the mobile medium particularly resource constrained devices like mobile phones or common PDAs. It is not realistic to believe the solution is mobile phones become as powerful as laptops and bandwidth to become as plentiful as air. Social, economic and environmental factors make this difficult to address and unlikely to succeed in practice.

Sadly, it seems this has been lost on the JSR 172 group and we'll have a mobile Web services specification, and eventually implementations, that really aren't very useful or reliable in reality.

I am cautiously optimistic that some form of Web services will be achievable though its likely to be outside of this specification and subject to a different set of issues.

Consider this: J2ME supports HTTP communications down through MIDP and the recently released MIDP 2.0 specification supports a push communications facilities. (See my article on MIDP 2.0 for more.) RESTful J2ME Web services anyone?

The following is my email to the JSR 172 in its entirety including grammatical mistakes. ;) 


Subject: JSR-172 v.03 Draft Comments.
Date: Sun, 15 Dec 2002 20:50:47 –0800 (PST)
From: Timothy Appnel
To: jsr-172-comments@sun.com


I've read the v0.3 draft of the J2ME Web services
specification and have these comments to submit for
consideration by the JSR 172 expert group.


First, I'd like to acknowledge and commend the group
on taking what is truly a difficult assignment. XML
and Web services specifications where not designed
with such resource constrained environments in mind,
however the loss of flexibility and openness to a
proprietary or binary would be unfortunate.


I think the JAXP subset, including restrictions of DTD
support, is reasonable though I feel 25KB is not
acceptable size in comparison to other J2ME XML
parsing packages such as kXML. I realize that this
packages are not JAXP compliant, however in my
experience in MIDP development, it is my belief that
file size and speed is more important then
compatibility with JAXP. Existing J2SE and J2EE code
is likely to be inappropriate for J2ME applications
and will require some refactoring regardless. Given
these circumstances I would choose to use kXML that
only has a file size of 9KB in its minimum package
form.


Likewise I think the JAX-RPC functionality is
reasonable however it is my opinion that RPC support
is not nearly as useful or relevant to providing Web
services through some simple form of asynchronous
messaging. The continued emphasis on RPC style Web
services remains my biggest criticism and
disappointment of the group's work so far. If there is
one place where asynchronous messaging is most needed
its with the unreliable low-bandwidth mobile networks
that mobile phone and PDAs operate. While the
specification does not preclude the implementation of
service QoS mechanisms that would provide the
infrastructure for dealing with unreliable
connections, a generic baseline should absolutely be
required. I strongly suggest the expert group
reconsider this decision.


A 50K file size is a bit larger then I would hope. I
had 35K-40K in mind. Related to file size, I
understand that the J2ME JAX-RPC package must be
independent of the JAXP package. The specification
does not clear state what (if any) ROM savings there
are if the two coexisted. If there were not any
savings to mention, I would question why this is since
clearly the JAX-RPC package must parse XML to
function.


The data types support in the JAX-RPC subset is
acceptable. In the tradition of the Web, I would
suggest unknown data types be quietly ignored[1]
unless explicitly declared programmatically by the
developer.


I think defining a recommended protocol would be
warrant if its allows the specification to assure a
standard and demonstrative means of reducing bandwidth
consumption. Given the verbosity of XML and Web
services protocols some form of compression is needed
in this specification.


Given the SOAP 1.2 protocol's release is likely to
occur before this specification's release, I would
suggest that more consideration and emphasis be placed
on SOAP 1.2 then what currently exists in this draft.


I hope that my comments have been helpful and
constructive. Please feel free to contact me if any
further questions exist or further discussion is
warranted.


<tim/>


[1] http://www.intertwingly.net/stories/2002/07/29/expectMore.html

What do you think of the JSR 172 specification and Web services place in mobile?