New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Gavin Terrill on Oct 29, 2007
RELAX-NG (pronounced "relaxing") is an alternative XML schema definition language characterized by being simpler and more elegant than the more generally known DTD or XSD based languages. W3C XML Schemas in particular has garnered a reputation as being overly complex, with XML luminaries such as Tim Bray commenting:
W3C XML Schemas (XSD) suck. They are hard to read, hard to write, hard to understand, have interoperability problems, and are unable to describe lots of things you want to do all the time in XML.
To help condense some of the information scattered around the internet on the virtues on RELAX-NG, Griffin Brown recently listed 10 reasons to model XML with RELAX NG , not W3C XML Schema. The list includes:
18 agile and lean practices for effective software development governance
SOA All-In-One Guide: KPIs & Best Practices, ESB Report
Mobile and the New Two-Tiered Web Architecture
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Getting Started with Stratos - an Open Source Cloud Platform
...before you'll see folks switch.
Brown points out 10 things that are arguably qualitative, not quantitative. XML-Schema, if anything, is complex, but not necessarily deficient.
I'm all for adopting standards that are easier to approach since xml schema modeling is very important. Again, it's hard to justify a switch in schema tooling when a good deal of infrastructure won't support it.
I agree with Noah. I am not a specialist of relax-ng by any means but a quick look at the spec seem to indicate that the extensibility of the language are weak (foreign elements and attributes seem to be limited to ##other namespace). If this is the case, this is a severe limitation and setback incompatible with SOA.
I did not see any performance comparison, it would be interesting how validation compares in both cases.
I agree that XML Schema is complex (tools somehow mitigate it) but I need this complexity. The question is for the casual designer of schemas (say a few schemas a year), what is the best approach for him or her? is a tool enough? Do we really need a new syntax?
I like the vision of David Chappell that seem to indicate that XML, WSDL, XSD, BPEL... are the byte code level of the technology. I am not sure we need more byte code level technologies.
Not convinced so far...
We use RelaxNG compact extensively in our systems. It is so easy to write that there is no need for complex tools. The Java XML parsers support it perfectly.
You can import definitions, use multiple name-spaces, use overriding of definitions and much more with ease. And almost any human with minimal knowledge of context-free grammars can understand them easily. It has the correct level of syntax sugar necessary to allow you to express complex schemas succinctly.
I do not wish XSD on anyone, not even on my worst enemy.
+1. "If WSDL is a turd, then XSD is the dodgy curry that makes it stink" - me.
...very nice.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
5 comments
Watch Thread Reply