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 recall saying recently that "this is my last post for 2009." Whoops... I don't think I was anticipating this. I watched with interest yesterday the coverage and reaction to the i4i judgment. I am not keen to share my own thoughts about the case here, but I would like to offer clarity around the specific area of Word in question, and suggestions for what people can do about it if they are using that functionality today. There is much confusion about the part of Word that is actually affected.

First, some things to understand:

We do not anticipate any interruption in the availability of Word or Office 2007. Additionally this ruling has no impact on the scheduled availability of the 2010 Office version which is planned for the first half of CY2010.

Current users are not affected. If you are using the custom XML tags in Word 2003 or 2007 (these show up in Word as Pink Tags around tagged content), you are free to continue doing so with the products you have already purchased.

Open XML standards (all ECMA and ISO versions) are not affected. Even if Word's specific implementation of custom XML support does infringe the i4i patent (which Microsoft does not believe to be the case), i4i has never claimed that its patent is essential to the OXML standard.

Content Controls of Word (screen shot below) are not affected. In Word 2007 and Word 2010, this is a common method of binding document content to data stored in a custom-defined schema within a document.

The functionality that is in question is indicated by the screen shot below. Custom XML Tags in Word documents are visible in the Word user interface as Pink Tags surrounding tagged content in a document.

What you can do if you have questions about your solutions that use Custom XML Tags:

First, download the Office 2010 beta and test your solution. If your solution works in Office 2010, it does not depend on the functionality in question. If your solution does utilize Custom XML Tags, consider re-implementing the solution using Content Controls. Detailed guidance on the use of Content Controls in Word 2007 can be found here. Also note the Word Content Controls Toolkit on CodePlex. The Open XML SDK, of course, is quite useful for getting people up to speed on developing solutions for Word and Open XML.

Update: Additional Detail

In response to several inquiries on the topic, I have included additional text describing the feature area that is affected vs. what is not affected, including links to KB articles which illustrate the capabilities in more detail. 

Affected:

