With all the talk about Azure at PDC09 today, I cannot help but observe the inevitable language correction required to once again accommodate the technology lexicon.

"On-premise" vs. "On-Premises."

Many, many people are throwing the words around, as if they are interchangeable. Dictionary.com has the following definition for "premise"

If you are a stickler for accuracy, "premises" would be the correct term to refer to applications, data and services hosted at your local facility. Not that anyone is in a hurry to correct the language or anything. But if you're looking for a good way to say "I'm smarter than you"… this may just be the thing. For completeness, here's the dictionary.com version of "premises."

It's all in fun of course. But I wonder how long it will take the 2.a definition from Dictionary.com to migrate up to "Premise" based on its continued abuse J.

At the recent SharePoint conference, one of the things I was asked most frequently was whether or not we were going to "do anything" about the Outlook MAPI API. Fair enough. As we do at trade shows, we say "let me check and I'll report back to you on that." Today I am happy to report back on that. MSDN has posted the Outlook 2010 MAPI Reference for your browsing. Many of you may recall the recent announcement about the availability of the PST format documentation as well. Between the two, Outlook developers certainly have a lot more to take advantage of. Excellent progress for this release.

Excerpted from the Outlook 2010 MAPI Reference for your pleasure:

What's New in This Edition
This documentation is preliminary and is subject to change.
The Microsoft Outlook 2010 MAPI Reference has been updated to include documentation for various new features. Documentation for deprecated features has been removed.

New Content
Content has been added for the following features:

• Support for 64-bit Microsoft Outlook—Reference topics for applicable API elements have been updated to correspond to new header files that support 64-bit Outlook. These header files are now available as a download at Outlook 2010: MAPI Header Files. A new code sample is provided in How to: Check the Version of Outlook to show how to check whether the installed version of Outlook is 64-bit Microsoft Outlook 2010. If your existing 32-bit MAPI application is going to be running on a 64-bit operating system with 64-bit Outlook installed, you will need to rebuild your 32-bit application as a 64-bit application. For more information about MAPI support for 64-bit Outlook, see Building MAPI Applications on 32-Bit and 64-Bit Platforms.
  
  
• Fast shutdown support for MAPI clients—MAPI clients can now initiate a quick shutdown and have the MAPI subsystem notify loaded providers to minimize data loss from the fast shutdown. Additional interfaces have been added for the client and provider to support fast shutdown. For more information about fast shutdown, see Client Shutdown in MAPI.
  
  
• Stream structure for field definitions for an Outlook item—Documentation for a binary stream for the PidLidPropertyDefinitionStream property has been added. This property specifies definitions of all custom fields and data-binding settings for built-in fields of an Outlook item.
  
  
• More properties—Documentation for an additional 38 tagged properties and named properties has been added to this release.
  
  
• Option of linking explicitly to MAPI functions—MAPI developers can now choose to explicitly link to the MAPI stub of the default MAPI client (for example, Msmapi32.dll of Outlook) without going through the MAPI library and the Windows MAPI stub. For more information about explicit linking as compared with implicit linking, see How to: Link to MAPI Functions.

Shortcuts for PowerPoint Developers
I've been digging into PowerPoint 2010 development extensively over the past week or so. I've learned a lot I had not worked with it in any meaningful way until a few weeks ago, and I thought I'd share a little beyond what I offered in VBA last week. First, a very useful piece of machinery for PowerPoint coding. This is a loop (written in VB) to iterate through all shapes on the slide currently in view. Once you get this down, the code to perform manipulations on those shapes and slide properties isn't too difficult (provided you can successfully navigate the OM).

(get the code)

As an example of this in use, here is a procedure to remove all underlines from the type used in the current slide.

(get the code)

Here's a way to identify the theme font and apply that font to shapes on the currently displayed slide. This is written in VB using VS2010 Beta 2 and Office 2010. This code sits under a button on a custom Ribbon tab. Theme fonts (both Major and Minor) have three variants: Latin, Complex script and East Asian, and each can be separately identified and modified given the appropriate changes to the code below. The biggest hurdle to identifying that font through the PPT OM is the ability to select (in most cases) the name of the Latin font. There isn't a lot of documentation for doing this, so I thought I'd share a little learning. As with all things, there are probably ways to do it better, but this works, so here it is.

(get the code)

PowerPoint Theme Builder
Also worth your time if you're doing a lot of work in PowerPoint is the Theme Builder. This handy tool will get you pretty far in developing or customizing theme files for PowerPoint. Theme builder works with PowerPoint 2007 today.

Continuing with the deep dive into new tools in Office 2010 Application Compatibility, we would like to explore and illustrate in detail how Code Compatibility Inspector (CI) functions.

Visit the prior post on App compat. Visit the drill down on the environment assessment tool.

The Microsoft Office 2010 Code Compatibility Inspector is designed to assist an enterprise or small business with updating VBA and VSTO code so that it becomes compatible with Office 2010. While the tool does not directly make code corrections (other than correcting Declare Statements for 64bit compatibility in VBA), it does comment code in locations where potential Object Model changes have been identified. Users or developers debugging their code can get assistance from the comments and links to topics on MSDN that detail the changes that may be affecting a specific line of code. Here is what CI actually do:

