1. The ability to override and change the rendering at runtime, e.g. by setting a control property.  To be used typically in webpart scenarios where solution designers want to easily prototype changes and minor improvements to the UX etc. without needing any recompilation.
2. The ability to update the original XML without having to write any code, e.g. by declaratively relating a control property to an XML node described by an XPath expression.

• Optional validation of the source data and any updates to it against a schema.
• Some kind of (extensible / replaceable) hash based check on the XML data when updating it to ensure it hasn't changed since the data was rendered.
• A provider / datasource model for the loading and saving of the data to avoid needing to code this.  Obvious data sources are databases (via DataSets and SqlAdapters or similar), web services and XML files stored in SharePoint libraries.
• Integration with SharePoint for the InfoPath style scenario of creating, storing and editing XML forms in SharePoint.  We love InfoPath for this scenario but sometimes as developers it just doesn't give us the control we'd like.  Xsltx gives us an option where we don't have to go fully bespoke if InfoPath doesn't fit.
• A wizard to convert an InfoPath form to Xsltx.  This would probably be lossy as script and code behind forms wouldn't migrate easily, but it would give you a quick design surface with InfoPath to accelerate initially building some of the Xsl(tx).
• Finally finishing the VS integration to support new file wizards, etc.  If only VS was easier to customise...

Files posted on skydrive.  Let me know if you want any other features or want some help.

• The default execution behaviour is now 'DataBindAndRender' rather than 'SinglePass', which although slightly slower is much easier to work with, fits with the normal ASP.NET page rendering lifecycle and should work in all scenarios.
• Embedding user controls in xsltx files is now possible (there's examples in the updated sample project) by using xsltx:use-control.
• xsltx:register is now a synonym for xsltx:register-namespace.  I just felt it was more concise and more similar to the equivalent Aspx directive.  You can use either - I haven't decided whether to deprecate the longer one.
• I've removed all use of reflection at execution time, which should make it faster in some scenarios.  There wasn't much use of reflection before (just OnInit during postbacks I think) but there is none whatsoever now.
• The xsltx controls serialise some data on child controls created, which allows the control hierarchy to be recreated on postback, and hence events handled.  Previously, the serialised data included all variable parameters and data used to intialise all the controls created, so could be quite large.  This was/is essential when using the 'SinglePass' approach as the controls weren't created until the Render method was called, so viewstate had already been saved and without outputting my own equivalent of viewstate after rendering, the controls couldn't have been recreated and appropriately initialised.
  
  However, for 'DataBindAndRender', the control hierarchy exists and is initialised before SaveViewState is called, so I'm making an assumption that controls will save any information that needs to be saved in there.  As a result I've changed the serialisation of control information for that scenario, so that the only data serialised is (more or less) the control type and id, i.e. the basic information I need to re-create the controls and their ids appropriately, to allow ViewState and events to work.  There's a chance I've got this slightly wrong and may need to serialise more info than I am doing, but in my own testing it seems to work.  Let me know about this.  FYI I am planning in future releases to change the format of the serialised information to make it more compact again (same info, but probably not serialised as B64 encoded XML ).  I might also need to consider signing the serialised data and may just (for DataBindAndRender anyway) move it into the viewstate... more thought needed by me here.

The updated version is available at the same link as before, at http://www.tesl.com/NR/rdonlyres/10DFD5E6-2D28-4F8B-A468-AA71E85A1684/0/TrinityXsltx.zip.

• Copy the Trinity.Xsltx.dll assembly and accompanying CHM file into c:\Program Files\Trinity Expert Systems\Trinity.Xsltx.
• Copies two sample projects and a solution file into c:\Program Files\Trinity Expert Systems\Samples.
• Copy the Trinity.Xsltx.dll assembly into the GAC.
• Backup and modify C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.CSharp.targets to add a build task into the C# compilation process.  If you don't want this, just copy the backup back over the modified version.
• Backup and modify C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config to add support for the new build provider and handler factory.  Again, if you don't want this, just copy the backup back over the modified version.

Uninstalling from add/remove programs will undo all the above steps - with the config files it re-edits them to remove the relevant entries rather than just copying the backup back over the modified file, so if you (or Microsoft) make any further changes after installing this framework and then uninstall, you won't lose them.

I'm not going to blog extensively today about how to use it - the samples and CHM file should be enough to start having a play.  Let me know if there's any problems, with the installer or otherwise, and I'll try and sort them out.

Have fun!