Slashdot Mirror

I was always under the impression that .NET was strictly for windows, and MS was intentionally shutting out Linux and Mac from using .NET.

I was always under the impression that .NET was strictly for windows, and MS was intentionally shutting out Linux and Mac from using .NET.

I doubt the ECMA would approve both and allow a patent bomb.

According to the ECMA Code of Conduct in Patent Matters there is no requirement that any relevant that patents pertaining be opened, merely that they are made available for licence under Reasonable And Non Discriminatory (RAND) terms.

The problem here is that RAND is not further defined, meaning that a company like MS can charge a peppercorn licence fee, and still place the licences out of the reach of FOSS projects who can't pass on the overheads to their customers.

Additionally, ECMA don't seem require the patents to be actually licenced, they just require a statement of policy from the patent holder. If the patent holder later declines to issue the patent, they may be excluded from further participation in that committee, but by that stage you could still have a whole hell of a lot of deeply entrenched patent violations, so I don't take much comfort from that provision.

Oh, and if they ask the patent holder if they have any undisclosed patents, and the holder doesn't respond, the technical committee is free to vote on adoption, and therefore presumably adopt, the standard anyway.

So, as it turns out, there's absolutely nothing in the ECMA procedures prohibiting patent bombs, at least in so far as Free Software is concerned.

IANAL, Groklaw has a bunch of them who examined this in detail at the time of the Massachusetts ODF flap. Check it out!

What Wikipedia says on javascript. Here's an excerpt that may interest some:

The standardization effort for JavaScript also needed to avoid trademark issues, so the ECMA 262 standard calls the language ECMAScript, three editions of which have been published since the work started in November 1996. The object model of browser-based JavaScript, the Document Object Model (DOM), is not part of the ECMAScript standard. It is defined in a set of separate standards developed by the W3C, and is applicable to the access and manipulation of HTML and XML documents in many computer languages and platforms.

if you look up ECMA, you will see a lot of browsers listed supporting the ECMA262 standard.

Here is a pdf on the ECMA262 spec. Warning: it's a big long winded, but it's pretty detailed. Good spec.

Anyway here's how the ECMA feels about patents: http://www.ecma-international.org/memento/codeofco nduct.htm . Note the liberal use of the word "should" and "reasonable". It seems unlikely the members of the ECMA who vote on such things, the ordinary members (list: http://www.ecma-international.org/memento/ordinary .htm ) have the same understanding of those words than you or I do. Even if they did, there's an escape clause:

Members who have not taken part in the technical work on a Standard are encouraged to vote in its favour in the General Assembly. The provisions of clause 2 of the Code of Conduct are not intended to discourage such supportive action and, therefore, do not require members to undertaken a detailed patent search in this situation. However, known rights should be claimed.

So if a majority of the members (see the list above) didn't work on a Standard, they're encouraged to vote in favor of it. Since the majority of that list has no interest in Office document minutiae, adoption of whatever standard Microsoft proposed seems predictable. Further, if they can't get a company to commit to being reasonable about licensing their patents, they assume the company will be reasonable at least to the other members (see that list again).

Anyway, if you don't care about patents, here's a list http://www.ecma-international.org/publications/sta ndards/Standard.htm of their standards.

Anyway here's how the ECMA feels about patents: http://www.ecma-international.org/memento/codeofco nduct.htm . Note the liberal use of the word "should" and "reasonable". It seems unlikely the members of the ECMA who vote on such things, the ordinary members (list: http://www.ecma-international.org/memento/ordinary .htm ) have the same understanding of those words than you or I do. Even if they did, there's an escape clause:

Members who have not taken part in the technical work on a Standard are encouraged to vote in its favour in the General Assembly. The provisions of clause 2 of the Code of Conduct are not intended to discourage such supportive action and, therefore, do not require members to undertaken a detailed patent search in this situation. However, known rights should be claimed.

So if a majority of the members (see the list above) didn't work on a Standard, they're encouraged to vote in favor of it. Since the majority of that list has no interest in Office document minutiae, adoption of whatever standard Microsoft proposed seems predictable. Further, if they can't get a company to commit to being reasonable about licensing their patents, they assume the company will be reasonable at least to the other members (see that list again).

Anyway, if you don't care about patents, here's a list http://www.ecma-international.org/publications/sta ndards/Standard.htm of their standards.

