Slashdot Mirror

Patents on OOXML, 1
Patents on OOXML, 2
Patents on the C# language
Patents on the Common Language Infrastructure

Patents on OOXML, 1
Patents on OOXML, 2
Patents on the C# language
Patents on the Common Language Infrastructure

Patents on OOXML, 1
Patents on OOXML, 2
Patents on the C# language
Patents on the Common Language Infrastructure

First - I know i4i states OO does not infringe on the patent. If you would have been paying attention you would have seen the second word in my post. Second - The DOCX format is a standard.

"...We introduce instructions newdata, lddata, stdata, castdata, isdata and switchdata to create and manipulate classunion values..." (emphasis mine).

All of those operations have been superseded by ECMA-335 4th edition. Which per the CP would be open for implementation. However, that doesn't exclude the possibility that more operations could be added without submitting to ECMA. However, the ones that you have cited are a non-issue.

Cheers.

The problem people seem to have is that they seem to have a hard time understanding that something can be a published standard and still patented.

Here is the Patent declaration by Microsoft to ECMA body

"This letter is to inform you, in the event that ECMA adopts an ECMA Standard for C# Programming Language and the Common Language Infrastructure (CLI), Microsoft Corporation will grant, on a non-discriminatory basis, to any party requesting it, licenses on reasonable term and conditions, for its patent(s) deemed to be necessary for the implementation of the ECMA Standard."

Note that what is reasonable is at Microsoft's discretion and can have a monetary value which would be the kiss of death for a free project.

If anybody can point to an actual patent that Mono or Tomboy violate, please file an issue report against the Mono project;

I know it is a bit old but, we'll file one once they publish which part they're going to patent, of course, that shouldn't be long. PS: The only complaint I have of .NET is the syntax of LINQ, but what'cha going do?

Besides, anyone thinking that MS would attacking Linux using patents isn't giving Microsoft any credit. I figure that they would try to kill Linux (GNOME proper, since GNOME != Linux) via contracts with Linux vendors as opposed to patents. It just seems too obvious to go that (patents) route. Linux isn't the problem with MS, it is more like the vendors pandering Linux that is.

Also I develop on OpenJDK, I was wondering if you could provide a list of patents that the OpenJDK is infringing on? I'm sure we could work out what it is that you feel is something we may have overlooked.

Mono is way ahead of languages like Java in that regard because, unlike Java, Mono is based on an open standard

Could you clear that up? I'm not sure I follow what you are talking about. Is it because .NET is a standard through an organized body? Whereas, Java is basically a community process with Sun at the head of the community? If this is your beef with Java then what exactly is different between how Java is made versus something like, Linux or GNU HURD?

Besides, what is all this seemingly bad blood between .NET and Java? I've been to many PDCs and the people behind .NET seem pretty accepting of Java much like the Samba - Microsoft love (which granted isn't awesome but it is still pretty good). Also, the Mono devs are pretty cool people on IRC. Really? Do we need to build walls?

Perhaps Debian doesn't believe that Microsoft might do something like Rambus did.

Rambus was chastised for their actions (like the linked article states). And I propose Debian approach this the same way someone would approach the Rambus situation from the beginning had they an inkling of Rambus' true intent.

Even though Microsoft submitted the CLI and C# main components of .NET, MIcrosoft does hold at least one patent on the .NET infrastructure. So far, Microsoft has agred to offer these under a "reasonable and non-discriminatory (RAND) terms of use" and they are currently royalty free. No one seems to be clear on how you get this into writing but it's allegedly the way things are.

Were I a Debian leader, I would simply approach Microsoft with the Mono code and the ECMA code of conduct and demand it in writing that for this snapshot of the code you have a forever royalty free to interact with .NET. Should they fail to comply with this request in a timely manner, I would submit all communications with Microsoft to ECMA in a motion to dismiss the aforementioned "standards" and remove Mono--and unfortunately Tomboy--from the Debian default package. I'd beef up the Debian wiki with details on how to get these two packages to fix this bug and focus on the bug for a near future release after Squeeze.

At that point, sit back and let ECMA and the community at large hash it out with Microsoft. Better now than later when other things may depend on this package and Microsoft has you right where Rambus has every memory maker on the planet.

Perhaps Debian doesn't believe that Microsoft might do something like Rambus did.

Rambus was chastised for their actions (like the linked article states). And I propose Debian approach this the same way someone would approach the Rambus situation from the beginning had they an inkling of Rambus' true intent.

