« The Secret Code to Vinyl Playback | Main | Package Management, or Bust »

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83452f49169e200e009972d418833

Listed below are links to weblogs that reference My Comment on Mass ITD's ETRM 4.0:

» Massachusetts ETRM V4.0 recommends Open XML and ODF 1.1 from Doug Mahugh
A month ago, the Commonwealth of Massachusetts posted a draft of its revised Enterprise Technical Reference [Read More]

» Massachusetts ETRM V4.0 recommends Open XML and ODF 1.1 from Doug Mahugh
A month ago, the Commonwealth of Massachusetts posted a draft of its revised Enterprise Technical Reference [Read More]

» Massachusetts ETRM V4.0 recommends Open XML and ODF 1.1 from Doug Mahugh
A month ago, the Commonwealth of Massachusetts posted a draft of its revised Enterprise Technical Reference [Read More]

» Massachusetts ETRM V4.0 recommends Open XML and ODF 1.1 from Noticias externas
A month ago, the Commonwealth of Massachusetts posted a draft of its revised Enterprise Technical Reference [Read More]

Comments

hAl

Reading your 'whitepaper' I saw you had all kind of issues with OOXML openness. However it did not get very concrete.

Could you for instance create certain documents with ODF licensing that I cannot implement with OOXML licensing ?
Give us an example please.

Sam Hiser

It was extremely concrete, if you took the time to look at the footnotes where pages of the OOXML spec are referenced.

Your question, hAl, reveals that you do not understand the issues very clearly. You seem to be confusing software (application) licensing questions with standards specification covenants not to sue.

Kindly come again.

hAl

No I do not confuse those.
If you state that there are licencing problems with OOXML that I would like to see what kind of documents you cannot implement because of such licensing issues.
Concrete examples that you can implement in ODF and not in OOXML because of licensing issues.
I looked at the OOXML spec to your references but I did not find things that prevent creating any document because of licensing which could be created in ODF.

For instance the embedding of WMF files. I have an WMF file here on my computer. How does the OOXML licensing provided by Microsoft prevent me from fuly legally embedding that file in an OOXML document using any of the required spec you can provide ?

Sam Hiser

"No I do not confuse those."

"If you state that there are licencing problems with OOXML that I would like to see what kind of documents you cannot implement because of such licensing issues."

