SABS tackles Microsoft

icyrus said:
The problem a lot of people have with OOXML is that it gives microsoft the ability to implement proprietary features straight into the document, preventing any other non-ms-blessed program from working with the files. What good is an open standard if its encumbered by proprietary binary blobs?
Click to expand...

But now are are telling me what I can and cannot embed in my document. Seems a little restricive. If you are using the format on an MS platform the you may very well need this feature. If you are going for interoperability in your system, then you wouldnt be embedding any binary informations at all since endian formats differ. At the end of the day at least with OOXML I got the choice.
 
Garyvdh said:
Oooh yes... sorry... and Santa is really a big jolly old fat man in a red suit that brings you lots of Free gifts from Microsoft every year! :p
Click to expand...

Are you absolutely certain you know what OOXML is?
We not talking about doc files here you know.
 
SlappY said:
Again, I reiterate, OOXML is not proprietry.
Click to expand...

I am fairly certain it allows for proprietary extensions, which sort of ruins the point of an open standard. It allows Microsoft to use these proprietary, undocumented blobs to chain people to its software.

An example:

The “Excel Macro-Enabled Workbook” option saves as an “xlsxm” extension. It is OOXML plus proprietary Microsoft extensions. These extensions, in the form of binary blob called vbaProject.bin, represent the source code of the macros. This part of the format is not described in the OOXML specification. It does not appear to be a compiled version of the macro. I could reload the document in Excel and restore the original text of my macro, including whitespace and comments. So source code appears to be stored, but in an opaque format that defied my attempts at deciphering it.

(What’s so hard about storing a macro, guys? It’s frickin’ text. How could you you[sic] screw it up? )

This has some interesting consequences. It is effectively a container for source code that not only requires Office to run it, but requires Office to even read it. So you could have your intellectual property in the form of extensive macros that you have written, and if Microsoft one day decides that your copy of Office is not “genuine” you could effectively be locked out of your own source code.
Click to expand...
 
Garyvdh said:
but what if I really, really wanted all that hassle? What if I like paying R4000.00 for a round piece of plastic, a few pieces of paper and some cardboard? (that I never really get to own anyway, cos Microsoft are just "lending" it to me). What if I really believe that Microsoft are doing me a favour by allowing me the privelege of doing that? Please? Pretty Please? :sick:

Oops... sorry.. .I actually meant R6000.00 ...

http://www.pcshopping.co.za/pages/4370976/details.asp?uID=73409
Click to expand...

They can stuff that R6k up where the sun doesn't shine.

I'd rather use it for a holiday then :D
 
SlappY said:
But now are are telling me what I can and cannot embed in my document. Seems a little restricive. If you are using the format on an MS platform the you may very well need this feature. If you are going for interoperability in your system, then you wouldnt be embedding any binary informations at all since endian formats differ. At the end of the day at least with OOXML I got the choice.
Click to expand...

You can embed whatever you like in your document, the problem is that ms will use the caveat to make sure that their standard documents are not correctly readable (and therefor not portable) on anything other than MS software.

So they get to tell governments that they have an ISO approved open standard for documents, but when they actually use it they are just as tied to MS as they are now.
 
This part of the format is not described in the OOXML specification. It does not appear to be a compiled version of the macro. I could reload the document in Excel and restore the original text of my macro, including whitespace and comments. So source code appears to be stored, but in an opaque format that defied my attempts at deciphering it.
Click to expand...

Open? Non.
 
SlappY said:
Are you absolutely certain you know what OOXML is?
We not talking about doc files here you know.
Click to expand...

I know what I am talking about, but where you are coming from I have no idea. Do you work for Microsoft? cos that would be the only rational explanation for anyone wanting to actually defend them the way you are?

and at the end of the day, we ARE actually talking about docs... cos that is where the rubber meets the road. But you seem to have missed that point. It's about users and docs. Users being able to actually USE the docs. Their docs... the docs they created and want to be able to share with others.
 
Wiehan said:
I am fairly certain it allows for proprietary extensions, which sort of ruins the point of an open standard. It allows Microsoft to use these proprietary, undocumented blobs to chain people to its software.

An example:
Click to expand...

Fair enough, but it is there for a reason, think of a real world example here. Our financial analysts here have written some pretty comprehensive macros and formulas for their financial models, (they chose excel cause at the time nothing else could do anything near whatthey wanted) that do some pretty amazing things, now you telling them they must just drop it all and move over. It is completely unfeasible for a business to do this. Instead, why not give the option to migrate slowly, use the blobs till they can redo them in a more open format. MS considers all these angles when developing. The world is never clean cut as a spec sheet would have it. In this case ODF is out of the question.
 
Face it. MS was ahead of the game and cornered the market, any format that wants to supercede this must cater for the transitional period that is going to have to take place.
ODF is somewhat arrogant if it think it can whitewash the industry into using it.

Why do we still have the old mainframes, why do COBOL apps still exist, these are clear examples of legacy, but the cost to revolutionarily replace them is not feasible.

MS has provided a format that caters for legacy code as well as moving towards open formats, an outlook the the Open Sources kinda fell short on, which is also why the end users will ultimately adopt OOXML and not ODF in the long run.
 
Last edited:
SlappY said:
Fair enough, but it is there for a reason, think of a real world example here. Our financial analysts here have written some pretty comprehensive macros and formulas for their financial models, (they chose excel cause at the time nothing else could do anything near whatthey wanted) that do some pretty amazing things, now you telling them they must just drop it all and move over. It is completely unfeasible for a business to do this. Instead, why not give the option to migrate slowly, use the blobs till they can redo them in a more open format. MS considers all these angles when developing. The world is never clean cut as a spec sheet would have it. In this case ODF is out of the question.
Click to expand...