Anyway here's how the ECMA feels about patents: http://www.ecma-international.org/memento/codeofco nduct.htm . Note the liberal use of the word "should" and "reasonable". It seems unlikely the members of the ECMA who vote on such things, the ordinary members (list: http://www.ecma-international.org/memento/ordinary .htm ) have the same understanding of those words than you or I do. Even if they did, there's an escape clause:

Members who have not taken part in the technical work on a Standard are encouraged to vote in its favour in the General Assembly. The provisions of clause 2 of the Code of Conduct are not intended to discourage such supportive action and, therefore, do not require members to undertaken a detailed patent search in this situation. However, known rights should be claimed.

So if a majority of the members (see the list above) didn't work on a Standard, they're encouraged to vote in favor of it. Since the majority of that list has no interest in Office document minutiae, adoption of whatever standard Microsoft proposed seems predictable. Further, if they can't get a company to commit to being reasonable about licensing their patents, they assume the company will be reasonable at least to the other members (see that list again).

Anyway, if you don't care about patents, here's a list http://www.ecma-international.org/publications/sta ndards/Standard.htm of their standards.

From the Wikipedia page:

For over forty years Ecma has actively contributed to world-wide standardization in information technology and telecommunications.

which, if it "isn't much more than a Microsoft rubber stamp" means they must have been twiddling their thumbs for quite a few years waiting for Microsoft to be founded.

Have a look at their list of standards; as far as I know, Microsoft make no claim to be the originators of Corporate Telecommunication Networks - Signalling Interworking between QSIG and H.323 - Generic Functional Protocol for the Support of Supplementary Services, Eiffel: Analysis, Design and Programming Language or File Structure and Labelling of Magnetic Tapes for Information Interchange.

On the top of my head: EMCAScript, Eiffel. See for yourself.

``C# isn't bad as a language, but it's Microsoft-only and too closely tied to Microsoft's run-time environment, which is too limiting.''

Is it really? I was under the impression that C# was an ECMA standard and had a number of non-Microsoft implementations.

Except that in a separate covenant they agreed not to sue anyone using the Office XML spec.

More information here. Basically it's an irrevocable agreement to not sue you over patents, provided that you do not sue them over any patents as well. This actually applies to a variety of web services specifications, the VHD format (Virtual PC's hard drive format), as well as Office 2003's XML format and Office 2007's formats. Also note that Office 2007 file formats have been submitted for Ecma standardization. You can read a final draft here.

OK, enough FUD, time for some cold hard facts:

Open XML is *NOT* proprietary See for yourself: http://www.ecma-international.org/memento/TC45-M.h tm

ODF is *JUST* as patent encumbered as Open XML is.

The owners of both ODF and Open XML do not and will not collect royalties (both have published a covenant not to sue)
Sun: http://www.oasis-open.org/committees/office/ipr.ph p
MS: http://www.microsoft.com/interop/osp/default.mspx
Non-Legalese Explanation: http://www.bakernet.com/NR/rdonlyres/CC54A6B6-79E8 -4E0D-B290-C836D5F70867/0/OpenXML.pdf

To implement either standard, a developer need not accept any kind of licensing agreement whatsoever.

A user, using software that implements either standard, does not have to accept any licensing agreement that covers the either respective format's standard.

Thanks for playing :)

OpenXML, on the other hand, is Microsoft's proprietary format that it wants to be registered as an open standard

Do you actually know what you're talking about?
OpenXML is not Microsoft's standard anymore - it's ECMA's, and it's been developed with the help of Apple, Barclays Capital, BP, The British Library, Essilor, Intel, The Library of Congress, Microsoft, NextPage, Novell, Statoil, and Toshiba (according to ECMA themselves).

however it won't be truly as it has patent encumbrances. Besides, Microsoft likely sees OpenXML as another way to extort the computer industry for more licensing fees.
Yes, you really don't know what you're talking about. Period.

OpenXML, on the other hand, is Microsoft's proprietary format that it wants to be registered as an open standard

Do you actually know what you're talking about?
OpenXML is not Microsoft's standard anymore - it's ECMA's, and it's been developed with the help of Apple, Barclays Capital, BP, The British Library, Essilor, Intel, The Library of Congress, Microsoft, NextPage, Novell, Statoil, and Toshiba (according to ECMA themselves).

however it won't be truly as it has patent encumbrances. Besides, Microsoft likely sees OpenXML as another way to extort the computer industry for more licensing fees.
Yes, you really don't know what you're talking about. Period.

Except the OpenDoc spec costs you money to get, while the MS doc spec is a free download:

