Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Serializer performance patches

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Serializer performance patches
  • Date: Wed, 29 Jun 2005 16:33:21 -0700


Are there other commiters to XOM than ERH? (especially after the latest saxon post to his blog (which I agree with!))

best,
-Rob



The Saxon code base may not win beauty contests but IMO it's by far the most standards compliant, mature and efficient product in that area. In practise, it get's the job done better than anything else out there. In a crowded place, there's rather limited value in (re) implementing some spec for the 100th time, this time just a little better or cleaner. Saxon is a race horse wrt. evolution and development approach, not a turtle for dummies. Wrt. the ill-advised unit test craze: Writing unit tests with exhaustive coverage for every line of code may work well for small toys or projects with many committers, but would be a complete waste of time for the Saxon one man show. While early interactive experimental tests and automated integration tests (of which Saxon has a gazillion) do have a useful cost/benefit ratio, fine grained 100% unit test coverage mania is ill advised. It would take *years* to write and maintain such tests, while interesting development and evolution would almost completely stagnate. Saxon is solid and at the same time far ahead leading the pack, getting the priorities right. Just my take.

P.S.:
Some of us learned programming on historic batch mainfraimes where a submitted hello world job would take one hour to complete, only to spit out a laconic "syntax error" on some printer in the computer center on the other side of campus. For most folks, this learning experience led to thinking hard about a program before doing anything, a style of programming that produces programs that are mostly bug free to begin with. Adding tests as a particular need arises seems sensible, thinking before testing is better, and refraining from mostly clueless arguments is best. Ah well, enjoy...

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page