decoration decoration
Stories

GROKLAW
When you want to know more... 		decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook

Donate

Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments

Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Novell's "Danaergeschenk", by Georg Greve - Updated
Friday, December 08 2006 @ 02:40 PM EST

Novell's "Danaergeschenk"
-- by Georg C. F. Greve, Free Software Foundation Europe

German is an interesting language, and many of its words have made it into English. Novell's recent deal with Microsoft is begging to add another one: Danaergeschenk. The term translates to "Gift by the Danaer" and has the same roots as "Greeks bearing gifts," which goes back to the siege of Troy.

[Update: Greve found your comments interesting and useful and he has written a followup article responding to some of the points you made.]

Novell's Danaergeschenk to the world is the recent announcement to implement OpenXML support in OpenOffice.org.

Bob Sutor, IBM's Vice President of Standards and Open Source has written a good analysis why the specification is more akin to a denial of service attack than an Open Standard. OpenXML basically represents a change of strategy: Instead of trying to hide information by not telling anything about their products to anyone, they've apparently now switched to hiding information in noise, which is by far the more effective method.

This is consistent with Microsoft's strategy in the European antitrust case, where the interoperability information for the workgroup server communication at the time of the hearing in April 2006 was said to amount to 12.560 pages and counting, put together by hundreds of people working "day and night" according to Microsoft. During the court hearing, Microsoft made clear that it would be impossible to make use of this documentation unless one had access to their specific form of representation, which was patented by Microsoft and would require a patent license, which they were not planning to give any time soon.

So in the case of OpenXML, Microsoft now seems to be using Novell to put a pro forma implementation of OpenXML into OpenOffice.org, which will make it easier to migrate from OpenOffice.org to Microsoft Office but can never be sufficient to read all Microsoft Word Documents.

One reason for this is the sheer size of the implementation; another reason relates to the containers used within OpenXML, which make use of Microsoft's proprietary implementations instead of industry standards such as SVG. Moreover, there is really no knowing what kind of hooks Microsoft has put into the specification that people will not detect at first reading. Indeed, it is quite possible that OpenXML will allow what Bruce Perens refers to as "Predatory Pratices" in his definition of an Open Standard.

And while there will be a migration path from OpenOffice.org to Microsoft Office, Microsoft avoids opening the inverse path to any other ODF-compliant Office program, by neglecting ODF support in Microsoft Office.

It appears that with the help of Novell, Microsoft has found a way to use the freedom to modify the software against Open Standards and the Free Software community.

Two of the mechanisms I expect they will seek to employ in this attempt to undermine Open Standards are well-known and comparatively powerful:

1. Incompatibility is always the fault of the competitor

2. Weaknesses in political decisions regarding technology

Point one is well-known as the fear of not being able to interoperate with colleagues, family, or other companies. This is a common fear especially among non-technical users today, who often feel (and are!) helpless in case of incompatibilities, no matter who caused them or for what reason.

With OpenXML, it appears as if there will be interoperability on paper only, but in reality people will experience numerous difficulties unless they use Microsoft Office. Because most users rightly fear and loathe incompatibilities, out of a sense of false security and lack of technological background, they will often choose the dominant product, effectively punishing the competitor for the behaviour of the dominant player.

The second point is slightly less obvious to people who have not had much interaction with the legislative process. The criteria of what constitutes an Open Standard are under permanent debate in various regions of the world and generally conclude at a set of principles that should be adhered to, but mostly without compliance checking.

The OpenXML specification was written to fulfill these criteria in theory, but in reality, will it prevent Open Standards? If so, it will undermine the expressed will of the political debate, which was intended to serve interoperability.

But understanding this and reaching a correct conclusion requires some grasp of technology, and the apparent strategy behind OpenXML obviously counts on the fact that politicians either are isolated from technology or not interested in the technological background and will apply a "the truth must be somewhere in the middle" approach instead of considering the technical facts.

The result of this then is the "mistaken salomonian solution" of accepting both ODF and OpenXML as sufficiently Open Standards, which is no solution, at all.

A common joke about Open Standards is that they are great because there are so many to choose from. In fact, a situation where each vendor has their own "Open Standard" is a situation in which there is no Open Standard, because having a standard means that multiple competing vendors all use the same protocol, format or specification.

As the various standards for power plugs used around the world demonstrate, standards are an area where too much choice can be detrimental to competition and society at large. That is why standard setting efforts generally try to arrive at only one standard for any given purpose.

