[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: JSR 206 and SAX


jsr sax parser
At 5:38 PM -0500 2/18/04, Norman Walsh wrote:

>So just recently, when Michael Glavassevich pointed out[1] on the
>sax-devel list why the extension framework is insufficient for our
>needs, I became deeply concerned.


Michael's claim is that properly supporting XML 1.1 requires placing 
xmlns:prefix attributes in a namespace. I disagree. Certainly the 
namespaces 1.1 specification does make a backwards incompatible 
change, and does clearly place these attributes in a namespace, 
unlike the Namespaces 1.0 specification and unlike SAX 2.0.

However, all that's really needed is for SAX to correctly and 
consistently report namespace declarations. It does not necessarily 
need to assign the same (or any) namespace URI to these prefixes that 
the spec suggests. The current SAX approach to handling namespace 
declarations and namespace declaration attributes is not a problem. 
All attributes are properly reported. if someone really wants to 
assign a namespace URI to these attributes, they can write the extra 
code to do so when they move them into a new environment. However, 
doing so now would be gratuitously incompatible with the large 
existing base of SAX programs. It's annoying situation, yes (I blame 
the DOM and XML core working groups for letting this change through 
in the first place) but the proposed cure is much worse than the 
disease.

>For better or worse, a JSR is not simply a specification exercise. We
>must ship a reference implementation. To make matters worse, a hard
>deadline has been imposed on JSR 206. So we have significant,
>practical challenges to overcome in a fairly short period of time.
>
>I don't know what to do and neither, as far as I can determine, do the
>members of the expert group.
>
>A number of possibilities occur to me, none of them very attractive:
>
>1. We could decide not to support XML 1.1 and Namespaces 1.1. The changes
>    in XML 1.1 are small, the RI team has worked to address them, and
>    the specifications are now recommendations. I think the argument that
>    we should abandon our position of supporting them because a few changes
>    are needed in the SAX API would be a hard sell.

Given your hard deadline, and the apparent unavailability of the 
Davids, this is what I recommend.

>2. JSR 206 could fork SAX, producing javax.xml.sax.* classes, for example.
>    This would be "honest" in the sense that we would not be changing an
>    API that we are not empowered to change. But it would be bad.

Double plus ungood, in fact.

>3. The developer community could endorse our EG to make the few small changes
>    needed to SAX to support XML 1.1 and Namespaces 1.1. Unlikely, I fear.
>
>4. The developer community could modify SAX to support XML 1.1 and
>    Namespaces 1.1. That would be best, but I'm uncomfortable with the prospect
>    of achieving that within the schedule I have to meet.

I think what this is demonstrating is that the SAX process needs to 
become a little more formalized. However, that is unlikely to happen 
within Sun's deadline. Unless someone can reach one of the Davids and 
get them to respond, then your only real options are to either except 
the current unfinished SAX extensions or to simply ship SAX 2.0. I'm 
honestly not sure that is such a bad idea. While version 
identification would be nice, I don't see anything crippling in SAX 
when it comes to XML 1.1. A 1.1 parser using SAX would just pass data 
to some methods where an XML 1.0 parser would have thrown an 
exception. In a few rare cases, the 1.1 parser would call 
ignorableWhitespace() where a 1.0 parser would call characters() 
instead. So I guess I'm really suggesting

5. Ship a 1.1 parser that uses the SAX 2.0 interfaces as designed, 
does not report version information, and does not assign xmlns:prefix 
attributes to a namespace by default.

Either that or don't support XML 1.1/Namespaces 1.1 at all.

-- 

   Elliotte Rusty Harold
   elharo@m...
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml
   http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.