Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ANN: SAX 2.0 extension proposals.
 Miles Sabin wrote: > > David Brownell wrote, > > So, have a look at my pipeline package. It layers code to > > control some of those basic features, including validation. > > You'll start to see why I don't think putting it into the > > core of SAX is necessary. > > Interesting, but, I think, orthogonal to the factory part of > my proposals. As a means of constucting chains of SAX event > processors it's quite nice (tho' I have a bit of a horror of > String based specifications), That's just a convenience for the simpler pipelines. Makes it very easy to them up and run them from the command line, without writing classes. When any stage needs serious configuration, code still provides access to the full functionality. > but it doesn't help to resolve the bootstrap issue. It does help resolve some of the feature negotiation you were worried about as part of bootstrapping. Based on the processing that needs to be done, some filters can be removed if the SAX2 parser driving the pipeline can achieve the same effect directly. Which is part of why I pointed it out: it DOES help resolve it. > At some point or another you'll still have > to programmatically reference some vendors parser. Some chunk of code has to deal with configuration management, and parser selection is only one of many such issues. I'd really rather that apps have internally consistent approaches, rather than expecting each subsystem to use a different framework for it. So IMHO it's actually good if the SAX2 core provides only minimal hooks (e.g. what I sent before), and thus forces apps to deal with their own configuration management issues in a consistent manner. And no, I wouldn't be in favor of SAX2 endorsing a particular scheme for configuration management. It's an area where apps need to vary widely -- from simple hardwired configs, to ones that are centrally managed via hierarchical configuration databases that are securely administered and which host automated integrity checking. It'd be as wrong to mandate one approach as another. > That means > either hard-wiring a reference to that parser into mainline > code, or coming up with an ad hoc factory solution. > > Better to put that in the SAX core, I'd say. I think we agree that some factory solution needs to be in the core, but I'm advocating a simpler approach than you are. What you're talking about is more of what I'd call a "broker": provide a feature list, it assembles something suitable. Such modules often get discussed, but seldom implemented at lower levels. Lots of E-Biznesses are getting set up to provide high level brokerage services -- best price on a commodity with some feature (these chemicals, quality X, delivered to me by Wednesday, billed to account) -- but brokers tend to need LOTS of options to chose from before they get viable, in code or economic senses. Part of the issue is that there really aren't that many parsers that are worth even considering, so the need for a broker isn't particularly strong (as I see it). Another part is that in my preferred model of the future, parsers are very similar in functionality, and the variability creeps in through higher levels -- so again, there's little need for brokerage facilities at the lowest level. - Dave *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/threads.html *************************************************************************** 
|
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
|
|||||||||
