[
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
Propylon
http://www.propylon.com
|
