Thanks to the XML hero Cazzu, via Paul and TheServerSide, for pointing this one out:
Altova announced a royaltee-free distribution of AltovaXML engine complete with .NET interfaces. It supports XQuery 1.0 and XSLT 2.0 (with or without schema support). Excelent news for .NET developers!!!
I was recently blessed with to have a conversation with someone I hope to call friend. The conversation itself seemed mundane enough. He had listened to the SQLDownUnder web cast and was getting back to me with thoughts and questions. He asked if I had read much about database refactoring. I've not, and frankly, the whole Schemata Theory isn't something I've spent as much time with as I probably should. My reason here though is simple: I've decided to spend my time learning the practice of the technology (e.g., what SQL Server 2005 is, does, how and why) rather than the theory of databases in general. Why? It is immediately applicable.
He then asked another question, which leads me to my contraction. As of late, I've been of the mind that we, as Computer Science educators, are doing the wrong thing when we teach students just the technology. We also do the wrong thing when we teach them just the theory. My current position is that the most effective teaching -- or perhaps mentoring -- we can do is teach our students how to effectively and efficient consume field-specific knowledge. It works like this: instead of me teaching you XQuery, or me teaching you about encoded document theory and query language theory, I would teach you about what aspects of these things are critical to success so that you can quickly select the best candidate sources of information to consume. I could then teach you skills to reconnoiter that information to see how likely it is that it expresses the knowledge you desire and finally, I could present skills you could use to validate both the correctness of the information presented and how you can go about assimilating and retaining that information when it comes time to apply it.
Why? Let's face facts: the rate of change of the rate of change in information technology knowledge is both large (it would be a high percentage of the base rate of change) and positive. If it hasn't already, this velocity of knowledge growth will make it impossible for even a specialist to keep up eventually. That's fine because most developer technologies have fairly short life expectancies. But as developers expand their fields of knowledge, the more durable those fields become. SQL Server versus Indigo is a prime example of this. SQL Server is a productized field of knowledge that is simply developer specific. It has its own life, and thus is a fairly durable field of knowledge. Indigo may become this, but right now, we don't know how persistent it will be, or how it will be persisted in products. Why does that matter? Simply put, the higher the durability of a field of knowledge, the longer time you have to annuitized the expense of learning it over. Economically speaking, if I know I can use the knowledge I've gained from a $5,000 training course on SQL Server 2005 for the next five years, or can use the knowledge I've gained from $2,000 Indigo course for the next year, I get a better return on the SQL Server class.
Following that logic, then, if somebody taught me the skills to learn anything at anytime when I needed to, I should be willing to pay a very great price for that indeed. Such an investment annuitized over a productive lifetime. And therein lies my own contradiction: I'm too busy learning to learn the skills of learning, which is really the investment I should be making.
It seems the person that I had this conversation with already knew that.