Office 2007 File Format Specs:
http://www.ecma-international.org/memento/TC45-M.h tm [ecma-international.org]

So, which appears more open???

Actually you two are both wrong. The current (2007) version of the office file formats are fully documented on the ECMA site, not MSDN (though MSDN does also have some docs on the file formats as well). In fact, it is actually the file formats and not just API documentation that you will find at ECMA.

Office 2007 File Format Specs:
http://www.ecma-international.org/memento/TC45-M.h tm

Listing of MSDN Articles on working with the Office 2K7 Formats:
http://openxmldeveloper.org/archive/2006/08/31/599 .aspx

*Bzzt* s/are/were/ thanks for playing...

Like seemingly 99.99999% of all OSS zealots you probably are outraged at my statment. Why not visit http://www.ecma-international.org/news/TC45_curren t_work/TC45-2006-50_final_draft.htm and see for yourself exactly how open it is. Notice how you can download the complete file format specs *without* accepting any kind of licensing agreement.

Yes, OpenXML formats are patented. Yes, ODF is patented too. Yes, both are protected under respective covenants not to sue. I'll leave you to google those details but arguments that try to explain why a format patented by one large and litigious company is worse than another standard patented by a different large and litigious company will be received only with amusement

Some day I think more FUD will come from open source supporters than emanates from Redmond!

The .NET Framework is divided in two parts: the ECMA/ISO covered technologies and the other technologies developed on top of it like ADO.NET, ASP.NET and Windows.Forms.

As always you are making stuff up or accusing them of doing things you think they might do. In reality 2 minutes of research shows that what you are saying is not the case.

You claim that Microsoft will break compatibility with older versions on purpose by putting out a new file format. Microsoft has addressed the issue of older versions of office being able to open the new formats with a free update. People who are using it now will not be forced to upgrade to read/write the new formats. Here is a source:

http://www.microsoft.com/office/preview/itpro/file overview.mspx

You say MS is only claiming "Open" and is going to produce a "uncrackable obfuscated wrench"? Here is the entire schema as submitted to a standards body:

http://www.ecma-international.org/news/TC45_curren t_work/TC45-2006-50_final_draft.htm

If you want a good unbiased source of information on this topic I suggest wikipedia:

http://en.wikipedia.org/wiki/Microsoft_Office_Open _XML

Stop making up wild accusations in an attempt to defend your poorly chosen position. Your accusations are only based on things that Microsoft could do when a quick stop at google will show that they have not done these things and cannot do them at this point. In the future I recommend that you at least look at the wikipedia entry for the topic you are going to flame someone on.

ObjectLiteral:
  { }
  { PropertyNameAndValueList }

PropertyNameAndValueList:
  PropertyName : AssignmentExpression
  PropertyNameAndValueList PropertyName : AssignmentExpression

PropertyName:
  Identifier
  StringLiteral
  NumericLiteral

each property I is an identifier (either a name, a number, or a string literal)

A JavaScript identifier must start with a letter, underscore (_), or dollar sign ($); subsequent characters can also be digits (0-9).

Hehe, cute, and far more constructive than "it's broke"; thanks. Though "the documentation" is more like this, where it explicitly allows numeric literals in object literals on page 42. Funky, but I'd still use strings so you don't get screwed when you pass (2**31)-1 comment ID's ;)

Looking at the object it actually produces, I see it's setting some spurious bits in there; 0x800000 becomes 0xff800000, etc. Silly. I guess you could always OR each cid with 0xff000000 *duck*

If you want to engage my argument — by all means; but unless you want to look childish, please avoid the ad-hominem attacks (you have no idea what I do or do not understand).

Even if you made a perfect browser [...] that implemented JavaScript to the exact EcmaScript specifications, you would still be vulnerable...

This is the point I was trying to make! The vulnerabilities are NOT the fault of the JavaScript language!

... because the XSS vulnerabilities exist in the web applications, not the browser. The design of JavaScript enables this, ...

No, as you just admitted just a sentence ago, "the design of JavaScript" does NOT enable XSS!

In all three types of XSS (DOM Based, Reflected, and Persistent) the fault is with the programmer (writing browser-side JavaScript code in the DOM Based case and writing server-side code in the other two cases) not validating data they are using to manipulate the DOM (DOM Based) or generate the HTML returned by the server (Reflected, Persistent). The fact that HTML allows a <script> tag is the very root of what allows this to exist at all; where the real fault lies is with the lazy programmer who is not validating the data. Neither the existence of the tag in HTML or the laziness of the programmer is the fault of the JavaScript language.

