OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Reusing, Refactoring, Reinventing??? (was Re: [xml-dev]SAX

[ Lists Home | Date Index | Thread Index ]

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS