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

Re: SAX2: Namespace proposal

  • From: David Megginson <david@m...>
  • To: "xml-dev@i..." <xml-dev@i...>
  • Date: 20 Dec 1999 09:05:39 -0500

Re: SAX2: Namespace proposal
Stefan Haustein <stefan.haustein@t...> writes:

> > For example, I think there are good arguments for moving to a
> > 
> > interface DocumentHandler {
> >   void startElement(StartElementEvent event)
> >   void endElement(EndElementEvent event)
> >   ...
> > }
> 
> I also would prefer this kind of interface. Further advantage besides
> the improved extensability might be that 
> 
> - building a new object seems some overhead at the first sight, 
>   but in JAVA also a new String is a new object...

And that is why most parsers internalize strings rather than creating
new ones, and that's why the SAX characters() and
ignorableWhiteSpace() methods use character arrays rather than
strings.  XML parsing shows up a lot of problems that Java programmers 
aren't used to, because it generates so many events (often tens of
thousands) in only a few seconds.

In this case, however, the real solution is internalizing but reusing
-- the SAX driver would have only one copy of each kind of event
object, and would simply change its values each time it makes a
callback.  The problem with this approach (it showed up before in C++
with a simple SP API that James Clark made) is that programmers will
try -- despite documentation warning against it -- to keep the event
objects around and reference them outside the scope of the callback,
where strange things will happen.

> - some computation could be performed on demand only(?) 

This might be an advantage, but probably not -- the parser will
probably have done all of the work anyway, because of basic
constraints for checking well-formedness, etc.

> - I think it is less difficult to remember the access method names 
>   than a more or less unmotivated order of a lot of parameters

Perhaps, but you have to remember a lot of class and method names.
I'm programmed to interfaces that use both approaches, and I did not
find either harder or easier -- on balance, I prefer to avoid bloating 
a low-level interface like SAX with a lot of extra classes, even if
the performance would be the same.

> - the ElementEvent access methods could be a subset of the DOM access
> methods (!)

No, I don't think we should go there.  SAX has its warts, and the DOM
has its warts, but any combination might give us the product rather
than the sum of their warts, and the world doesn't need that much
ugliness.

> please do not forget to include the "old" SAX 1 methods in HandlerBase
> and call them from the new methods as default behaviour preserving
> compatibility at least with applications extending
> HandlerBase instead of implementing DocumentHandler. 

Actually, if we create a new package, there will be no compatibility
at all, except by using adapters (aka filters).  There will certainly
be a SAX1Filter class to wrap around SAX 1.0 parsers, and there may
also be a SAX2Filter class to make SAX2 parsers act like SAX 1.0
parsers.


All the best,


David

-- 
David Megginson                 david@m...
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)



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.