MS will be supporting ODF in the next Office 2007 service pack so they can just save these files as ODF files. On the other hand, OOXML is so complex that MS won't be supporting it before the end of next year.
 
Abe said:
MS will be supporting ODF in the next Office 2007 service pack so they can just save these files as ODF files. On the other hand, OOXML is so complex that MS won't be supporting it before the end of next year.
Click to expand...

The format yes, but obviously with the restirctions of the format imposed.
You get a compatibility warning that information will be lossed, as it does with any non native file its translation engine supports.

Not to mention the fact that the ODF format specification has been out for a while now giving them time to develop for it.
 
Last edited:
SlappY said:
Face it. MS was ahead of the game and cornered the market, any format that wants to supercede this must cater for the transitional period that is going to have to take place.
Click to expand...

Not quite. Have a look at your history. MS used Windows 95 to block the other office suite vendors. The other vendors could only have a look at the Windows 95 API's after it's release. The MS Office team, however, had access to the API's far earlier then that and MS Office for Windows 95 was released within 6 months of Windows 95. Most other suites took more then a year to release. From this point onwards it was game over. What made matters worse is that the other vendors had no clauses in their contracts regarding file formats. MS put clauses in their office suites preventing the reverse engineering of MS Office files which was a stumbling block in people supporting the new MS Office files directly. There have been some court cases around these. Just to give you that warm fuzzy feeling, MS now makes almost 50% of their profit from MS Office. It makes more money then their OS.
 
SlappY said:
Fair enough, but it is there for a reason, think of a real world example here. Our financial analysts here have written some pretty comprehensive macros and formulas for their financial models, (they chose excel cause at the time nothing else could do anything near whatthey wanted) that do some pretty amazing things, now you telling them they must just drop it all and move over. It is completely unfeasible for a business to do this. Instead, why not give the option to migrate slowly, use the blobs till they can redo them in a more open format. MS considers all these angles when developing. The world is never clean cut as a spec sheet would have it. In this case ODF is out of the question.
Click to expand...

Move over to what? Is there anything preventing them from continuing to use their current software to open these spreadsheets? In fact, is there anything preventing future Microsoft releases from opening previous versions' formats?

MS-OOXML (if Microsoft's intent was in any way sincere) was supposed to be a clean start - an attempt at a clearly documented standard that prevents vendor lock-ins like your real world example from happening. By dragging in these deliberately uninteroperable blobs, they defeat the purpose of interoperability. Would it really kill them to document their macro-ing system? With 6000+ pages, another few wouldn't hurt.

A standard that takes account of legacy MS code, has no place at a body like ISO.
 
SlappY said:
The format yes, but obviously with the restirctions of the format imposed.
You get a compatibility warning that information will be lossed, as it does with any non native file its translation engine supports
Click to expand...

Well lets look at it again in 6 months (Probably sooner using OpenOffice 3). We will take some files, save them as ODF files, close the application. Start it up again, load the files and then save them as .DOC files. Lets take a look and see how much is lost (if anything). I doubt you will be able to tell the difference. The limitations with ODF are not as big as MS would have you believe. The problems sit in embedding proprietary objects in the file which is not the intention of a open standard anyway.
 
Wiehan said:
MS-OOXML (if Microsoft's intent was in any way sincere) was supposed to be a clean start - an attempt at a clearly documented standard that prevents vendor lock-ins like your real world example from happening. By dragging in these deliberately uninteroperable blobs, they defeat the purpose of interoperability. Would it really kill them to document their macro-ing system? With 6000+ pages, another few wouldn't hurt.

A standard that takes account of legacy MS code, has no place at a body like ISO.
Click to expand...

Agreed, a standard is supposed to open up the format for others to implement.
 
Abe said:
Not quite. Have a look at your history. MS used Windows 95 to block the other office suite vendors. The other vendors could only have a look at the Windows 95 API's after it's release. The MS Office team, however, had access to the API's far earlier then that and MS Office for Windows 95 was released within 6 months of Windows 95. Most other suites took more then a year to release. From this point onwards it was game over. What made matters worse is that the other vendors had no clauses in their contracts regarding file formats. MS put clauses in their office suites preventing the reverse engineering of MS Office files which was a stumbling block in people supporting the new MS Office files directly. There have been some court cases around these. Just to give you that warm fuzzy feeling, MS now makes almost 50% of their profit from MS Office. It makes more money then their OS.
Click to expand...

Of course they had access to them, they are the same company. Doesnt mean they were complete, imagine releasing an incomplete OS API to the public. The Open Source lads would have a field day with that one. That is a benefit of playing on many fields at once. Kudos to them. Called competitive advantage. And why would they want to allow people to reverse engineer their IP that they spent millions on R&D for. I wanna come live in your world. Are the streets paved with candy too?
 
SlappY said:
Face it. MS was ahead of the game and cornered the market, any format that wants to supercede this must cater for the transitional period that is going to have to take place.
ODF is somewhat arrogant if it think it can whitewash the industry into using it.

Why do we still have the old mainframes, why do COBOL apps still exist, these are clear examples of legacy, but the cost to revolutionarily replace them is not feasible.

MS has provided a format that caters for legacy code as well as moving towards open formats, an outlook the the Open Sources kinda fell short on, which is also why the end users will ultimately adopt OOXML and not ODF in the long run.
Click to expand...

No, MS was not ahead of the game. They merely used their considerable power as virtually the only OS vendor available to the public at large to cut off the air supply of other vendors.

I reiterate, an open standard that caters for the legacy code of a single software vendor has no place being called an *open* standard. Imagine, if you will, something like xhtml making provision for the inclusion of legacy ms binary office files in web page content.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X