because the separation between code and data is flimsy (you can insert JavaScript almost everywhere in HTML, with "on ..." events -- you don't even need a script tag);

OK.... let's look at some JavaScript :

var b = {x:'y', i:'z'};
doSomething(b);

Well, what's "code" and what's "data" seems pretty clear to me, b is holding some "data"; there's a function getting called as part of some "code", etc; but I imagine you are trying to refer to something along the lines of:

<html>
<head>
<script>var a = 1;</script>
</head>
<body onload="alert(a);">
</body>
</html>

The problem with referring to that though, is that's HTML, not JavaScript. (And you didn't title your comment thread HTML means no dice.) (Your assertion that you can "insert JavaScript almost everywhere" is flatly wrong too, btw; you can only insert it in <script> elements or in event hander attributes (onload, etc). You can throw <script> elements just about anywhere, but with JavaScript only existing in those two places, it's really not that hard to identify it as being "code".)

you couldn't do it unintentionally with a web browser that only understood Java, and a Java web application. JavaScript makes it very easy, just like C makes it easy to mishandle pointers and fixed length buffers. If C gets criticized for that, it's fair to criticize JavaScript for making XSS vulnerabilities easy.

More of the same... There is no reason someone couldn't (though plenty of reasons someone wouldn't) write a web browser that supported interpreting Java source code instead of JavaScript source code. And if that browser exposed the same host objects (like document) you'd have about an identical number of vulnerabilities, and the exact same XSS vulnerabilities.

Furthermore, mishandled pointers arise directly out of a the design of the C language, for the about fifth time in this

If you want to engage my argument — by all means; but unless you want to look childish, please avoid the ad-hominem attacks (you have no idea what I do or do not understand).

Even if you made a perfect browser [...] that implemented JavaScript to the exact EcmaScript specifications, you would still be vulnerable...

This is the point I was trying to make! The vulnerabilities are NOT the fault of the JavaScript language!

... because the XSS vulnerabilities exist in the web applications, not the browser. The design of JavaScript enables this, ...

No, as you just admitted just a sentence ago, "the design of JavaScript" does NOT enable XSS!

In all three types of XSS (DOM Based, Reflected, and Persistent) the fault is with the programmer (writing browser-side JavaScript code in the DOM Based case and writing server-side code in the other two cases) not validating data they are using to manipulate the DOM (DOM Based) or generate the HTML returned by the server (Reflected, Persistent). The fact that HTML allows a <script> tag is the very root of what allows this to exist at all; where the real fault lies is with the lazy programmer who is not validating the data. Neither the existence of the tag in HTML or the laziness of the programmer is the fault of the JavaScript language.

because the separation between code and data is flimsy (you can insert JavaScript almost everywhere in HTML, with "on ..." events -- you don't even need a script tag);

OK.... let's look at some JavaScript :

var b = {x:'y', i:'z'};
doSomething(b);

Well, what's "code" and what's "data" seems pretty clear to me, b is holding some "data"; there's a function getting called as part of some "code", etc; but I imagine you are trying to refer to something along the lines of:

<html>
<head>
<script>var a = 1;</script>
</head>
<body onload="alert(a);">
</body>
</html>

The problem with referring to that though, is that's HTML, not JavaScript. (And you didn't title your comment thread HTML means no dice.) (Your assertion that you can "insert JavaScript almost everywhere" is flatly wrong too, btw; you can only insert it in <script> elements or in event hander attributes (onload, etc). You can throw <script> elements just about anywhere, but with JavaScript only existing in those two places, it's really not that hard to identify it as being "code".)

you couldn't do it unintentionally with a web browser that only understood Java, and a Java web application. JavaScript makes it very easy, just like C makes it easy to mishandle pointers and fixed length buffers. If C gets criticized for that, it's fair to criticize JavaScript for making XSS vulnerabilities easy.

More of the same... There is no reason someone couldn't (though plenty of reasons someone wouldn't) write a web browser that supported interpreting Java source code instead of JavaScript source code. And if that browser exposed the same host objects (like document) you'd have about an identical number of vulnerabilities, and the exact same XSS vulnerabilities.

Furthermore, mishandled pointers arise directly out of a the design of the C language, for the about fifth time in this

If you want to engage my argument — by all means; but unless you want to look childish, please avoid the ad-hominem attacks (you have no idea what I do or do not understand).

