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 email@example.com, and for the PASS Summit Unite conference, please contact firstname.lastname@example.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:
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.
“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 7th, 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.