Elliotte,

I don't agree with your assessment that we are forking SAX. 
Creating a fork implies starting a new development effort to 
evolve an API/codebase in a new direction. This does not 
even come close to describing what we are trying to do.

What are we trying to do? We are trying to define a subset 
of the SAX api that can be productively used on the J2ME 
platform. This means providing an implementation that is 
both small enough to be included by device manfs. and rich 
enough in features to be useful to developers.

In this case, small enough means 35K, and rich enough means 
an api that can be used to process the event generated by 
parsing XML 1.0 documents. By using a (strict) subset of SAX 
we get the benefit of being upwardly portable to J2SE and we 
provide developers with an API / paradigm with which they 
are likely to be familiar. Being downwardly portable (J2SE 
to J2ME) was not a goal of this work, nor is it (in general) 
practical.

Elliotte Rusty Harold wrote:

>  Sun has recently posted the second proposed final draft of Java 
>  Specification Request 172, J2ME Web Services Specification:
>  
>  http://jcp.org/aboutJava/communityprocess/first/jsr172/index2.html
>  
>  This draft is much improved in terms of XML conformance. It no longer 
>  appears to subset XML. However, it does subset SAX in several very 
>  incompatible ways. In particular,
>  
>  *   Sun is using the confusing, underspecified SAXParser and 
>  SAXParserFactory instead of the much cleaner, better specified XMLReader 
>  and XMLReaderFactory.

This was a difficult decision to make, the EG discussed it 
at length. There are several issues:

- XMLReader pulls in several other interfaces, these impact 
the footprint.
- we did not want to subset interfaces, if we do so then 
future revisions of the API can break existing code.
- one of the big advantages of XMLReader is that it splits 
the handling of classes of events out into seperate 
interfaces. In J2ME, were application size is paramount, 
this is less useful, as one of the first optimizations made 
when space gets tight is to collapse everything down into as 
few classes as possible.

So, in practice, instead of implementing the XMLReader 
interface developers extend the DefaultHandler class.

I can understand why you prefer the flexibilty of using 
XMLReader but that increased flexibility comes at a price - 
increased footprint for both the API and applications.

>  * Sun has removed the ContentHandler interface and replaced it with the 
>  DefaultHandler adapter class.

Hopefully the above explains this.

>  There are lots of other interfaces and classes that have been removed. 
>  However, these two strike me as the most objectionable. This subset is 
>  going to make it difficult to port standard SAX code to J2ME 
>  environments. It's also going to encourage developers to continue use 
>  the seriously confusing and broken (e.g. non-namespace aware by default) 
>  SAXParser instead of the better XMLReader.

If your expectation is that you can simply recompile J2SE 
applications for J2ME you are going to be disappointed. J2ME 
only provides a subset of the functionality available in 
J2SE, application have to be designed accordingly.

If we pull in all of SAX (and increse the footprint 
requirements accordingly) the API will be less widely 
adopted. This doesn't benefit anyone.

FWIW, there are several groups within JSR-172 EG member 
organizations (Sun included) that have successfully used 
this API subset. All the comments that we have received have 
been positive...

>  This draft is tantalizingly close to something useful, but there's still 
>  work that remains to be done. Comments can be sent to 
>  jsr-172-comments@[...].com

All feedback welcome!

Regards

j.


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>