Cart
[Home] [By Thread] [By Date] [Recent Entries]
David Brownell wrote, > 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 This would be a good argument _if_ adoption of something along the lines of the factory I proposed _excluded_ other forms of configuration management. It doesn't tho', and one part of it, the XMLReaderImplementation interface, would probably _enable_ other configuration management mechanisms. Funnily enough, the bare interface part isn't a million miles away from your own minimalist proposal: see, http://www3.mistral.co.uk/miles/doc/org/xml/sax/XMLReaderImplementation.html The concrete factory/broker class OTOH could easily be optional, and treated as a convenience implementation for those applications which don't have much in the way of global configuration management infrastructure. > What you're talking about is more of what I'd call a > "broker": provide a feature list, it assembles something > suitable. Part of my factory proposal is indeed a broker. The optional part that is ... > brokers tend to need LOTS of options to chose from before > they get viable, in code or economic senses. In general yes. WRT the SAX API they don't: SAX specifies a simple boolean combination of features. That's relatively easy to provide complete support for. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)20 8817 4030 London, W6 0LJ, England msabin@c... http://www.cromwellmedia.com/ *************************************************************************** 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 ***************************************************************************
|