There are licensing problems with OOXML -- it's specification -- which prevent me from designing and building an application that can create good OOXML. I can't create good OOXML files without Microsoft software (the Translators don't work either to the degree my customers require); but I'd like to.

"Concrete examples that you can implement in ODF and not in OOXML because of licensing issues.
I looked at the OOXML spec to your references but I did not find things that prevent creating any document because of licensing which could be created in ODF."

I have no idea what you're talking about.

"For instance the embedding of WMF files. I have an WMF file here on my computer. How does the OOXML licensing provided by Microsoft prevent me from fuly legally embedding that file in an OOXML document using any of the required spec you can provide ?"

The WMF implementation in OOXML is not a licensing issue; it's an example of a proprietary dependency built into the OOXML spec and into the OOXML formats which tie OOXML files (illegally, in the anti-trust context) to Microsoft Windows and Office.

Certain files from Office will not function as the author intended on Linux, for example, because the file contains interactions with software facilities in Windows.

hAl

[quote]There are licensing problems with OOXML -- it's specification -- which prevent me from designing and building an application that can create good OOXML[/quote]

Give us an example of that good ooxml that the MS licensing prevents applications to create. I have yet to see any example of valid OOXML that has a licensing issue.

About WMF
[quote]it's an example of a proprietary dependency built into the OOXML spec and into the OOXML formats which tie OOXML files[/quote]The dependency is a datetype value. You can use the datatype value on any platform without any dependency on windows or MS Office. Actually any Office suite on any can use the datatype value for embedding WMF files in OOXML documnet just like you could actually embed WMF files in ODF document on any platform. It mayby so that WMF files are useless on non windows systems but it does not prevent any kind of implementation. In comparison instance ODF contains a reference to java applets. Java applets only work when you have a java virtual machine which is dfor instance an item that Micrsoft is not allowed to produce after their legal affeir with Sun. However Sun added java applets to ODF spec knowingly that the biggest software prodcuer cannot create and distribute it''s own virtual machine making it dependant on licening a virtual machine form antoher party. That actually makes ODF the non open spec I would say...

Sam Hiser

hAl-

Permit me to address a question that I think is useful rather than the one you ask which is mixed up.

If a user of Office 2007 creates documents with a .docx extension and I cannot attain all the content or perfectly faithful layout (for some reason) using my own application of choice or I cannot pass this document in a business process with my collaborating work group partners successfully and reuse and resave this document many times over in that business process, then .docx has failed to be an open format.

How's that?

Not strictly a licensing issue.

Re your confused WMF example: ODF indeed CAN be extended in all and infinite ways; but you will not see it being extended toward a proprietary machine owned by a single vendor.

hAl

[quote]If a user of Office 2007 creates documents with a .docx extension and I cannot attain all the content or perfectly faithful layout (for some reason) using my own application of choice or I cannot pass this document in a business process with my collaborating work group partners successfully and reuse and resave this document many times over in that business process, then .docx has failed to be an open format.[/quote]

Replace MS Office with OOo and docx with odt and it would be the same. I see nothing in the OOXML spec that is about content that I cannot attain by using OOXML and it's licensing so you object actually to MS Office being able to do things you cannot your preferred application cannot do.

That you think your preffered application cannot match MS Office features is irrelevant to OOXML itself though.

But it might show where the basis of your interpretating is. You fight against Microsoft and their Office suite MS Office rather than against OOXML and you see blocking OOXML as an integrate strategy in hindering the use of MS Office.

There might be a point about faithfull rendering of OOXML. Based on the format I do not see that as possible however the same applies to ODF which also is impossible to faithfully render based on the format. As both these specs do not describe rendering I however do not see a problem in that for ISO standardization of OOXML. If it were then ISO should also demand that OASIS add 100% faithfull rendering specifcation to ODF.

Jeff

Not to interrupt this exchange, but I wonder Sam what you think about MS submitting its Shared Source License to OSI for approval?

Sam Hiser

Jeff-

The Shared Source initiative has been a reach from the start...another hilarious example of the Kings's semantic license. (It's a false proposition fit for the myth-tellers & historians: intended to emulate open source on the marketing brochure checklist by showing code under NDA to some people who wish to see it, like academics or Chinese counter-espionage agents, so that shamefully inadequate Microsoft product can appear to be more like Free Software while reinforcing and doubling-down on Microsoft's potential ability to threaten lawsuits and commit future extortion against those who were dumb enough to look at the code and thereby expose themselves to copyright and patent litigation or the threat of copyright and patent litigation from Microsoft. No mature or thinking technologist of any quality or with a career horizon longer than 18 months would be so foolish as to look at that piss-poor spaghetti code, as it would prevent him permanently from contributing to Free Software; though many people of low mental capacity have made the mistake).

Microsoft grasping for OSI approval will seal OSI's reputation as another agency-for-rent and enemy of Free (& Quality) Software.

Microsoft grasping for OSI approval NOW, upon the infamies of OOXML, XPS & XAML, is about the funniest thing I have ever seen.

In addition it's my view that they will probably win.

Sam Hiser

hAl-

You err again.

"Replace MS Office with OOo and docx with odt and it would be the same. I see nothing in the OOXML spec that is about content that I cannot attain by using OOXML and it's licensing so you object actually to MS Office being able to do things you cannot your preferred application cannot do."

It was my colleagues at the OpenDocument Foundation who produced a Plugin to MS Office so effective at outputting faithful ODF formatted documents from within MS Office, that your example is completely moot.

Here is what we've achived...

"Plugin: Transparently Open a File"

"Plugin: Transparently Save a File"

"Plugin: Default to ODF"

Our friends at Sun and the OASIS ODF TC have stalled the plugin effort to preserve utter non-interoperability of ODF with Microsoft file formats.

But we have faith that the Plugin concept is right, correct and the only practical alternative to another decade of Microsoft hegemony and the only way in fact to save the advances made by Free Software under the GPL(s) and the Internet's W3C standards. It is the only solution the CUSTOMERS (Massachusetts, California & Europe ) want. And, indeed, they have asked. Everyone, especially in the ODF Community, said it couldn't be done; or would not try in order to preserve their pecunious relationships with Microsoft.

We did it. We are going to see it through. It means the vendor-backed consortia have failed and proven their inadequacy to steward a Universal Document Format which can be used. That means Ecma, OASIS & ISO have all failed. The customers have no choice but to file like sheep into the next Microsoft stack. This is because the ODF Community -- of which I am a member -- failed totally.

What I mean to say, hAl, to address your question is that my friends in the ODF Community stopped a successful approach offered by the OpenDocument Foundation that will permit ODF and ODF-enabled applications to handle everything (content & layout) presented in OOXML files (except the obvious hidden proprietary objects -- and it would even have preserved the hidden proprietary objects to permit them to function if the file were returned in a business process back to a Microsoft application where the proprietary facilities were originated or intended to function).

Q.E.D. You lose!

Please, always, make good arguments.

W^L+

hAl,
Never forget that Office Not-so-open XML was never intended to be implemented outside of Microsoft. That explains many of the technical problems--they are only problems if your application does not have legacy parts included to process the legacy blobs and flags--possession of the ancient compiled MSFT code enables them to quickly handle these things as they come up.

That they have put so much emphasis on OOXML and other proprietary formats in drag shows how important they are for MSFT's intended future.

No intelligent person believes that they'd open up such a format when it is key to their strategy of being noncompatible with competitors' products.

hAl

Strangely enougn Sam your example does not refer to OOXML icensing or openness of the format at all.

The plug you refer to seems to be based around an OpenOffice engine that is able to read most of the internal RTF format using in MS Office 2003 and store the things it cannot read as binary data in ODF and use Micrsoft compatibility software to convert to OOXML.

So the whole plugin seem to avoid even interpreting XML but just tries to use existing programs to convert files. A risky effort as it complelty relies on closed Micrsoft software binaries to stay working (and it does not seem to work for Office 2007). Micrsoft Office is closed source and I never doubted that and every ICT'ers knows that.

Office Open XML how ever is not about MS Office but about a file format. And you again avoided any calim related to the openness of the format.

So I say again what can you not implement in the Office Open XML format that is prevented by licencing not being open that you can implemebnt in ODF because it is open. And try to avoid your dislike for Mcirsoft and their Office dominance and just focus on the format licensing which to try to avoid every sinlge time even though you wrote a white paper on it.

If it is so simple than show me a example OOXML file that MS lack of open licensing prevents a third party from creating on linux for instance. This is an obvious and simple way to prove you are correct.

Why would you avoid such a simple way to prove you are right and begin about interoperability with MS Office and not about a format ???

Show me a file and convince me.

Sam

hAl-

Your understanding of the issue -- where format licensing ends and application licensing begins -- would evidently prevent you from receiving benefit from an example.

My consulting fee is $185 per hour. If you would like to book time in Boston in early August, I'm happy to accommodate you in my schedule.

If you would like me to demonstrate OOXML, you will have to send me a Dell with Vista & Office 2007 loaded...preferably a WORKING one.

The comments to this entry are closed.


Sam Hiser

Categories

OFF-WHITEPAPERS

ARTICLES


www.flickr.com
This is a Flickr badge showing public photos from swhiser. Make your own badge here.


Locations of visitors to this page


Google
Search PlexNex

  

View Sam Hiser's profile on LinkedIn

Powered by TypePad