From a naive stance, having two standards for documents may not seem so bad. But when considering that only ODF really is an Open Standard fully supported by multiple office applications and that the OpenXML format will be pushed with all the power of the dominant desktop vendor, it becomes obvious that accepting both ultimately means undoing the political efforts on Open Standards that have been undertaken in the past years.

Given that the strategy to undermine Open Standards and freedom of choice is comparatively clear and obvious, what is there to do? On the governmental side, in my view it will be necessary to continue the debate on Open Standards and review the current policies to do assessment of levels of interoperability, and to come to one preferred standard for each purpose.

Criteria that should be used for making such a preference are the number of independent programs providing a complete implementation of that standard and length of the specification with a strong preference for concise definitions.

From a vendor's side, it will be necessary to provide clear, concise and understandable information on why OpenXML is not truly a standard and have default settings that discourage its use.

OpenOffice.org should refuse to add OpenXML to its main branch, and we should avoid OpenXML while spreading information about the problems as far as we can.

And finally, we will need to enlarge the global multi-stakeholder discussion about the subject of Open Standards. The Dynamic Coalition on Open Standards (DCOS) that FSFE helped initiate at the recent UN Internet Governance Forum (IGF) may be a first step for that.

Let us return this Danaergeschenk to the store.

The author is initiator and president of the Free Software Foundation Europe (FSFE) and his personal blog is available at the Fellowship of FSFE.

  


Novell's "Danaergeschenk", by Georg Greve - Updated | 247 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here, please
Authored by: Jude on Friday, December 08 2006 @ 02:53 PM EST
... so PJ can find them.

