A principle which states that it doesn't explicitly take energy to compute data, but rather, it takes energy to erase any data, since erasure is an important step in computation.
This explains why work accumulates but can never be exhusted...
Here's a flip-flop that would make both "GWB" and John Kerry proud.
If you've read my blog for any time, you'll probably "get" the idea that I love XQuery. I think its the coolest thing since... XPath. And I'm tickled pink that SQL Server 2005 is going to supported it.
But I'm also happy that, As Dare has announced, its been cut from the .NET 2.0 framework.
No, I'm not being greedy and wanting to just keep XQuery has something exclusive to SQL Server 2005, rather I think Microsoft is making the right support decisions here.
Microsoft has decided not to ship a client side XQuery implementation in .NET Framework 2.0 as our customers expect us to ship an implementation that meets the following criteria: Compliant with the W3C standards . Functionally addresses key scenarios. As a core platform component in Windows, they also expect us to ship a product that meets the high bar of not breaking their applications when future updates are released. After talking to key customers and partners, we have determined it is important that we cross this high bar before shipping a full implementation of XQuery in the platform.
The best estimates tell us that ETA for XQuery to become a W3C recommendation is end of 2005 which does not fit with the .NET Framework 2.0 product release cycle.
In the meantime, we are shipping a well-defined small subset of XQuery in SQL Server 2005 to query information stored natively as XML data type. This will enable new customer scenarios in SQL Server for storing and retrieving semi-structured data.
I think this is a good change because it both minimizes and localizes the changes needed if and when changes are made to the XQuery processor in light of changes to the RFC for XQuery. Its flat out eaiser to patch a fewer SQL Servers than many applications. Its not that I don't want XQuery in the .NET Framework, but I'd rather have it right out-of-the box rather than right now.
If you really want client-side XQuery right now, there's SAXON for Java and SAXON.NET (SAXON ported to .NET) to consider. Stylus Studio looks interesting, but I've not really played with enough yet.
Welcome to the first installlment of "And You Want To Do That Why?" the fun and informative web game you can play today. The rules are simple: the first person to submit an answer that I think is best wins a gmail invite. Its totally my choice: say thank you if you win, don't bitch if you don't. :)
On to Today's question...
XML Schema gives us the ability to serialize dates as:
- <date>2004-10-13<date>
- <date>2004-10-13Z<date> which indicates UTC.
- <date>2004-10-13-06:00<date> which indicates an offset from UTC in hours:minutes
Option #1 from that list is assumed to just make sense, but why would you say are the reasons we need options #2 and #3?
And "because you can" isn't acceptable answer, ok?