Even if you made a perfect browser [...] that implemented JavaScript to the exact EcmaScript specifications, you would still be vulnerable...

This is the point I was trying to make! The vulnerabilities are NOT the fault of the JavaScript language!

... because the XSS vulnerabilities exist in the web applications, not the browser. The design of JavaScript enables this, ...

No, as you just admitted just a sentence ago, "the design of JavaScript" does NOT enable XSS!

In all three types of XSS (DOM Based, Reflected, and Persistent) the fault is with the programmer (writing browser-side JavaScript code in the DOM Based case and writing server-side code in the other two cases) not validating data they are using to manipulate the DOM (DOM Based) or generate the HTML returned by the server (Reflected, Persistent). The fact that HTML allows a <script> tag is the very root of what allows this to exist at all; where the real fault lies is with the lazy programmer who is not validating the data. Neither the existence of the tag in HTML or the laziness of the programmer is the fault of the JavaScript language.

because the separation between code and data is flimsy (you can insert JavaScript almost everywhere in HTML, with "on ..." events -- you don't even need a script tag);

OK.... let's look at some JavaScript :

var b = {x:'y', i:'z'};
doSomething(b);

Well, what's "code" and what's "data" seems pretty clear to me, b is holding some "data"; there's a function getting called as part of some "code", etc; but I imagine you are trying to refer to something along the lines of:

<html>
<head>
<script>var a = 1;</script>
</head>
<body onload="alert(a);">
</body>
</html>

The problem with referring to that though, is that's HTML, not JavaScript. (And you didn't title your comment thread HTML means no dice.) (Your assertion that you can "insert JavaScript almost everywhere" is flatly wrong too, btw; you can only insert it in <script> elements or in event hander attributes (onload, etc). You can throw <script> elements just about anywhere, but with JavaScript only existing in those two places, it's really not that hard to identify it as being "code".)

you couldn't do it unintentionally with a web browser that only understood Java, and a Java web application. JavaScript makes it very easy, just like C makes it easy to mishandle pointers and fixed length buffers. If C gets criticized for that, it's fair to criticize JavaScript for making XSS vulnerabilities easy.

More of the same... There is no reason someone couldn't (though plenty of reasons someone wouldn't) write a web browser that supported interpreting Java source code instead of JavaScript source code. And if that browser exposed the same host objects (like document) you'd have about an identical number of vulnerabilities, and the exact same XSS vulnerabilities.

Furthermore, mishandled pointers arise directly out of a the design of the C language, for the about fifth time in this

To those noting that DOC is 4 times larger than OpenXML, and are therefore gloating that this proves that DOC is bloated, how about Adobe's PDF?

I've just downloaded the just released ECMA Draft 1.4 OpenXML Specs. They are 5 files, available in both DOCX (the OpenXML version of DOC) and PDF.
The PDF files are 4 to 7 times larger than the DOCX files (except for the "Part 3 - Primer" doc, where the PDF file is only 1.2 times larger than the corresponding DOCX file).
For the main file, "Part 4 - Markup Language Reference", the PDF version is is 42MB and the DOCX version is 10MB.

Just adding some perspective.

Microsoft has a substancial "bully" position because they can bend the standards in their web server, and their browser to assure they work together. I am a security consultant sometimes, and I became livid when Microsoft announced their http tunneling protocol to help programs get through corporate firewalls. In a way though, Microsoft is attempting to comply with standards on the higher level. If you read: http://www.ecma-international.org/publications/fil es/ECMA-TR/TR-055.pdf you will see that Microsoft's direction is moving towards the direction indicated in the Technical Report TR/55 Reference Model for Frameworks of Software Engineering Environments Now I don't know to what extent Microsoft contributed to the document, but if you read it (I recomment reading it with a bucket of good ice cream at hand) you will be struck by the extent to which Microsoft's current products contain or are moving towards the elements described in the report. The picture of the .NET Framework and the various servers and clients within it reflect the requirements of the Reference Model. I stayed up late last night reading it, OK I am a nerd, and I kept saying ..Yes...Um...Yes..They do that...Interesting... FWIW IMHO The document is thought provoking and provides some context within which to evaluate Microsoft's position and behavior. dwg

Microsoft's .NET framework is and always be open, XAML as with the rest of .NET will be submitted to ECMA standards committee. MS.NET already runs on Windows CE mobile devices, plus linux, and soon OS-X. XAML being XML, it will obviously it is a trivial matter for Microsoft to define a subset of tags applicable to mobile devices. This is makes it a far better cross platform solution than a proprietry technology such as Adobe Flash.