[ Reply to This | # ]

OT here, please
Authored by: Jude on Friday, December 08 2006 @ 02:54 PM EST
... and please make your links clickable.

[ Reply to This | # ]

Another good German word[s] to Novell
Authored by: Nick_UK on Friday, December 08 2006 @ 02:58 PM EST
auf Wiedersehen...

Nick

[ Reply to This | # ]

What about being Open about the issues?
Authored by: Anonymous on Friday, December 08 2006 @ 03:18 PM EST
The approach being advocated appears to be that everyone should avoid OpenXML.
Another approach is to use the open nature of specs and implementations to
highlight the compatibility problems. Help IT to know how to write their RFPs to
specify true compatibility vs. superficial compliance.

Groklaw's lesson to me is that focusing the glaring light of the web and folks
that care about an issue can highlight both the good and bad of an issue very
quickly.

[ Reply to This | # ]

    You missed one, PJ
    Authored by: overshoot on Friday, December 08 2006 @ 03:22 PM EST
    One of the great classic abuses of standards is when the dominant player has a few "bugs" which deviate from the standard -- and are essential to interoperability.

    In the case at hand, all Microsoft needs to do is have their implementation of EcXmL be not quite as described. That won't cost them any sales, and any potential competitors will be up against:

    • Reverse-engineering the "real" format
    • Choosing to comply with the published spec -- and losing for being MS-incompatible, or
    • Being (sorta) MS-compatible, and having some good-hearted volunteer publish voluminously on how they don't comply with the published spec.

    [ Reply to This | # ]

    The importance of this battle is great
    Authored by: freeio on Friday, December 08 2006 @ 03:23 PM EST
    This document-standard business is much more important than many people seem to realize. The lock-in achieved by the “must-be-upgraded-immediately” standard churn is one of the most powerful forces behind the monopoly dominance of the Word/Excel hegemony. At any office, it is desirable to have everyone able to write and read the same format. Certain users use the programs out to the limits of the programs capabilities, and the honest expectation is that any form or document made on one system will operate and reproduce identically on another system. As long as all of the systems run identical versions of identical software, then this is nearly achievable. But as soon as one new system is introduced, it breaks the compatibility, and the only (legal) way to overcome this is to upgrade every single system to the version of the new system.  I have seen this at every office where I have ever worked.

    Now, this odd-man-out upgrade would not be such a problem except that, at some date, any new computer purchased will come pre-installed with a later version that the one on all of the other systems. This is a pre-planned obsolescence of the first magnitude. You virtually will not be able to buy a previous version of any Microsoft product pre-installed on a system once the new version is introduced. Thus every one of the older systems will have to be upgraded.  Now, in some cases, there come a decree from the IT department that no new version will be used. This works just fine right up to the point that some vice-president buys a new system at home, and demands to know why no one can read his most blessed new files. No IT department can withstand the onslaught of unhappy upper-level managers, who though technically quite ignorant, nevertheless demand that the whole company be compatible with their latest toy. “I am the boss and you will do what I say, and do it NOW.”  We have seen this before, more frequently than we wish to admit.

    So this document standard is a very important thing. A truly open standard, that everyone can support is a vast advantage for the computer user, whether an individual or a company. It is a feared, dreadful thing for the monopolist, because it can break their stranglehold on the market. A truly open standard means that competitors can gain entrance into the market, and that is quite unacceptable to a “proven market leader.”

    The simple fact of being able to throw around billions and billions of dollars makes the current “market leader” a force to be reckoned with. Marketing can be overwhelming. Tie-ins with OEMs can be unbreakable. Politicians can and will be bought. If that much is at stake, then why not try to kill off every form of competition, commercial or volunteer? Kill it dead if they can, because it is a threat to the next multi-many billions of dollars. That cash flow is what they worship, that and nothing else. The almighty dollar is their idol, and before it they will sacrifice anything which gets in their way. Bet on it.

    Yes, this is an important battle.

    (Yes, I am still quite alive. We have had nothing short of a miracle, and after 2-1/2 years of battling pancreatic cancer, I am doing beter than I was before it all started.  The cancer blog is here http://diehlmartin.com/cancer.html .)


    ---
    Tux et bona et fortuna est.

    [ Reply to This | # ]

    Back to the Origins
    Authored by: Anonymous on Friday, December 08 2006 @ 03:24 PM EST
    Well, someone will profit from all this, the typewriter business will get a
    boost as everyone goes back to the original "open" standard, the
    written page.

    <I can't believe I said that>

    wb

    [ Reply to This | # ]

    Novell's "Danaergeschenk", by Georg Greve
    Authored by: Anonymous on Friday, December 08 2006 @ 03:44 PM EST
    If "Danaergeshenk" is a gift borne by Greeks, then surely the English
    equivalent already exists. It's called a Trojan Horse.

    [ Reply to This | # ]

    saving documents
    Authored by: Anonymous on Friday, December 08 2006 @ 04:01 PM EST
    I remember a situation where if you were careful about organizing the html code
    in your html documents carefully, or used a program specifically designed for
    html, to keep the actual code organized and neat - and then you opened up that
    document in OpenOffice, for instance (I guess at that time it was Star Office) -
    that Star Office would mangle your html, which you tried to keep nice and clean,
    and organized and neat.

    Simply by opening a document (if you had auto-save or whatever), or just making
    one change in a "intelligent" html editor, or "WYSIWYG" html
    editor, as opposed to an html editor designed for html, designed to keep the
    underlying code clean, neat, and organized - just so much as opening up and
    saving a document could turn it into a a jumbled mass of nonsense (more or
    less). Not that you couldn't then use the document on your website, but just
    that the code was jumbled up and if you wanted to later come along and implement
    functionality that the WYSIWGY html editor didn't do very well, you couldn't,
    because the code was so mangled it was very difficult to work with the raw code
    itself.

    The xml code should be able to be edited by hand, essentially is what I'm saying
    - including comments, syntax, "neatifying", and so on. And the editor
    shouldn't mangle your "neatifying". Of course, that's wishful
    thinking, but anyway, I won't accept any less for any webpages I do.

    Getting a standard acceped by ISO is one thing - but perhaps we should also
    consider how the particular applications that are being used work with that
    standard (at a government level). In other words - if I study OpenXML day and
    night, night and day - for many days and nights - and I put together a volunteer
    team and put together a simple editor that saves in that standard, but yet keeps
    the underlying code as nice and clean as possible, and then along comes
    Microsoft Office, takes my nice clean code, and mangles it into something that
    is much less clean and neat and desirable - that - aesthetically speaking, in
    terms of keeping the underlying code organized, that should be a knock against
    Microsoft Office.

    In other words - if the standard simply represents a way to interpret what MS
    Office does, then it's not really a standard in the sense of being a standard,
    where a standard helps standardize the way something is - which, in this case is
    a document format, which is a subset of xml. Xml is no different from html in
    the sense that it can be used in web pages, and in the sense that there is
    underlying code, which can be edited directly if you're familiar with it or have
    a reference book handy, or can be used via a WYSIWYG editor. The common problem
    is that WYSIWGY editors mangle the code so you can't very easily then come along
    and edit the code directly (which, it being xml, is something you should still
    be able to do). Having MS Office (an application that edits the xml standard)
    play the role of a law of physics (essentially no different than a natural
    language, an immovable object), or something along those lines, in a standard
    which is supposed to be a document format, sort of defeats the purpose of what a
    standard for a document format is.

    It's not enough to have the requirement be ISO-approved, obviously, because the
    ISO process itself gets hijacked. Ok, fine, it's a standard. A standard in how
    you mangle my clean, nice, organized xml code. So by adhering to the standard, I
    am simply codifying the mangling of my code. That's not a standard, at least it
    shouldn't be a standard.

    It's not enough to have it open, it's not enough (if it gets ISO approval),
    obviously, because the whole ISO process, in that sense, is being used to simply
    standardize the mangling of clean code that makes sense.

    It's being worked backwards. Here we have MS Office, and we're taking MS
    Office's file format, and turning it into a standard. That's wrong.

    What you do is you start from scratch, you create a standard - you look at what
    documents need, what is necessary to internationlize, support all languages that
    are supported, including Japanese family names, which requires 32-bit encoding
    because each one is like a coat of arms or something, you look at support for
    handicapped individuals, you look at mathematics, physics, and perhaps even
    music or whatever. In any case, perhaps its a subset of that. Perhaps it's just
    8-bit encoding, or whatever - perhaps it sticks with ISO 8859-xx, and doesn't
    get much into Japanese family names - well, it probably should, but in any case
    - you create a standard from the needs to fit a particular situation.

    For example, treating Japanese family names as a law of nature, or Korean
    characters or Chinese characters as a law of nature - well, that's where the
    standard should stop. We can't say, "sorry, you're going to have to change
    your language, our standard doesn't support it" - that would be absurd, and
    would defeat the purpose of the standard in the first place.

    I don't, however, think that it's inappropriate to ask a vendor to change their
    software to comply with a standard. Do we seriously give MS Office the standing
    of a national language? The standing of English, or French, or Spanish, or
    Chinese, or Japanese? Do we really have no right, in the standards process, to
    ask Microsoft to change their software? Well, not so much change their software,
    but to implement the standard the other way around - for MS Office to implement
    the standard, not for the standard to implement MS Office, which is obviously
    why it's 4000+ pages, and getting bigger.

    The standard is not really a standard - it's MS Office. It's MS Office coming
    along and saying, well, we ARE a standard already - we're just going to codify
    ourselves as a standard. Exactly John Stuart Mill's complaint about marriage in
    England in the 1800's and before. Just a codificiation of cavemen, essentially.
    Taking an existing situation, which is unacceptable, and turning it into law.
    That does no one any good.

    So if they do succeed in turning MS Office into a standard, ethically, and
    morally it changes absoutely nothing. The actual "what's going down"
    doesn't change one iota. It just now gets to be called a "standard".

    As far as Novell, I'm not quite as negative as some folks here, becuase I'm
    "wait and see" on that - but as far as this ISO standardization of
    Open XML, from what I've seen, it's exactly the same thing John Stuart Mill
    complained about with regards to marriage in England 100+ some years ago. It's
    simply a codification of an unacceptable situation.

    Undoing the damage often takes centuries.

    [ Reply to This | # ]

    • Dang... - Authored by: Anonymous on Friday, December 08 2006 @ 11:26 PM EST
    Not entirely enlightening
    Authored by: meydey on Friday, December 08 2006 @ 04:08 PM EST
    While the author covers some well-traveled thoughts on standards, I don't follow his reasoning for the first part of this statement:
    OpenOffice.org should refuse to add OpenXML to its main branch, and we should avoid OpenXML while spreading information about the problems as far as we can.
    While I agree Microsoft's OpenXML is not a standard, it is the format they're likely to use, just as with their older proprietary format. So, what is the benefit to OpenOffice.org not to include the ability to read and write it? If you're dealing with other people, the alternatives are to have to use MS Office, find another less convenient way to convert them so you can use them, or force the other party to have to convert them. That seems contrary to the "open" and "free" axioms of which I'm aware. One of the primary reason's for OOo's growth to date has been the ability to work with MS docs.

    And on the topic, Novell has clearly stated the preferred and default format is ODF-- why is the ability to deal with OpenXML a bad thing, and yet another errant stone tossed in Novell's direction? I think we should support giving people every reason not to use MS Office or their format, and hope it may eventually be replaced with the better standard.

    ---
    “Tell me and I'll forget; show me and I may remember; involve me and I'll understand.” Chinese Proverb

    [ Reply to This | # ]

    Wait until some US diplomat tries to communicate overseas
    Authored by: Anonymous on Friday, December 08 2006 @ 04:36 PM EST
    Just wait until some US diplomat tries to communicate with someone overseas.
    Most of the rest of the world will be using ODF, and the US government, duped
    and bribed into staying with Microsoft, will find itself isolated in a
    communications box.

    [ Reply to This | # ]

    German is an interesting language, and many of its words have made it into English
    Authored by: Anonymous on Friday, December 08 2006 @ 05:13 PM EST
    Well, English *is* a Germanic language, believe it or not.

    [ Reply to This | # ]

    Maybe look it other way...
    Authored by: ikocher on Friday, December 08 2006 @ 05:14 PM EST
    I am not fun of M$ and their "tactics", not even close.

    But I just think on this... what if (as hp used to say) what if the comunity
    sees this "office support" in openoffice as a tool to make a point?
    Let's say that novell implementation works, and OO can import the m$.doc thing.
    now it will be able to save it in odf, native OO format. Well I see a way to
    "test" how good it goes, how good the format is to represent what is
    created in one format can be represented in the other.

    If it turns out that ODF support what m$.doc supports, then you can see no
    problem there, and see where it doesn't work, for instance, formulas, macros,
    programing, etc. I know that there is some lack of these in OO. Now this can
    be great, OO will learn where it needs the fixes, features, etc.

    I know there is a big list out there of needed features, but this is a way of
    checking interoperability at the sae time. I t doesn't mean that OO includes
    the patches in the main release, just for people that need (developers, special
    users, testers, and so).

    Also, In the mean time the format are going to be "tried",
    performance, memory use, disk space, accesability (blind, deaf), security, and
    so on. This can be a direct attack at whatr m$ says about odf, but they don't
    have code to show it, while OO will have it, and everyone out there be able to
    check if it is an implementation problem or a standard problem.

    If m$ is willing to make it difficult, using this tactics, why not make it fun
    at the same time? If they say their "standard" is better, put them to
    the test. They will notbe able to do it, not odf import, so the play ground
    will be OO, and they have no real control on it.

    Again, the Troyan horse is already know for it "functionality" so
    there is no secret there. What if we place a a big pot with boiling oil under
    it, or set it on fire so people can enjoy a good BBQ? Let's use this situation
    for advantege, and not try to stop their "good will".

    I am totally with PJ point of view, but I think we can make the next step, and
    not let the convicted monopolist do it.

    This is sort a little bit of food for thought, don't flame me too much. I
    understand the whole patent mess, extensibility os m$ format, etc. I have been
    tracking it all this time.

    Just comment ideas ... please. Keep flame level low, my shield is not used to
    being flamed :)


    Ivan

    [ Reply to This | # ]

    Another German term: "Bärendienst"
    Authored by: scorp123 on Friday, December 08 2006 @ 05:40 PM EST

    There is another German term coming to my mind: "Bärendienst",
    sometimes also written "Baerendienst" ("ae" =
    "ä"). Guessing from the links on the German Wikipedia page
    Scandinavian people might know it as "Bjørnetjeneste" (Denmark +
    Norway) and "Björntjänst" (Sweden) -- apparently the concept is known
    there as well :-)

    Litterally translated it means "a bear's service". "Jemandem
    einen Bärendienst erweisen" = To do someone a bear's service = To do
    someone a serious disservice.

    According to the German Wikipedia this is based on a French fable by Jean de La
    Fontaine, where a bear wants to remove a fly from an old man's face ... by
    crushing the old man's skull with brute force.

    Fontaine's conclusion was: "Rien n'est si dangereux qu'un ignorant ami.
    Mieux vaudroit un sage ennemi."

    Translated into English:

    "Nothing is as dangerous as a stupid friend. A smart enemy is of far more
    value."

    In other words: With "friends" like Novell you don't need enemies.

    Hence, a "Bärendienst". Thank you Novell, we love you so much now ...



    Regards,
    Scorp123

    [ Reply to This | # ]

    Novell's "Danaergeschenk", by Georg Greve
    Authored by: bigbert on Friday, December 08 2006 @ 05:45 PM EST
    Hammer. Nail. Spot on.

    ---
    LnxRlz!

    [ Reply to This | # ]

    Novell's "Danaergeschenk", by Georg Greve
    Authored by: Anonymous on Friday, December 08 2006 @ 05:46 PM EST
    A common joke about Open Standards is that they are great because there are so many to choose from. In fact, a situation where each vendor has their own "Open Standard" is a situation in which there is no Open Standard, because having a standard means that multiple competing vendors all use the same protocol, format or specification.

    Really? I though the standard joke was about Microsoft saying "We love standards - in fact we love standards so much that we create a new MS Office standard every three years."

    [ Reply to This | # ]

    Seems the document format does not matter...
    Authored by: gjleger on Friday, December 08 2006 @ 06:40 PM EST
    Seems it does not matter what the document format is, if you do not run MICROSOFT Office, Microsoft will not let you open it. This story explains how you will need an "unauthorized document reader" to decrypt and read office files.

    [ Reply to This | # ]

    Which is why HTML is the future
    Authored by: Anonymous on Friday, December 08 2006 @ 06:55 PM EST

    I suspect someone will come up with an open source program that uses HTML to do
    everything Microsoft Office (and Open Office) does.

    No, it's not ready yet, but I've seen some awfully good HTML documents on the
    web, mostly at universities who publish their catalogs online.

    (As an aside, how well does, say, Firefox read straight XML documents? Would
    HTML be needed?)

    And I agree with others who say that the world outside the U.S. will be avoiding
    MS formats. U.S. companies who do business overseas may have to do without MS
    formats for their overseas business.

    [ Reply to This | # ]

    How about "d12k"?
    Authored by: Anonymous on Friday, December 08 2006 @ 07:05 PM EST
    Am I the first one to be of the opinion this word should be referred to as
    "d12k", in the tradition of "internationalization", et.
    al.?

    :-)

    [ Reply to This | # ]

    Speculation
    Authored by: luca.b on Friday, December 08 2006 @ 07:21 PM EST
    It appears that with the help of Novell, Microsoft has found a way to use the freedom to modify the software against Open Standards and the Free Software community.

    I think it's mostly speculation. While the deal by itself needs to be kept under observation, all we saw so far are press releases and little else. Where's the contributed code?

    ---
    Violence is the last refuge of the incapable. - Salvor Hardin

    [ Reply to This | # ]

    Novell's "Danaergeschenk", by Georg Greve
    Authored by: josmith42 on Friday, December 08 2006 @ 07:43 PM EST

    I started reading this article without realizing that PJ hadn't written it. A got about a third of the way through the article before realizing that the writing style was completely different. Once I realized that, it was kind of refreshing. (Not that I don't like PJ's writing style, mind you. It would be like listening to Beethoven all the time, and then one day, hearing Berlioz. It's something different.)

    This is further proof that PJ isn't a real person. She is an AI application written in Python and Java. That's where the name PJ comes from to begin with. It's an acronym. The pseudonym "Pamela Jones" is just a front.

    ---
    This comment was typed using the Dvorak keyboard layout. :-)

    [ Reply to This | # ]

    Community Review during the ISO comment period? Novell's "Danaergeschenk", by Georg Greve
    Authored by: tce on Friday, December 08 2006 @ 09:33 PM EST
    OpenXML will have a fixed length review and comment period prior to an ISO
    vote.

    That vote needs to be, and can be confronted with comments from every single
    page of the 6000 or so pages of documentation.

    This we, and maybe a few other interested communities, can do.



    [ Reply to This | # ]

    Applause due
    Authored by: Anonymous on Friday, December 08 2006 @ 09:52 PM EST

    It seems that each time we turn a corner in the sage of the Novell-MS marriage, we discover a new, and sinister ramification for the world of free.

    One has to hand it to Microsoft, this was a masterstroke.

    And let's not forget the prize for best supporting actor, which goes to Novell. Thank you, Novell. Thank you so very much!

    [ Reply to This | # ]

      power plugs -- how about the Internet itself
      Authored by: qu1j0t3 on Friday, December 08 2006 @ 11:04 PM EST

      As the various standards for power plugs used around the world demonstrate, standards are an area where too much choice can be detrimental to competition and society at large.

      The Internet itself was made possible by standardisation on TCP/IP. It's reasonably self-explanatory that the network is broken to the extent that standards are not followed. This is also a powerful argument against software patents, since patents simply rule out competition between vendors in implementing infrastructure or platforms: in other words, an instant antitrust apocalypse. This is Micro$oft's Big Dream.

      ---
      I have a semicolon and I'm not afraid to use it.

      [ Reply to This | # ]

      Novell's "Danaergeschenk", by Georg Greve
      Authored by: gbl on Saturday, December 09 2006 @ 03:06 AM EST
      There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- Tony Hoare

      ---
      If you love some code, set it free.

      [ Reply to This | # ]

      Novell's "Danaergeschenk", by Georg Greve
      Authored by: Anonymous on Saturday, December 09 2006 @ 04:18 AM EST
      If you follow the story links from story to story, you eventually end up at the blog of someone from Microsoft who talks about how they ended up with the date format used in their "new file format" for MS-Excel ("OOXML"). Brian Jones - SpreadsheetML Dates

      I say "new file format" in quotes, because it's clear that the new format is really just a conversion of the old binary format into ASCII text. The new MS-Word format has a similar relationship to the old ".doc" format. The ".doc" and ".xls" files are not really "formats", they are just "dumps" of the internal program representation.

      The new OOXML format is not a new universal document format, nor apparently was it originally intended to be. That perception appears to be something that the Microsoft marketting department siezed upon either as a PR effort or due to a complete misunderstanding of what the OOXML was. Rather, the technical people at Microsoft seem to view OOXML simply as a way of more easily documenting and describing the old formats, bugs, quirks, and all. It is intended to make it easier to write file filters for programs which are not word processors or spreadsheets but which want to import and export MS-Office documents. This isn't something new, and lots of people have reverse engineered the ".xls" spreadsheet format in particular to allow you to export data to a spreadsheet to manipulate it in ways not supported by the original application.

      ODF format however is something completely different. It is intended to be independent of any particular word processor or spreadsheet. A lot of time was spent doing things the "right" way because it was expected that the format will need to be useful for many years in the future. The intention was to try to avoid any design mistakes that we would end up regretting in future.

      From this we can see that the goals and objectives of ODF and OOXML are completely different. ODF is intended to be readable a hundred years from now, while with OOXML that simply wasn't a design consideration. OOXML is simply an incremental change to the existing ".doc" and ".xls" file formats.

      I don't think Microsoft had any deeply thought out grand strategy behind their new OOXML format. I think what happened was that a planning comittee in Microsoft knew that they were having problems working with file formats and decided that XML was the answer. So they passed a recommendation up the ladder, and a decree was issued that all file formats were from now on to use XML. As a result some team of programmers was given the job of converting the existing formats to XML. Which they did, labouriously converting the old binary format feature for feature to something that could vaguely be called XML. It isn't pretty and it isn't useful, but at least it didn't require significant change to the internals of the existing MS-Office applications.

      So What Does This Mean?
      What this means is that if you want to preserve a document for long periods of time in the original format, then the only document format that even deals with this issue is ODF. A good word processor or spreadsheet will allow you to import or export other file formats. Importing an OOXML file into OpenOffice.org or KOffice (or whatever) is really no different than importing a ".doc" or ".xls" file, something we have done for years.

      However, we should realise that there will never be a perfect translation between ODF and OOXML. This is not however due to some clever evil plan on Microsoft's part. It's because OOXML is simply not as technically capable as ODF; it's not intended to be a universal file format.

      There has been some discussion on how Microsoft ought to support ODF. Personally, I think this would be a bad thing at this time. We are better off if they don't support it for at least several years until ODF has the kinks worked out of it, and there are a large number of existing ODF documents that they need to be compatible with. If Microsoft were to offer support for ODF now, they would implement it badly (due to incompetence, not design) and create a split or "fork" in the format that would defeat the whole intent of it.

      What people need to do is to promote ODF for use with all software other than MS-Office. This means more than just word processors and spreadsheets. For example, I am researching doing a project that will store the project data in an ODF spreadsheet. In this class of software, people very often want to create the data in a spreadsheet or import it into a spreadsheet anyway, so why not simply use ODF as the native format? Doing this promotes ODF in some small way while resulting in an application that is superior and easier to use because it avoids an unnecessary data import/export exercise.

      I believe that ODF addresses a genuine need in the market. Eventually, Microsoft will be forced to support it. I believe however that we are better off if they oppose it until they have lost a significant amount of market share.

      [ Reply to This | # ]

      Too much choice - 1990s SVGA mess and Plauger on C++
      Authored by: Wesley_Parish on Saturday, December 09 2006 @ 04:58 AM EST

      Circa Anno Domini 1997 I was practically given a book titled "PC Video Systems" by Richard Wilton, published by Microsoft Press, 1994, by someone in a local bookshop. Chapter 13 has some interesting things to say about standards and the lack of them:

      Because there is no de facto industry standard for SVGA hardware, anyone who intends to develop portable software for SVGA systems must decide how to deal with the variety of SVGA hardware implementations.[...] In some ways, SVGA programming is a journey through the untamed frontier of video programming. SVGA technical documentation is often cryptic, inaccurate, or out of date; non-standard I/O port assignments, sporadically implemented BIOS functions, and strangely configured video modes are common; and, of course, you'll find that hardly anything you write is portable from one vendor's hardware to another.

      Now, SVGA had been IBM's development of its prior VGA standard; except it hadn't been fully defined. And so every-man-and-his-dog had had a go at re-defining SVGA. The result was the mess so described.

      Microsofties such as Brian Jones will no doubt complain when I say this, but it must be said, MS OOXML is the definitive attempt to be compatible with Microsoft Office - and before that MS Word, and Excel - file formats covering at least a decade. There is just one major problem - most of those file formats have some incompatibilities with the ones preceding them, and are naturally incompatible to at least a small degree with their replacement applications and office suites' file formats. (There has to be some incentive for upgrade after all - there may be one born every moment, and some mothers do 'ave 'em, but they don't grow on trees - at least not yet! ;)

      When I was starting programming, I read an article by Dr. P.J. Plauger in Dr Dobbs Journal - c. 1993? 1995? - when he said that the problem with too-large computer languages such as C++, Algol 68 and PL/I, was that there were rules, but those rules could be bent very easily, and very drastically. To the extent that logic bombs and such hidden errors could proliferate. Since the compiler could not be certain that any given expression meant any one thing, it could in theory come up with any result.

      I really don't have anything to add to Georg C. F. Greve's comments on the Microsoft OOXML file format - all I really need is for Dr. P.J. Plauger to post a URL to his article - and let Microsoft explain why it doesn't apply to MS OOXML and why Microsoft's XML parser is necessarily infallible.

      ---
      finagement: The Vampire's veins and Pacific torturers stretching back through his own season. Well, cutting like a child on one of these states of view, I duck

      [ Reply to This | # ]

      Doesn't Microsoft need a separate implementation?
      Authored by: Anonymous on Monday, December 11 2006 @ 05:29 PM EST
      If I remember correctly, one of the basic requirements for being approved as a
      standard by international standardization bodies (like ISO), is that there exist
      at least two separate implementations of the specification. As far as I know,
      only MS Office 2007 currently implements the OpenXML spec, and Microsoft would
      therefore need someone else to implement it, too.

      Could this actually be one of the major reasons for the deal with Novell?

      [ Reply to This | # ]

      Wrap-up of the discussion
      Authored by: Anonymous on Tuesday, December 12 2006 @ 02:02 AM EST

      I would like to thank everyone on this site for their extremely insightful comments, some of which qualified as excellent articles in their own right.

      Since I've noticed that a couple of questions remained and I wanted to do the discussion in this forum some justice, I've put together an "OpenXML wrap-up after D12K" on my blog, which is also where I am planning to publish an article on some of the backgrounds in the next days.

      Regards,
      Georg Greve

      [ Reply to This | # ]

      thank goodness for Usenet
      Authored by: qu1j0t3 on Sunday, December 17 2006 @ 08:02 AM EST

      (Thanks to Google Groups) I've been reading some old threads circa 1990/1 at a time when the FSF and GPL first began to really stir things up. In fact, by 1991 - the year Linux was born - it is possible to see claims that RMS and the FSF had already revo lutionised the industry (a self-evident claim today). In these threads we see the ancestors of almost every one of today's talking points, usually expressed firmly and precisely (this is quite a few Eternal Septembers ago, after all).

      But it was this plaintive, prescient para graph by Kevin Paul Herbert which prompted me to post here:

      Why is so much bandwidth being used to talk about how to get around the copyleft, and so little about the ethics of the situation?

      Kevin

      ---
      I have a semicolon and I'm not afraid to use it.

      [ Reply to This | # ]
      Groklaw © Copyright 2003-2013 Pamela Jones.
      All trademarks and copyrights on this page are owned by their respective owners.
      Comments are owned by the individual posters.

      PJ's articles are licensed under a Creative Commons License. ( Details )       		Site layout based on Woodlands theme by Bryan Bell.
      Groklaw logo by John Crowley.
      News Picks logo by Ted Thompson.
      Powered By GeekLog
      Created this page in 0.05 seconds