One of the really cool things about working at Microsoft is the chance to work on next generation technologies that really make a difference. A few weeks ago, my boss offered me the chance to work on the technical evangelism effort for the next version of SharePoint, and I jumped at the chance.
This blog is inactive.New blog: EricWhite.com/blogBlog TOCNote: This isn't replacing our evangelism efforts around Open XML, it is augmenting them. More about this in a minute.
We, of course, use SharePoint throughout Microsoft. Fairly often, when working in a large company, you end up in a situation where you must communicate something to a large group of internal users, and SharePoint is by far the easiest way to do this. Sometimes it is as simple as posting some documents on your //my site, and letting the group know about them. There are many more elaborate scenarios too, of course. When writing the LINQ to XML documentation, I wrote some quick and dirty tools to convert the documentation set to a SharePoint wiki. Then, the dev team was able to do their technical review of the docs in the wiki, simply changing the code or text as appropriate, adding comments, or whatever. The ease with which they could do the technical review really facilitated great participation within the team. Their barrier to entry was really low – they just had to be on the corporate network, have a browser, and they were off to the races. I used the history feature of SharePoint wikis to see the exact changes made by each team member. In contrast, other tech review tools involve downloading a special application, with associated installation issues, or passing around documents, which means that the developers or program managers can't see comments or corrections already made by another member of the team, which adds to their (and my) workload. Using SharePoint wikis worked well - the end result is that to date, I haven't found any cases where the LINQ to XML docs are not semantically complete.
The beauty of this is the ease with which you can use SharePoint. I don't believe that I ever cracked open a manual or read a book on SharePoint. I just jumped onto my //my site and did it.
About a year ago, I was talking to my (then) boss, and he asked me what I would really like to do in Microsoft. My response: LINQ to XML is one of the most powerful and enabling technologies that I have come across. There are many XML dialects used throughout the Microsoft stack (Open XML, CAML, XAML, XHTML, to name a few), and I wanted to work at the intersection of these technologies, using the power of LINQ to XML to connect them.
I can imagine writing SharePoint code that takes a collection of Open XML documents, and presents a new view of them in SilverLight. LINQ to XML has the capacity to reduce code line counts by an order of magnitude. You can write a couple of hundred lines of code in this scenario that does some incredibly cool things. This vision of Open XML within SharePoint is particularly compelling. With the ISO ratification of Open XML, we have this dialect documented in extreme detail. This means that we have the ability within SharePoint to write .NET code that cracks open every document in a document collection, a site, or a site collection, and present the extracted information in innovative and powerful ways. Leveraging custom XML within Open XML means that embedded business or semantic information can be aggregated and transformed, giving upper management a new lens with which to view the activity of their group or division. Combining this with the metadata stored in SharePoint opens up even more possibilities.
Another scenario: take some external data source, generate Open XML documents, and automatically provision a SharePoint site with documents that enable a group to accomplish their mission in an easier way.
As any of the many SharePoint experts could tell you, these are some of the underlying reasons behind the dramatic growth of the use of SharePoint! I'm really excited about the future!