[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Sun is forking SAX
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@s... All feedback welcome! Regards j.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|