Upcoming changes in LINQ to XML

There have been a few changes to LINQ to XML after Beta1. These changes are in Beta2.

This blog is inactive.
New blog: EricWhite.com/blog

Blog TOC- Data binding for WPF is now supported. There is an example in the docs that shows how to bind WPF controls to an XML tree. Changes to the data in the user interface are reflected in the tree, and changes to the tree are reflected in the user interface. You can find the explanation of how to do data binding, as well as the example, as children topics under the topic “Advanced LINQ to XML Programming”.

- There is an XNamespace singleton that is used for elements and attributes that are in no namespace. In Beta2, this property was named XNamespace.Blank. In the final version, this property will be named XNamespace.None.

- The default XmlReader setting does not resolve external entities. In addition, there is a preset limit of 10 million characters for the internal subset. This is security hardening against obvious denial-of-service attacks.

- There were a few changes for performance reasons. Performance is better in Beta2, and better yet in the RTM release.

Since Beta2, there are a few more changes.

- The delegate XObjectChangeEventHandler used for notifications is replaced by EventHandler<XObjectChangeEventArgs>.

- New explicit conversion operators are defined on both XElement and XAttribute that allow you to cast to the new type DateTimeOffset. Further, instances of DateTimeOffset are valid content for XElement and XAttribute. Just as with DateTime, LINQ to XML is lax when converting to DateTimeOffset from an element or attribute, but is strict when formatting XML from a DateTimeOffset.

- XDocument no-longer implements IXmlSerializable since both the XmlSerializer and the DataContractSerializer have only partial support for all the data that can be stored in a XDocument. The workaround is to use XElement.