James's Space

1. It's simple.  One (fairly small) set of concepts apply to all communication, through one UI.
2. It puts users in control.  By and large (and barring mistakes), it is clear to them what they are doing, and with who.
3. It's pervasive and available anywhere and offline.  Web access, blackberries and other interfaces make it easy to access a consistently rich level of functionality from anywhere.
4. It's mature, robust and changes slowly.  As a result, people trust it as a reliable way to communicate, and as an information repository (rightly or wrongly).
5. It's multi-platform and highly compatible.

• Blogs
• Wikis
• Discussion Boards
• Lists and Libraries
• RSS
• Social networking portals

In my opinion, e-mail, as exposed through modern business solutions, still represents an incredible breadth of capabilities for information sharing, collaboration and control and adds more value by deploying it to an organisation than any of the above (yes, I think for most businesses probably deploying only e-mail adds more value than deploying all of the above without e-mail).  For now I'm out of energy and dislike 'thinking out loud' as I'll make foolish errors, so I'll elaborate at some point in the future when I've thought some more :).

However I will add that for me, the latest social networking portals such as Facebook are doing an excellent job of combining and relating different sources of information to improve the richness and relevance of information presented to users.  Rather than competing with e-mail as a communication format, they really show where e-mail and e-mail clients such as Outlook need to go next.  Please, please combine content analysis, content metadata with (evolving) social networks and user behaviour to improve the richness and relevance of the information presented.  Microsoft, Presence is not enough.

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.

• MCMS 2002 was processor licensed only.  It didn't matter how many end-users you had, the cost remained the same.
• SharePoint 2007 can only be server licensed (instead of processor licensed) for 'internet sites'.  Specifically, that option does not allow you to create content that will only be accessed and used by internal users.
• The 2 points just listed mean that you will now have to buy CALs for all your users!  If you have a few thousand users, your costs may only increase by double or similar (depends on your MCMS architecture).  If you have tens of thousands of users, that will probably represent an increase by typically one or more orders of magnitude.

This is a BIG DEAL.  We have at least one customer who may consider moving off the MS stack as regards web content management as a result.  Why, oh why, couldn't Microsoft just let organisations make the choice, as they do today with SQL Server, between CAL and processor licensing?  It just starts to look like a device to squeeze more money out of medium -> large customers... or maybe a less cynical take would be that it's to up the profile of MOSS in line with the cost and so force businesses to realise the potential value in the product?  Who knows, but there are alternative approaches that would have made my life easier :).

Incidentally, if you have Software Assurance on MCMS and you're in an intranet scenario, you may be okay.  This page mentions an upgrade option for this scenario that translates a MCMS processor license into a MOSS server / CAL license(s): http://office.microsoft.com/en-us/sharepointserver/HA101655351033.aspx (look under upgrades).  However, I can't find any information on the detail of this yet, but if I do then I'll post it here.

Update: Apparently for customers with MCMS Enterprise Edition and Software Assurance, 1 processor licence equates to 250 SharePoint Enterprise CALs - if this isn't enough then you'd need to have further discussions with Microsoft.  If you don't have SA, there's no upgrade option.

• 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.