How is it a silver bullet ? XAML is an XML based document format that unifies many existing technologies such as Flash, Direct X, and Windows Development, it is backed by an Enterprise development framework as well as thousands of third party vendors, plus it being a .NET technology it has close integraton with SQL Server, Share Point Portal Server, Biztalk Server, Commerce Server, Exchange Server, Map Point etc etc. Microsoft's annual R&D budget is ten times bigger than Adobe's. Adobe simply has absolutely no chance to match the power of this development platform.

I'm guessing that you have a lot of knowlege invested in Flash, and that you probably feel a little threatened. If most of the flash development that goes on out there wasn't so disposable I might be able to say, don't worry you'll have plenty of legacy work for many years to come. But unfortunately I think there's a good chance one day you may have to let go, as most things developed in flash have a life span of less than six months.

The C++/CLI language looks interesting. You can download the spec from http://www.ecma-international.org/publications/sta ndards/Ecma-372.htm. Yes, it is Microsoft grown, but they seem to have some good people on the design team (Lippman, Sutter) and it's nothing at all like the mess that Managed C++ was. It's worth looking at if you want to keep abreast of 'current trends'.

The hypocrisy on this site is astounding.

Consider this:
1. Adobe's market share in PDF creation software is similar to Microsoft's marketshare in desktop OSes for intel-compatible CPUs. Therefore, one could argue that Adobe has a "monopoly" in pdf creation software (not 100% share, but nearly so). But to keep some of you from bitching about the use of the term "monopoly" in this case, I'll use the term "quasi-monopoly".

2. Adobe, wanting to protect their "quasi-monopoly", was willing to allow Microsoft Office 2007 to export PDF if Microsoft charged extra for that functionality so as to not undercut the price of Adobe's own PDF creation software. In other words, Adobe wanted to engage in price-fixing with Microsoft in order to protect Adobe's quasi-monopoly. That is what you guys are supporting! Do you really want to go down that road? Surely you'll want to rethink your position, or does your hypocrisy really go that far?

3. Microsoft wasn't bastardizing PDF. What would be the point, since Microsoft is not producing any PDF reader? Since Microsoft isn't creating their own reader, any PDF document producted by Microsoft Office would have to be readable by other readers (and printable by printers), so why bastardize the format? Think logically.

4. If you want to see an example of the PDF produced by Office 2007, try Office 2007 beta 2. Or you can read the PDF version of the latest draft of the OpenXML ECMA spec, a PDF document that was created by Office 2007 beta. Guess what, it's perfectly readable by Acrobat Reader and any other PDF compliant reader.

5. Regarding XPS, XPS is a PDF competitor based on XML, but includes many advances over the current PDF spec (though future PDF specs may add such advances). XPS is part of Vista; XPS's role in Vista is similar to PDF's role in Mac OS X. Microsoft has shared with Adobe info on XPS for several years. Now Microsoft, bending over backwards to allay Adobe's hypocritcal paranoia, is removing from Office 2007 built-in support for both PDF and XPS. Furthermore, Microsoft is leaving it up to OEMs as to whether they want to include XPS support in Vista itself (except for XPS's role as a spool file format for Vista's printing enhacements).

6. Lastly, Microsoft is still going to provide PDF and XPS export support in Office 2007 as free downloadable plug-ins. Adobe's still pissed about this because they want Microsoft to charge for the plug-ins (more of the price-fixing scheme that you guys are supporting).

See these links for sources of the above info:
http://blogs.msdn.com/andy_simonds/archive/2006/06 /02/XPSAdobe.aspx
http://blogs.msdn.com/brian_jones/archive/2006/06/ 02/613702.aspx
http://blogs.msdn.com/brian_jones/archive/2006/06/ 03/616022.aspx

Lastly, please don't you (or the state of MA) ever refer to PDF as "open" in the future. If it's not open for all, then it's not truly open, period.

OK, hotshot, which do you prefer?

Example 1:
<row><c><v>1</v></c><c><v>2</v></c><c><v>3</v></c> </row>
<row><c><v>4</v></c><c><v>5</v></c><c><v>6</v></c> </row>

