At PDC 2009, Michael Shim and Rob Relyea presented Microsoft’s plans for the future of XAML. Currently there are two XAML implementations in .NET, one for Windows Workflow and another for Windows Presentation Foundation. Anyone wanting to use XAML is thus required to take on dependencies on either WF or WPF.
With .NET 4, Microsoft is adding an independent XAML engine in the new System.XAML library. This version only needs System.XML and the core runtimes, making it much more suitable for applications that want to use XAML without loading the Fx libraries.
With .NET 4 we are seeing heavy promotion of XAML Nodes Streams. A node stream is an event-driven API for working with structured data. Readers may be familiar with the XML equivalents based around the SAX-style libraries. In addition to straight processing, XAML Node Streams can be used to alter XAML as it is being loaded by other frameworks.
As part of the refactoring in .NET 4, Microsoft has greatly increased the extensibility of the parser. In .NET 3, the extension points were limited to IXamlTypeResolver, IUriConext, and IProvideValueTarget. The new parser adds support for injecting many other services through these interfaces. Many of these interfaces aren’t new; they just were not publically exposed.
- IRootObjectProvider
- IXamlNameResolver
- IXamlNameProvider
- IAmbientProviders
- IDestinationTypeProvider
- IXamlNamespaceProvider
- INamespacePrefixLookup
- IXamlSchemaContextProvider
- IXamlObjectWriterFactory
Like XML, XAML will have two parsing APIs. In addition to XAML Node Streams, there is going to be a XAML DOM. The XAML Document Object Model allows developers to work with the entire XAML tree at one time. In addition to working directly with the node tree, developers will also have access to a LINQ provider.The combination of the XAML Node Stream and XAML DOM parsers are being used to add support for static analysis tools like FxCOP.
So far we have only been talking about the parser tool, but there is also a new version of the language called XAML 2009. In XAML 2009 we see full support for generics, non-default constructors, factory methods, built-in types, and defining new properties.
Please not that the compilers and designers in .NET 4, VS 2010, and Blend will not be offering XAML 2009 features in this release. XAML 2009 is only available for “loose XAML”, such as the small configuration files used by Workflow Foundation. A major reason for this is that the WPF designers already have their own parsers and rewriting them to use the common parser will take a significant amount of time.
Silverlight will be adopting the same XAML parser that the rest of the .NET ecosystem is using. This will allow for both better error detection and future support for more XAML 2006 and XAML 2009 features. Silverlight still has a requirement to be a lightweight runtime, so they are adding features on a case-by-case basis rather than whole-clothe.
Part of what will enable Silverlight to use the unified XAML parser is the previously mentioned IXamlSchemaContextProvider. By creating a schema context that is specific to the subset of XAML that Silverlight understands, tools will no longer need to hard-code the differences between Silverlight and WPF-based XAML. The Expression Blend team is said to be particularly interested in this functionality.