Even though Microsoft submitted the CLI and C# main components of .NET, MIcrosoft does hold at least one patent on the .NET infrastructure. So far, Microsoft has agred to offer these under a "reasonable and non-discriminatory (RAND) terms of use" and they are currently royalty free. No one seems to be clear on how you get this into writing but it's allegedly the way things are.

Were I a Debian leader, I would simply approach Microsoft with the Mono code and the ECMA code of conduct and demand it in writing that for this snapshot of the code you have a forever royalty free to interact with .NET. Should they fail to comply with this request in a timely manner, I would submit all communications with Microsoft to ECMA in a motion to dismiss the aforementioned "standards" and remove Mono--and unfortunately Tomboy--from the Debian default package. I'd beef up the Debian wiki with details on how to get these two packages to fix this bug and focus on the bug for a near future release after Squeeze.

At that point, sit back and let ECMA and the community at large hash it out with Microsoft. Better now than later when other things may depend on this package and Microsoft has you right where Rambus has every memory maker on the planet.

Perhaps Debian doesn't believe that Microsoft might do something like Rambus did.

Rambus was chastised for their actions (like the linked article states). And I propose Debian approach this the same way someone would approach the Rambus situation from the beginning had they an inkling of Rambus' true intent.

Even though Microsoft submitted the CLI and C# main components of .NET, MIcrosoft does hold at least one patent on the .NET infrastructure. So far, Microsoft has agred to offer these under a "reasonable and non-discriminatory (RAND) terms of use" and they are currently royalty free. No one seems to be clear on how you get this into writing but it's allegedly the way things are.

Were I a Debian leader, I would simply approach Microsoft with the Mono code and the ECMA code of conduct and demand it in writing that for this snapshot of the code you have a forever royalty free to interact with .NET. Should they fail to comply with this request in a timely manner, I would submit all communications with Microsoft to ECMA in a motion to dismiss the aforementioned "standards" and remove Mono--and unfortunately Tomboy--from the Debian default package. I'd beef up the Debian wiki with details on how to get these two packages to fix this bug and focus on the bug for a near future release after Squeeze.

At that point, sit back and let ECMA and the community at large hash it out with Microsoft. Better now than later when other things may depend on this package and Microsoft has you right where Rambus has every memory maker on the planet.

Silverlight is essentially .NET bytecode + XAML markup + media .NET ECMA spec: http://www.ecma-international.org/publications/standards/Ecma-335.htm

Silverlight XAML spec (under Open Specification Promise):
http://blogs.windowsclient.net/rob_relyea/archive/2008/10/14/ms-slxv-silverlight-xaml-vocabulary-2008-specification-v0-9-published.aspx

Media is MPEG-4 or MP3 (ISO), Windows Media (VC-1 is a SMPTE spec), and the Raw AV pipeline for extensitbilty to aribtrary codecs.

As for interoperabilty and portability, how about a GPL'ed clean room implementation?
http://www.mono-project.com/Moonlight

But compare to Adobe's covenant not to sue users of Gnash...

Adobe has no grounds to sue gnash/swfdecode, its an implementation based on an open standards.