Example 2:
<table:table-row table:style-name="ro1"><table:table-cell office:value-type="float" office:value="1"><text:p>1</text:p></table:table-c ell><table:table-cell office:value-type="float" office:value="2"><text:p>2</text:p></table:table-c ell><table:table-cell office:value-type="float" office:value="3"> <text:p>3</text:p></table:table-cell></table:table -row>
<table:table-row table:style-name="ro1"><table:table-cell office:value-type="float" office:value="4"><text:p>4</text:p></table:table-c ell><table:table-cell office:value-type="float" office:value="5"><text:p>5</text:p></table:table-c ell> <table:table-cell office:value-type="float" office:value="6"><text:p>6</text:p></table:table-c ell></table:table-row>

I'll let you figure out which one is ODF and which is the MS format.

Face it, Microsoft has decades of experience in writing and parsing document formats. They understand that the format has to be optimized for actual users, the bulk of whom don't care to poke around inside the files, as opposed to the hobbyist who makes up a tiny fraction of the Office user base.

If you look at the George Ou experiment, his spreadsheet (when saved as OpenXML) has 7 million tags, with over 9M attributes. While it is larger than normal for a spreadsheet, it is by far not the largest. Parsing those 16M strings is just naturally going to take an ODF parser 7 times as long as an OpenXML parser because the strings are 7 times as long. People are used to opening and saving their files in a few seconds, not a few minutes. Microsoft knows that people won't use the XML format if it takes 100 times longer to do anything with it. Maybe people won't notice 10 times slower, but 100 times is like going back to floppies!

And the XML does not contain any binary. The Office team created hierarchical file formats 15 years ago (like single-file FAT filesystems); why would they go back now? The ZIP file format allows them to include the images as separate files, and they make use of that. You can verify for yourself by reading http://www.ecma-international.org/news/TC45_curren t_work/Ecma%20TC45%20OOXML%20Standard%20-%20Draft% 201.3.pdf. That's the PDF version of the draft as saved by Word 2007.

dom

Here is the draft of ECMA standard, enjoy its 2000+ pages of detailed info.

That's sad really, I wonder on what standards those "wonderful Mono efforts" are based on ? Yeah. There'll never be a open standard for .NET, never bother about open source implementations.

Eiffel users continuously demonstrate that they can produce between two and ten times as much software in a given amount of time as can be achieved using other IDEs and tool sets. Eiffel has thus gained prominence in challenging enterprise environments in the financial, insurance, manufacturing, and government sectors as well as among independent development teams.

Check section 15.1.3 of the ECMA standard, which the source refers to. The algorithm is explained there, and the variable names are taken from the standard for readability.

Sheesh, do a little homework first.

So i wouldn't be surprised at all to see MS drop managed C++ entirely.

Actually, MS is pushing C++/CLI for standardization. The .Net 2.0 Managed C++ is much less ugly than in .Net 1.x.

The nice thing about .NET though is that you aren't stuck to any particular language though...

Everyone touts this, and I agree that it's a seductive idea. However, I think few people consider the likely long-term ramifications, particularly in large applications built, augmented and maintained over long periods of time. Imagine some large organization having an internal CLR application which has accreted multiple modules in several .Net (or Mono) languages. Now imagine that Mr. VB.Net needs to track and correct a flaw in a module written by Mr. Perl.Net long after Mr. Perl.Net has left the company. Some will say that the modules written by Mr. Perl.Net would have been appropriately designed & documented so that any other CLR developer can understand & modify them regardless of programming language - but that doesn't happen on the planet most of us live on, especially with internal applications.

So in short, they're forcing you to .NET, but not off any particular language.

Agreed. MS gains the most as more developers move to a platform it "controls" - how much control is debatable, but I think no one is foolish enough to believe that MS's .Net push is in any way altruistic. However, the native Win32 C++ developers will be the hardest to convert, and that's why MS is investing effort in C++/CLI to entice them. Few native C++ programmers have any love for MFC, but also few seem willing to leave native Win32 for .Net drag-and-drop GUI capabilities. And for desktop/server applications, experienced C++ devs already know what native APIs to use for whatever they're working on - there's a perception that .Net has little to offer them when building these apps. That's a big hurdle for MS if they intend (regardless of their current public stance) to derive a crushing long-term strategic advantage from mass adoption of .Net.

T

Erm... you dumbass .NET is not an M$ API. Ever heard of ECMA?

M$ got .NET and the CLR standardised by ECMA (which is a standardization body, btw.)

Take a look at:
http://www.ecma-international.org/publications/sta ndards/Ecma-335.htm

Ankur

