[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX2: org.xml.sax.helpers.SAXUtils
David Megginson <david@m...> wrote: [snip] > > Yes, but in retrospect I think it might be overkill -- this kind of > thing belongs at a higher application layer, not in a low-level > driver. I was never too happy with the SAX1 ParserFactory either. Fair enough, and I can see that there are larger fish to fry at the moment. Maybe it does belong at a higher level but the concept does seem to resonate with the general SAX theme. Our attraction to SAX (for data exchange facilities) is that it allows us to (hopefully) avoid a heck of a lot of code change associated with moving specific parsers into or out of our environment (and we don't have to blow the whole document into volatile before dealing with the data, of course). The missing piece, at least in our context, is a similar abstraction to the "get-a-parser" process. My first hack was a crude static Parser getSAXParser(String features[]) with a lot of ugly, hard-wired "if" innards, but if the app requests "Validation" (and we have deployed a parser able to validate), it (ultimately) gets (a reference to) a Parser that validates. As it stands, this works for us only 'cause the group that handles this (and other) interfaces also controls which parsers are deployed on our systems and when. The interface can be enhanced and deployed in lockstep with the parser(s) and the app developers use the interface (or at least they are strongly encouraged to do so) to at least reduce the potential for modification when/if (more likely when) we change/add/remove a parser. Sounds like hog-heaven except now we have looming on the horizon the need to deploy and integrate with a piece of third-party middleware of sorts that also needs a parser. Mutually nuts for them to use our interface (a "standard" only on our systems). Implementation of a similar mechanism on their part still injects another (although still relatively manageable) configuration coordination point. Maybe I'm missing something (spouse says I'm a Pessimist I prefer Realist :-) but I can see this getting more convoluted down the pike as XML and the various parsers evolve (and we hit our Nth third party package). A public, standard mechanism (widely supported as is SAX) to acquire a parser by feature, would appear to at least mitigate, if not eliminate, this bit of inelegance. Not necessarily arguing that this belongs in SAX2 (the list of what I don't get about XML seems to be growing way faster than what I do get, despite lurking xml-dev and grinding slowly through the various specs ). Also currently devoid of vision at the moment as to the details behind such an animal (the approach we've taken so far would be a maintenance debacle in a general public context). Perhaps an idea to resurrect some time in the future (or in some other context)... Regards, Jim Layer ____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.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/ or CD-ROM/ISBN 981-02-3594-1 Please note: New list subscriptions now closed in preparation for transfer to OASIS.
|
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
|