Word 2003 and Word 2007 distributed prior to 1/11/2010 can read files that contain XML markup (ref: “Understanding Word's XML Markup [Word 2003 XML Reference]”, http://msdn.microsoft.com/en-us/library/aa212889(office.11).aspx. When custom XML markup is present, Word delineates this content in a Word document which allows it to later save the file to .DOCX, .DOCM, or .XML with that content marked up.

The Word 2007 product distributed by Microsoft after 1/10/2010 will no longer read the Custom XML markup contained within .DOCX, .DOCM, or .XML files.  These files will continue to open, but the Custom XML markup tags will be removed. Custom XML markup stored within .DOC files will not be affected by these changes.  Word 2003 and existing installations of Word 2007 will not be affected by this change.

 Not Affected:

Word 2007 also added features allowing Content Controls to map to XML data stored in a DOCX or DOCM file (ref: “Mapping Word 2007 Content Controls to Custom XML Using the XML Mapping Object”, http://msdn.microsoft.com/en-us/library/bb510135.aspx). Content Controls and XML data stored within DOCX or DOCM files will not be affected by this change. 

A great way to wind down for the weekend. This is a wonderful site.

Happy Friday!

Michael.

Yes, Office 2007 is fully supported when used with Windows XP. This question is one I'd heard a few times in the past week; there is a lingering perception that Vista is required to use the 2007 versions of the products. Rest assured, this is not the case.

System requirements are posted here: http://office.microsoft.com/en-us/products/HA101668651033.aspx

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.

I could make a full time job of tearing down the "say anything we possibly can" approach to Open XML opposition. Seems like we're seeing a new level of arm-flailing and finger pointing, now that we are weeks away from the close of the post BRM period. I wanted to offer some comments about the SFLC's analysis of the OSP. This is an unfortunate report, these all represent issues that have been raised in a campaign that includes innuendo and supposition, leaving out inconvenient information and language and ignoring the same, similar, or less attractive, language that exists for ODF.

The big news in this is their admission/confirmation that the OSP is in fact compatible with the GPL.  They say "The OSP cannot be relied upon by GPL developers for their implementations not because its provisions conflict with the GPL but because it does not provide the freedom that the GPL requires." They go on to identify that "freedom" being linked to the OSP being unsafe is because new versions of the specifications could be excluded from the OSP in the future. 

It is unusual for promises like the OSP to automatically include every spec or all future versions (IBM's pledge is exactly like ours).  The norm is for new versions to be added to them to be covered.  In the case of Sun's statement new versions are automatically added only when they participate in the development of the new version to the extent that the OASIS IPR rules would then obligate them to provide patent rights under the OASIS IPR Policy.  None of these promises include future versions of the specifications without any qualification.

Let's deal with the points one by one:

Irrevocable only for now

This section points out that the OSP only applies to listed versions of covered specifications. True, except that we have already committed to extending it to ISO/IEC DIS 29500 when it is approved in our filing with ISO/IEC. For ODF, IBM in their ISP takes the identical approach. Strange how things that seem appropriate for ODF are not appropriate for Open XML.

OSP covers specifications not code

Not true. The OSP is a promise to not assert patents that are necessarily infringed by implementations of covered specifications. Like all similar patent non-asserts (including the Sun and IBM versions for ODF) the promise covers that part of a product that implements that specification (and not other parts that have nothing to do with the specification). While the Sun covenant is silent about conformance to the specification, the OSP allows implementers the freedom to implement any (or all) parts of a covered specification and to the extent they do implement those portions (also known as conform to those parts) they are covered by the promise for those parts. Contrast that to the IBM pledge that requires total conformance and so programming errors or absence of something required by the spec (but not by an implementer's product) means that the promise is totally void for that product.

No consistency with the GPL

Not true. As far as we are concerned we are happy to extend the OSP to implementers who distribute their code under any copyright license including the GPL. The FAQ cited just states what everyone knows and acknowledges, the GPL is a copyright license that is drafted in a way that leaves many issues (not just those related to patent rights) open to many interpretations. Any particular user or implementer should read the GPL carefully and make their own judgment about what it means and requires in accordance with their own circumstances. The FAQ states that Microsoft is not in a position to give blanket advice about the GPL to others. They missed these two FAQs for some reason...

"Q: Is the Open Specification Promise intended to apply to open source developers and users of open source developed software?

A: Yes. The OSP applies directly to all persons or entities that make, use, sell, offer for sale, imports and/or distributes an implementation of a Covered Specification. It is intended to enable open source implementations, and in fact several parties in the open source community have specifically stated that the OSP meets their needs. Moreover there are already a significant number of implementations of Covered Specifications that have been created and/or distributed under a variety of open source licenses as well as under proprietary software development models. Because open source software licenses can vary you may want to consult with your legal counsel to understand your particular legal environment.

Q: Is this Promise consistent with open source licensing, namely the GPL? And can anyone implement the specification(s) without any concerns about Microsoft patents?

A: The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement the covered specification(s). We leave it to those implementing these technologies to understand the legal environments in which they operate. This includes people operating in a GPL environment. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can't give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s)."

By popular demand, Eric White has returned to provide more guidance regarding the use of Content Controls. Eric's guest post today outlines more of how you can use Content Controls in your environment.

......

In a previous post on Gray's blog, I discussed an approach for building a content publishing system using styles and content controls. This is only one of the scenarios where content controls are useful. Another scenario is where you have a sophisticated document generation system where content controls are replaced with automatically generated text. The replacement instructions could be fairly elaborate - perhaps including the database server name, table name, filter, and column name, for example. In a different scenario, you may have a system that automates testing of code listings that are contained in documents, and you may have build instructions for each snippet in the document. I blogged about this approach in OpenXmlCodeTester: Validating Code in Open XML Documents.

Note: I co-wrote this post with Anil Kumar. Many thanks to Anil for writing the managed add-in code.

In all of the above scenarios, you may have the need to associate arbitrary amounts of data with each content control. You may also have the requirement that the document author can create and edit this auxiliary information. Content controls don't directly have a facility for storing and maintaining such information, but there is a fairly easy approach to solving this problem.

Note: In this post, I refer to 'custom XML parts'. Open XML documents are stored using the Open Packaging Conventions. They are essentially zip files (packages) that contain multiple XML and other types of files (parts) within them. These parts are related to each other by a very specific mechanism called relationships. A custom XML part is a part (a file in XML format) of your own design stored in the package. You can design your own XML vocabulary for this part. I've written an MSDN article, The Essentials of Open Packaging Conventions, which explains what you need to know to work with packages and parts. 'Custom XML parts' in this sense are not affected by January 2010 update  for Office Word that Gray has blogged about previously.   Custom XML parts will continue to be supported in Word.

The gist of the technique for associating data with content controls is as follows:

You create a custom XML part that contains some XML that looks something like this:

If you need to maintain more than one value for each content control, you can have as many child elements of the Content element as necessary.

Each content control contains a unique ID that is assigned by Word upon creation of the content control. The data in the custom XML part is related to the content control using this ID. Following is the markup for one of the content controls that is related to the above XML:

You can make it easy for users to edit this auxiliary information in a custom task pane. To create this functionality, you create an Office managed add-in. When the focus is in a content control, the task pane is updated with information from the custom XML part, and when the user updates the data, the managed add-in updates the custom XML part. The following screen shot shows the task pane that is created by the example presented in this post:

As the user moves from content control to content control, the example updates the contents of the task pane. If the user moves to text in the document that is not in a content control, the example clears the text box in the task pane, and disables the "Update CustomXml Part" button. Another approach that you can take is to hide and show the task pane as the selection moves into and out of content controls. The example contains commented-out code that shows how to do this.

This example relies on the user pressing the "Update CustomXml Part" button. You may want to take another approach of updating the custom XML part data when the user changes any data in the task pane.

Custom Task Panes Overview provides a detailed explanation of custom task panes, and how to create them. Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer provides what you need to know to deploy an add-in.

There are three source files for this example:

You can download the code, along with a Visual Studio solution here.

Updated: The Source Code for this tool is now available:

Here's an interesting development (anyone for pun-free Fridays?)

Intergen, a New Zealand based company, has developed a viewer for Open XML documents. You can get take a look at TextGlow for yourself: http://www.textglow.net/.

The viewer allows you to pan through Open XML documents using Silverlight 2.0 runtime. (Get the details from the developer here) Much like the current viewers for Word, Excel, and PowerPoint documents, TextGlow requires no paid-for product, only to install the Silverlight 2.0 runtime. This is a Microsoft Office-free rendering of Open XML documents.

"TextGlow is a unique product combining Office Open XML and Silverlight for the first time," says Chris Auld, Intergen's Director of Strategy and Innovation.

"Microsoft Office documents have traditionally required software to be installed on the local machine. The new XML- based file format, coupled with Silverlight, has allowed us to make documents viewable directly through users' web browsers.  Having an internationally documented standard such as Office Open XML allows innovative New Zealand companies such as Intergen to reach a global audience," says Mr Auld." 

I had the pleasure of attending a Standards New Zealand Open XML workshop last year, where I met Chris and had the chance to chat with him during the breaks. (I'm a bit amused recalling a discussion where the folks in the room discussing intellectual property issues all had to preface their comments with "I am not an attorney but…[I am going to interpret IP law like I am one anyway]…" Chris, as I recall, does have a background in IP law, so he was unique among his peers in offering some thoughts about bogus claims of Open XML IP risks.)

During that workshop, several developers in the room claimed that implementing Open XML was not possible by New Zealand (or more to the point, non-Microsoft) companies. (Worth noting that one of the companies making these claims already had a full implementation of VML in its "Maps" product.) Another of these companies eventually implemented Open XML in a handful of its products, to the chagrin of Bob Sutor and Rob Weir.

It is great to see Chris and Intergen offer this viewer. I suspect this should have a good silencing effect in New Zealand, because this is such a great example of how Open XML and the compatibility it brings is a boost to local economies, it is also a testament to the openness of the spec. Not only will I use this in discussions around the world when highlighting Open XML, I am also recommending this tool to our account teams in need of document viewing solutions. I'm also hopeful that the participation of Intergen in the broader Open XML community will bring them fame and fortune as well. (After all, building community is the point, is it not?)

I guess this is pretty clear evidence that New Zealand companies can successfully implement Open XML. It's a good reminder to me that when we look at facts rather than reading fiction, we can interpret the "nobody can implement Open XML" claims as more of "I can't" than "nobody can."

Truth (2) will carry the day over fiction.

In case you want to read more about Text Glow:

http://www.920.co.nz/?p=81
http://www.scoop.co.nz/stories/SC0803/S00016.htm
http://www.geekzone.co.nz/content.asp?contentid=7673
http://computerworld.co.nz/news.nsf/tech/6845F290082F5A7BCC2574030018AD4A
http://www.vnunet.com/vnunet/news/2211395/open-xml-docs-accessible-via
http://www.first.org/newsroom/globalsecurity/218004.html
Tim Sneath
https://blogs.msdn.com/tims/archive/2008/03/06/a-great-early-silverlight-2-showcase-textglow.aspx
http://geeks.ms/blogs/roller/archive/2008/03/06/a-great-early-silverlight-2-showcase-textglow.aspx
http://www.silverlightshow.net/items/3963.aspx
http://www.sunherald.com/447/story/414469.html
http://www.topix.com/tech/ms-office
http://newsblaze.com/
http://www.golem.de/0803/58225.html
http://www.itnews.com.au/News/NewsStory.aspx?story=71552

Updated. April 28, 2009. Office 2007 SP2 is available for download. For more information: http://blogs.technet.com/gray_knowlton/archive/2009/04/27/office-2007-service-pack-2-kiosk.aspx 

For those of you who have been following the file format issue for a while, you'll recognize today's action by Microsoft as another significant step forward in enabling interoperability. This hopefully sends a signal (again) to our customers that we are committed (like all successful software businesses are) to addressing the needs of people who use our products by providing choice and interoperability. (Read more, Read even more)

If you missed the announcement, it roughly said the following:

Microsoft Office functionality will be updated to include ODF, PDF and XPS support:

• Microsoft Office 2007 Service Pack 2 will include both "Save as ODF" and "Save as PDF and XPS" functionality.
• The next major release of Microsoft Office, currently codenamed "Office 14," will update its support for IS29500, the specification that resulted from the ISO process.

Microsoft will contribute to the future evolution of the ODF and Open XML specifications.   

• Microsoft will join the OASIS ODF Technical Committee
• Microsoft will participate in the ISO/IEC JTC1 SC-34 committee responsible for the maintenance of Open XML (IS29500)
• Microsoft will participate in the ISO/IEC JTC1 SC-34 committee responsible for the maintenance of ODF (IS26300)
• Microsoft will participate in the ISO/IEC JTC1 SC-34 committee responsible for interoperability between IS29500 and IS26300

Microsoft will contribute to the developments of other document format standards:

• Microsoft will participate in the standardization of XPS underway in ECMA
• Microsoft will participate in future maintenance of PDF in AIIM
• Microsoft will work to promote interoperability with Open XML and UOF, the Chinese national document format standard

A lot of the folks who read the blogs are (rightfully) consumed with the "why?" question… or perhaps even the "Why now?" question. I'd like to take a little time to explain both. I think I can help add some context about why this decision was made, and why we think now is an appropriate time to take these steps.

There are really two central catalysts for these actions. One of these is the feedback we have received from the regulatory environment. There is a high degree of interest in our working with other software vendors to improve information exchange through the use of standardized technologies. In addition, we remain committed to promoting interoperability in our products which means creating the technology bridges necessary for the successful exchange of data with other solutions.

The second catalyst is how these advancements will help drive success in our business. Folks will offer theories across the spectrum about what Microsoft is "trying to do" or what these actions "mean." I'd like to offer a very simple rationale to explain why this is a net positive for our business, and to illustrate some of the thinking about our timing for the adoption of ODF.

Success in our industry (like a lot of other industries) boils down to successfully addressing the needs of customers. By offering greater choice for file formats, our products address more scenarios and provide greater flexibility in enabling specific solutions. From a pragmatic standpoint, adding ODF to Office allows us to re-focus Office on product capabilities rather than a debate about file formats. We're quite comfortable when we compete in the marketplace on these merits.

A natural follow-on question seeks to understand why we would bother with Open XML when we could have just supported ODF from the beginning and moved on…

(I'm oversimplifying a bit here, but) questions about compatibility and moving legacy content forward were very important to our customers, and we were already well down the road with XML-based formats that were designed to represent legacy content. Because ODF side-stepped the compatibility question, we were left to solve (continue solving) that challenge elsewhere; the aversion to dealing with legacy content created a real problem for customers who want to transition to more open file formats.

Speaking very plainly, business continuity is one of the most important drivers of software purchasing decisions. The goals of Open XML with regard to compatibility and preserving legacy content are things that we simply could not do without.

Those who have been involved with Microsoft Office for many years will remember the problems created when Microsoft essentially "flipped the switch" on a new document format for Office '97, offering little consideration for compatibility with existing applications. This had a negative effect on our business, and we were not keen to repeat the mistake. In many standards committee meetings, compatibility was regarded as a "factor," but in reality, the list of things that rank higher in importance is very short.

Open XML is a necessary, worthy standard; it is unique in its intent to address this problem. We will sustain our investment in Open XML through participation in ECMA and ISO, as well as in the development community. We are also committed to having a high-quality implementation of ODF. We accept the responsibility of driving toward interoperability with other products and platforms. We will work with supporters of Open XML, ODF, PDF and XPS to achieve interoperability.

Achieving meaningful, successful interoperability involves participation in the evolution of the standards as well as conducting public forums on real-world implementation issues. In our early testing we are observing that every product implementing these standards has some level of variation from the written spec. If you've been around standards for a while, you'll know this is common, and requires dialog to establish best practices & patterns. This is our reason for joining the OASIS, AIIM and ISO committees, as well as our motivation for hosting public forums like OpenXMLDeveloper.org to discuss our implementation of the formats. These are environments where we hope to learn as much as we contribute… we now get to the real work of enabling interoperability rather than theorizing about its potential in committees. I know the work will be challenging, but I am hopeful that this will ground the document format standards conversation in real-world implementation conversations, where we can uncover and resolve issues that make products share data with greater success.

Just some technical notes (and to tee up future posts) Office 2007 Service Pack 2 will incorporate support for ODF 1.1, to align to the other significant products and policies that support ODF today. SP2 will also support PDF 1.5, and the ISO standard PDF/A. These PDF versions are intended to maximize compatibility with the existing base of installed PDF viewing applications.

Office 14 will update our support for IS29500. The timing for this might seem strange, but I do hope the rationale is clear. ODF 1.1 is a completed specification. The final version of IS29500 is not published today. While we do support a significant portion of IS29500 already, the BRM changes and other issues raised in public forums will inform us on how to best move forward with IS29500… and it gives me a little time to address the compatibility considerations that will be an important part of any file format related changes in Office. ODF has a potential upside in expanding interoperability, but as always, business continuity requirements will have a significant effect on our approach to these file format changes. Our customers will accept nothing less…

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.

Background Reading
What is Custom XML- ... and the impact of the i4i judgment on Word,
Regarding Custom XML Patch distribution and availability,
Associating Data with Content Controls,
Scanning tool to detect documents with custom XML 

In my last post, What is "Custom XML" . . . and the impact of the i4i judgment on Word, I took some steps to identify the areas of Word that are affected by the ruling. This generated a handful of questions from people seeking to understand how they should consider moving forward with solutions in Word.

It is important to understand that using custom XML markup isn't the only way to supply semantic meaning to rich markup. Content controls provide an excellent user experience for this.

The following is a guest post by Eric White, explaining an approach for using styles and content controls for implementing an authoring environment for a publishing system. If you haven't read Eric's blog before, I highly recommend it as a source for learning Open XML and Word development. Eric is among the most knowledgeable about development using Open XML.

..........

I've seen publishing systems that use styles as a means for supplying semantic meaning to content, but this is problematic in some scenarios (but the problems are solvable by content controls). You could format the above document to look like this:

The above screen clipping uses an option in Word that allows you to display the style name for every paragraph to the left of the paragraph.

You could then write a transform from this to the desired format. This approach is problematic because the approach for extracting content involves grouping together adjacent paragraphs of a particular style, and this can lead to an idiosyncratic experience for content writers. For example, I've seen a system where the writer needed to supply a specially formatted line for a code block that would indicate the language for the code. If you needed to supply code snippets for multiple languages, you *needed* to supply a blank line formatted as normal between the code snippets:

This is, of course, problematic. If the writer did not supply this blank line, then the transform would conjoin the two code blocks. I suppose that the developers writing the transform could watch for the magic lines that contain [c#] or [vb], but writing code that looks for magic values is never a good idea. What if there is some valid code that contains that exact string on a line as part of a multi-line string? The transform would be broken, and worse, the writer would need to hack the code in some way to make the transform work properly.

If I were designing a content publishing system that needed to allow writers to work in Word and then transform the document to another format upon publishing, I would design it to use content controls. It is far better to use content controls to group multiple lines together, and to supply appropriate metadata about those lines.

The transform can then extract the contents of each code block in a deterministic fashion.

Here are the characteristics that I would give to a publishing system:

· If there is a direct transform from a single paragraph in a source document to a corresponding construct in the transformed document, then use paragraph styles. You can alter the user experience in Word to allow only valid styles.

· If there is a direct transform from runs in a paragraph to desired constructs in the transformed document, then use character styles.

· Using styles gives the writer a great user experience. The Word user interface is optimized to allow writers to select paragraphs, apply styles, specify what the style for the paragraph following should be, and so on.

· If you need to select multiple paragraphs for transform to some construct in the transformed document, then use content controls to group those paragraphs. This also gives a great experience. The metadata about grouped paragraphs (the code block in the above example) is clearly specified, and not through some magically formatted line or some other questionable technique. If you are the developer for this system, you can supply macros for easy insertion of content controls, although it is super easy to insert content controls using the stock user interface.

Using styles and content controls gives a user experience that is quite different from editing XML. Instead of inserting elements that surround content, you use styles to supply semantic meaning to paragraphs. If you need to associate groups of paragraphs together, you surround them with a content control.

Here are some additional resources to help you work with content controls:

Using LINQ to XML to Retrieve the Contents of Content Controls

Using DocumentBuilder with Content Controls for Document Assembly

Creating Data-Bound Content Controls using the Open XML SDK and LINQ to XML

I was asked recently to comment on "security" of Office 2007. Conversations like this tend to unfold in a certain way… which is to play a fun game of Technology-Tennis, where we volley questions back and forth until we get at the root of the thing… although I've never understood why the grunting is necessary. In the end our conversation was about document encryption. I'd like to post (more or less) the answer to the question on my blog, as it is one that comes up from time to time.

The question was in reference to an article about another product opening XLS files that ignored the protection settings specified on a worksheet tab, and what they could do ensure their content was actually not viewable by unintended parties. For simplicity, I'll reduce the discussion to what happens in the applications here (Vs. the use of SharePoint, NTFS, BitLocker or things like IPSec).

The conversation began by explaining that the functionality in Excel to show/hide or protect content within the workbook are not intended as a full-fledged "security" feature, rather "strong guidance" for how the consumer should be reading the information in the workbook. The use of encryption with Office is much more robust, and is the recommended method for how to apply a password to an Office 2007 document for Word, Excel or PowerPoint.

For the full detail, read this document. If you are interested in the deeper story of how Office security is managed, download this guide. If you are interested in reading about how Open XML documents are encrypted, read this document. If you are interested in reading the blog of a (the) Office security guru, read here: http://blogs.msdn.com/david_leblanc/default.aspx . His most recent post is about the MS-CRYPTO documentation.

I think you'll find that the breadth and depth of coverage available for encrypting documents, helping secure communication, protecting users from potentially harmful content and other aspects of security are an excellent illustration of how much innovation we bring to the table with any new Office release.

Below is an excerpt from the first white paper I referenced:

Microsoft 2007 Office system Document Encryption Improvements

Password protection is not a new concept in the Microsoft 2007 Office system, but it has been made stronger and easier to use. Previous versions of Microsoft Office used an RC4 stream cipher with a key length of up to 128 bits. The problem with this approach was that when changes are made to the encrypted document and the document is saved, the initialization vector (IV) remains unchanged and the same keystream is used to encrypt subsequent versions of the encrypted document. This weakness in the implementation of the RC4 encryption algorithm made it possible for hackers compare two versions of a password-protected file to discover the contents and allow unauthorized users to read its contents. A number of software companies took advantage of these limitations to make "password recovery utilities" that could decrypt RC4-protected documents. Obviously, it was time to move to a now a new means of encrypting documents.

Microsoft 2007 Office system document encryption is a significant improvement. The encryption information block is the same as in previous versions of Office, but the Microsoft 2007 Office system uses the Advanced Encryption Standard (AES) encryption, which is the strongest industry-standard algorithm available and was selected by the National Security Agency (NSA) to be used as the standard for the U.S. Government, AES has a default 128-bit key (which can be increased to 256-bit via the Windows Registry) and uses SHA-1 hashing. In addition, The Microsoft 2007 Office system improves the algorithm of converting passwords into keys: 50,000 SHA-1 sequential iterations are performed.

Some key facts about Microsoft 2007 Office system document encryption:

• Only Microsoft Word 2007 documents, Microsoft Excel 2007 workbooks, and Microsoft PowerPoint 2007 presentations can be encrypted using the built-in Microsoft 2007 Office system encryption feature.
  
• The default encryption algorithm is AES 128-bit. This value can be increased to AES 256-bit via a Registry entry, local security policy, or domain Group Policy.
  
• AES encryption is supported for Open XML formats used in previous versions of Microsoft Office when those documents are created in an Microsoft 2007 Office system application. However, documents saved in the older Office binary formats can only be encrypted using RC4 to maintain compatibility with older versions of Microsoft Office.
  
• AES support is a function of the operating system's cryptographic services providers (CSPs). AES encryption is supported on Windows Server 2003, Windows XP SP2 and Windows Vista.
  
• The level of protection provided by the AES encryption is related to the strength of the password used to protect the document. You should use complex passwords that include upper and lower case letters, numbers and symbols and that are at least 8 characters long.
  
• Password complexity cannot be enforced for Microsoft 2007 Office system encryption. Users should be encouraged to use complex passwords during training.
  
• There are no administrative settings that force users to encrypt documents
  

It's important to note that there are two options to add a password in Microsoft 2007 Office system documents. One option enables you to encrypt the document using a password; this is referred to as a Password to open. The second option does not use any encryption. It is designed so you can collaborate with content reviewers you trust, but is not designed to help make the file more secure. This is referred to as the Password to modify.

Taking a left turn for a moment on the software talk.

I’m at a point where I have to vent on a topic, and no better place to do it than to the anonymous reader. For some reason I’ve been in a lot of these lately (usually the presenter or I am needed for some reason; not as the presentee), and I’m at a point where I just have to empty the chamber on the reviews that are failing for lack of experience / guidance on how to do them well.

With this and so many other things in my management career, I am compelled to teach people to avoid the same mistakes that I make / made. With my enthusiasm for developing people is combined a new perspective of "the other side of the table." I understand now what I could not understand before.

I used to be so bad at this. (Maybe I am still not very good at it.) At some point by design or by intervention, a meeting shows up on the calendar titled "business review" or something similar. These are the dreaded "tell me what you think is important enough for me to know" type meetings, they are common in large companies, where high-level managers don’t have great visibility into the daily lives of people in their organizations. I’m in my 11th year of practice, it took me quite a few to figure this stuff out.

I thought I would share my thoughts on what makes a good review. Having seen enough of them go the wrong way, and being on a streak of reviews that have been moderately successful, I can summarize what I believe the formula to be.

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.

After we made a patch available for Word related to the recent court ruling, we were asked by a handful of customers if there is a way to identify document files or solutions which may be affected. One way to identify solutions within an organization that may be affected is to scan your existing XML format based Word files (.docx and .docm) for the presence of the markup in question.

On my blog today I am posting a no-cost, unsupported tool to help you scan repositories for documents which may contain markup that would be affected by the patch. We are also providing the source code for the tool in case you would want to modify it to scan for specific directories, or to add additional functionality to the tool. It is written in C#.

Results provided by the tool can help you to identify possible areas of impact for your specific IT environment.

The documents identified by the tool as containing custom XML markup are themselves not affected by the ruling, and require no action on your part. What positive scan results will indicate are documents that will behave differently when opened in patched and unpatched versions of Office.

Positive results concentrated on a single machine or set of machines may also indicate the presence of a solution or template generating the affected markup, and may indicate the presence of a solution that will perform differently when opened by a patched or unpatched version of Word.

The scanning tool will work when run by a local user on a local machine. For SharePoint and other systems whose directories are identifiable by a UNC path, the scanning tool can be used on a server to examine documents stored within those systems.

How to Use the Software

IT Administrators can configure a login or startup script for computers in their domain to copy the .exe file to a local machine, and to execute the command line tool. Alternatively, a startup or login script can be created to run the installer locally, and execute the command line tool. For more information on login and startup scripts, visit http://www.technet.microsoft.com, or http://technet.microsoft.com/en-us/magazine/dd630947.aspx.

1. Run a command prompt window (Run as Administrator)

2. Go to the directory where you have installed the Custom XML Markup Detection Tool
    a. By default, this directory is "C:\Program Files\Microsoft\Custom XML Markup Detection Tool\"

3. Run the tool with the following command: DetectCustomXMLMarkup.exe [directory path]
    a. For example DetectCustomXMLMarkup.exe c:\temp

4. At this point, the tool will tell you how many files it is scanning and how many files it detected with Custom XML markup

5. An "output.log" file will be created, in the same directory the tool was run, that summarizes the findings of the tool. This log file includes information on files that include Custom XML markup and/or files that the tool encountered errors while scanning. This log file is a tab delimited text file, which can be opened in Notepad or Excel. Here is an example log file opened in Excel:

Notes: The tool works with directories and UNC file paths.

The Installer is located here. 

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.

Today is a very important day in the history of Microsoft; it's a moment with which I am very happy to be associated. If you didn't see the big news, you can read about it here. But if you just want to skip to the "What does this mean for Office and File Formats?" part, read on.

To recap what was announced, Microsoft is making changes to its technology and business practices in the area of interoperability. These advancements are designed to make our products more open and more available to the broader software community. There are four central principles involved:

• Ensuring open connections to our high-volume products
• Promoting data portability via open document formats, interfaces, import/export functions and other means
• Enhancing support for industry standards
• Engaging more actively (than we currently do) with the industry at large on standards and other interoperability issues

This is consistent with a path we've been on with Office for quite some time. This is also reflected by many actions we've taken over the past 5 years. By "change," one can really argue that we're moving out of the slow lane into the fast lane on this topic, but we're still on the same road traveling in the same direction. A great example of the steps we've been taking is our announcement last week of broad, public availability of the Binary file format documentation.

To recap some of the ground we've already covered with respect to interoperability, here's a short list of background reading that is helpful: Interoperability Executive Customer (IEC) Council, Interoperability Vendor Alliance (IVA), CodePlex, Interoperability Home, OpenXMLDeveloper.org, OpenXMLCommunity.org, Accessibility, Interop Agreements with Novell, Xandros, Linspire, Turbolinux, IdeaAlliance & XML 2007 Conference, Virtualization, OpenID, JVC, Health Care, ADO.NET, the OSP, Microsoft Public License (MPL), Microsoft Reciprocal License (Ms-RL) and a host of others (hopefully the point is clear).

There's a specific aspect of this announcement that I wanted to highlight, because it is very relevant to the ODF discussion (as well as other file formats.) You may have seen this text in connection with the announcement:

"Enhancing Office 2007 to provide greater flexibility of document formats. To promote user choice among document formats, Microsoft will design new APIs for the Word, Excel and PowerPoint applications in Office 2007 to enable developers to plug in additional document formats and to enable users to set these formats as their default for saving documents."

For Office 2007, we will design and make available interfaces that can enable different file formats to be set as a default format in Word, Excel and PowerPoint. This addresses a key concern of organizations like BECTA who desire to have ODF or UOF or other formats enabled as a "default" for Microsoft Office applications. Should other file formats emerge in the future that are suited to word processing, spreadsheets or presentations, these new interfaces will enable their use with Office as well. In the past few years, we've seen a lot of momentum around document format support, and today's announcement will only improve the ability for others to integrate with our products.

It's important to note that the interoperability principles are unrelated to the current ISO standardization process for Open XML, and that process will proceed without regard to what is being announced today. But the objectives of Open XML now have an increased focus and sharpness. The purpose of the Ecma standard (and proposed ISO standard) is to represent content that exists in billions of binary documents, as well as delivering the type of business process integration enabled by the use of custom-defined schema. Open XML is unique in this regard.

We've said this before, but the goals of Open XML are distinctly different than ODF, PDF or UOF, and hopefully we can begin to separate the conversation about product functionality from the necessity for the Open XML standard. In our view, these have always been different conversations. The addition of these interfaces removes a potential obstacle to the adoption of other standards within our products.

The change should also underscore the idea that support for Open XML is not the same as opposition to other standards, despite many claims to this effect. Different formats are a means to achieving specific types of work, and interested communities exist to offer support for them. Today's commitment creates new opportunities to use many document formats in Office, and will allow people a greater ability to choose the formats that best suit their specific needs. This is good for our customers, but it's good for our business, too; adding these interfaces makes a lot of sense.

Update: URL's in the post were not functioning properly, and have now been fixed. 

Today we are please to announce that a public beta of Office Environment Assessment Tool, a beta of Office Code Compatibility Inspector and a draft of the Assessment and Remediation Guide are now available for download at the new Office 2010 Application Compatibility resource page on MSDN. These tools and documentation are made available to you as per our announcement of the Office 2010 Application Compatibility program at SPC09 in October. Please use the links below to navigate and get the tools and the documentation. We encourage you to send us your feedback, comments and suggestions by either using Office 2010 Application Compatibility Forum on TechNet or by just sending a direct mail to ofappcpt@microsoft.com.

Tools and Guidance

Office 2010 Code Compatibility Inspector

The Office Code Compatibility Inspector for VBA and the Office Code Compatibility Inspector for Visual Studio are add-ins that you install with Office 2010 or Visual Studio. The tools scan VBA, VB.NET, and C# code for object model usage that is incompatible with Office 2010.

Office Code Compatibility Inspector Documentation
Office Environment Assessment Tool (OEAT)

This tool helps you determine the kinds of add-ins that are installed on users' computers and the extent to which the add-ins are used. OEAT collects and reports add-in information about Office 2000, Office XP, Office 2003, and the 2007 Office system.

Office Environment Assessment Tool Quick Start Guide
Office Environment Assessment Tool User Manual

Application Compatibility Assessment and Remediation Guide

The Application Compatibility Assessment and Remediation Guide for Office 2010 describes the overall assessment and remediation process, including planning, testing, piloting, and deployment.

Send us feedback on the Code Compatibility Inspector and OEAT via e-mail

It's great to see the adoption of Open XML accelerating. The Compatibility Pack for Open XML has been downloaded more than 70 million times*. Countless large organizations have taken that single download and deployed that across their organizations. These numbers continue to improve in favor of Open XML.

There are a number of tools available for manipulating, processing, scanning or otherwise handling Open XML documents. As I read the forums on OpenXMLDeveloper.org, I think I can be of service by providing a list of the tools that I know about today. There may be others, but this will help folks get started who might be looking for an entry point:

Today we will release the beta version of Microsoft Producer for Microsoft Office PowerPoint 2007 via our Connect site. This version of Producer works with PowerPoint 2007, Windows Vista, and IE7, and is also compatible with Open XML. This is a long-awaited add-in for many customers, we're happy to be on the final path to getting it out the door.

In case you're not familiar with Producer, it is a free add-in which enables PowerPoint users to capture, synchronize, and publish audio, video, slides, and images to create engaging rich media presentations that can be viewed in a web browser.

We're running the beta until June 30, 2008, and then will review the feedback we received from customers. We're planning to release the final version of Producer 2007 to the Office Download Center in the Jul/Aug'08 timeframe.

Here's how you can access the Producer 2007 beta:

Click here to jump to the Connect site or type http://www.connect.microsoft.com in your web browser.

Click Sign In and enter your Windows Live ID.

• If you are not already registered on Connect, enter the requested details to complete your Connect site registration.

Click the Connection Directory tab, and then click Office in the Categories list in the left-hand navigation pane.

Scroll through the list of available Connections and locate the Producer for PowerPoint 2007 Beta.

• You may want to change the Sort By criteria to list by Connection Name (A-Z).

When you have found the link for the Producer beta site, click the + Add to Your Dashboard link displayed next to it.

• The next time you return to the Connect site you can click the Your Dashboard tab instead of the Connection Directory tab to jump to the Producer beta site or any other Connection you are participating in.

Click the Producer for PowerPoint 2007 Beta link to go to the beta site.

• Review the FAQs and Links on the site for helpful information about Producer and this beta.
• Click the Downloads link in the left-hand navigation pane to download and install Producer 2007.
• Click the Feedback link in the left-hand navigation pane to provide feedback and report any possible bugs.

If you can't find the Producer beta site in Connect, check back later today. It will be posted during the day today. You can also learn more about Producer from the PowerPoint team's blog here .

The first compatibility pack for Open XML was released in November of 2006. This add-in for Office XP and 2003 (which also works with Office 2000 in some cases) enables users to open, edit and save Open XML files using prior releases of Office. The compatibility pack is designed to ease the pain of introducing a new file format. As we learned in Office 97, changing file formats can create some significant deployment and compatibility challenges. It is a migration that we're handling with all due care and consideration for our customers' business continuity requirements.

The availability of the compatibility pack has been an interesting discussion. Today, the compatibility pack is only available as a manual download. In other words, Microsoft does not "push" the compatibility pack to users using its update tools. IT organizations or end users must manually download the tool, and deploy or install it themselves. Many organizations have (literally) demanded this be made available as an automatic update, while others would be dissatisfied with this, claiming that Microsoft is "forcing" Open XML onto its existing user community.

We decided to make it available as a manual download, and not as an automatic update, and during the first 12 months of its release, the compatibility pack has been successfully downloaded over 20 million times. This means that 20 million people have elected to manually download this 26.2MB software to their computer. This is a significant number of people adding Open XML to their environment.

Why do people download the compatibility pack? – to use Open XML, of course. If a user of Office 2003 or XP tries to read/edit an Open XML file type, Windows will offer the "Use a web service to find the appropriate program" dialog box to direct you to the compatibility pack download site. If you have updated Office with the latest service packs, you will get a similar (but more user-friendly) dialog box that directs you to the same place.

On the download center, users select their language, get the bits and off they go. The 20 million people who have already completed this demonstrate that Open XML is already in widespread use today, about 1 year after its formal introduction with Office 2007. This is in addition to the adoption Open XML is gaining in the broader software community: http://www.openxmlcommunity.org.

What is also interesting about the compatibility pack statistics is that they do not reflect deployment by IT organizations… It takes only one download by the IT desktop management team to prepare thousands of desktops with the compatibility pack (I have worked on a handful of these directly). The usage numbers for the compatibility pack are likely to be significantly higher than the download statistics indicate.

I won't explain in detail how these download numbers compare to things like the ODF Translator for Microsoft Office, but you can look at the download stats on SourceForge for that one and see for yourself. Being a product person (not a standards person) I'm far more interested in what users are doing with the software, so I don't have a positive or negative view of ODF (nor do I care to swordfight with the ODF community). But the statistics do speak pretty clearly about the preference of Microsoft Office users…

I believe in the marketing lexicon this is typically referred to as "rapid traction," but it does come with the responsibility of sustainability (speaking of buzzwords) and maintenance. Our commitment to the standard goes hand-in-hand with our long-term commitment to IT organizations and end users who have taken the opportunity to incorporate Open XML into their Office environment. Instead of the theoretical arguments and "what-if" scenarios that the document format standards community gets into, longevity of Open XML is a real consideration based only on the activity of people who use our products. In other words, Open XML is here to stay.

That's pretty exciting news.

Happy Holidays everybody.

On February 21, 2008, I posted on Microsoft Interoperability Principles, which are designed to make our products more open and more available to the broader software community. Since that day, Microsoft has made several strides in this area, too many to recount here and now, but largely explained by the Interoperability@Microsoft team.

Today we are making an important advance in the area of document format interoperability for Office, as part of our ongoing commitment to these interoperability principles.

After four successful Technology Previews, today we are releasing the 2.0 version of the Open XML SDK for Microsoft Office. Among its benefits, this release of the Open XML SDK is a significant step forward because of the amount and quality of functionality it provides to developers seeking to build document processing solutions without the use of Microsoft Office applications.

Today Visual Studio is the primary developer tool for Office 2010, and Visual Basic for Applications (VBA) is also widely used to extend and automate our Office client software. Traditionally Visual Studio developers build add-ins, integrations with SharePoint and other solutions that exist within Office products. In the past, one of the common developer tasks with Visual Studio and Visual Basic for VBA was processing of Office documents. This was typically accomplished with macros and scripts running inside client applications. This is sub-optimal for many reasons. Client applications are not optimized for large-scale automation, and in-client document processing solutions are error-prone as a result.

Document processing is spreading to mainstream development because of advances in more transparent XML-based formats and the associated tooling to modify documents represented in those formats.

The Open XML SDK improves the ability to process Office documents. Automation operations no longer require a client environment that was never really designed to support bulk processing solutions. With the SDK developers now have direct (element-level) access to a document's content. It is great for enabling solutions to extract, examine or modify a document's contents.

The SDK also improves developer choice and platform-neutral document interoperability. By freeing documents from their dependence on a particular application or platform, government agencies and other entities gain greater access to the information they store in their documents.

Many people will comment on the capabilities of the SDK. If I might recommend some resources to get started, I would point readers to the following posts:

Download the SDK

Download the Open XML SDK 2.0 for Microsoft Office This download provides strongly typed part and content classes for use with Office 2007 & Office 2010 Open XML documents. http://www.microsoft.com/downloads/details.aspx?FamilyID=c6e744e5-36e9-45f5-8d8c-331df206e0d0

http://msdn.microsoft.com/en-us/office/ee441239.aspx

http://msdn.microsoft.com/en-us/office/bb265236.aspx

http://www.openxmldeveloper.org

http://blogs.msdn.com/brian_jones

http://blogs.msdn.com/johnrdurant/archive/2010/03/15/open-xml-sdk-2-0-for-microsoft-office-is-live.aspx

http://blogs.msdn.com/erikaehrli/archive/2010/03/15/open-xml-sdk-2-0-rtm-articles-videos-code-snippets-and-resources-on-msdn.aspx

http://blogs.msdn.com/ericwhite/archive/2010/03/15/release-of-the-open-xml-sdk-2-0-for-microsoft-office.aspx

I am very excited for the release of the Open XML SDK, and I hope that the Open XML Development community will be as well.

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.

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.