Microsoft has a stockpile of software patents and are known to threaten people with them (although I'm yet to see them go after anybody that could defend themselves).

It doesn't have any ramifications one way or another for any part not listed.

While it may not set a legal president, it has the clear ramification that they have patents and the implicit ramification that these patents are valid (much like the outcome recent tomtom case).

so now you know you won't be sued for using Moonlight

It offers no protection for users moonlight on non-novell distros, while the agreement seams to take care to protect end-users, that is fairly pointless as it also takes care to leave the door open to attacks against canonical/red hat/etc. I am also not protected if i run a modified version (e.g if i need to patch it to get it to work), as i did not receive my copy from novell.But most importantly the agreement expires in 2011.

So you have to choose who you trust more:
Adobe- a company who AFAIK are yet to patent anything that gnash would violate, and are fairly open source friendly.
Microsoft - a company who have made it clear that they have patents they think moonlight violates, and are fairly bipolar when it comes to open source, offering temporary protection to a tiny subset of users.

Yes moonlight is OSS and that's great, but I don't want to be trusting Microsoft to NOT attack Linux, so ill take a closed flash player and push for more openness (html4 and gnash) over moonlight where i can.

so i stand by my statements:
If you want suggestions on how to open up silverlight, then waiving the right to sue any distributor of any open source implementation, permanently is the way to go. Until then moonlight is not much better than flash.

Er, no?

While Moonlight is a Novell product based on Mono, GPL'ed and all that, it also gets support from Microsoft in providing unit tests and that kind of thing.

And there's this agreement explicitly waiving the right to sue users of Moonlight getting it from Novell:
http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx

I think of Silverlight as having three pillars: .NET runtime, XAML, and media.

C# and the .NET CLI are both ECMA specs:
http://www.ecma-international.org/publications/standards/Ecma-335.htm
http://www.ecma-international.org/publications/standards/Ecma-334.htm

The specification for XAML has been published under the Open Specification Promise:
http://www.betanews.com/article/XAML-specification-published-added-to-Microsofts-open-promise/1206482161

And for media formats, Silverlight 3 supports:
WMV (VC-1 is a SMPTE standard, other components under RAND licensing)
MPEG-4 with H.264 and AAC-LC (ISO spec)
MP3 (ISO spec)
Generic extensibility via Raw AV MediaStreamSource

There's even a royalty-paid codec pack for Moonlight provided by Microsoft.

If you've got practical suggestions for how we could be more open than this, I'd love to hear them, but I think there has already been a lot of traction in that direction. It certainly goes well beyond what Adobe does for Gnash, and Moonlight is already capable of handling many more high-profile Silverlight sites than any non-Adobe Flash player is. Even:

http://www.smoothhd.com/

Er, no?

While Moonlight is a Novell product based on Mono, GPL'ed and all that, it also gets support from Microsoft in providing unit tests and that kind of thing.

And there's this agreement explicitly waiving the right to sue users of Moonlight getting it from Novell:
http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx

I think of Silverlight as having three pillars: .NET runtime, XAML, and media.

C# and the .NET CLI are both ECMA specs:
http://www.ecma-international.org/publications/standards/Ecma-335.htm
http://www.ecma-international.org/publications/standards/Ecma-334.htm

The specification for XAML has been published under the Open Specification Promise:
http://www.betanews.com/article/XAML-specification-published-added-to-Microsofts-open-promise/1206482161

And for media formats, Silverlight 3 supports:
WMV (VC-1 is a SMPTE standard, other components under RAND licensing)
MPEG-4 with H.264 and AAC-LC (ISO spec)
MP3 (ISO spec)
Generic extensibility via Raw AV MediaStreamSource

There's even a royalty-paid codec pack for Moonlight provided by Microsoft.

If you've got practical suggestions for how we could be more open than this, I'd love to hear them, but I think there has already been a lot of traction in that direction. It certainly goes well beyond what Adobe does for Gnash, and Moonlight is already capable of handling many more high-profile Silverlight sites than any non-Adobe Flash player is. Even:

http://www.smoothhd.com/

Plenty of info here:

http://en.wikipedia.org/wiki/Office_Open_XML

and here:

http://www.ecma-international.org/publications/standards/Ecma-376.htm

Go easy on them. Have you seen the OOXML standard?? That thing is freaking enormous. They'll be working on the basics for several years, after which they'll ship a half baked implementation and pray that future patches plug the holes.

I can't wait until this becomes available though -- just imagine, an open format to share documents in, easily implementable by different vendors. It should be great.

ECMA, you mean the Oooopen XML ISO fast-track scam machine "ECMA International".

Why don't they publish the specification on their servers down in Redmond instead? Do the standard developers have a girl friend in Geneva? Or do they think it is more fun with free beer parties with Mozilla?

And finally, what has the current hugging to do with what goes on in Brussels?

XPS is proprietary.

XPS is not proprietary. It is currently being finalized by ECMA as Open XPS.

And the specs to see what needs to be complied to? Oh wait...

here it is. http://www.ecma-international.org/publications/standards/Ecma-335.htm

Unless you meant the spec for XAML, which you could find at http://robrelyea.com/silverlight/xvSpec

Or perhaps the SMPTE spec for VC-1 ala http://www.smpte.org/news/pr/view?item_key=a135f13b173a982bb71f1cd3ee4403671fcf2057

C# definition is openly "specified" (ECMA), not openly sourced. Mono provides the open implementation for this specification.

http://www.ecma-international.org/publications/standards/Ecma-334.htm

You mean there is no ECMA standard about .NET and you can't write a clone without a deal with Microsoft?

Its all ECMA's fault!

We need "interoperability" only in as much as benefits our cause.

Then your cause will continue to flounder and suck. Isn't that so awesome?!

Microsoft is hostile to open source and Linux.

There's a fairly significant cultural shift going on at Microsoft. They've got a considerable amount of code under permissive open source licenses (you do recall that the Ms-PL and Ms-RL are OSI-approved licenses, right?), and, more importantly, they're getting behind open standards. Personally, I don't give a shit whether they go open source so long as they adhere to standards; their current direction as a company is indicating considerably more support for open standards, and they should be applauded for such.

Unfortunately, it seems like the zealots, as per their M.O., are unable to recognize progress. Just more paranoia and vitriol. It's interesting.

mono and moonbat are not a "must haves" yet, and supporting them is a mistake that undercuts the competitive environment.

Really! It undercuts the competitive environment by being another choice? Interesting...sounds like insecurity.

We should be driving open and usable standards, not the convicted monopolist.

Hi there, open standard!

Ok, time to throw some karma on the fire. Silverlight supports vector graphics. If you ask for the spec on the Silverlight vector graphics, MS will direct you to the XPS spec. In there you will find a very complete 2D graphic markup specification that will look a lot like SVG (in fact converting SVG to XPS is fairly trivial). This is a legitimate specification that is currently be made into an open standard (TC46). I know bashing Microsoft is a popular pastime on Slashdot (and most of the time they deserve it). But sometimes, MS does the right thing (e.g. DirectX and Silverlight) -- perhaps only be accident, but still.

You mean like a formal standard for the language? That's ECMAScript. Do you mean a standard way of interfacing with the browser? That would be DOM. Or do you mean some practical tests of scripting to ensure that different browsers behave consistently? Sounds like Acid3.

I wholeheartedly agree with Brendan that we should at any cost stop JavaScript in particulat and Ecmascript in general from being as painful as Java in any way possible. However what we should do is not only improving all of the ECMA-262 derivatives but to make a systematical progress towards better flexibility and interoperability of various scripting approaches in the future. Take for example the wonderful project by Mehmet Yavuz Selim Soyturk called PJS which is an important step in the direction to allow the Parrot virtual machine, designed to run Perl, Tcl, Javascript, Ruby, Lua, Scheme, Befunge, Lisp, PHP, Python, Perl 6, APL, Java, .NET, et al., to run on JavaScript, so all of those languages could be used together to enhance your browsing experience on the Web. For this to be even remotely plausible the JavaScript must be as flexible and as fast as possible because it would basically mean running high-level language code compiled to the Parrot intermediate representation (PIR, or IMC), that converted to the Parrot assembly language, assembled, linked, converted to Parrot bytecode and then execuded on the Parrot virtual machine or PVM which would itself be a large JavaScript interpreted script running in a Web browser, running in the operating system... You get the picture. A logical step forward would be to include PVM in all of the major browsers to run the Parrot bytecode natively and efficiently in the browser. There are already plans to include PVM interpreter in Firefox which means it will be available as a viable target for scriping dynamic html pages for all of its derivatives like Camino, Galeon and Konqueror. Hopefully the commercial browsers would follow (the Artistic license is not anti-commercial like GPL so there should be no legal problems with the integration). I really look forward to the future of perfect interoperability when every single Web page could potentially run scripts written in literally dozens of programming languages simultaneously. One day we will experience that synergy thanks to people like Brendan Eich,Mehmet Yavuz Selim Soyturk, Larry Wall, et al. if they only agree to work together on one common solution to the big mess of Web scripts that we have today. Let's all hope they will.

It's because Microsoft has always been unable to provide upwards compatible specifications. Let's look at the Microsoft-related standards that have been issued by the ECMA (European Computer Manufacturer's Association), they're all free downloads:

OOXML, 1st ed., Dec. 2006
CLI, 4th ed., Jun. 2006; see also TR/84, TR/89
Managed C++, 1st ed., Dec. 2005
C#, 4th ed., Jun. 2006
Windows API, Dec. 1995 (Windows 3.1 API)

Let's note that in those areas, in which Microsoft wished for stronger support by the industry, there are standards. The .NET standards might also be a result of the first ruling of the EU court in the antitrust case (2004).

Note that the Windows API standard was never updated.

The first edition of OOXML is already one and a half years old, and typical development by Microsoft probably introduced new elements that deviate from the standard. What they need to do now, is to update the OOXML standard to a second edition that is compatible with Office 2007.

Every standard is behind current developments if standards are not being followed.

If you look at the C and C++ standards, you'll see how long it took until they were adopted by the software industry (some compilers still aren't fully compliant, like Microsoft Visual C++: in VC++ 2008, "stdint.h" and "stdbool.h" are missing, for example).

It's because Microsoft has always been unable to provide upwards compatible specifications. Let's look at the Microsoft-related standards that have been issued by the ECMA (European Computer Manufacturer's Association), they're all free downloads:

OOXML, 1st ed., Dec. 2006
CLI, 4th ed., Jun. 2006; see also TR/84, TR/89
Managed C++, 1st ed., Dec. 2005
C#, 4th ed., Jun. 2006
Windows API, Dec. 1995 (Windows 3.1 API)

Let's note that in those areas, in which Microsoft wished for stronger support by the industry, there are standards. The .NET standards might also be a result of the first ruling of the EU court in the antitrust case (2004).

Note that the Windows API standard was never updated.

The first edition of OOXML is already one and a half years old, and typical development by Microsoft probably introduced new elements that deviate from the standard. What they need to do now, is to update the OOXML standard to a second edition that is compatible with Office 2007.

Every standard is behind current developments if standards are not being followed.

If you look at the C and C++ standards, you'll see how long it took until they were adopted by the software industry (some compilers still aren't fully compliant, like Microsoft Visual C++: in VC++ 2008, "stdint.h" and "stdbool.h" are missing, for example).

It's because Microsoft has always been unable to provide upwards compatible specifications. Let's look at the Microsoft-related standards that have been issued by the ECMA (European Computer Manufacturer's Association), they're all free downloads:

OOXML, 1st ed., Dec. 2006
CLI, 4th ed., Jun. 2006; see also TR/84, TR/89
Managed C++, 1st ed., Dec. 2005
C#, 4th ed., Jun. 2006
Windows API, Dec. 1995 (Windows 3.1 API)

Let's note that in those areas, in which Microsoft wished for stronger support by the industry, there are standards. The .NET standards might also be a result of the first ruling of the EU court in the antitrust case (2004).

Note that the Windows API standard was never updated.

The first edition of OOXML is already one and a half years old, and typical development by Microsoft probably introduced new elements that deviate from the standard. What they need to do now, is to update the OOXML standard to a second edition that is compatible with Office 2007.

Every standard is behind current developments if standards are not being followed.

If you look at the C and C++ standards, you'll see how long it took until they were adopted by the software industry (some compilers still aren't fully compliant, like Microsoft Visual C++: in VC++ 2008, "stdint.h" and "stdbool.h" are missing, for example).

It's because Microsoft has always been unable to provide upwards compatible specifications. Let's look at the Microsoft-related standards that have been issued by the ECMA (European Computer Manufacturer's Association), they're all free downloads:

OOXML, 1st ed., Dec. 2006
CLI, 4th ed., Jun. 2006; see also TR/84, TR/89
Managed C++, 1st ed., Dec. 2005
C#, 4th ed., Jun. 2006
Windows API, Dec. 1995 (Windows 3.1 API)

Let's note that in those areas, in which Microsoft wished for stronger support by the industry, there are standards. The .NET standards might also be a result of the first ruling of the EU court in the antitrust case (2004).

Note that the Windows API standard was never updated.

The first edition of OOXML is already one and a half years old, and typical development by Microsoft probably introduced new elements that deviate from the standard. What they need to do now, is to update the OOXML standard to a second edition that is compatible with Office 2007.

Every standard is behind current developments if standards are not being followed.

If you look at the C and C++ standards, you'll see how long it took until they were adopted by the software industry (some compilers still aren't fully compliant, like Microsoft Visual C++: in VC++ 2008, "stdint.h" and "stdbool.h" are missing, for example).

It's because Microsoft has always been unable to provide upwards compatible specifications. Let's look at the Microsoft-related standards that have been issued by the ECMA (European Computer Manufacturer's Association), they're all free downloads:

OOXML, 1st ed., Dec. 2006
CLI, 4th ed., Jun. 2006; see also TR/84, TR/89
Managed C++, 1st ed., Dec. 2005
C#, 4th ed., Jun. 2006
Windows API, Dec. 1995 (Windows 3.1 API)

Let's note that in those areas, in which Microsoft wished for stronger support by the industry, there are standards. The .NET standards might also be a result of the first ruling of the EU court in the antitrust case (2004).

Note that the Windows API standard was never updated.

The first edition of OOXML is already one and a half years old, and typical development by Microsoft probably introduced new elements that deviate from the standard. What they need to do now, is to update the OOXML standard to a second edition that is compatible with Office 2007.

Every standard is behind current developments if standards are not being followed.

If you look at the C and C++ standards, you'll see how long it took until they were adopted by the software industry (some compilers still aren't fully compliant, like Microsoft Visual C++: in VC++ 2008, "stdint.h" and "stdbool.h" are missing, for example).

It's because Microsoft has always been unable to provide upwards compatible specifications. Let's look at the Microsoft-related standards that have been issued by the ECMA (European Computer Manufacturer's Association), they're all free downloads:

OOXML, 1st ed., Dec. 2006
CLI, 4th ed., Jun. 2006; see also TR/84, TR/89
Managed C++, 1st ed., Dec. 2005
C#, 4th ed., Jun. 2006
Windows API, Dec. 1995 (Windows 3.1 API)

Let's note that in those areas, in which Microsoft wished for stronger support by the industry, there are standards. The .NET standards might also be a result of the first ruling of the EU court in the antitrust case (2004).

Note that the Windows API standard was never updated.

The first edition of OOXML is already one and a half years old, and typical development by Microsoft probably introduced new elements that deviate from the standard. What they need to do now, is to update the OOXML standard to a second edition that is compatible with Office 2007.

Every standard is behind current developments if standards are not being followed.

If you look at the C and C++ standards, you'll see how long it took until they were adopted by the software industry (some compilers still aren't fully compliant, like Microsoft Visual C++: in VC++ 2008, "stdint.h" and "stdbool.h" are missing, for example).

It's because Microsoft has always been unable to provide upwards compatible specifications. Let's look at the Microsoft-related standards that have been issued by the ECMA (European Computer Manufacturer's Association), they're all free downloads:

OOXML, 1st ed., Dec. 2006
CLI, 4th ed., Jun. 2006; see also TR/84, TR/89
Managed C++, 1st ed., Dec. 2005
C#, 4th ed., Jun. 2006
Windows API, Dec. 1995 (Windows 3.1 API)

Let's note that in those areas, in which Microsoft wished for stronger support by the industry, there are standards. The .NET standards might also be a result of the first ruling of the EU court in the antitrust case (2004).

Note that the Windows API standard was never updated.

The first edition of OOXML is already one and a half years old, and typical development by Microsoft probably introduced new elements that deviate from the standard. What they need to do now, is to update the OOXML standard to a second edition that is compatible with Office 2007.

Every standard is behind current developments if standards are not being followed.

If you look at the C and C++ standards, you'll see how long it took until they were adopted by the software industry (some compilers still aren't fully compliant, like Microsoft Visual C++: in VC++ 2008, "stdint.h" and "stdbool.h" are missing, for example).

It's because Microsoft has always been unable to provide upwards compatible specifications. Let's look at the Microsoft-related standards that have been issued by the ECMA (European Computer Manufacturer's Association), they're all free downloads:

OOXML, 1st ed., Dec. 2006
CLI, 4th ed., Jun. 2006; see also TR/84, TR/89
Managed C++, 1st ed., Dec. 2005
C#, 4th ed., Jun. 2006
Windows API, Dec. 1995 (Windows 3.1 API)

Let's note that in those areas, in which Microsoft wished for stronger support by the industry, there are standards. The .NET standards might also be a result of the first ruling of the EU court in the antitrust case (2004).

Note that the Windows API standard was never updated.

The first edition of OOXML is already one and a half years old, and typical development by Microsoft probably introduced new elements that deviate from the standard. What they need to do now, is to update the OOXML standard to a second edition that is compatible with Office 2007.

Every standard is behind current developments if standards are not being followed.

If you look at the C and C++ standards, you'll see how long it took until they were adopted by the software industry (some compilers still aren't fully compliant, like Microsoft Visual C++: in VC++ 2008, "stdint.h" and "stdbool.h" are missing, for example).

I do love Slashdot, but the apparent wish of the entire community to remain wilfully and childishly ignorant, insofar as Microsoft is concerned, is really quite disturbing.

The fact that content-free posts like " OOXML is such a foul, repugnant anti-standard " are repeatedly modded 'insightful' -- as are the myrad identical "OOXML is unimplementable because it includes undocumented tagss like autoSpaceLikeWord95" replies that inundate anyone who dares question the dogma of OOXMLBADBADBAD -- whereas any posts, such as the parent, which try to point out that autoSpaceLikeWord95 is actually documented perfectly well (albeit in the appendix rather than the main body due to its status as deprecated, as mandated by the ECMA), and give the relevent part of the spec are quickly modded down to Score: 0 and stay there...

It does make you wonder how many people are just ignorant, merely repeating what everyone else is saying because they haven't read the spec themselves (it is, after all, quite long); and how many are actually perfectly aware of the relevent facts but just don't like them.

It does in the version of spec approved by ISO (just search for "autoSpaceLikeWord95" in the web page at the link).

I haven't seen a Wraplineslikeword95 but I have seen AutoSpaceLikeWord95 which was deprecated a while ago. http://www.ecma-international.org/news/TC45_current_work/New%20proposed%20dispositions%20extend%20progress%20in%20addressing%20all%20National%20Body%20comments.htm Unless your converter has to convert Word95 documents I don't see why you would need to implement that to have a compliant converter.

Released

http://www.ecma-international.org/news/TC45_current_work/ISO_and_IEC_approve_Office_Open_XML.htm

http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf

OOXML:

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%201%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%202%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%203%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%204%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%205%20(PDF).zip

http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf

OOXML:

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%201%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%202%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%203%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%204%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%205%20(PDF).zip

http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf

OOXML:

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%201%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%202%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%203%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%204%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%205%20(PDF).zip

http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf

OOXML:

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%201%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%202%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%203%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%204%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%205%20(PDF).zip

http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf

OOXML:

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%201%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%202%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%203%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%204%20(PDF).zip

http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%20Part%205%20(PDF).zip

The Acid3 test is a NEW test that uses/tests the NEW feature that the CSS3 intoduces.

Let's do exactly what you suggest, and "RTFM". From the Acid3 page at webstandards.org, with links to the specifications and dates added by me:

Here is the list of specifications tested:

• DOM2 Core [specification published in 2000.]
• DOM2 Events [specification published in 2000.]
• DOM2 HTML [specification published in 2003.]
• DOM2 Range [specification published in 2000.]
• DOM2 Style (getComputedStyle, ...) [specification published in 2000.]
• DOM2 Traversal (NodeIterator, TreeWalker) [specification published in 2000.]
• DOM2 Views (defaultView) [specification published in 2000.]
• ECMAScript [specification published in 1997, although I could only locate the third edition, published in 1999.]
• HTML4 (<object>, <iframe>, ...) [specification published in 1997.]
• HTTP (Content-Type, 404, ...) [specification published in 1999.]
• Media Queries [specification published in 2002.]
• Selectors (:lang, :nth-child(), combinators, dynamic changes, ...) [specification published in 2001 , with some of it part of the CSS 2.0 specification published in 1998 .]
• XHTML 1.0 [specification published in 2000.]
• CSS2 (@font-face) [specification published in 1998.]
• CSS2.1 ('inline-block', 'pre-wrap', parsing...) [specification published in 2007.]
• CSS3 Color (rgba(), hsla(), ...) [specification published in 2003.]
• CSS3 UI ('cursor') [specification published in 2004.]
• data: URIs [specification published in 1998.]
• SVG (SVG Animation, SVG Fonts, ...) [specification published in 2001.]

As you can see, the majority of the Acid3 test is comprised of behaviour described in specifications published years ago, with a substantial portion of them over five years old and some over a decade old.

CSS3 intoduces many changes,

Actually, CSS 3 is not a single specification, but a group of

No, Mac users can use silverlight, and have been able to for quite some time. Linux users will be able to use it soon, although I don't know about licensing and patents.

So, from a user's perspective, this is irrelevant. The concern in this new technology is on the server side of things, and in Microsoft's market position. Silverlight's purpose in life is to dynamically load xml within the DOM tree, which should sound familiar since that is essentially what Ajax does. Ajax, however, has some short comings, for which the w3c developed the E4X standard.

However, given the high quality of web applications written in Ajax, Microsoft rightly assessed that E4X threatened their office and email monopolies, and therefore their OS monopoly, because such applications are platform-agnostic. It is no coincidence that MS really started to push Silverlight development shortly after Google started testing high quality Ajax-based office, email and collaboration software.

Therefore, IE, which is already pretty non-standards compliant in its javascript syntax, still does not support it at all, although all other major browsers have for years. By creating and promoting silverlight, MS is essentially embracing and extending to get control of dynamic web page standards away from the w3c. They will try to promote silverlight in as many places as possible, and hobble Ajax in IE. They will develop a series of neat free tools that make it easy to develop in silverlight. Once there is a critical mass of pages that use silverlight, they will start to make "improvements" to the standard but only integrate those changes into their Windows plugin. When that happens, all web users will once again be locked into Microsoft. It will MS will also have the bonus of also being able to integrate features that depend on asp, forcing their way into the server market.

If you don't believe MS would use a strategy like this, just ask yourself why there was an IE5.5 for Macs and no IE6 for Macs.

Thus, improvements in technology that should be happening around an open standards making body, indeed would happen faster and more effeciently in this standards making body, are going to go into the hands of one company at proceed at a much slower rate. It's a classic embrace/extend/extinguish. It is just sad that the US government is supporting this.

So what you're saying is that before Microsoft can get on with business in Europe they are required to spend some of the money they made from their illegal monopoly practises there? Wow, that's so unfair!

As for pouring time and effort into producing vast amounts of documentation that is of no real use to anyone, I thought Microsoft was a big fan .

Everybody who cares to look already knows that ODF is about IBM's business AND the pubic good.

Yeah, but.. " Microsoft executives have accused the rest of the world of leading the campaign against their initiative to have Office Open XML approved by the International Organization for Standardization. " doesn't have the right spin.

I've downloaded and looked at the MSOOXML spec and I thought it was some kind of insult. I seriously invite everyone who has ever read a spec, and who still doubts how bad this one really is, to download the 38 Mb PDF file from .. oh wait.. it's not there anymore.. now probably from ECMA-376 and you probably want the ZIP file "ECMA-376 part 4" (warning, 32 Mb) and also get the 2000+ pages of errata from ECMA which the countries have to read in the next 2 weeks before they get to have a final vote at the ballot resolution meeting.

You want the file titled "Office Open XML Part 4 - Markup Language Reference.pdf".

A copy of the 2200 page PDF file of criticisms can be downloaded from here.

Frankly, you can get a good laugh out of all the stuff about 1900 and 1904 date systems (response 43, I quote CH-0007

"Software bugs should be fixed, not exported by ISO standards to the programs of competitors."

) and the mathematically wrong CEILING function (response 30 p. 121),

But I believe this is the one "killer question" that the BRM should consider discussing for those 5 days: Response 31 on p. 122 (211) to questions BE-0001, CH-0013, CL-0001, DE-0119, KR-0001, NZ-0003, PE-0010, ZA-0003

Basically, AFAIK, the comments are "We already have ODF, why do we need OOXML?" and the proposed solutions are of the gist "Develop OOXML starting from ODF". This is ECMA's response:

Proposed Disposition

There are currently several XML-based document formats in use, each designed to address a different set of goals or requirements. These include ISO/IEC IS 26300 (ODF), China's UOF, and ECMA-376 (DIS 29500 Open XML). All these formats have numerous implementations in multiple tools and multiple platforms (Linux, Windows, Mac OS, hand-held devices).

The Ecma Response Document from the Fast Track 30-Day contradiction phase for DIS29500 addressed the question of harmonization by explaining the differences between the ODF and Open XML formats as follows:

"... one must recognize that creating a single "merged" format to address the user requirements of both ODF and OpenXML is a much more difficult goal--one that is hindered by fundamental obstacles comparable to what one might encounter while merging HTML and ODF or HTML and PDF. This is because of sheer difference of scope, feature and architecture. Ecma believes that one format cannot simultaneously meet the requirements that would come from the merge of the two formats and the stringent requirements of backward compatibility that drive the design of OpenXML.

First, while both formats share the high-level goal, to represent documents, presentations, and spreadsheets in XML, their low-level goals differ fundamentally. OpenXML is designed to represent the existing corpus of documents faithfully, even if that means preserving idiosyncrasies that one might not choose given the luxury of starting from a clean slate. In the ODF design, compatibility with and preservation of existing Office documents were not goals. Each set of goals is valuable; sacrificing either at the expense of the other may not be in the best interest of users.

Second, the resulting differences are not merely variances in scope that could be resolved by adding capabilities to one or the other. They are structural and architectural in nature

• If they win they don't have a product which supports the improved OOXML standard and the standard is much more open to others.
• If they loose they don't have an office suite that supports an ISO certified standard.

Microsoft is fucking scared right now because neither MS Office 2007 nor the 2003 plugin support the version of OOXML which is the version that may be approved by ISO... that is with all the corrections made by ECMA after the last vote.
I'm btw. shocked that neither /. nor Groklaw has anything about the corrected OOXML case.

A CD is any plastic disc with pits on a reflective layer physically organized in a manner conforming to the requirements set forth by Philips and Sony. If I buy Britney's latest "CD" at the store, guess what. It really is a CD.