• The Code Compatibility Inspector consists of four addins that load in PowerPoint 2010, Word 2010, Excel 2010 and Visual Studio (VS 2008 is the targeted version with VB.NET and C# languages supported).
• It operates on a per-user/per-document/per-solution basis. When a user opens a document (or Visual Studio solution) they can run the tool from the developer tab (or Tools menu in Visual Studio).
• The CI scans the VBA projects in the current document or Visual Studio Solution via simple text search looking for parentObject.Property combinations.
• It also scans Declare statements for 64bit compatibility in VBA.
• Where potential issues are found, the tool will add comments right next to that code, including links to the topics on the details of the change pointing to MSDN.
• When completed, the tool will provide a summary and detailed report of what was found in the project as well as an option to remove the inserted comments.

CI can be run by an individual developer or macro user, when they have access to the code. Here is what you can expect to see when you download and run the installation package:

You have choice of the installation either in the Office VBA environment or in the Visual Studio environment or both if you prefer.

To inspect a code in a document for compatibility, you would follow these steps:

1. Open the desired document in PowerPoint/Word/Excel.
2. On the Developer Tab, click Inspect VBA Code.

    

3. On the Inspect VBA Project dialog, select the options you want, then click Inspect.

1. The Inspect Visual Basic for Application Projects has to be checked in order to inspect your VBA project for potential Object Model changes.
2. The Inspect Declare Statements will make your project 64bit compatible. Select this option if:
   1. Your project will only be run on Office 2010.
   2. May be run on a system running 64bit Office 2010.
3. The Add comments option will place comments in your code where potential compatibility issues are discovered. These comments will appear similar to the following:

The <URL></URL> tag will contain a URL to the relevant site on MSDN describing the suspect OM change found (it is not in this picture because.

1. The Detailed Report option will create a text file report at the end of the inspection process. This report will contain the following information:

   SUMMARY:

   ========

   Document scanned:                  c:\Test.ppt
   Date scanned:                                   Tuesday, October 20, 2009
   Total lines scanned:                        319
   Total items found:                           35
   Deprecated items:                          0
   Changed items:                                2
   Redesigned items:                          0
   Declare statements:                       32

   DETAILS:
   ========
   MODULE:                            clsPPTEvents
   FUNCTION:                         PowerPointApp_WindowSelectionChange
   LINE:                                      20
   TYPE:                                     CHANGE
   ITEM:                                    Presentation.SlideMaster
   URL:                      
   CODE:                                   Set objMaster = ActivePresentation.SlideMaster
   MODULE:                            clsPPTEvents
   FUNCTION:                         PowerPointApp_WindowSelectionChange
   LINE:                                      37
   TYPE:                                     CHANGE
   ITEM:                                    Presentation.TitleMaster
   URL:                      
   CODE:                                   Set objMaster = ActivePresentation.TitleMaster

1. When the scan is completed, you will get a summary report similar to the following that will detail the number of changed items, deprecated items and design changed items (described in more detail below):

1. Total Lines Scanned – the total number of VBA code lines scanned in the document.
2. Total items found – this is the total number of declare statements updates, changed items, deprecated item and design change items found in the code.
3. Deprecated items – these are items that were found which were removed from the object model. These items may require a code workaround – an alternative approach as the feature it is dependent on is no longer available in the product.
4. Changed items – these are the items found where the syntax of the command were changed and may need to be updated.
5. Redesigned items – these are items where the syntax is still the same and the item/feature still exists. However, the desired result may no longer be the same. For example, a textbox formatting may have changed because of new text services. While a textbox will be created, the layout of the text in the box may differ when compared to previous versions.
6. Declare statements – this is the count of the total number of Windows API statements that were detected in the VBA code and were updated for 64-bit compatibility by adding the PTRSAFE keyword.

Once you have successfully inspected your code if CHANGED, DEPRECATED or REDESIGNED items were found will be to start debugging your code. We suggest you perform a full test pass on your code, inspecting each function. If problem are found and you break into the debug of your code, check to see if there is a VSTO Code Compatibility Inspector comment above that line. If there is, it should give you direction on the type of problem occurring in that line of code and will contain a URL that you can copy and paste into your browser to get more information. Once you have completed verifying your code for Office 2010 compatibility, you can remove the comments from the code by clicking the Remove VSTO Inspector Comments on the Tools menu:

  As we mentioned in our previous post on OEAT - we will be offering a preview of the tools for Office 2010 application compatibility in early December. We also recommend you stay tuned to the Office 2010 public beta to be delivered in November as well, so that you can experiment with getting your 2003 and 2007 solutions to work with Office 2010.

If you would like to sign up for the beta of OEAT and CI, please send an email to this address: mailto:OFAPPCPT@Microsoft.com.

The Office 2010 train is now boarding. For those of you looking to get your hands on some training content in advance of this month's public beta, we've got your fix. Today on Channel 9, developer workshops for Office 2010 and SharePoint 2010 are posted and live.

Office 2010 Developer Training available today on Channel 9:

• Office 2010 Developer Roadmap
• Office UI Customization
• Office Client Workflow
• Security and Deployment
• Business Connectivity Services
• Developing BI Applications
• Open XML
• Office 2010 Services
• InfoPath 2010 and Forms Services

Congratulations to Donovan Follette and team on some outstanding work!

Most weekly newspapers publish on Thursday because this is the day when the majority of young people plan their weekends. Thursday is a good day for a lot of things; it's when I have my team meeting. I choose Thursday because there's a good bit of news to recap with the team, and there's a bit of time to put things on track that need to be put on track. As it turns out Thursday (especially this one) is a good day for a blog post. I have some things to share, and some news that is worth reading about Office 2010 for Developers.

Did you see the newly designed Office Developer Center on MSDN?

For designers: A quick taste of PowerPoint VBA. People who know me well have witnessed my neurosis for PowerPoint slide design, particularly how type is treated. I lay awake at night wondering how much mental sludge one accumulates after looking at poorly set type over a period of years. For an untrained eye poorly designed slides are hard to read. For a designer they're like nails on a chalkboard. It doesn't have to be this way.

I review a lot of decks (on the order of 50 per week as a guess). I'm famous for fixing them before I can read them. I can't sit and read a bunch of text that is mashed together or poorly organized. I am compelled to act. As a compromise to the people sitting in my office watching me re-typeset their decks, I spent some time coding up a simple VBA add-in to programmatically fix the things that drive me up the wall. I'd like to share a brief sample of that for folks who need an introduction to VBA in PowerPoint. One of the things that I must fix is the line spacing of text. In auto-fit mode, PowerPoint will compress that line spacing down to values as low as 0.9. This gives me the same claustrophobia as bunk beds that are stacked too closely together. The VBA routine below fixes the line spacing issue.

The magic is highlighted below. It reviews each shape on a given slide, checks whether that shape is a text frame, and sets the "SpaceWithin" attribute to 1.0, giving lines 100% height, and a little air to breathe. The remaining code is a few simple loops and variables – probably 100 ways to do it better, the example is crude. But this saves me a tremendous amount of time.

Warning: this may shrink your type in auto-fit mode, but I'll take smaller type sizes over the claustrophobic bunk bed problem 100% of the time. I have similar modules for getting rid of underline type, fixing user-inflicted kerning (tracking / character spacing) problems, and a handful of other things. Each of them took no more than 10 minutes to code, and I save at least 10 minutes of review time on almost every slide deck I see. – per my simple math above, that's 500 minutes a week. Message to fellow designers: It's worth the time to learn how to use VBA in PowerPoint.

Option Explicit
Sub FixLineSpacing()

Dim i,y,j,z As Integer
y = 1
z = 1
i = ActivePresentation.Slides.Count + 1

While y < i

With ActivePresentation.Slides(y)
j = ActivePresentation.Slides(y).Shapes.Count + 1

While z < j
With ActivePresentation.Slides(y).Shapes(z)
If ActivePresentation.Slides(y).Shapes(z).HasTextFrame Then
With .TextFrame.TextRange
.Lines.ParagraphFormat.SpaceWithin = 1
End With
End If
End With
z = z + 1

Wend
z = 1

End With
y = y + 1

Wend

End Sub

By the way I am very aware that the setup to explain what the thing does and why I have it is longer than the code itself -- I encourage you to draw conclusions about the complexity of coding in VBA. It is not a hard mountain to climb.

The great thing about the product launch window is that there is so much great information to share. Following is a list of very good blog posts relating to Office 2010 development. There are enough now that they're hard to keep track of:

• John Durant discusses some VBA routines in Excel to help with data analysis.
• Mirko Mandic discusses some of the changes to the Fluent™ User Interface extensibility in Office 2010.
• TechRepublic gives us a little more broad view of Excel 2010
• Redmond Developer News gave the Office 2010 app compat program a little ink. Great to see and much appreciated.
• Eric White has yet another outstanding post on working with Open XML – this time presenting SharePoint lists in documents
• Asif Rehmani breaks down some of the new capabilities in InfoPath 2010
• John Morgan illustrates some of the problems with the Seahawks and what it will take to get them on track. Good thing we have the Lions at home this Sunday, although I fear that this might mess up our march toward the #1 draft pick.

Update: I caught wind of some problems with the email address for the beta signup through blog comments and other channels. We had to resolve a technical difficulty with the email alias. With our apologies, please continue to use the email address below to sign up for the beta. It should be working now. mailto:OFAPPCPT@Microsoft.com

 In the earlier post discussing Office 2010 Compatibility, we outlined the new tools and guidance for Office 2010 to help update code to work with the new version. There has been quite a lot of interest in the program, which is great to see. I'd like to take some time today to drill further on the tools, this post is one in a handful we will do on app compatibility leading up to the availability of beta tools in December.

As a program, the app compatibility work could be best reflected in the following illustration.

The migration guidance (documents) along with the three tools will be delivered through various deployment programs like DDPS and MDT, but will also be available for use at TechNet and MSDN in the future. These tools and guidance will be freely available for anyone to download and use.

Today I'd like to discuss the Environment Assessment Tool (OEAT) in depth.

The purpose of OEAT is to help assess what applications and Office add-ins you have in your environment. This tool will also help you assess which add-ins vendors have verified will work for Office 2010 and give you enough information on other add-ins and applications in your environment to perform meaningful remediation of potential issues before you deploy. OEAT provides you a snapshot of your organizations add-ins and other applications that automate Office.

OEAT can be run by individuals, locally, or remotely from a UNC share using common IT actions like a login script. OEAT will scan each specified system and report the results to a designated location. OEAT can then be used to compile the results of a single scan or multiple scans into an Excel Spreadsheet, which can be used to assess the environment (and prepare for remediation) before the deployment of Office.

Scans can be done through the OEAT user interface or via command lines. In both cases, output is directed to a location of choice, and for multiple desktop scans, output is aggregated in a single location for compilation. After the completion of scanning, OEAT will compile the results of all scans into an Excel workbook for analysis.

An interesting feature of OEAT is the ability to "passively" scan a system for programmatic access to Office applications. Passive Scan is initiated by turning it on in the setup wizard. Passive Scan Settings is currently step 3 of the Wizard.

The interesting bit of magic for passive scanning is that the program will remain resident in memory on the local machine for the specified duration, performs the scan by placing Audit keys on the specific Word, PowerPoint, Excel and Outlook CLSID Automation keys in the Windows Registry. When any application automates an Office application, Windows will capture that event and add it to the Windows Security Log. It is important to point out that these operations will require the tool to operate with administrative privilege on the system.

OEAT Report

OEAT produces a system summary report that is useful in helping you assess your Microsoft Office installation environment. There are two major categories of information reported by the Office Environment Assessment Tool.

• Systems Summary Report – a summary of the hardware and software environment of your organization. This includes:
  • Drive Space
  • Installed Memory
  • Processor Types
  • Computer Types
  • Windows Installs
  • Installed Anti-virus
  • A series of charts that show these summary reports.

• Detailed Add-ins Report – a detailed report of all systems scanned that include add-ins and automating applications. This includes several lists:
  • All add-ins found – this includes Microsoft add-ins (shipped with Office).
  • Add-ins not installed with Office – this is a subset list of add-ins found in your environment that is not included with Office.

There are additional slices on the data such as 32-bit vs. 64-bit hardware, average disk space, etc. When you report on a single desktop or gather reports from many systems, the raw data is also stored in the report so that you can create your own pivots of the information.

As we move toward release of the tools, Microsoft will be working with vendors to verify whether their add-ins are compatible with Office 2010. As vendors verify which versions of their solutions are upgraded or work with 2010, we plan to offer a forum and a list for vendors to declare their tools as Office 2010 ready. OEAT is planned to integrate with that list, and we should be able to correlate between scan results and the online list, schedule permitting. This is still being implemented, so we'll have more to share in the future.

Sign up for the OEAT Beta

Are you interested in testing the tools on your environment? We will be offering a preview of the tools for Office 2010 application compatibility in early December. We also recommend you stay tuned to the Office 2010 public beta to be delivered in November as well, so that you can experiment with getting your 2003 and 2007 solutions to work with Office 2010.

If you would like to sign up for the beta of OEAT, please send an email to this address: mailto:OFAPPCPT@Microsoft.com. If you are already testing Office 2010 Technical Preview, an Alpha version of the tool is available on Connect: https://connect.microsoft.com/office/Downloads/DownloadDetails.aspx?DownloadID=21775

In a future post, we'll discuss the Compatibility Inspector (The thing that scans your code), OMPM, and the forthcoming documentation for application migration.

SharePoint Conference was a very busy time for us. We were finally able to pull back the curtain on many of the capability areas of 2010, and for a lot of folks, this was the first opportunity to see what all the excitement is about. There is a lot of buzz about Office and SharePoint 2010, but there are some important developer capabilities that are worth paying attention to. I wanted to take a moment to highlight some of the more interesting "sleeper" areas that we discussed in detail at the show, and point you at more information on those.

Visual Basic for Applications (VBA)
Speculation regarding the future of VBA has been a topic of conversation for quite a while. This is a sensitive area for us – there are millions upon millions of VBA coders in the world. A quick analysis of file types on Google search (where we can distinctly identify the differences between macro-enabled and non-macro-enabled documents) shows us that ~4% of Open XML documents for Excel indexed on Google are Macro enabled. Multiply that out to the billions of Office documents that exist, and you get the idea of the value that VBA has to the Office user community.

To cast aside any doubt – VBA is supported in Office 2010. In fact it has been upgraded to support the new, native 64-bit client version of Office. VBA remains a powerful tool in automating Office, and Alt-F11 remains the coding experience of choice for many people. To cast aside any speculation – we love VBA. We encourage you to use VBA, and VBA is a viable and important part of our product. John Durant has an excellent post – "Why VBA still makes sense." It is very much worth reading.

InfoPath 2010 and InfoPath Forms Services
Forms capability in Office and SharePoint is maturing rapidly. With the inclusion of BCS in SharePoint 2010 and Office 2010, InfoPath becomes even more powerful as a tool for aggregating, presenting and gathering information. Why? – People are now discovering how easy it is to bind BCS entities to a SharePoint list, and then present that list data to users in a rich InfoPath form. Because InfoPath does a great job of making complex data interaction simple for end users, it is becoming a critical component of LOB solutions managed in the SharePoint environment. Surfacing InfoPath solutions via the browser, InfoPath mobile forms, through Outlook, SharePoint Workspace or other interfaces makes the rich InfoPath experience portable and flexible. People on the floor certainly responded positively; InfoPath was a smashing success. Visit the InfoPath team blog to read about some of the solutions they were previewing. Below is an excerpt from the post:

Demo 3: Office Business Applications: Procurement scenario
In this final demo,  Peter and Bojana showed the audience how InfoPath helps IT departments develop full Office Business Applications on the SharePoint platform. They used a procurement scenario to demo these capabilities. In this scenario, an employee submits a request to purchase a new laptop computer. The solution used an InfoPath form that connects to a vendor database, that brings in details about the goods you can purchase.

Procurement Form:

Access 2010 and Access Services
Access 2010 and Access Services take a very powerful product and make it stronger. Imagine the ability to design a tracking application in Access, and then the ability to surface that Access application via SharePoint and the browser. A lot of people are observing the type of capability enabled by Access Services, and like this blogger, finding that Access 2010 is worth a look.

At about 9:00 of the embedded video another great new feature of Access 2010 is highlighted – a visual Macro designer.

Business Connectivity Services (BCS)
SharePoint veterans will appreciate BCS as the "read/write implementation of BDC." For the rest of us, BCS is a way to define, store and manage line of business connectivity through SharePoint. BCS is accompanied by a client-side runtime that ALSO allows you to push and cache the results of the BCS connections to the client. This makes it much easier to surface LOB data in Office client applications. The BCS team blog can get you up to speed quickly on how BCS works and describe some of the scenarios that are aided by BCS.

Word Services of SharePoint 2010
Probably my favorite feature of SharePoint 2010 is what we call Word Services. In the past, we've seen many developers who install Office on a server and write VBA for Office to automate things like Open/Save operations. With SharePoint 2010, the introduction of Word Services gets us out of jail on that… instead of scriping the client app, we now offer essentially a "file save as" on the server side, without requiring the client user interface. This makes for a much more robust environment for doing batch document conversions. All file formats written in the client version are supported, and because of this, we now offer bulk conversion to PDF in SharePoint 2010. The Word Team blog has plenty of great details on Word Services. When combined with the Open XML SDK, this new capability opens endless possibilities for processing documents.

There is so much to discuss for Office 2010. Over the next two or three months, we'll drill into the details on several areas. The next post will drill on the Office Environment Assessment tools and the Application Compatibility Program we announced last week.

Michael.

SharePoint conference is just a few days away. We are thrilled that in an era of shrinking shows and budgets, we're able to have a sold out conference dedicated to learning about Office and SharePoint 2010. It will be an exciting week.

A positive trend in Office development is the migration of solutions away from in-application scripted processing toward more data-centric development. Of course this is a primary purpose of Open XML, and it is great to see the amount of activity in this area. We've seen customers scripting Word in a server environment to batch process / print documents or for other automation tasks. In reality Word isn't built to do that on a large scale, it is better to work directly against the document rather than via the application whenever possible.

The Open XML SDK unlocks a "whole nuther" environment for document processing, and gets you out of the business of scripting client apps on servers to do the work of a true server application (not to mention the licensing problems created by installing Office on a server). We'll have the Open XML SDK in many sessions at the show.

I am also very excited about the Application Compatibility Program for Office 2010, and in the next post on this blog, we'll go into deep detail about what we're planning for the 2010 release. App compat is a very important area for our customers, ensuring solutions can be easily migrated between versions of Office will help those IT's & Devs charged with migrating masses of desktops to a new version. – this should be easier than ever with 2010 if we've done our job correctly. (Hint: If you'd like a sneak peek at one of the new app compat tools we're planning, hop onto connect and give this a test drive.)

You'll see these stickers about. Intergen is sponsoring a promotion for OpenXMLDeveloper.org at the show. Be sure to get your sticker from them as you see them around.

In terms of Open XML session content, there's plenty to enjoy. I'm adding a sample of the sessions from the show. Some sessions have an explicit focus on Open XML, but Open XML is present in most of them for various reasons.

There is so much for us to share at SPC. If you are planning to attend, please stop by our booth(s) and say hello. For those not attending, we'll do our best to share that information on my blog and across MSDN, Channel 9 and more.

There's no doubt that Microsoft offers perhaps the best benefits package in this industry, particularly for those people with families. One of those benefits related to child birth is an extended paternity leave which goes well above and beyond what is minimally required within FMLA. After the birth of our second child, I was fortunate to have the opportunity to take 4 weeks away from work to be with my family. After a lengthy, grueling stretch of launch planning, Open XML activity, developer readiness, trade shows, etc., the break was well timed. It didn't take me long to stop checking my email, but I did think about how much I appreciated the benefit every day.

The family time for me was a great reminder of why I expend the time and effort I do at work, but also great for sharpening focus on what is most important in life. I return renewed, energized and grateful to my employer.

So now we buckle down and get to the business of educating developers on the improvements in Office 2010. Many of you have seen the teaser trailer, some of the basic introductory content for Office 2010, and are probably paying close attention to the Office Web Applications. Some of you are testing pre-release products.

I wanted to take a minute to tip you off on areas that may be of interest if you are a Developer looking at Office 2010 for what's new.

A primary learning opportunity is the SharePoint Conference, coming up in October in Las Vegas. Despite the name, the new capability for developers in Office 2010 will be prominently on display, and many of us will be there to share details about those investments with you. I would recommend if you are attending to seek out John Durant, who is not only well-versed in the past present and future of Office development, but also (not coincidentally) responsible for much of what you'll see at the show. He's been working very hard to put together the complete picture for the client side. His most recent post, "Why VBA Still Makes Sense" ... makes a lot of sense. I'm looking forward to seeing a lot more of John's posts on Office development.

Another area worth investigating at the SharePoint conference are the sessions on the Open XML SDK, Server-side document processing and conversion, and generally the concept of using documents as a data source. A long-standing tenet of the transition to XML-based document format for the core authoring applications has been the ability to mine & re-use the content contained within them, or perhaps to generate and process those documents outside the context of an authoring application. We'll have a lot to say about this topic area at the show.

As many of you have also seen, Office 2010 will offer a native 64-bit client version. This has implications for developers. Part of our mission at SPC is to discuss how the 64-bit transition will take place, and to discuss the tools & techniques available to you for making the transition.

For Access developers (and emerging developers using Access), we'll have plenty to share as well. In fact, there is quite a bit of detail for developers of virtually every office Application. The InfoPath team will be there in force, we'll have plenty to share about the future of InfoPath as well.

•    Publishing Access solutions to SharePoint
•    How to program the Office Backstage view
•    How to leverage the Ribbon UI in custom solutions
•    Access as RAD tracking application tool
•    Overview of all developer investments in Office 2010
•    Visual Studio 2010 Office development tools improvements
•    Open XML-based solution building
•    Excel Services and REST APIs

If you are an Office developer, and you have $ to attend only one show, I recommend you find your way to Vegas and visit us in the booth.

So today we pull back the curtain on Office 2010. Product managers know that launch is the most exciting (and exhausting) time. Late nights building demos on "not release candidate" builds, refining the storytelling, making sure we're not missing any key new features, and so on. The last mile of product communication is quite difficult, requires a lot of dotting and crossing. Having watched this version of Office evolve from concept to reality has been quite a journey, filled with fascinating discussions large and small. (Remind me to blog in the future about arguments on what an acceptable download size is, and why fonts matter so much.)

This is my second launch for Office, and the 14^th (or so, I've lost count after 10 years) product launch I've been involved with in my career. What is unique about the build-up to 2010 for me is the anticipation of something so new and innovative, and the expectation for Microsoft to deliver something great in this release. Now that I've been using Office 2010 for a while, I am confident that the early Tech Preview testers of the product will find a lot in there, as will the folks testing the broader public beta down the road.

I wanted to take a minute to point you to some of the great resources you can use to learn more about Office 2010.

• Videos and discussion on Office 2010: http://www.microsoft.com/office2010
• The Awesome movie trailers: http://www.office2010themovie.com
• SharePoint 2010 Preview site: http://sharepoint.microsoft.com/2010/sneak_peek/Pages/default.aspx
• John Durant is a long-time Office coder and Office expert: http://blogs.msdn.com/johnrdurant/
• Paul Andrew is a SharePoint guru and is leading the charge for SharePoint developers: http://blogs.msdn.com/pandrew/
• Steve Fox is an Office developer evangelist without peer: http://blogs.msdn.com/steve_fox/

I'll have a lot more to share on this blog as we move forward with 2010. Some of the topics that you will find here:

• Open XML and the Open XML SDK
• Application and Macro compatibility with Office 14
• Visual Basic for Applications (VBA)
• Connecting with Office developers in the wild
• And much more.

Office 2010 is a groundbreaking release, and with it folks will be reminded why Microsoft Office has been the leading innovator in business productivity software for 20 years.

Sorry for the absence, I took a short break from work and blogging after the birth of our second child. Being a parent is a great blessing. It's just the signing up for 12 more months of 3-hour increments of sleep that I'm not so sure about J.

But it's back to work for me now, and it is a pleasure to return to some great news related to the adoption of Open XML. The Compatibility Pack, software that allows you to open, edit and save Open XML format documents in Office XP and 2003 has now been downloaded over 100 million times. This is quite a strong indicator of the global adoption of the Open XML formats. This is incredibly positive news.

Why?

As I discussed when we were at the 20 million mark, the compatibility pack is a manual download. It is not pushed through any update channels*. In order for an end user to obtain it, they must visit the Microsoft download center, select one of the 35 available languages, and download the 26MB installer. To say it differently, more than 100 million people have had cause to seek out and download the compatibility pack for Open XML; likely due to their encountering a document stored in one of the formats.

This number also does not include IT departments who have pushed the compatibility pack to users through tools such as WSUS or other software management services. Typically that would have a download count of 1, and a distribution count of thousands. I have worked on several of those projects with various customers. The number also excludes our OEM partners who have elected to distribute the compatibility pack. Two months ago I purchased an HP Laptop which came with the compatibility pack pre-installed.

Also worth noting is the conservative nature of this measurement. The statistic measures known, completed downloads, but we're also aware that in many cases, the download completes successfully even if we don't receive the feedback that it has. It is very likely the case that the number of actual end user downloads greatly exceeds 100 million. We're also not counting the # of downloads of the free viewers for Word, Excel and PowerPoint 2007 either.

Combined with the outstanding traction of Office 2007 to date, we are now at a point where a substantial percentage of business productivity desktops are reading and writing Open XML documents.

This is also a good time to refresh this data. As of today, the gap between the number of indexed documents for Open XML and ODF is increasing. According to Google file type searches:

As I also said in my prior post on format adoption, however, relative to the 81 million binary Office documents indexed on Google, we have a long way to go. It's great to see that we're off to a great start on Open XML though.

*You can see from Microsoft Update that patches or updates to the compatibility pack are offered as automatic updates. The compatibility pack itself, however, is not available through any automatic update channels.

Doug Mahugh posted today on Interoperability – specifically the difficulty of enabling cross-application exchange of document formats. This represents one (important) aspect of the overall interoperability challenge, but I would like to set some context for this conversation in my blog. There is laser-sharp focus on XML-based document exchange fidelity & quality between Microsoft Office, OpenOffice.org, and other business productivity suites. The broader category of data interchange however, is often left unaddressed. I'd like to open that window for a moment.

Countless solution providers for Office exist, a community built over time by providing and incredible breadth of capability enabling the development of powerful solutions. One of the core requirements for Office development is data connectivity and data portability. I'd like to take a moment to point folks at 3 resources on MSDN that illustrate various aspects of data portability for Office – hopefully to add a little context to our investments around interoperability, which is broad and deep in our products.

1. http://msdn.microsoft.com/en-us/library/bb545041(office.11).aspx Frank Rice discusses how to create data connections in Excel 2007, at least at the most basic level. From here you can connect through OLE, OLAP, Web Services,

• Simba connects Oracle to Excel 2007 using OLAP and MDX Query language.
• Straightthrough integrates Excel 2007 to Salesforce.com.
• So does the Salesforce Excel connector, connecting Excel to Salesforce.com.
  

2. http://msdn.microsoft.com/en-us/library/cc197932.aspx Stephen Oliver discusses how to use content controls, data bindings, the Open XML SDK and custom-defined schema to introduce variable length repeating data items into Word templates.

• LeaderGuide Pro helps you create advanced templates through the use of building blocks.
• AptarMerge is does (among other things) document assembly-type work for Word, and also integrates to SalesForce.com
• IBM Rational RequisitePro uses the familiar environment of Word for software requirements definition, and integrates that to a requirements database
• DocToHelp integrates Word 2007 (and Open XML) into its enterprise scale help systems
  

3. http://msdn.microsoft.com/en-us/library/bb332455.aspx Ken Getz discusses how to replace PowerPoint slide images

• Perspector Provides 3D graphics support for PowerPoint
• Impatica Provides plug-in free streaming for videos into PowerPoint
• Knowledge tree provides in-application integration for Word, Excel and PowerPoint to browse Knowledge Tree content within the applications
• Wondershare offers a number of products for converting PowerPoint documents to various formats.

This extremely narrow slice of life within the Office partner community illustrates a very important concept – interoperability with Microsoft Office is a well-worn path, supported by thousands of software providers, developers, experts, and so on. http://msdn.microsoft.com/office provides a tremendous resource for those developers and partners.

We will continue to do our best to support not only the document interoperability scenarios that Doug outlines in his post, but also those that are important to Microsoft partners and solution providers, whose businesses depend on us, and to whom we are grateful for their lasting and continuing support.

Want to get an in-depth look at Office 2010 for Developers? Want to see what 64-bit Office looks like? 

As you may have seen at PDC, TechEd or elsewhere, Office 2010 is on its way. To help you get ready, Office 2010 for Developers will be highlighted at the upcoming SharePoint Conference (October 2009, Las Vegas, NV) and TechEd conferences around the world in 2009 and 2010. 

NET: Office Developer Conference will not take place this year; instead we are including the Office Developer Conference content within the SharePoint Conference.  If you are an attendee of Office Developer Conference in the past, we strongly recommend you come see us at the SharePoint Conference in October, where we’ll cover Office client development in depth. Be sure to sign up for the Technical Preview as well!

We are optimizing our show presence for developers seeking opportunities to build on the Office platform, which includes Office client applications, SharePoint, Exchange and Communicator. By adding the ODC track to the 2009 SharePoint conference, we can provide better exposure to those seeking to develop solutions across the platform.

For more information on the SharePoint Conference contact spc@microsoft.com, and for the PASS Summit Unite conference, please contact marcella.mckeown@sqlpass.org.

I am re-posting from the Office 2010 blog as a public service to ensure folks don't cause themselves any problems. We are on track to deliver the technical preview of Office 2010 in July and will share additional details at that point. Microsoft has not yet distributed any official code for Office 2010 and will not do so until that technical preview.   We strongly recommend that customers only download or use officially released Microsoft products, through appropriate Microsoft channels, since unofficial copies might contain malicious code.

For more about Office 2010 and the upcoming Technical preview, please visit Reed's blog: http://blogs.technet.com/office2010/default.aspx

Leaked build and Staying Safe

I wanted to post quickly to acknowledge the information that you have seen today around bits of Office 2010 being leaked. While all of us here are happy to see the incredible excitement and engagement (and are absolutely chomping at the bit to reach the July milestone) we aren't quite ready to release the technical preview bits. I would encourage all of you to wait until the official bits are available to ensure the best possible experience and not miss out on anything we may include.

As a heads up, because we want to ensure our customers are safe, we have been monitoring various torrents and already detected quite a few that were infected. As a reminder, the Win 7 leak was used as a vector for attack and it's not surprising to see this being used the same way. So, please be aware that if you download this torrent there is a very good chance you are also getting some unexpected malware with it.

In the meantime keep checking back as we will certainly have more updates.

Reed
Published Tuesday, May 19, 2009 12:43 AM by reedshaff
Filed under: Leak, Security

You should read these posts if you care to understand the technical facts of the matter:

-          http://blogs.msdn.com/dmahugh/archive/2009/05/09/1-2-1.aspx

-          http://blogs.msdn.com/dmahugh/archive/2009/05/05/odf-spreadsheet-interoperability.aspx

I’d like folks to see some of the commentary on the web by people who have been close to the discussion. While I may be on the end of a continuum with respect to my opinions of the conduct of the ODF TC chair (please notice I am speaking of the conduct and not the person), I am certainly not alone. There is A LOT of smoke here, some of it from ODF TC members past and days gone by.

ODF Editor, Patrick Durusau: “Every keystroke for a negative message about some other standard, corporation or process is a keystroke taken away from promotion of OpenDocument. If enough such keystrokes fall, so will OpenDocument. It's your choice.”

Rick Jelliffe: “A committee chairman has to be a mediator. That is their most basic function, along with organizer and promoter. A contentious and proudly partisan person is simply not suitable as a mediator, nor can someone who is paid to be a provocateur simply pretend they can be an effective mediator.

Also, standards committees usually feel it incumbent on themselves to have commercially neutral chairs. This is why academics and government people usually are appointed to these positions. The more that someone is involved commercially in the fray, the less appropriate and congenial it is for them to exercise authority in committees.”

Guy Creese: “I recommend that you read both blog posts, in that they highlight the complexities of coding to an ever-evolving open standard. However, look at the blog posts as an educational exercise--try to understand the arcane details, but don't get taken in by them. While the vendors would like you to believe that, "We're right--and they're wrong," the takeaway is the larger picture of, "ODF interoperability isn't here yet."”

Alex Brown: “So I believe Rob’s statement that “SP2's implementation of ODF spreadsheets does not, in fact, conform to the requirements of the ODF standard” is mistaken on this point. This might be his personal interpretation of the standard, but it is based on an ingenious reading (argued around the meaning of comma placement, and privileging certain statements over other), and should certainly give no grounds for complacency about the sufficiency of the ODF specification.”

Michael Hickins: “Microsoft’s acceptance of ODF would thus seem to be a victory for IBM, which makes Weir’s petulance puzzling. Government customers in particular have sought alternatives to Microsoft so as not to be in the position of subsidizing a private company (i.e., Microsoft) with public monies, and IBM has long coveted this market as an opening for its own suite of applications. IBM has also been trying to wean customers off Microsoft Office in the hopes of winning them over to its Workplace collaboration tool as an alternative to Microsoft’s SharePoint. But according to Sam Hiser, former executive director of the now-defunct Open Document Foundation, Microsoft has successfully called IBM’s bluff and forced Big Blue to show its losing hand.”

Marbux: “I am a former member of the OASIS ODF Technical Committee. I left two years ago because of that big vendor-dominated TC's obdurate refusal to get started on make the ODF Interoperability Myth that the big vendors spread come true.”

Gary Edwards: “So what we have in Rob Weir is this image of a goon who skates out onto the ice whenever IBM's opposition scores a goal. And anyone who interferes in any way with their business plans is the opposition. His job is to take them out by whatever means necessary. The thing is, the guy is wearing pink tights and spouting methinks and wherefore art thous. Before you know it, the bastard sneaks up on you and is clubbing you to death with lies.”

James Clark: “I really hope I'm missing something, because, frankly, I'm speechless.  You cannot be serious. You have virtually zero interoperability for spreadsheet documents. OpenDocument has the potential to be extraodinarily valuable and important standard. I urge you not to throw away a huge part of that potential by leaving such a gaping hole in your specification.”

Tim Bray: “I learned, to my dismay, that the ODF specification is silent on spreadsheet formulas, they’re just strings. This is obviously a problem; much discussion on what to do ensued. I lean to the idea, much bally-hooed by Novell, of simply figuring out what Excel does, writing that down, and building it into ODF v.Next. Mind you, anyone who’s really been to the mat with Excel, in terms of Math & Macros, knows that it isn’t a pretty picture, there are real coherency problems. But it’s good enough and the world has learned how to make it work.”

And finally I’ll speak my piece on the matter. With a nod to Oliver Bell, Doug Mahugh, and many other comments on my post, I have no issue with the ODF TC, or even with the contribution that Rob may have made to the standard. My comment and complaint is very simple, and my point of view is one that the editor of ODF apparently shares:

Patrick Durusau: “Some members of the press have confused OpenDocument supporters with people who write for NOOXML blogs and websites, or that bash OpenXML, Microsoft, ISO, JTC 1, SC 34, etc. Those are not activities that support OpenDocument.”

So that you don’t miss it, the links in the quote are pointing to Rob Weir blog posts criticizing each of these entities. Rob’s response to the dust-up over SP2? (Which was apparently directed at nobody in particular)

Rob Weir: “I've been trying to respond to the many comments by anonymous FUDsters and Fanboys on various web sites where my post is being discussed. However, it is getting rather laborious swatting all the gnats. They obviously breed in stagnant waters, and there is an awful lot of that on the web.”

I rest my case.

I’m also (not surprised) disappointed at the tendency to opt for the sensational.

I found this headline pretty interesting. Just a note to Roy… had I ( “I” ≠ “Microsoft”) asked for “IBM” to leave the ODF TC, I would have addressed all 14 IBM employees currently listed as ODF TC members. I didn’t do that. In my post, I did not identify IBM until I replied to Rob in a comment, and at no point did I speak of the role of the IBM Corporation in my post. I addressed only one person who works for IBM, and this is because he is in the role committee co-Chair, and he has a history of criticizing Microsoft, ISO, JTC-1, Open XML, SC 34, Gary Edwards, Rick Jelliffe or virtually anyone else who dares to disagree. And FWIW, that photo used in the graphic isn’t me.

 One last note on assigning my perspectives to Microsoft. Visit this post to see another Microsoft employee who sees things a little differently than I do. http://osrin.net/2009/05/back-and-forth-back-and-forth-odf-11-ods-and-interoperability/. My opinions are my opinions, just like so many other folks involved in this discussion.  

As for my new “Friendo,” well, I don’t think I have a lot to say about the post. This one gives off more heat than light, it really doesn’t offer much. But there are some assertions being made that are worth correcting/addressing:

First (unfortunate that we have to keep covering this ground), war metaphors really are not appropriate for this conversation. We’re not discussing human rights violations; we’re discussing matters of software and industry. Let’s keep this in the proper perspective.

How does this stack up against TC-45? – well, if you can find a member of TC-45 conducting a blog whose apparent purpose is to criticize Open XML implementers, we’ll talk. I’m pretty sure none of those exist.

Regarding “Supporters,” someone has already covered that ground.

On this…

“I would be really, really pleased to see a top-notch quality support of ODF inside Microsoft Office. Why? Because this would be fair and unbiased competition based on one true Open Standard. It would a give a real level-playing field, where products could compete on sole merit and not on twisted situations of users’ lock-in. So trust me Gray: the world has everything to win from our competition.”

we are in [at least partial] agreement. I am very happy that we have added the Save as ODF and PDF functionality to SP2. I am glad that we are able to offer the choice of formats to users. Unfortunately Rob’s tactic here is to isolate SP2 based on one feature of one application for reasons that are being rejected in other forums. And as far as “one” standard goes, this is the part I don't agree with. Paving the entire world with a single document format doesn’t seem wise to me, and I’d rather be in the position of supporting the standards that people choose to use, rather than forcing people to use the one my product supports.

“I understand Gray. Gray is the Product Manager of Microsoft Office at Microsoft. Which means he is ultimately to blame for the lousy job Microsoft engineers have done in implementing ODF inside Microsoft Office. Gray is in the front line, and you can bet he’s having to answer some tough calls from customers right now. Gray does not have to ride the smooth « try Seven after Vista » wave; he has to go through the clutter that Microsoft’s big heads have created by thinking: What if we had ODF wrecked inside Office and get the world to believe that it’s not our fault? That’s Gray’s problem. And this is how we come to the waterboarding of Rob. But I digress.”

While the title “Product Manager” at many software companies includes responsibilities of spec writing, bug reviews, design meetings, etc., at Microsoft (at least in the Office group) it does not. I have held that type of role at other companies, but here, my focus is on enabling Developers to get more out of our software. I did not write the specs, I did not attend any design meetings, etc. The assertions made in the post are inaccurate.

I am involved because I have been working on various aspects of Open XML and document format standards in Office for almost 5 years now, and when added to prior experience in dealing with products’ implementations of document format standards, I’ve been at this for about 8 years or so. I know the neighborhood pretty well.

My ongoing disappointment with this discussion is the inability for people to apply the same principles for which Open XML was so heartily criticized (application dependence, under-specified or missing features, etc.,) to ODF implementers. I am hopeful that the chair of the ODF TC can focus his energy on solving those challenges, rather than trying to isolate Microsoft through subjective criteria. If he can’t, then he should just step aside.

As I have stated on my blog earlier, I WANT a good ODF implementation in Office to improve the satisfaction level of those interested in interoperability. I am very much rooting for a positive outcome to this discussion. We have a commitment to doing a high quality job just as we do with other aspects of our products.  We will certainly focus on the demands of our customers for quality and interoperability and will continue to engage with other vendors in the years to come to (a) improve the spec and (b) improve the Interop between implementations of the spec. 

To date, I have not fielded a call or request from a developer seeking to build a solution in Office with ODF. By contrast I see many requests of developers who wish to build Office solutions that include PDF. (Open XML is quite healthy as well, but I’ll leave that part out for a bit so as to not compare the two formats.) I assign no positive or negative value in the level ODF adoption that I see when dealing with developers; if they use it, our product can write the format; if ODF is a means to improving their solution, then I will gladly provide my best effort toward ensuring that Office-based solution is top quality. Either way I am hopeful that our product can be successful in supporting whatever use people seek to achieve with it.

I can't help but observe the "discussion" underway with respect to spreadsheet interoperability that Rob Weir has started. Essentially Rob is complaining that Microsoft didn't implement the formula namespace of OpenOffice.

For the chair of the committee to post vitriol like this about the implementation of his own format raises a number of very concerning problems.

I'd like everyone reading the post to know that Rob was invited to participate in the DII events leading up to the SP2 release, and offered the opportunity to test the beta software specifically for the purpose of providing feedback on the implementation. Normally the chair of group of the standard being implemented would jump at the chance. Rob didn't, electing instead to wait for the shipping version and then claim that it is somehow deficient to other ODF implementations that he has deemed suitable for his purposes.

Does it make sense to have a chair for the ODF TC whose apparent mission is to create a caste system for ODF implementers? Do we really think Rob, who debates whether the tough (and publicly vetted) implementation decisions of his constituents are "malice" or "incompetence?" – is this the hallmark of a leader in the standards community striving for innovation using open technologies? Is this the characteristic that OASIS wants to promote in the development of technology standards? In Rob, do we really have a person capable of operating in a vendor-neutral forum? If departments within 18 various governments really do use ODF as their standard, should we be comfortable with an ODF TC chair that is trying very hard to discredit and divide its supporters?

Is it time for Rob to step down as chair? I think so.

I'm not saying Microsoft (or anyone) should be the chair instead, but I am saying that Rob is unfit as a leader given his inability to separate his personal venom from his role as a leader in driving the standard forward. It seems like a better approach to empower people on the ODF TC who have a long-term view of the need to enable interoperability, and to move those with more short-term vendor-oriented agendas to the side.

John Head is on point with this post. eWeek seems to be fine with SP2.

As far as I can see, the only thing that Rob is really demonstrating here is that the "grossly inadequate" formula support of ODF (those are the words of David Wheeler, leader of OpenFormula, read on for details) is causing problems with vendors implementing the standard. He instead resorts to scoring implementations based on a percentage of common ground, rather than conformance to something written on paper. This gives Rob the freedom he needs to define his own criteria for what ODF implementation is, and who is doing it according to his rules.

Rob seems to be positioning himself as the final arbiter on what is "good" ODF vs. "bad" ODF. OASIS? specification? – Unimportant when Rob Weir can arbitrarily define criteria for what he thinks is good. He's in a position where only he will declare his own ODF preferences as the blessed implementation. It seems that neither the ODF TC nor the spec matter anymore. It seems that ODF is being run by an individual.

Current ODF standards do not support formulas no matter how much Rob wishes it to be so. Implementations of ODF spreadsheets are application-dependent. ODF 1.2 is not an approved standard. OpenFormula is not an approved standard. While it may be that both are on a path to standardization in the future, today they are not. This is a situation that has been known to the ODF TC for more than 4 years, yet no solution based on an approved standard (other than Open XML) has been found. These are all indisputable facts.

In his post, Rob proposes using "legacy OO namespaces" (also declaring OpenOffice as the "current convention"). Rob's suggestion to use "legacy OO namespaces" is a reference to a vendor's product and indicates favoritism to a particular implementation. The defender of "precise, repeatable, common" seems to be abandoning that hill, hoping instead to claim for his own the dialog that Microsoft has been conducting for a long time: Interoperability requires the participation of many, and will not be defined by a standard alone. Doug covers that pretty well I think.

The irony isn't lost at all. This is the same guy who went to such a length to chastise Open XML for its undefined list styles and compatibility settings. For some reason his expectations of Open XML seem to be somewhat higher than they are for the committee he chairs. For some reason, it is ok for Rob to patch glaring holes in ODF as "current convention" and then complain vigorously about alleged dependence on Microsoft Office for implementing Open XML. This is shameful, hypocritical and warrants corrective action.

It wouldn't be such a huge deal if the tone were constructive or aimed at improving the situation. It seems he is only interested in distancing himself from scenarios where ODF can be used successfully with Microsoft Office (as well as the DII discussions where that implementation was discussed in detail during its development. Funny that he didn't show up there to share this feedback.)

Rob's conclusion on the cause of that problem:

"I was taught to never assume malice where incompetence would be the simpler explanation. But the degree of incompetence needed to explain SP2's poor ODF support boggles the mind and leads me to further uncharitable thoughts. So I must stop here"

Let's just remember that it was the ODF TC which deemed formulas "out of scope," and after 4 years, still have no solution for standardizing the definition of "Sum = 2+2." Rob says "Everyone knows what =A1+A2 means."  Really Rob?  What does it mean if A1 contains 1, and A2 contains "two"?   Would it surprise you to learn that Excel and OpenOffice produce different answers in that case?  Which one is correct? This question and a thousand more like it is why formula interoperability is hard work, and not at all the trivial matter Rob claims it is.

During the original discussion within the ODF TC, not everyone agreed with the omission of formulas from the spec… David Wheeler seemed to be pretty clear when commented on this on February 7^th, 2005:

This previous comment scares me: "There are from our point of view also no interoperability issues, because the namespace prefix mechanism we have specified unambiguously specifies what syntax and semantics are used for a formula". Here's how I read that: "Every implementation must reverse engineer all other implementations' namespaces (they're not in the spec, so everyone's free to invent their own private incompatible namespaces). Then, every implementation must implement all the syntax and semantics of all other implementations' namespaces for formulas, if they wish to achive interoperability. And oh, by the way, your implementation might not implement the namespace for the document you're trying to load, so you may lose all the formulas."

I'm sure that's not what was meant, but that's how it reads to me. I hope that helps explain why I think that the current formula information in the OpenOffice specification is grossly inadequate."

So… maybe it's too easy, but "I was taught to never assume malice where incompetence would be the simpler explanation." David Wheeler saw this coming over 4 years ago, and yet, OpenFormula is not a standard today, and ODF has no definition for spreadsheet formulas. Rob tries to excuse his way around this in his post, but these comments are made by the committee that he chairs. I'll leave it to you, then, to decide between "malice" or "incompetence" of the poster who would elect to throw his own committee under the bus to get hits on his blog… or fail to take this very good advice.

By the way, it is worth noting the response to this stern (and very accurate) prediction.

"Hi David,

Thanks for the concerned comments and all the considerable effort you have put into solving this problem.  You're challenging us all to go where none have dared tread before.  So go ahead and lead the way.  You have the TC's attention.  We are listening.  As you grind out the grit of your proposal, please keep in mind that we have to fit proposed solutions into the politic of work that has already been done.  A politic that represents years of work that is just now on it's way to ratification at OASIS, and beyond to ISO.  Keep in mind also that the ISO certification comes at the request of the European Union. Time is of the essence.  Ratification perhaps trumps perfection.  At least for the moment."

This comment was from Gary Edwards, (he of "cracks in the foundation" / OpenDocument Foundation fame) who eventually left the TC and shuttered the OpenDocument Foundation. I seem to remember some dialog from Rob about Open XML being "rushed" through standardization. Funny how those things come back to haunt you.

I'm very discouraged by Rob's post. As far as I can tell, rob is playing a shell game where only his definition will be good enough for supporting ODF, and that definition will change to whatever Microsoft isn't doing.

This is far from constructive. This is not a way to foster interoperability and industry dialog. This is not a leader for people to follow.

I wanted to discuss a specific coverage area for Office 2007 SP2.

I was recently directed toward the Acrobat Team blog, which is pointing out some of the differences between Adobe Acrobat 9 and Office 2007 SP2. As explained in the post, Adobe has worked hard to add value to the Office platform with the Acrobat product family. They are a valued Office partner and solution provider. And it sems that Adobe has invested heavily in Acrobat well beyond the creation of PDF documents… and for good reason. A search for Free PDF Creation on the web gives you 21,000,000 hits. While I am certain there are not 21 Million providers of no-cost PDF creation tools, a wide proliferation of PDF creation technology exists for no cost or a very low cost.

We added support for PDF because it is the most commonly exchanged document format on the web, and was the #2 requested feature of our customer base. In that sense, we are in good alignment with Adobe in this regard:

“For Reader, there will likely be more PDF files in the world for users to consume using the product. And for Acrobat, the more PDFs that are created the more users will be interested in doing additional things with those documents”

It’s seems that Adobe is trying to help folks understand why Acrobat provides value to the work environment, and I have no argument with that as a long-time Acrobat user who enjoys the product. The area I’m struggling with is the portion that draws a contrast to our PDF support vs. what you get with Acrobat 9.

A quote from the post:

“Regarding PDF in particular, Microsoft has mentioned SP2 will support the creation of PDF 1.5 files from some Office applications. The specification for PDF 1.5 was first published by Adobe in 2003 and was supported that same year in Acrobat 6. Acrobat 9, the current release of the product line, supports PDF 1.7 files, which was the version ratified as ISO 32000. Jim King has an informative blog that, in part, talks about the ISO standardization process of PDF.”

This is strange because I don’t see us as being dramatically different than Acrobat in this area. Let’s just state for the record what SP2 actually supports:

-          All of the PDF that we write is intended to be compliant with ISO 32000, even if marked with the 1.5 version header.

-          Optionally, users can create PDF documents that are also intended to be compliant with the ISO 19005 (PDF/A) subset of ISO 32000.

The reason I took the time to write this post is to point out an apparent contrast between what Adobe seems to be implying in the statement above vs. what is supported out of the box in their Acrobat products. A quick scan of the Acrobat 9 Distiller settings files (the primary vehicle for creating PDF documents with Acrobat) reveals something that doesn’t jive with the blog post. Acrobat 9 “Standard” Job Options (the default for creating PDF documents) default to the same version of PDF that our add-in does, PDF 1.5. The screen shot below makes that pretty clear. In essence, the same data point Adobe is raising at SP2 is equally valid for Acrobat 9. Very much a “Pot/Kettle” type situation (call PDF versioning a problem if you find it to be one.)

I’m not sure why Adobe would call that out for us when the behavior is a perfect mirror to their product.

Our reasons for choosing the Adobe PDF 1.5 spec / Acrobat 6 as the default was to optimize for maximum compatibility with existing products on folks’ desktops. I’ll refrain from speculating about Adobe’s reasons for defaulting to PDF 1.5, but we should be clear that the default PDF version is the same between SP2 and Acrobat 9.

We could also conduct the discussion in a different way. Adobe has posted a document that is a copy of the IS32000 standard where the “technical content is identical including the section numbering and page numbering.” The Conformance Clause of that specification, section 2.6:

“6 Version Designations

For the convenience of the reader, the PDF versions in which various features were introduced are provided informatively within this document. The first version of PDF was designated PDF 1.0 and was specified by Adobe Systems Incorporated in the PDF Reference 1.0 document published by Adobe and Addison Wesley. Since then, PDF has gone through seven revisions designated as: PDF 1.1, PDF 1.2, PDF 1.3, PDF 1.4, PDF 1.5, PDF 1.6 and PDF 1.7. All non-deprecated features defined in a previous PDF version were also included in the subsequent PDF version. Since ISO 32000-1 is a PDF version matching PDF 1.7, it is also suitable for interpretation of files made to conform with any of the PDF specifications 1.0 through 1.7. Throughout this specification in order to indicate at which point in the sequence of versions a feature was introduced, a notation with a PDF version number in parenthesis (e.g., (PDF 1.3)) is used. Thus if a feature is labelled with (PDF 1.3)it means that PDF 1.0, PDF 1.1 and PDF 1.2 were not specified to support this feature whereas all versions of PDF 1.3 and greater were defined to support it.”

Read: PDF 1.5 files are inherently compliant with 1.7, and “since ISO32000-1 is a PDF version matching PDF 1.7”, one can conclude that PDF 1.5 documents are also IS32000 compliant. (I’m probably oversimplifying that, but this section of the text in the PDF 1.7 document on the Adobe site seems to be very clear on the point.)

I’m not claiming that SP2 supports any new PDF 1.6 of 1.7 functionality.  Per the definition outlined in the PDF 1.7 / copy of the ISO32000 spec, however, we’re aligned with Adobe on our ability to produce PDF 1.5 files by default, PDF/A compliant files as an option, and (at least in the simplest definition) conformant with the IS32000 and IS19005 specifications. As I can see there is little difference.

It is worth pointing out that we were relatively late to the game for business productivity suites supporting PDF export; PDF creation is supported everywhere from the Mac OS to OpenOffice. Since (per the quote above) the PDF specification has been published since version 1.0, and prior versions are inherently compliant to future versions, I’m not sure why the version distinction matters as much, or where we should be doing more with the format, or for that matter, how we are different from anyone else. I’m not sure what motivation Adobe has in implying that PDF producers must write the most recent PDF version header into the documents they create. The spec doesn't support that assertion.

I raise this not to pick on Adobe of course, I used to work on the team who publishes this blog, and I know the author of the post; I have a healthy respect for both. But I am hopeful that these issues are bringing the IS29500 discussion into the same light as we’re viewing some of the challenges emerging with the two other significant document format standards in play.

Read this first if you're looking for SP2 details: http://blogs.technet.com/gray_knowlton/archive/2009/04/27/office-2007-service-pack-2-kiosk.aspx

Office 2007 Service Pack 2 is getting quite a bit of attention, it is great to see. There has been world-wide traffic coming to my blog, and I’m sure that Doug’s, Tom Robertson’s, Sustaining Engineering, and other posts are getting lots of traffic as well. Offline today (and on Twitter) I’ve been dealing with a handful of common questions on SP2 that I thought I’d take a moment to answer.

Q: What if I was on the SP2 Beta? How do I uninstall that and add the release version of SP2?

A:  First, you don’t have to. The Service Pack 2 installer should pave over the existing beta version of the SP without trouble. I say should, because I’m not on the testing team and am careful about making statements about testing that could be regarded as absolute. IF you wanted to do it the hard way (and for cleanliness purposes, I chose to do it this way), you can use the new Service Pack Uninstall tool to clean your machine. Here is how that looks when doing it from a DOS prompt. The tool is pretty simple to use. All of the packages you should see in the tool (at least as of today) should be for SP2 if you have them installed. Executing the remove command will uninstall the packages. Be sure to close your Office apps before you do this, and reboot after you are done. This is a handy tool. I’m hopeful that IT Pros will see this as a useful addition for managing add-in / update compatibility on various configurations of Office desktops.

Q: I saw a comment that “Office 2007 SP2 allows you to Open, Edit, and Save ODF, PDF and XPS.” Is that true?

A: This one is an important one to clarify:

-          You can Open, Edit and Save documents using ODF 1.1 format.

-          You can Save documents as PDF and XPS. This Service Pack release does not enable the editing or opening of PDF or XPS documents.

Q: If I am an IT Administrator, can I block users from downloading or installing SP2 before I have a chance to test it?

A:  Yes, through Windows Server Update Services. (WSUS) is a free add-on for the Windows Server operating system to help network administrators manage updates for computers. By using WSUS with Active Directory® group policy, administrators can fully manage update settings and the distribution of updates for computers on their network. To find out more about using WSUS, go to the Windows Software Update Services (WSUS) Web site http://technet.microsoft.com/en-us/wsus/default.aspx.

Q: Microsoft is saying that Outlook is more than 25% faster with SP2. Do you have data to support that? Where can I read that?

A:  The Outlook team blog has a bit more detail than I shared in my post, and that data originates from a report from Principled Technologies. A highlight quote from the report: “we found Outlook 2007 SP2 was noticeably more responsive to user input and actions than the earlier version and took less time to perform the standard operations”

Q: Is this update only for Office client products? What about SharePoint? Is there an SP2 for SharePoint?

A: Yes, SharePoint and many other products have been updated. A SharePoint white paper describes in more depth what they have updated, and I have re-added the table pointing to the other Service Pack release details.

If there are other pressing FAQ's to handle, I'll update this post as we go forward.

UPDATE: The links for the downloads for SP2 are in the process of replicating across mirrors for our WW download center. The download links are expected to be live at around 11:00AM PDT.  

Update: The download links for SP2 are now live.

The Office development team has been pretty busy with the Service Pack 2 release (SP2). This is a monster Service Pack release for Office. The Sustaining Engineering blog for Office has quite a bit of the background, but I wanted to raise awareness on a few key aspects of the release, partially for the world-at-large, but more for the developer audience. Allow me to staple a handful of worthy links on my blog to get you started on the depth of data available about SP2.

Coming soon to a portal near you..

One of the things we spend time on in my group is education and awareness of various types of developer solutions available for Office. Today many people build solutions for Office. They range from complex line-of-business solutions where Office is the front end (we typically label those as "OBA" (Office Business Applications), all the way to automation tasks or recorded macros. We've launched a new home for those on Office Online, and we've created the OfficePalooza contest for the VBA warriors out there to strut their stuff.

Is this you? we'd love to see what you've got. Be sure to sign up to win the prizes!

I have attached a DAISY Talking book to this post for reading in http://www.buttercupreader.net/.

TextGlow, the prototype Open XML Viewer for Silverlight is one of the most popular posts in the brief history of my blog. Intergen, a Microsoft partner in New Zealand, have now elected to offer the source code for this application on OpenXMLDeveloper.org. I am very excited about this development, Silverlight is amazing, and the combination of Open XML and Siverlight easy for a nerd like me to get excited about.

If you haven't signed up for OpenXMLDeveloper.org, now is a good time to do so. You'll find this source code as well as other projects to help your development of Open XML solutions.

Here is an excerpt from the article:

Displaying Open XML documents in Silverlight with TextGlow
By James Newton-King

The Office Open XML file format has opened up a new range of possibilities to working with documents. The Microsoft Office 2007 suite of products replaces the old binary formats and produces documents in a parser friendly XML format by default instead.

TextGlow (www.textglow.net) is a Silverlight 2.0 application that leverages the new Office Open XML file format to display Word documents directly in the browser. This article will look at how to use the built-in features of Silverlight 2.0 to read content from an OpenXML package, parse XML using LINQ to XML and display the document contents using Silverlight.

In case you missed it yesterday, DAISY Consortium announced the release of the second version of the DAISY Translator for Word.

I've said it a few times on my blog, but I did want to say again how much we value our partnership with the DAISY Consortium, and our gratitude towards them for their help on this work. Microsoft Office is the leader in providing accessibility support in business productivity software; we are committed to continuous improvement of our support for users with disabilities.

From the press release: "Michael Hingson, the President of The Hingson Group, believes that the "DAISY navigation system is one of the most significant developments to be made available since the development of Braille. DAISY allows people who are blind to move around recorded and electronic documents easily and seamlessly in a way so far only available to sighted readers."

The big news with the 2.0 release is the addition of Full DAISY Text and Audio books. Instead of converting to a DAISY XML file, you can now effectively save your Word documents as MP3 files. DAISY XML files can be read natively by some DAISY players, and the DAISY Pipeline is still available for processing those XML files. For more technical readers, this means that Version 2.0 of the translator incorporates the "Lite" version of the DAISY Pipeline, and generates full text and audio books using the Text-to-Speech service on your PC.

But the change to the 2.0 release of the Translator for Word represents a monumental simplification of this process. This is a fantastic development.

Figure 1: Screen shot of the Word Save As DAISY 2.0 Dialog Box

As part of this activity, a new web-based player is available for DAISY Talking books. Buttercup has been developed through a partnership between DAISY, Microsoft and New Zealand's Intergen to allow people to listen to & navigate DTB's through a browser via a Silverlight control.

I have also attached a full-audio full-text book of this post. This book was created only by using the translator. You can download this ZIP file, and open it with the Buttercup player. No other software than Word 2007, Vista (the TTS engine) and the translator are required to create this talking book.

If you are interested in learning more about DAISY Talking book formats, a good description has been added to the DAISY.org forums.

I would like to thank the DAISY Consortium, George Kerscher, Intergen Software, Sonata Software, and the Adaptive Technology experts from the Royal New Zealand Foundation for their support on the project.

Just keeping tabs on the state of matters for document format standards. I thought I'd share some of those interesting data points and connect some dots along the way.

Ouch. Rich Jelliffe discusses some of the dynamics of the OASIS ODF TC.

Rick says: "It seems that OASIS rules actually ban Technical Committee members from participating on the comments list with non-committee members. Communication is a one-way affair, an offering to silent gods. …

It didn't used to be this way. And snooping around the archives, it seems that when the rules were changed (by the then OASIS board) in 2003, there was quite a stink. The justification was to prevent spam: I cannot quite understand the logic, but the effect is that it meant if you want to participate at OASIS you have to pay."

I don't pretend to understand the inner workings of standards organizations, but I definitely recall some very sharp criticism of Microsoft and ECMA for some very similar reasons. Does this mean the withdraw of IBM from OASIS is imminent? J It's also strange how, when faced with criticism, some individuals revert to Microsoft-bashing as a means to defending their own actions. So then let me revert to some old habits and point out an apparent contrast between the words written in a different forum:

"Those who control the exchange format, can control interoperability and turn it on or off like a water faucet to meet their business objectives." – this from the chair of the ODF TC.

Interesting: Alex Brown (a while ago, I know) drills on conformance issues for ODF 1.2 and exposes a fairly basic and problematic reality. Rick had a little to say about this as well.

This is an extension of the discussion that is exemplified by Oracle's comment on Open XML conformance during the BRM process, and those of Google as well. It seems that after all this time we're not settled on basic questions, for example whether or not all content within the ZIP package should be described using XML. Again I don't pretend to have an answer, but appreciate the level of attention that Open XML has brought to this problem.

The University of Illinois Law has published a paper on the (recent, but somewhat aged) state of interoperability for Open XML and ODF. It isn't a glowingly positive report for either standard, but it is based on older implementations, and by virtue of the fact that the numbers in the tables seem higher for Open XML than they do ODF, one could regard that as a "win" for Open XML. I think the bigger message is that for both Open XML and ODF, things are improving. In the long view, this report isn't surprising. In the 20+ year history of desktop business productivity applications, it is reasonable to expect a long ramp for interoperability for brand new document formats. I would like to raise my hand on this with a few questions:

Why isn't anyone talking about PDF? – seems like if one wanted to discuss document exchange, PDF would be an interesting basis for comparison. For example, how likely are various PDF Viewing applications to get it "right" when opening a PDF file? What is the degree of variance across the thousands of PDF generation implementations in the world? Odd that people seem to have vacated that space very quickly. The warm fire around which folks are huddled seems to be the one where people have a hope of editing.

Why isn't anyone talking about binary documents? – I hate to draw attention to a white elephant, but the use of binary document formats (at least by count of what is indexed on the web) is on the order of ~200,000 to 200,000,000. I would love to see an amendment to this study which illustrates the interoperability of binary documents in the same test.

And for all this, here's the point:

The rough edges of document format interoperability are apparent. One should question the fastest way to get to the goal of high quality inter application document exchange. It would seem that (reference above) that a wealth of IQ is being devoted to evolving standards to achieve the lofty goals that are floating around this topic; lots and lots of paint is being used for boxing things into tight corners.

For the folks who don't appreciate the handfighting and procedural aspects to the standards work, though, how can they get any benefit out of this? If it is the case that "the little guy" isn't welcome at the table in the standards discussion (which I don't believe is the case for Open XML or ODF), what is the fastest means to high-quality document exchange?

As far as I can see, only one vendor is doing this: http://www.documentinteropinitiative.org. I have not found this documentation from other developers: http://www.documentinteropinitiative.org/ECMA-376/reference.aspx, http://www.documentinteropinitiative.org/OASISODF1.1/reference.aspx. I am hopeful to see other vendors bringing this data to the table, beyond their participation in DII and on OpenXMLDeveloper.org. I hope to see this because it helps folks sort through the real problems vs. those that are less significant, and helps ensure that we're really talking about document format exchange, rather than hopeful RFP checkbox filling.

I am optimistic for the future and hopeful for more developer-to-developer engagement on real product implementations. I think it matters a great deal for this transition to standardized document formats.

http://blog.seattletimes.nwsource.com/techtracks/2009/02/23/microsoft_employees_gave_87.7_million_to_charity_la.html

"On average, U.S. Microsoft employees contributed on average about $1,523 each -- counting the company match. That's based on a U.S. work force of 57,588 as of Dec. 31."

A lot of people @Microsoft are very proud of this number, including me. I am one of these contributors. I am a believer in giving back to the community. For a lot of personal reasons, I believe in providing the support to help people go further in their lives and to exceed their circumstances. Among the many great benefits of Working at Microsoft, this one is something that every person I work with is committed to. While Jeff Raikes was still leading our division, he was one in particular who stressed the importance and benefit of supporting various causes and activities.

The recognition is nice, and thanks to Seattle Times for the pick-up.