The move to WPF

Now SketchPath has got XPath 2.0 support built-in, the next stage is to more to using the .NET WPF and XAML, to give this tool more flexibility.

Progress has been fairly slow with WPF as I try out different techniques. Initial impressions are that this is an extremely powerful environment for developing visually rich applications. The cost however is that there is some additional complexity, because the 'off the shelf' controls really need to be modified to get the most from WPF.

Now, the bridging between XAML and C# can be somewhat tricky. XAML dependency properties need to map to CLR properties. XAML ControlTemplates are a very powerful way of enhancing existing controls. However, if you need to add extra properties to your control you need to dip into c# to create a Custom Control class. This acts as a useful wrapper and registers dependency properties with equivalent CLR properties.

The biggest issue seems to be referencing XAML resources such as a ControlTemplate from within c#. As an interim measure I'm actually using a hidden control's instance (declared in XAML) to get a handle on that control's template dynamically in c# to create further controls (a custom TreeViewItem in this case) but there's got to be a better way. Whenever I come across a method starting with 'FindResource("name")' or even, 'TryFindResource' it makes me wary.

Still, even with these teething problems, there's a significant improvement over Windows Forms. Because geometry and trigonometry are not my favourite subjects, I'm relying heavily on Expression Blend 2 to do much of the visual design work and Visual Studio 2008 Professional for the C# side. The integration between these two products is much better than it was, but its still not exactly seamless.

Top 10 XPath Expression Errors

My List of XPath expression errors I come across most frequently:

1. Attempted use of the default namespace in XPath 1.0
2. Incorrect loading of namespaces into the XPath evaluation environment
3. Use of a != b when not(a = b) is probably what was meant
4. Mis-Capitalization. Either in location-paths or for operators (use 'and' not 'AND')
5. Using a predicate to find the nth child node of each parent - wrap the expression in brackets - e.g. (/workbook/sheets)/sheet[n]
6. Assuming that nodes are zero-indexed - a[1] actually returns the first node
7. Using a reverse-axis such as ancestor:: without considering the nodes are accessed this way in reverse-document order - sheet/ancestor::*[1] returns the node closest to element sheet - in other words its parent
8. Misunderstanding of the real context node for a relative xpath expression (If the expression doesn't start with a '/' - then its relative to the context node which may be modified by the host language e.g. XSLT)
9. Overuse of the // expression for descendant-or-self - adversely affects performance
10. Errors due to an excessively lengthy expression that is hard to document. If in XSLT or XQuery, try using variables to make the expression clearer, and to help understand errors when they occur.

XPath isn't hard. Its just that some expressions that look really simple, actually require a bit of extra thought and testing.

A New XPath Tutorial

If you're new to XPath you might want to try out the following tutorial by Brett McLaughLin:

http://www.ibm.com/developerworks/edu/x-dw-x-introxpath1.html?S_TACT=105AGX01&S_CMP=HP

This is just the first part and you need to register on the IBM developerworks host site first.

One thing to note is that this is an XPath 2.0 tutorial. Though this isn't mentioned explicitly, its clear from some small details in the contents of the first part. No doubt in subsequent parts things will become clearer, but it would have been nice to have seen this mentioned up front.

The XPath tools recommended by Brett are AquaPath for Mac OSX and Stylus Studio for Windows.

The tutorial and resources have a Java perspective on things but this should be useful to all developers new to XPath. No standalone XPath 2.0 processors are mentioned in the first part, but in my view, Java developers will probably go for Saxon.

Disappointed that SketchPath doesn't get a mention, but I'm sure there's a good reason, probably commercial.

LINQ to XML / XSD and XPath 2.0

Much has been written comparing LINQ to XML with XPath 1.0.

This is not a valid comparison, so to do my small bit to even things up, I'll briefly show XPath 2.0 (though I could as easily have used XQuery or XSLT 2.0) on a simple test case that was first illustrated here.

Sample 1: LINQ to XML:

(from item in purchaseOrder.Elements("Item")
select (double)item.Element("Price")
* (int)item.Element("Quantity")
).Sum();

Sample 2: LINQ to XSD

(from item in purchaseOrder.Item
select item.Price * item.Quantity
).Sum()


Sample 3: XPath 2.0

sum(
for $item in purchaseOrder/item
return $item/price * $item/quantity
)

Now, LINQ to XSD is certainly an improvement on LINQ to XML (the latter just looks ugly to me), but is it neater than XPath 2.0. And given the similarities, why invent yet another XML expression language?

As to when LINQ to XSD is coming, there appears to be some doubt though progress is definitely being made. Scott Hanselman commented on this in a blog article some time ago.