With the hype growing to a feverish pitch about the public announcement of Xen, I thought I would share some insight into the knowledge I've had of the language for almost a year and a half. I'm still under orders not to post the video demonstration I have back to my blog (not because the subject matter is Xen, but because apparently the demonstration is internal to Microsoft... I still don't understand this (expecially now that the cat is out of the bag), but it certainly doesn't stop me from sharing some of the information contained in it. This will be an ongoing post as the demonstration is over an hour long, with lots of code samples to boot.
Intro to Xen
This article was submitted for publication by Jayson Knight, a certified Microsoft Solution Provider.
I won't rehash the whole "programming with rectangles, triangles, and circles" paradigm that seems to be the encompassing theme of Xen, simply do a search on any search engine for Xen/X# for that kind of information.
One of the first things mentioned is about declarative languages, XML and XSLT falling neatly into that category. one of the fallbacks of declarative languages is lack of typing/loose typing, and being late bound and uncompiled/interpreted. the ultimate end goal of Xen will be something that is 100% reliant on the CLR type system, and also fully compiled and optimized. while there are numerous primitives in XML/XSLT, extracting this data from the document at this point is done almost entirely using string types for all of these. this is something that simply must be overcome (v 2.0 makes some serious inroads into this, but nowhere near as much as Xen, as you'll see shortly). in the .Net world, there are basically 3 seperate type systems:
The SQL type system, encompassing TSQL and SQL types (varchar, money, etc)
The XSD type system, which provides Xml serialization functionality and encompasses XML, XPath, XSLT, and XQuery
The CLR type system, which includes all of the .Net types that i am sure everyone is quite familiar with
There are 3 sets of API's to bring these 3 type systems together:
ADO.NET for the CLR - SQL bridge
SQL XML for the SQL - XSD bridge
System.Xml for the XSD - CLR bridge
now for some code. here the way you would typically handle some data extraction from and XML document using the DOM:
decimal AddTotal(XmlDocument doc, int zip) {
decimal total = 0;
foreach (XmlElement item in
doc.SelectNodes("order[Zip=‘"+zip+"’]/item"))
{
XmlElement price = item.SelectSingleNode("price");
XmlElement qty = item.SelectSingleNode("quantity")
decimal p = Decimal.Parse(price.InnerText);
decimal q = Decimal.Parse(quantity.InnerText);
total += p * q;
}
return total;
}
This is most defintely a functional snippet, however it's string based typing with lots of casts, and overall isn't that readable, and notice the way the XPath query is assembled using an assortment of double and single quotes. of course, you can use the XmlSerializer class to work around some of the typing issues as such:
class Order {
public Item[] Items;
}
class Item {
[XmlAttribute] int id;
public int Zip;
public decimal Price;
public decimal Quantity;
}
XmlSerializer s = new XmlSerializer(typeof(Order[]));
Order[] orders = (Order[])s.Deserialize(stream);
decimal AddTotal(Order[] orders, int zip) {
decimal total = 0;
foreach (Order o in orders) {
if (o.Zip == zip)
{
foreach (Item item in o.Items) {
{
total += item.Price * item.Quantity;
}
}
}
return total;
}
While this example is functionally equivalent, it's actually much more verbose and harder to read due to the fact that we lost out querying language and had to basically roll our own by using a nested foreach loop, and an "if" test. Xen is attempting to merge the two programming models together, and here is a sample (syntax will probably change by the time it's released, look at the concepts more than anything else) written in Xen, with key code in red:
public decimal AddTotal(Order orders, int zip)
{
decimal total = 0;
foreach (Item item in order[Zip == zip].item)
{
total += item.price * item.quantity;
}
return total;
}
What in the heck is "Order"? what is this new syntax on the right side of the foreach loop? it's a little hard to explain without first giving a short history lesson on XSD types, and the importance of them (obviously) in the integration of Xen with C# (which is elegantly described as Xen = C# + XSD + XML + XQuery + SQL). here are the basic types in XSD that Xen will attempt to roll up:
sequence
choice
all
* + ?
T , U
T | U
T & U
attribute
attributeGroup
required
typedef
mixed
xml:space
T requires expr
and a short example using some of these types based on an SVG scenario:
<xs:complexType name="container">
<xs:complexContent mixed="false">
<xs:extension base="t:shape">
<xs:sequence>
<xs:element name="desc" type="xs:string" />
<xs:element name="title" type="xs:string" />
<xs:choice maxOccurs="unbounded">
<xs:element name="rect" type="t:rect" />
<xs:element name="line" type="t:line" />
<xs:element name="g" type="t:group" />
<xs:element name="ellipse" type="t:ellipse" />
<xs:element name="polygon" type="t
olygon"/>
<xs:element name="styles" type="t:styles"/>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
So the question is how to take this declarative model and model it in Xen? here it is:
public class rect : shape
{
attribute int x;
attribute int y;
attribute int width;
attribute int height;
}
class container : shape
{
sequence {
string title;
string desc;
choice {
rect;
line;
group g;
ellipse;
polygon;
styles
}*
}
}
As you can see, the XSD constructs of "sequence" and "choice" are made first class citizens of Xen, as well as the notion of zero or more as indicated by the asterisk for the "choice" block, and attributes are strongly typed and mapped to CLR prmitives. this is quite obviously quite an improvement over the XSD way of handling things. so that covers the XSD part of the equation, now on to the XML portion and what is slated to be included. There are 5 fundamental XML Literals that are mentioned, along with their importance to the XML language, they are:
namespace "URI" { }
using prefix = "URI";
Foo f = ;
Code snippets: ;
XSD validation by the compiler
One ramification of this is that the Xen compiler will be doing the XSD validation at compile time. of course you can validate in the current version of .Net, but a realistic situation is that you will be building an XSD document at runtime to be sent to perhaps another application to be consumed, what happens if it's not valid? Trying to track down the source of the error is also time consuming and arduous. the benifits of moving this sort of validation into the compiler should be quite obvious. here is an example of some code that uses current XML technologies in .Net to build an HTML table:
protected override table GetResult() {
table result = new Table();
tr row = new row();
result.Items.Add(row);
th cell = new th();
cell.InnerText = "ID";
row.Items.Add(cell);
cell = new th();
cell.InnerText = "Name";
row.Items.Add(cell);
…
foreach (tr row in GetCustomersByCountry(this.country)){
table.Items.Add(row);
}
return result;
}
Here is a Xen example using an XML literal to describe the table declaratively:
protected override table GetResult() {
return <table>
<tr>
<th>ID</th>
<th>Name</th>
<th>Company</th>
<th>Address</th>
<th>City</th>
<th>Zip</th>
<th>Phone</th>
</tr>
{GetCustomersByCountry(this.country)}
</table>;
}
It's still strongly typed (demos to come later), and it gets compiled completely down to IL via the Xen compiler. notice the curly braces following the closing < /tr> tag, that's an example of a code snippet XML Literal in Xen. The last part of Xen that i will touch on in this post is querying...the Xen way. there is quite a bit of useful information here, and one of the most exciting is SQL DML keywords (SELECT, DELETE, UPDATE, INSERT) becoming first class citizens as you will see. Querying takes on a new form in Xen. For now, it's being modeled after XQuery, but with a few changes:
no more "/", these will become "." to follow the paradigm we are all used to with C#/VB.NET/etc
0 based indexes instead of 1 based
XPath aggregates are supported (avg(), sum(), etc)
Queries are strongly typed, and mapped to the CLR
Xen/C# variables can be plugged directly (and typesafely) into queries (without all the messy "" and '')
of course, here is a short snippet demonstrating some of these (this also explains the red code in one of the first samples):
Book[] books = ...;
string name = "Joe Bloggs";
string* titles = books[author == name].title;
What this example does is select all of the books with the author name of "Joe Bloggs", then return this as a stream to the variable "titles" of type string*. the asterisk simply means a stream of strings, 0 or more values, a better definition is IEnumerator typed as "string". a good question is why not just return to an array of strings? you can't gaurantee the richer symantics of an array (indexing, counting, etc) over any query due to limitations of SQL itself.
we are at the last part of the equation in order to implement the ADO.NET programming problem, the SQL portion. the full set of SQL DML operations need to be implemented, and in it's prelimenary form, Xen will add two more; "Replace" and "Move" for XML design reasons (where in a tree you want to do these operations). here is a list of each, and their Xen implementation:
Select - select * from Customers where Zip == 98072
Update - update group.employee.salary *= 1.1;
Insert - insert group.employee[salary>100] before foo;
Replace - replace group.employee[salary>100].bonus with 10;
Move - move group.employee[salary>1000] after wdinc;
Delete - delete group.employee[salary>1000000];
I think they are pretty self explanatory, it's also worth noting that Xen isn't rebuilding these notions, it's simply a wrapper on top of the existing model that's already in place...why reinvent the wheel. here is an example of ADO.NET code, and it's corresponding Xen counterpart:
SqlCommand cmd = new SqlCommand("select *" +
+ " from orders"
+ " where Total > @threshold",
this.Connection);
cmd.Parameters.Add("@threshold").Value = threshold;
IDataReader r = cmd.ExecuteReader();
while (r.Read()) {
…
}
Becomes:
foreach (OrdersRow row in
(select * from orders where Total > threshold))
{
…
}
Again, the benefits should be pretty apparent just from glancing at the code. one of the final things i will touch on is XSLT in Xen. here is a short snippet of XSLT that has an embedded C# function in it to calculate the balance of a ledger and return it to the XSLT document:
<xsl:for-each select="Ledger/*">
<xsl:value-of select="user:Total(.))"/>
xsl:for-each>
<msxsl:script implements-prefix='user' language='C#'>>
decimal balance = 0;
void Total(XPathNodeIterator iter) {
XmlNode node = e.NextNode();
string s = node.SelectSingleNode("amount").InnerText;
decimal amount = Decimal.Parse(s);
if (node.Name == "deposit" || node.Name == "balance")
balance += amount;
else
balance -= amount;
return balance;
}
]]>
msxsl:script>>
One of the things about XSLT is that, while it certainly tries to be, it's not a general purpose programming language, so you will always run into those boundaries and end up in the classic ASP paradigm of embedding script into your XSLT docs if you need anything dynamic. here is the same code block implemented in Xen:
int position = 0;
foreach (Item c in ledger.child::*) {
if (c is Deposit || c is OpeningBalance) {
balance += c.amount;
} else {
balance -= c.amount;
}
yield {balance};
}
And again, the advantages should be pretty apparent. *note* if you are wondering what the "yield" statement does, check out some info on iterators in the v 2.0 release of C#, the statement does the exact same in this situation as it does for iterators.
So that's the end of the first part of my multi-post on Xen. This was meant to be purely an informative post, i am saving opinions for another time. also, the code examples in this post are meant to be informative only as no doubt the syntax will change drastically before Xen ever sees the light of the CLR. In a future post I will touch on how Xen may be implenting some of the new features of C# v 2.0 (we've seen iterators here, generics, etc are also tied in to Xen), as well as some more XPath information and some samples of what Xen can do to enhance existing applications. as always, comments are welcome (please note that i am not an XML guru). This is pretty revolutionary stuff, and it makes me remember why I chose to be a programmer in the first place.
, now you were very objective and constructive 
. 