By far, I am not a Microsoft shill, but I enjoy programming in C#, and like the CLI.
Mono's main goal is an implementation of this: the ECMA CLI standard The windows.forms portion is there for compatibility with programs written for windows. (no different legally than WINE providing compatibility with win32 APIs)
It is suggested to develop using the GTK# toolkit, which is available for Mono or Windows.

IMHO, this is a step toward systems and applications that are OS-independent, making the "fight" between windows and Linux moot.

Er, how was the parent marked insightful? Mark parent down!

C# runs on the .NET platform which was openly standardized. The standards have been adopted by the ISO, the same body that determines the metric units and also manages the C++ language. Furthermore, a number of open source groups have begun implementing .NET for other platforms than Windows.

And last but not least, all of the patents that Microsoft has covering the .NET platform have been released for public use.

With open-source leaders such as Miguel de Icaza (founder of GNOME, Mono) involved in producing .NET implementations for OSes other than Windows, it's hard for me to believe you just said what you did if you're anything but completely ignorant. .NET will exist on as many platforms and OSes as people choose to implement it on. And it currently exists on many.

Also, sorry for the double post, but it is worth noting that the CLI is, a standard. That's right, the bytecode is protected similarly to C#. So they standardized the wheel, pedals, engine, frame, gas tank, seats, and everything else... to sucker you into getting locked into one namespace which is essentially the air conditioner.

Diabolical.

C# is an official ECMA standard, Java is not. So tell me again who can more easily take their toys and go home?

Javascript is a much maligned language that is actually pretty powerful.

I've been toying around with XUL applications on Mozilla and have been learning alot about the power of the language.

I think it's humble beginnings have stereotyped it as a toy, while the reality is that it's extremely powerful and flexible.

The new ECMA 357 spec is pretty interesting, too.

Actually, he should have said ECMAScript, which is what is referred to as JavaScript.

It's standardized and accepted by the ECMA (European Computer Manufacturor's Association)

Standard 262

And the W3C provides a binding specification for it: for example

So, yeah, it very much is an accepted internet standard.

Actually, it's not "mimicking" anyting ... .NET is Microsoft's implementation of the Common Language Infrastructure, which is an ECMA (international) standard. Microsoft co-sponsored the submission of the CLI along with other companies, but it is by no means a proprietary "Microsoft thing".

Mono happens to be a 'nix implementation of the CLI. Again, this is not "mimicking" anything... it's a native implementation of a recent standard. It also happens that the C# (also specified in the ECMA submission) implementation in Mono is basically complete.

The problem right now doesn't sit with the c# language or Mono... the problem is that an appropriate cross-platform gui/widget set doesn't exist. GTK# shows some promise, but is slow to be adopted. Windows.Forms (Microsoft's GUI implementation for the CLI) *is* proprietary, and thus, has proved difficult to implement on platforms other than Windows. BUT, let's not confuse the implementation of Windows.Forms with the CLI/Mono because they really don't have much to do with each other.

Additionally, Mono is NOT the only non-Microsoft implementation of the CLI. dotGNU Portable.net (www.dotgnu.org) is another -- and I'm sure there are more.

Feel free to educate yourself on the CLI and it's background by starting here:

http://www.dotnetexperts.com/ecma/
http://www.ecma-international.org/publications/sta ndards/Ecma-335.htm

to say this, but C# isn't the only language which runs on the Common Language Infrastructure, which is to say, .NET on Windows or Mono on Linux.

But still, you say, evil Microsoft owns the standard! Vendor lock-in, oh no!
Actually, it's an open standard maintained by ECMA. That's right, those same evil people who maintain things like the standard for javaScript.

ECMA-262 (ECMAScript Language Specification).

The XMLHttpRequest class that fashionable web applications use is not a standard, but it is pretty simple; it looks like the only difference between using it in IE and Mozilla/KHTML is how you create an instance of it.

I cry foolishness and an unwillingness to read.

Per the ECMA site.: General Declaration: The General Assembly of Ecma shall not approve recommendations of Standards which are covered by patents when such patents will not be licensed by their owners on a reasonable and non-discriminatory basis.

The ECMA page totally backs what the AC said. And that is about the language itself. The ECMA standard has nothing to do with .net library, which is almost certainly covered by numerous MS Patents and Trademarks. Everybody seems to want to take the republican approach to this issue and look the other way (no such issue exists; if we ignore it, it will go away; MS would never file suit against mono). This is a problem, and it will not be going away.

I'm not worried because I trust the standards body to not put completely unnecessary stuff into the language. What do you C# programmers think?

• HTML 4.01
• ECMA script
• DOM 1.0