Alrighty. If it is a virtual machine, where can we find documentation about: 1) the OPCODES of this vm 2) the standard libraries and interbrowser API 3) The format of silverlight compiled scripts
The opcodes of the machine are documented on the standard ECMA 335.
The standard libaries and browser APIs are available from http://msdn2.microsoft.com/ a lot of the documentation is still under development for Silverlight 1.1 (1.0 is much more complete) so for a few things that are new in 1.1, you have to guess what they are, or look it up in the WPF docs (which is where stuff ultimately came from).
The format of the Silverlight compiled scripts is documented in ECMA 335 as well.
Meh, IIRC Mono hasn't even completed the port of.Net 2.0 (especially the ASP.NET part), let alone.Net 3.0. So they had to implement whatever.Net 3.0 libraries Silverlight may have needed.
You do not remember correctly, and in particular the ASP.NET 2.0 piece is incorrect.
We are in fact not done with 100% of.NET 2.0, but we got pretty much all the APIs that people are using according to the 2,000 or so reports that we are getting through our Migration Tool. There is still work left to do, but we are on good track.
ASP.NET 2.0 is complete, it is so complete that Mainsoft already shipped their Grasshopper product (whose ASP.NET 2.0 support is the same Mono code base). We have not shipped because we are going to ship other technologies like Windows forms that Grasshopper is not targeting.
Miguel.
You might want to look at our release announcements (they come out about every six weeks) as we have been making a lot of progress on Windows.Forms, we have a team of six developers working on it and they commit on a daily basis.
I like to think that my opinion on Avalon is a bit more sophisticated than one post from 2004 (which predated the Ajax revolution, I blogged about Google and Ajax in September 2004, so five months after that post), the following are the files where I cover Xaml, Avalon, Silverlight:
The problem is that some of us want to have access to content that will be produced with Silverlight
And some of us don't want there to be lots of content produced with Silverlight. It's bad enough that so much of the content on the web is tied up in little obfuscated applets in Java and Flash as it is. And you honestly believe that Mono implementing Silverlight will actually make a difference as to whether Silverlight succeeds or fails?
Seriously, there's pretty much only three things these are used for: advertising, low-quality DRM, and toys and games. Exceptions like the Java applets at Greg Egan's site are far and few between, and Google has shown us with Maps and Gmail that you don't *need* these plugins to produce rich content.
Thank goodness Microsoft's first try failed, and we don't have ActiveX and its security problems on Mac and Linux.
We don't need a better Silverlight or a better Flash. We need better tools inside the framework that we already have. You are preaching to the choir:
PS Curiosity-> Any word about Indigo on mono? Yes, check the "Olive" module and www.mono-project.com/Olive page, it contains the information on our ongoing work for 3.0 assemblies.
Atsushi did a great job getting the basics of Indigo going. There is still a lot of work ahead left to do, and some great students are helping us in the Summer of Code to make progress on WCF.
We already do that; Although Mono has an incredibly rich ecosystem of libraries that are Unix-specific, Linux-specific or Gnome-specific we usually try to make our libraries cross platform.
This means that we tend to make our code run not only on Mono/Linux but also on.NET/Windows, as it expands the developer base, and the contributor base (see Mono.Addins for a recent example).
Or www.mono-project.com/Software and www.mono-project.com/Libraries to view the Mono ecosystem of libraries.
IronPython provides a direct bridge to communicate with.NET, so it is a more natural choice for.NET developers to use IronPython. Also IronPython is being used as a test-bed (together with new implementations of Javascript, Ruby and Visual Basic) for the Dynamic Language Runtime.
Part of the realization is that web developers use dynamic languages, and they are doing an effort to make sure that there is good support in the platform (in particular Silverlight, a technology targeted to the web developer community) for these kinds of languages.
You need a kernel that supports sigaltstack to enable us to process the stack overflow.
You can enable this with --enable-sigaltstack when you build Mono. But we found a bug in this setup: the GC currently has no visibility into the alternate stack, so it is technically not 100% correct as it does not scan the alternate stack conservatively.
It is obviously something that must be fixed before something like Silverlight is completely supported.
It's only a useful piece of technology if you want to abandon the UNIX programming environment and switch to one that's based on the Windows API and isolates you from all the rest of the UNIX tools you're used to.
When was the last time that you used the "UNIX programming environment" in your web browser? Last I checked, you had to write in a subset that isoaltes you from the operating system and only allowed DOM access and Javascript.
Flash, the other major tool for RIAs, does not give you access to *any* Unix facilities.
You seem to be confused as to what Silverlight is.
One of the nice things about Silverlight (as I pointed out in a blog entry a few weeks ago) is that you can actually generate Silverlight content with any Unix tool you want.
The problem is that some of us want to have access to content that will be produced with Silverlight, inventing a better system will not make the Silverlight content magically be transformed or accessible to us.
If you make it better enough that there is a compelling reason for people to use it as their content platform rather than Silverlight, yes, it will. Well, except not "magically", unless you regard the normal action of the market as "magic".
How come I did not think of that? This is what people must mean when they use the expression "this is a stroke of genius".
I hope you do not mind leading the way, we will follow you.
The problem with your argument is that no one has even tried to make something better. You jump on the Microsoft bandwagon every single time.
People have created tons of fantastic development platforms, are you kidding me?
I can name a few:
* The whole python universe. * The Javascript/Ajax revolution in all of its forms and shapes. * Smalltalk/Squeak * Java/Swing * Java/SWT and the Eclipse platform * Ruby on Rails * Pylons/Dojo/TurboGears * Flash
Aa for jumping into Silverlight, the explanation is very simple: it has a high resonance with what we do: it is an incremental upgrade to the Mono platform.
We work on Mono, and on many technologies based on the CLR (both for.NET and Mono-unique), and this seems like a natural next step.
I miss the Miguel from the Gnome project. This new Miguel is just a Microsoft sellout.
Brother, am sorry I have shattered your childhood dreams. You are going to find yourself a new role model to fight the system and stick it to the man.
Silverlight hasnt even begun to take root, not by a long shot, and yet here you are already working hard to make sure it does.
If you think that/us/ supporting Silverlight is really what will tilt the balance in the Flash/Silverlight/Ajax universe you are giving us way more credit than we deserve. You might want to revisit your assumptions.
Microsoft is not unbeatable. They have failed at everything they've tried over the last 5 years, whether it's Vista, IE7 or Zune. Making the stupid assumption that Silverlight is the next greatest thing is why people have lost respect for you.
From reading this dialog, I get the feeling that fear and hatred have overtaken you. I can appreciate Silverlight and at the same time dislike Windows, I know that this might cause a bit of cognitive dissonance, but my evaluation of technology is not binary. I think Silverlight is a very nice use of the CLR, resonates with our work, and is relatively simple to implement.
My recommendation: "The Art of Possibility" from Benjamin Zander, one of my favorite books. Either that, or going on meds.
Invent something better and open source it rather than play catch up and gamble on the evil empire playing nice.
Seriously, rather than copy them, try being creative for a change and invent something better.
The problem is that some of us want to have access to content that will be produced with Silverlight, inventing a better system will not make the Silverlight content magically be transformed or accessible to us.
Building a "player" for Silverlight is also orders of magnitude simpler than building the complete ecosystem: the engine, the development tools, the designer tools and the partnerships.
Having a better technology does not mean that the better technology will have the reach that something from Macromedia and Microsoft will have.
But my all means, if you want to design, architect and implement a better Silverlight and a better Flash, you should go ahead and do it. But the technology piece is only going to be a fraction of the problem to solve.
They didn't. They instead chose to pull the rug out from under you by open sourcing their own CLR (to some extent) and making it cross platform (to some extent).
They did not open source their CLR, you are confused.
They open sourced a chunk of code that we do not have, the DLR and as I said on my blog post, we will be shipping the DLR together with IronPython and NRuby (when it becomes
You've clearly got a lot of talent, so why are you wasting your time making Open Source versions of all of Microsoft's products? All you're effectively doing is giving Microsoft the foothold in Linux that they need.
Well, because I believe that Siverlight will become an important component in future applications. The majority of people will probably be happy to spice up their web applications with a little silverlight as it will run on Windows and MacOS.
But if there is no Silverlight for Linux, we will be prevented from getting access to content and applications that will be available.
So we got a couple of strategies dealing with this:
(a) the ostrich strategy also known as the "i-cant-hear-you" strategy: pretend that Silverlight does not exist and hope that by ignoring it, it will go away and vanish.
(b) Hope that nobody adopts it. I seriously doubt that Silverlight will not be adopted, in particular the CLR version shows a lot of promise.
(c) Be proactive and implement it ourselves: we got most of the hard bits of the technology already (a CLR, a JIT, the GC, the core class libraries, even up to some parts of LINQ).
Considering that we are very familiar with the technology, we can do something along the lines of (c). You can feel free to pursue avenues (a) and (b).
In fact, you can ignore Mono completely, nobody is forcing you to use it; Nobody is asking you to contribute to the effort, and nobody is in any position to force you to stop using whatever other technology happens to be your favorite one.
I loved the Silverlight announcement, it is a way of bringing my favorite platform to the web (the CLR and now the DLR) and it seems like a natural fit and extension to what Mono does.
There are plenty of Linux apps out there that could do with your skills and that don't infringe on Microsoft's patents. Why not write a program that'll do something with that number that everyone's been talking about recently. I can't remember what it is, but I'll find it in a moment...
And why exactly would I care about your pet project?
Sebastien Pouliot suggested we call it "Moonlight" (anagram on Mono).
And I was thinking Silver-light in another language, bonus points if the script is good looking.
For instance, in Arabic it would be fad-da daw' ( ) which looks cool on a large font(thanks to Hisham Bardam for the translation) although it does not roll easily. We might need some shortening.
Novell has not received any licenses to any patents, and neither has SUSE, nor OpenSUSE.
The Microsoft-Novell agreement is about not suing customers over any potential patent infringement.
Since OpenSUSE is a community effort, and it is used by people that might not be customers of Novell, removing code that is known to infringe on a patent is the correct thing to do (same policy applies to Mono).
I do know about OpenFormula, but OpenFormula is not part of ODF, it is a work in progress that will eventually end up in ODF and with luck, will end up in the ISO standard.
Which was precisely my point: you can build a spreadsheet, as long as you are willing to read third-party information (source code, Excel documentation, Excel books, or OpenFormula) or you resort to the OOXML ECMA standard (ECMA, not ISO yet).
The problem with Microsoft's "standard" is that in many places it says things like "do what Word 5.0.3 does in when in double-line-spaced mode" without saying just what that means. The specification for Microsoft's XML format is not in the standards documents, it exists in only one place - the source code for Microsoft Word. Making a fully compliant implementation of Microsoft's XML format when you haven't got access to the Word codebase is therefore virtually impossible.
As it turns out OpenOffice has a similar feature the "config:config-item" XML property, and there are a number of these config properties that remain unspecified (from page 14):
The ODF committee chose to exclude the list of settings (many of which are commonly used in a variety of applications) from the ODF standard, which has resulted in a large number of separately defined application specific settings which is an actual barrier to interoperability. For example, the following are a small selection of properties that OpenOffice saves into ODF using application specific settings (all of which affect the display of the document):
ChartAutoUpdate - specifies if charts in text documents are updated automatically.
AddParaTableSpacing - specifies if spacing between paragraphs and tables is to be added.
AddParaTableSpacingAtStart - specifies if top paragraph spacing is applied to paragraphs 1 on the first page of text documents.
AlignTabStopPosition - specifies the alignment of tab stops in text documents.
SaveGlobalDocumentLinks - specifies if the contents of links in the global document are saved or not.
IsLabelDocument - specifies if the document has been created as a label document.
UseFormerLineSpacing - specifies if the former (till OpenOffice.org 1.1) or the new line spacing formatting is applied.
AddParaSpacingToTableCells - specifies if paragraph and table spacing is added at the bottom of table cells
UseFormerObjectPositioning - specifies if the former (till OpenOffice.org 1.1) or the new object positioning is applied.
ConsiderTextWrapOnObjPos - specifies if the text wrap of floating screen objects are considered in a specified way in the positioning algorithm.
It seems that more effort has gone into finding faults into OOXML while the same faults exist in ODF.
{If|When} "Open XML" gets set as a standard, Microsoft will claim that Office is "standards-based and open". Which, by definition, it would be.
Open Office et. al will implement ODF. It will also implement a partial version of Open XML - as best as it possibly can do, given the vague nature of some of the Open XML implementation points.
OOXML is already a standard (an ECMA one, but a standard), what this process will do is turn it into an ISO standard as well.
That being said, OOXML is vastly better specified than ODF is. As I pointed out on my blog some time ago, it would not be possible to build a spreadsheet today using the ODF specification, too many details would have to be extracted from either the OOXML spec (oh, the irony!) or an existing implementation that was based on public information like the Excel documentation (Gnumeric, Open Office).
Am sure that OOXML could still use some work and do more along the lines of having the specification be as clear as possible, but if your point of reference is ODF then the criticism is a bit like the elephant that criticized animals with big ears.
As you will note if you follow the previously supplied link, MSOfficeXML references the results of their old binary cruft without further definitions, which is no better than nothing at all.
This is quite an exaggeration as the only "binary blobs" are for image metafiles, so it is a tiny fraction of the standard.
I would not mind having them standardized as well (of course, the "6,000-pages-is-too-long-istas" will complain that this is making it harder to implement.
The reality is that today's office suites already have code to cope with those metafile images as they are already used extensively, the formats have been documented in a number of implementations and can be downloaded from Microsoft's site.
On the other hand, we could all collective freak out.
Most people do not understand that the fast track process is only a way of accelerating the process, it is not a mechanism of rubber stamping the standard, there are still six months of work ahead before the actual voting can begin.
Details about how this work can be found in Brian Jones' blog:
Slashdot Mirror
The opcodes of the machine are documented on the standard ECMA 335.
The standard libaries and browser APIs are available from http://msdn2.microsoft.com/ a lot of the documentation is still under development for Silverlight 1.1 (1.0 is much more complete) so for a few things that are new in 1.1, you have to guess what they are, or look it up in the WPF docs (which is where stuff ultimately came from).
The format of the Silverlight compiled scripts is documented in ECMA 335 as well.
Mono is not coded in C++, it is coded in C.
The Moonlight rendering engine is written in C++, this is the piece that can be used without Mono, although for most things you will want Mono.
The binding to link the engine to Mono is written in C#.
Hello,
You might want to look at our release announcements (they come out about every six weeks) as we have been making a lot of progress on Windows.Forms, we have a team of six developers working on it and they commit on a daily basis.
Miguel.
Hello,
I like to think that my opinion on Avalon is a bit more sophisticated than one post from 2004 (which predated the Ajax revolution, I blogged about Google and Ajax in September 2004, so five months after that post), the following are the files where I cover Xaml, Avalon, Silverlight:
http://tirania.org/blog/archive/2003/Nov-13.html
http://tirania.org/blog/archive/2004/Mar-03.html
http://tirania.org/blog/archive/2004/Mar-11.html
http://tirania.org/blog/archive/2004/Mar-20.html
http://tirania.org/blog/archive/2004/Mar-29.html
http://tirania.org/blog/archive/2004/Apr-24.html
http://tirania.org/blog/archive/2004/Jul-13.html
http://tirania.org/blog/archive/2004/Sep-01.html
http://tirania.org/blog/archive/2004/Sep-09.html
http://tirania.org/blog/archive/2004/Sep-19.html
http://tirania.org/blog/archive/2005/Aug-27-2.html
http://tirania.org/blog/archive/2005/Sep-06.html
http://tirania.org/blog/archive/2007/Jan-30.html
http://tirania.org/blog/archive/2007/Mar-06.html
http://tirania.org/blog/archive/2007/Apr-12.html
http://tirania.org/blog/archive/2006/Apr-13.html
http://tirania.org/blog/archive/2007/Apr-16.html
http://tirania.org/blog/archive/2007/Apr-20.html
http://tirania.org/blog/archive/2007/Apr-25.html
http://tirania.org/blog/archive/2007/May-01-1.html
http://tirania.org/blog/archive/2007/May-01.html
http://tirania.org/blog/archive/2007/May-03-1.html
http://tirania.org/blog/archive/2007/May-03-2.html
http://tirania.org/blog/archive/2006/Jun-30.html
http://tirania.org/blog/archive/2006/Sep-15-3.html
http://tirania.org/blog/archive/2006/Oct-02-2.html
http://tirania.org/blog/archive/2006/Aug-02.html
http://tirania.org/blog/archive/2006/Aug-03.html
http://tirania.org/blog/archive/2006/Aug-04.html
http://tirania.org/blog/archive/2006/Aug-16-1.html
WPF was late, in fact, it was only released as a completed product in November so it clearly has not been used wildly in the market.
Miguel
And some of us don't want there to be lots of content produced with Silverlight. It's bad enough that so much of the content on the web is tied up in little obfuscated applets in Java and Flash as it is. And you honestly believe that Mono implementing Silverlight will actually make a difference as to whether Silverlight succeeds or fails? Seriously, there's pretty much only three things these are used for: advertising, low-quality DRM, and toys and games. Exceptions like the Java applets at Greg Egan's site are far and few between, and Google has shown us with Maps and Gmail that you don't *need* these plugins to produce rich content.
Thank goodness Microsoft's first try failed, and we don't have ActiveX and its security problems on Mac and Linux.
We don't need a better Silverlight or a better Flash. We need better tools inside the framework that we already have. You are preaching to the choir:
http://tirania.org/blog/archive/2007/Apr-20.html
Miguel
PS
Curiosity-> Any word about Indigo on mono? Yes, check the "Olive" module and www.mono-project.com/Olive page, it contains the information on our ongoing work for 3.0 assemblies.
Atsushi did a great job getting the basics of Indigo going. There is still a lot of work ahead left to do, and some great students are helping us in the Summer of Code to make progress on WCF.
You can join as well:
www.mono-project.com/Contributing
Miguel.
Hello,
.NET/Windows, as it expands the developer base, and the contributor base (see Mono.Addins for a recent example).
We already do that; Although Mono has an incredibly rich ecosystem of libraries that are Unix-specific, Linux-specific or Gnome-specific we usually try to make our libraries cross platform.
This means that we tend to make our code run not only on Mono/Linux but also on
Or www.mono-project.com/Software and www.mono-project.com/Libraries to view the Mono ecosystem of libraries.
Hello,
.NET, so it is a more natural choice for .NET developers to use IronPython. Also IronPython is being used as a test-bed (together with new implementations of Javascript, Ruby and Visual Basic) for the Dynamic Language Runtime.
IronPython provides a direct bridge to communicate with
Part of the realization is that web developers use dynamic languages, and they are doing an effort to make sure that there is good support in the platform (in particular Silverlight, a technology targeted to the web developer community) for these kinds of languages.
Miguel.
There is a long story behind this.
:-)
You need a kernel that supports sigaltstack to enable us to process the stack overflow.
You can enable this with --enable-sigaltstack when you build Mono. But we found a bug in this setup: the GC currently has no visibility into the alternate stack, so it is technically not 100% correct as it does not scan the alternate stack conservatively.
It is obviously something that must be fixed before something like Silverlight is completely supported.
But we are taking patches
When was the last time that you used the "UNIX programming environment" in your web browser? Last I checked, you had to write in a subset that isoaltes you from the operating system and only allowed DOM access and Javascript.
Flash, the other major tool for RIAs, does not give you access to *any* Unix facilities.
You seem to be confused as to what Silverlight is.
One of the nice things about Silverlight (as I pointed out in a blog entry a few weeks ago) is that you can actually generate Silverlight content with any Unix tool you want.
You can easily generate it with PHP:
header ("Content-Type: application/xaml");
print "
";
Or you can generate it with shell, perl, python or assembly language.
The server side is probably as Unixy as anything else can get.
How come I did not think of that? This is what people must mean when they use the expression "this is a stroke of genius".
I hope you do not mind leading the way, we will follow you.
Miguel.
People have created tons of fantastic development platforms, are you kidding me?
I can name a few:
* The whole python universe.
* The Javascript/Ajax revolution in all of its forms and shapes.
* Smalltalk/Squeak
* Java/Swing
* Java/SWT and the Eclipse platform
* Ruby on Rails
* Pylons/Dojo/TurboGears
* Flash
Aa for jumping into Silverlight, the explanation is very simple: it has a high resonance with what we do: it is an incremental upgrade to the Mono platform.
We work on Mono, and on many technologies based on the CLR (both for
Brother, am sorry I have shattered your childhood dreams. You are going to find yourself a new role model to fight the system and stick it to the man.
If you think that
From reading this dialog, I get the feeling that fear and hatred have overtaken you. I can appreciate Silverlight and at the same time dislike Windows, I know that this might cause a bit of cognitive dissonance, but my evaluation of technology is not binary. I think Silverlight is a very nice use of the CLR, resonates with our work, and is relatively simple to implement.
My recommendation: "The Art of Possibility" from Benjamin Zander, one of my favorite books. Either that, or going on meds.
Miguel.
The problem is that some of us want to have access to content that will be produced with Silverlight, inventing a better system will not make the Silverlight content magically be transformed or accessible to us.
Building a "player" for Silverlight is also orders of magnitude simpler than building the complete ecosystem: the engine, the development tools, the designer tools and the partnerships.
Having a better technology does not mean that the better technology will have the reach that something from Macromedia and Microsoft will have.
But my all means, if you want to design, architect and implement a better Silverlight and a better Flash, you should go ahead and do it. But the technology piece is only going to be a fraction of the problem to solve.
Miguel.
They did not open source their CLR, you are confused.
They open sourced a chunk of code that we do not have, the DLR and as I said on my blog post, we will be shipping the DLR together with IronPython and NRuby (when it becomes
Well, because I believe that Siverlight will become an important component in future applications. The majority of people will probably be happy to spice up their web applications with a little silverlight as it will run on Windows and MacOS.
But if there is no Silverlight for Linux, we will be prevented from getting access to content and applications that will be available.
So we got a couple of strategies dealing with this:
(a) the ostrich strategy also known as the "i-cant-hear-you" strategy: pretend that Silverlight does not exist and hope that by ignoring it, it will go away and vanish.
(b) Hope that nobody adopts it. I seriously doubt that Silverlight will not be adopted, in particular the CLR version shows a lot of promise.
(c) Be proactive and implement it ourselves: we got most of the hard bits of the technology already (a CLR, a JIT, the GC, the core class libraries, even up to some parts of LINQ).
Considering that we are very familiar with the technology, we can do something along the lines of (c). You can feel free to pursue avenues (a) and (b).
In fact, you can ignore Mono completely, nobody is forcing you to use it; Nobody is asking you to contribute to the effort, and nobody is in any position to force you to stop using whatever other technology happens to be your favorite one.
I loved the Silverlight announcement, it is a way of bringing my favorite platform to the web (the CLR and now the DLR) and it seems like a natural fit and extension to what Mono does.
And why exactly would I care about your pet project?
Yes. Because Silverlight does not run on Linux.
Sebastien Pouliot suggested we call it "Moonlight" (anagram on Mono).
And I was thinking Silver-light in another language, bonus points if the script is good looking.
For instance, in Arabic it would be fad-da daw' ( ) which looks cool on a large font(thanks to Hisham Bardam for the translation) although it does not roll easily. We might need some shortening.
Miguel.
Just to clarify the thesis of the post.
Novell has not received any licenses to any patents, and neither has SUSE, nor OpenSUSE.
The Microsoft-Novell agreement is about not suing customers over any potential patent infringement.
Since OpenSUSE is a community effort, and it is used by people that might not be customers of Novell, removing code that is known to infringe on a patent is the correct thing to do (same policy applies to Mono).
Yes, a XAML parser was written two years ago, as part of Google's Summer of code.
.NET 3.0 you could have picked the actual class libraries, xaml is really easy.
It is on SVN, in the module "olive", the command line compiler is "xamlc", its supporting libraries all under olive/class.
Now, if you wanted to make a big deal out of where Mono stands with
Miguel.
Hello,
I do know about OpenFormula, but OpenFormula is not part of ODF, it is a work in progress that will eventually end up in ODF and with luck, will end up in the ISO standard.
Which was precisely my point: you can build a spreadsheet, as long as you are willing to read third-party information (source code, Excel documentation, Excel books, or OpenFormula) or you resort to the OOXML ECMA standard (ECMA, not ISO yet).
Miguel.
I found the answer from the reply from ECMA to ISO (here: http://www.computerworld.com/pdfs/Ecma.pdf) very enlightening.
As it turns out OpenOffice has a similar feature the "config:config-item" XML property, and there are a number of these config properties that remain unspecified (from page 14):
OOXML is already a standard (an ECMA one, but a standard), what this process will do is turn it into an ISO standard as well.
That being said, OOXML is vastly better specified than ODF is. As I pointed out on my blog some time ago, it would not be possible to build a spreadsheet today using the ODF specification, too many details would have to be extracted from either the OOXML spec (oh, the irony!) or an existing implementation that was based on public information like the Excel documentation (Gnumeric, Open Office).
Am sure that OOXML could still use some work and do more along the lines of having the specification be as clear as possible, but if your point of reference is ODF then the criticism is a bit like the elephant that criticized animals with big ears.
Miguel.
This is quite an exaggeration as the only "binary blobs" are for image metafiles, so it is a tiny fraction of the standard.
I would not mind having them standardized as well (of course, the "6,000-pages-is-too-long-istas" will complain that this is making it harder to implement.
The reality is that today's office suites already have code to cope with those metafile images as they are already used extensively, the formats have been documented in a number of implementations and can be downloaded from Microsoft's site.
On the other hand, we could all collective freak out.
Miguel.
Most people do not understand that the fast track process is only a way of accelerating the process, it is not a mechanism of rubber stamping the standard, there are still six months of work ahead before the actual voting can begin.
/ 29/explanation-of-the-iso-fast-track-process.aspx
Details about how this work can be found in Brian Jones' blog:
http://blogs.msdn.com/brian_jones/archive/2007/01
Miguel.