OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] JSR 206 and SAX

[ Lists Home | Date Index | Thread Index ]

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@metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml
   http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS