[
Lists Home |
Date Index |
Thread Index
]
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@sun.com
All feedback welcome!
Regards
j.
|
