Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Reusing, Refactoring, Reinventing??? (was Re: SAX
 Michael Champion wrote: > I thought the suggestion on the table was to standardize EXTENSIONS to > SAX to allow binary and/or typed data. It sounds like textbook software > engineering to me -- re-use what is common, add specialized extensions > for what is not common. Learning from SAX while forking / reinventing it > seems to do what everybody laments about the state of the software > industry -- too many wheels being reinvented, too little code being > reused, resulting in proprietary lock-in, unreliability of relatively > untested code, etc. Aw Mike. Sounding like something desirable isn't sufficient! You can't credit arguments for binary processing and type resolution out of SAX by claiming proposals for it sound like textbook software engineering, or that not doing so is lamentable with respect to the software industry. I don't know - is textbook software engineering desirable anymore? ;-). Also, SAX is not designed for binary streaming or type resolution, using it so will always be working against it imo. As Elliote and I keep pointing out, SAX is predicated on Unicode and char[] not Binary and byte[] and certainly not Object - no amount of opting or bit twiddling with URLs will change that. Put it this way - if binary processing and type resolution gets into SAX, I predict SAX will cease to become an acronym soon after. Whether you would want to take the SAX callback pattern and create an API for binary parsers is another matter. I imagine you would want to consider it. > I also ask that the designers not call their new format or APIs > anything that reminds people of XML. That is, don't use the names > SAX, XML, DOM, Xerces, etc. This merely confuses developers. Let the > formats, APIs, etc. stand or fall on their own merits without trying > to bask in the XML glory. > > > I hvae to disagree with this sentiment. First, I doubt very much if > ordinary developers give a rat's patootie about the subtle distinctions > here, and they are so UTTERLY confused about the various "XML" specs and > APIs already that this is just a very small drop in an immense bucket. I don't know what ordinary would be in this case, I think there are a lot of developers out there doing silly things with XML, especially in web services. But, I do know that the most of developers I've come across in my work with XML much prefer working with Plain Old XML mapped onto Plain Old Objects. Anything else is treated as gorp that somebody or some tool is imposing on them, supposedly for their own good. Anyway, past idiocy is not a justification for being idiotic tommorrow. That bucket is being filled one drop at a time :) > Finally, the rhetoric on this list (especially this thread, but > obviously the Avalon/Indigo threads too) is getting a bit overheated, to > the detriment of clear communication. We all could profit [me too! I'm > one of the sinners, feel free to rub my nose in it] by reading Orwell's > "Politics and the English Language" > http://www.mtholyoke.edu/acad/intrel/orwell46.htm every now and then. I > think this quote succinctly summarizes his point: "If you simplify your > English, you are freed from the worst follies of orthodoxy ... when you > make a stupid remark its stupidity will be obvious, even to yourself. " My objection with this proposal is that I see no value in retrofitting non-Unicode streaming into SAX. First of all, binary decoding with current Unicode/XML processing adds a cost to those who just want to work with XML - appeals to simplicity are not going to convince me otherwise, optionality != simplicity. Second, I haven't seen any good arguments that suggests driving type resolution down into XML parsing infrastructure is warranted. Sorry, but once bitten twice shy - after everything I've seen and coded aginst with datatypes, namespaces, infosets, I'm a very hard sell on mucking about with SAX. Thus I think that functionality should appear in its own API, which may or may not look a lot like SAX. I would want want a couple of years running text and binary callback parsing side by side in the wild before unifying the APIs. Plus if it's really that simple, why can't some of the ASN.1 folks build a SAD engine as proof of concept? Bill de hÓra -- Technical Architect Propylon http://www.propylon.com 
|
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
|
|||||||||
