Gepubliceerd: Woensdag 24 september 2008
IBM dreigt uit standaardisatieorganisaties te stappen die 'oneerlijke procesinvloeden' niet kunnen verhinderen. Aanleiding is het 'doorduwen' van Open XML.
Toon volledig artikel
Ach, het is IBM maar. Ze moeten doen wat ze niet laten kunnen. In praktijk doen ze exact hetzelfde wat ze anderen verwijten.
In praktijk doen ze exact hetzelfde wat ze anderen verwijten.
En weer iemand die de verzinsels uit de Microsoft FUD molen klakkeloos slikt. Of heb je bewijs voor deze boude bewering?
@Peter
Nee, ik slik niet de FUD-molen van een bedrijf. Dus ook niet van Microsoft. Als je kijkt naar de geschiedenis van IBM, dan kan je tot dezelfde conclusie komen.
Dat kan, maar zonder bewijs dat het in deze situatie gebeurt is kan ik er niets mee. IBM was ooit een grote monopolist, maar om daar nu nog steeds je mening op te baseren...
natuurlijk heeft IBM gelobbied tegen OXML, net zo goed als dat Microsoft er voor heeft gelobbied. De vraag is alleen, wie te ver is gegaan. Op dat punt wijzen de meeste vingers klaarblijkelijk naar Microsoft.
Het is multinational eigen om grenzen te zoeken en op te rekken.
De belangrijkste doel voor IBM om tegen OOXML te stemmen is om hun eiegen producten beter te kunnen verkopen. Hun producten ondersteunen momenteel ODF. Indien ODF de enigste ISO-standaard zou zijn, zou IBM een behoorlijke voordeel hebben bij de verkoop van hun software.
De kern is dat IBM gewoon een commercieel bedrijf is die moet denken aan "Shareholder Value".
Daarbij hoort dit soort "gevechten" op de markt van software.
Het is bijvoorbeeld bekend dat bij verschillende overleggen van de nationale ISO organen de IBM vertegenwoordigers al direct hebben aangegeven dat ze opdracht hadden vanuit hun organisatie om tegen de OOXML standaardisatie te stemmen.
Als een dergelijke dictaat vanuit een bedrijf is wat IBM verstaat onder het participeren in standaardisatie processen dan denk ik dat bijvoorbeeld ISO/IEC daar niet op zit te wachten. IBM heeft heel duidelijk gemaakt met hun houding dat zij het bedrijfsbelang zetten voor het belang van ISO/IEC. Dat is hun goed recht maar maakt hun participatie ook dramatisch minder nuttig. ISO/IEC is namelijk een organisatie gericht op het bevorderend van standaarden en standaardisering en niet gericht op het blokkeren van standaarden.
IBM is de belangrijkste contributeur aan het ODF standaardisatie proces en als dat gaat inhouden dat IBM mede van daaruit gaat voortaan standaardisatie van formaten van andere partijen gaat blokkeren is hun blijvende lidmaatschap zelfs hoogst ongewenst.
Een bekend voorbeeldje van IBM beinvloeding tijdens het standaardisatie proces was trouwens dat Kenia, een landje met normaliter heel beperkte participatie in JCT1 standaarden vorig jaar tijdens de eerste fase van de OOXML een heel lijvig document inleverde, groter dan dat van alle ander 100 of zo leden van JCT1 en dat achteraf bleek dat dit document volledig uit IBM Duitsland afkomstig was en niet een gevolg was van afwegingen binnen het Keniaanse committee.
Het is bijvoorbeeld bekend dat bij verschillende overleggen van de nationale ISO organen de IBM vertegenwoordigers al direct hebben aangegeven dat ze opdracht hadden vanuit hun organisatie om tegen de OOXML standaardisatie te stemmen.
Heb je daar bewijs voor?
Ik heb naar een paar losse stukken van de OOXML draft gekeken en daar was, naar mijn mening, behoorlijk wat werk nodig om die naar de gewenste kwaliteit voor een standaard te krijgen. Meer tijd dan waarvoor een fast-track proces ruimte biedt.
P.S. Is de officiele versie van de standaard al beschikbaat? Die was een paar maanden geleden gepland.
Een bekend voorbeeldje van IBM beinvloeding tijdens het standaardisatie proces was trouwens dat Kenia, een landje met normaliter heel beperkte participatie in JCT1 standaarden vorig jaar tijdens de eerste fase van de OOXML een heel lijvig document inleverde, groter dan dat van alle ander 100 of zo leden van JCT1 en dat achteraf bleek dat dit document volledig uit IBM Duitsland afkomstig was en niet een gevolg was van afwegingen binnen het Keniaanse committee.
Jij zegt: Kenia vindt een berg relevant commentaar en stuurt dat in: "Doe daar alsjeblieft iets aan". Sinds wanneer is het wijzen op defecten in de standaard onbehoorlijk?
Jij zegt: Kenia vindt een berg relevant commentaar en stuurt dat in: "Doe daar alsjeblieft iets aan". Sinds wanneer is het wijzen op defecten in de standaard onbehoorlijk?
Hoezo zei ik dat Kenia dat document heeft gevonden ?
Het betreffende PDF document van IBM Duitsland was nooit gepubliceerd en er stond ook geen kenmerk van IBM duitsland op maar er stond gewoon Kenia boven.
Alleen uit de document eigenschappen bleek de schrijver een duitse IBM medewerker te zijn. Het kwam pas naar voren maanden later toen ISO/IEC JTC1 de ingestuurde doucmenten ergens op een publieke plaats neerzette.
<hAl>Het betreffende PDF document van IBM Duitsland was nooit gepubliceerd en er stond ook geen kenmerk van IBM duitsland op maar er stond gewoon Kenia boven.</hAl>
Waar vind ik het document? Dan ga ik zelf wel op zoek naar de ledenlijst van de Keniaanse technische commissie.
Andere Peter, maar toch bedankt. ;) Het korte artikel inclusief de reacties geven voor mij aan hoe verschrikkelijk moeilijk het is geworden om de waarheid te vinden in het mijnenveld dat dit Open Formaat 'meningsverschilletje' is geworden.
hoe verschrikkelijk moeilijk het is geworden om de waarheid te vinden in het mijnenveld dat dit Open Formaat 'meningsverschilletje' is geworden.
Zie hier het probleem: Microsoft vaart wel bij complexiteit. In een transparante wereld hebben kleine partijen immers goede kansen.
Ik denk dat ze in Redmond wel een flesje hebben ontkurkt toen ze hoorden, dat de EU graag wilde dat ze OOXML als open standaard registreerden. Hoefden ze in elk geval zelf geen reden te vinden om die markt te verstoren.
Nee, toen was er namelijk ook nog helemaal geen sprake van dat OASIS hun Open Office formaat aan ISO zou voorleggen.
Er was dus een heel stabiel situatie waarin Microsoft eigenlijk geen actie hoefde te ondernemen en de markt liep toch wel goed voor hen.
Juist doordaat de EU zowel OASIS als Microsoft heeft opgeroepen hun formaten te standaaridseren en aan ISO voor te leggen is er een soort competitie sfeer tussen deze formaten ontstaan. Het lijkt me niet dat Microsoft daarop zat te wachten.
Volgens mij moet je geen compatibiliteitstrucs opnemen in je formaat maar het formaat zo opbouwen dat je uitzonderingen er inpassen en daarvoor een goede conversie schrijven.
Dank je; die website schetst een ander beeld dan hAl. (Zie ook mijn opmerking over "halve waarheden" verder in de commentaren.)
In de woorden van Yoon Kit Yong:
What would make a really interesting article is the actual content of the comments which Kenya has picked up on and felt was accurate and important enough to submit as its National Body comment against Fast Tracking MSOOXML. Remember, National Bodies are completely free to refer to experts, consult online documents and extract information from any source which they think is important and accurate.
National Bodies are completely free to refer to experts, consult online documents and extract information from any source which they think is important and accurate.
Dat is zonder meer waar.
Het is echter dan nog wel de vraag waarom Kenia een land dat vrijwel op geen enkele JCT1 standaardiseringprocessen reacties stuurt of stemt ineens voor OOXML een vermogen uitgeeft om een duitse IBM expert in te huren om voor hen een verder anonieme reactie te schrijven.
hAl, je probeert de aandacht af te leiden van de relevante vragen:
- Waren de gesignaleerde problemen relevante technische issues in de voorgestelde standaard?
- Zijn de problemen inmiddels op technisch correcte wijze opgelost?
- Hebben de oplossingen nieuwe problemen opgeleverd?
Wanneer het doel is om een technisch correcte technische standaard op te leveren zijn dat de vragen die van belang zijn voor de deelnemers aan het proces. Waar de lijst met potentiele issues vandaan komt is niet belangrijk.
Willen we een documentstandaard die van 1900 een schrikkeljaar maakt?
Nee, dat hebben ze gefixt: er is nu een vlag waarmee je kunt kiezen of je wilt dat 1900 een schrikkeljaar is.
Voor mij is het nog maar de vraag of dat er überhaupt toe doet. Sinds wanneer is het verboden om van een patroon af te wijken?
Het ging om procesbeinvloeding toch ?
Het zou pas verboden zijn als IBM de Kenianen had omgekocht om hun eigen protesten door de achterdeur bij de ISO/IEC binnen te krijgen. Ik neem maar even aan dat men niet zo ver is gegaan.
Ik neem maar even aan dat men niet zo ver is gegaan.
Ah kijk, een nieuwe rookwolk. Je zegt het niet, maar wat rolt ie heerlijk over het scherm. Wedden dat IBM ook niet de moeite neemt om deze pluim te ontkrachten?
Van Microsoft is bekend dat ze niet boven een beetje omkoping staan. Laptops weggeven aan bloggers... weet je nog? Jammer dat hier alleen Zweden boven tafel is gekomen, want het waren er vast meer.
Hoezo zei ik dat Kenia dat document heeft gevonden ?
Het betreffende PDF document van IBM Duitsland was nooit gepubliceerd en er stond ook geen kenmerk van IBM duitsland op maar er stond gewoon Kenia boven.
Alleen uit de document eigenschappen bleek de schrijver een duitse IBM medewerker te zijn. Het kwam pas naar voren maanden later toen ISO/IEC JTC1 de ingestuurde doucmenten ergens op een publieke plaats neerzette.
Wat is nou je punt? Het lijkt alsof je suggereert dat zich Kenia oneigenlijk heeft gedragen en komt daarvoor met een stuk dat geschreven is door een Duitse IBM-medewerker. Tja, misschien is het wel zo dat de Kenianen zich konden vinden in de strekking van de documentatie? Daar lijkt mij niets duisters aan. En sinds wanneer is het gebruiken van externe expertise iets wat niet door de beugel kan? Lijkt mij een prima uitganspunt voor een open standaard!
En wie ontdekte vervolgens dat het ging om een nooit gepubliceerd intern document van IBM? Het lijkt me dat alleen IBM daar toegang toe had, en als jouw theorie klopt hadden zij er geen enkel belang bij om dat document bekend te maken, in tegendeel.
Het zou natuurlijk ook kunnen dat een IBM-GE medewerker, mogelijk van Keniaanse afkomst, en handelend vanuit ongepast eigen initiatief, iemand uit Kenia zo gek had gekregen om dit op te nemen. Daarna ontdekte IBM dat één van haar documenten buiten lag, en meldde ze dat publiekelijk.
En er zijn vast nog wel een berg scenarios te bedenken.
ISO/IEC is namelijk een organisatie gericht op het bevorderend van standaarden en standaardisering en niet gericht op het blokkeren van standaarden.
Precies, en in dat opzicht is het dus heel raar dat er na het aannemen van een standaard (ODF) een hernieuwd standaardisatieproces is gestart. In principe blokkeert ISO/IEC daarmee de eerder aangenomen standaard. Logisch dat partijen daar boos danwel verontwaardigd over zijn.
Precies, en in dat opzicht is het dus heel raar dat er na het aannemen van een standaard (ODF) een hernieuwd standaardisatieproces is gestart. In principe blokkeert ISO/IEC daarmee de eerder aangenomen standaard.
Dat is een vreemde opmerking. Er bestonden ook voor ODF al andere documentstandaarden binnen ISO en ODF stemt daar niet mee overeen. Volgens jou redenering had ODF ook niet een ISO/IEC standaard mogen worden.
Gellukkig neemt IBM nog de moeite om het standaarden eeh systeem "schoon" te houden.
We hebben vast wel gevolgd (ook hier op webwereld) hoe lullig de manier van zaken ging die M$ gebruikte om openXML door te drukken, er waren meer protesten dan goedkeuringen, en toch is het zgn open.
Je moet toch wel oogkleppen op hebben, om niet door te hebben hoe akelig naar die lobby praktijken zijn(niet alleen M$, bv ook de hedendaagse coax kabelboeren).
Even ter info.
Microsoft valt eigenlijk niets te verwijten.
Microsoft wilde het spul er doorheen douwen, en het was juist aan ISO om dat de kop in te drukken.
ISO is er om dat soort zaken te reguleren. Dat Microsoft dat heeft gedaan, is gewoon een manier van aggressief zaken doen, niet echt iets wat nieuw is. ISO heeft zich van een verkeerde kant laten zien, en het is daarom begrijpelijk dat bedrijven deze instantie gaan wantrouwen.
en het was juist aan ISO om dat de kop in te drukken
Ik denk dat ISO/IEC dat heel anders ziet.
Zij zien het als een taak standaardisatie te bevorderen.
Vanuit ISO/IEC gezien is het juist wenselijk dat het bijvoorbeeld Microsoft Office inderdaad een ISO/IEC standaard als default formaat heeft zodat de hele wereld daarmee interoperabel kan zijn.
Het standaardiseren van dergelijke zaken ligt in hun doelstelling.
Het probleem van een standaard is, dat zodra je er meer dan één hebt, het geen standaard meer is.
Zo werkt het dus niet.
Standaardisatie is niet een race naar een finish lijn om als eerste een edict op te kunnen leggen.
Standaaardiseren is het formaliseren en vastleggen van duidelijke afspraken over bepaalde zaken zoals maten, criteria, methodes, technieken.
Standaardiseren is niet het opleggen van een methode om andere methodes uit te sluiten. Dat kan incidenteel overigens wel iets zijn waar je een standaard voor kunt gebruiken.
Microsoft valt eigenlijk niets te verwijten.
Ik wacht op de uitkomsten van het onderzoek dat Neelie Kroes op dit punt uitvoert. De berichten over het betalen van een Zweedse Microsoft partner om lid te worden van het Zweedse nationale lichaam doen mij in ieder geval vermoeden dat Microsoft wel iets te verwijten valt.
(Omkoping overschijdt de grens van een respectabele lobby.)
ISO is er om dat soort zaken te reguleren.
Ja, het ISO secretariaat heeft ook boter op haar hoofd vanwege het niet correct volgen van de procedures. Hetzelfde geldt voor de nationale lichamen waar procedures misbruikt zijn of politici de stem van de technische committees genegeerd hebben. Het ISO bleek niet bestand tegen de grootschalige wereldwijde aanval die Microsoft opgezet had.
De ECMA treft ook blaam
Zij heeft Microsoft de vrije hand gegeven (met onvoldoende controle) om een ECMA-OOXML standaard te maken, met veel te weinig tijd voor een behoorlijke review. De ECMA zou haar "fast-track" rechten moeten inleveren.
De berichten over het betalen van een Zweedse Microsoft partner om lid te worden van het Zweedse nationale lichaam doen mij in ieder geval vermoeden dat Microsoft wel iets te verwijten valt.
Je vergeet dat in Zweden het Microsoft zelf was die aan het Zweedse standaardsinstituut melding maakte van een ten onrechte verstuurd aanbond aan twee partners (overigens juist niet om het lidmaatschap te betalen) door een medewerker en dat Microsoft dit toen ook al direct gecorrigeerd had. (info)
Dat snelle optreden en de openheid van zaken op dat punt vallen juist eerder in de categorie correct etisch handelen.
Dat anderen proberen elementen uit dat verhaal te implanteren in hun eigen versie van de geschiedenis en verder niet vermelden dat het juist Microsoft zelfs was die stappen heeft genoemen en melding heeft gemaakt van deze fout is altijd weer opvallend.
<hAl>Dat snelle optreden en de openheid van zaken op dat punt vallen juist eerder in de categorie correct etisch handelen.</hAl>
hAl, ethiek spel je met de h van hAl; ethisch zelfs met twee h's.
Maar ik herhaal:
Ik wacht op de uitkomsten van het onderzoek dat Neelie Kroes op dit punt uitvoert.
Ik weet dat de handelswijze van Microsoft m.b.t. "commissie vullen" onder de aandacht van de EC is gebracht. De EC heeft de wettelijke mogelijkheden om bewijs te vergaren en als de EC hier iets over gaat zeggen is dat aanzienlijk betrouwbaarder dan een willekeurige blog post.
Ik plaatste de reactie met name om te laten zien dat de werkelijkheid rondom het verhaal dat je citeerde duidelijk nogal anders was dan waar jij het hebt gelezen. Deze kleuring van de werkelijkheid is een opvallend kenmerk van de anti-ooxml campagne.
Als er voor ooxml werd gestemd dan was dat stemmanipulatie door de net lid geworden partners van MS, als er tegen gestemd ooxml werd was dat een succes voor de (ook net toevallig lid geworden) opensource organisaties in hun dappere strijd tegen onrecht.
Vaak ligt het werkelijk verhaal veel genuanceerder maar dat is vaak geen lekker pakkende headline.
Maar ook niet jouw werkelijkheid.
Hiermee geef je eindelijk toe dat jouw verhaal ook niet klopt. Chapeau!
Nee, dat zeg ik niet.
Ik heb duidelijk een andere kij op de zaak dan bijvoorbeeld jij.
Zo vind ik het bijvoorbeeld heel correct handeleen van Microsoft dat ze hun fout in Zweeden direct corrigeren, zelf aanmelden er open over zijn.
Anderen vinden dat misschien wel niet.
Dat zegt niet of mijn verhaal klopt of niet maar het zegt wel dat ik er mogelijk andere naar kijk dan anderen.
Hetgeen Peter R eerst citeerde bevatte naast een andere view toch ook wel bepaald de nodige storende feitelijk onjuistheden en omissies. Die wilde ik met name rechtzetten.
Dat is daar verder nog bij kwalificeer dat ik het handelen zover ik dat kan beoordelend correct vond is mijn blik op de werkelijkheid. Bepaalde mensen zullen alle handelingen van Microsoft veroordelen ongeacht wat ze doen. Dat is hun eigen blik op hun werkelijkheid.
Als iemand jouw verteld dat je werkelijkheid niet klopt en je antwoord daarop dat de zijne OOK niet klopt, dan geef je daarmee toe dat je eigen werkelijkheid niet klopt.
Zo vind ik het bijvoorbeeld heel correct handelen van Microsoft dat ze hun fout in Zweden direct corrigeren, zelf aanmelden er open over zijn.
Ik denk dat het damage control was. Je kan het beter naar buiten brengen en het boetekleed aantrekken om er op die manier in elk geval nog een draai aan te geven.
Als je op die gedachte voortborduurt kan je stellen, dat de toebedachte rol van IBM in het Kenia verhaaltje misschien zo op los zand gebaseerd is, dat IBM het niet nodig vind om er op te reageren. Want verdediging wordt in sommige kringen gezien als: "Waar rook is is vuur!" En als er geen vuur is, waarom zou je dan uitlaten over een willekeurige pluim?
Ik heb duidelijk een andere kij op de zaak dan bijvoorbeeld jij.
dat is je goed recht. Maar jouw formuleringen komen altijd neer op dat, *jij* en alleen jij, de waarheid spreekt. Komen daar reacties op (die hout snijden) dan blijf je doordrammen. Vooral dat laatste is bijzonder irritant en de oorzaak van dat je gemind wordt.
Nee die minnetje komen door kleinzielige mensen zoals jij die het belangrijk vinden dat hun einge standpunten hoger gewaardeerd worden dan die van anderen.
Ga gerust door met die minnetje Puist.
Weer een minnetje van een minnetje denk ik dan.
Ik wacht op de uitkomsten van het onderzoek dat Neelie Kroes op dit punt uitvoert.
Ik heb genoeg van alle beschuldigingen. Ik heb genoeg van alle halve waarheden.
Ik will weloverwogen conclusies, gebaseerd op harde feiten.
ec.europa.eu/co...n/index_nl.html
of
ec.europa.eu/co...n/index_en.html
Alleen even geduld hebben tot het onderzoek is afgerond.
Zelf als zouden ze dat doen, heeft dat verder met dit onderwerp weer helemaal niets te maken. Jij bent weer één van de vele die roepen omdat bedrijf x ook hetzelfde doet hebben ze ineens helemaal geen recht van spreken meer, dat zeg je min of meer letterlijk.
Zoals vele mag ook microsoft over google niets zeggen, die over die niet omdat ze zich allemaal niet netjes gedragen. Als je zo doorgaat mag niemand meer iets zeggen omdat ze allemaal niet zuiver zijn, met als gevolg dat het een nog groter zooitje gaat worden.
Naast IBM lees ik dat er nog meer mensen grote zorgen hebben over de hele gang van zaken. Zelfs zo erg dat er een onderzoek komt. Dat zegt denk ik genoeg over de hele gang van zaken en de betrouwbaarheid van beide genoemde instanties ISO en ECMA
Zelfs zo erg dat er een onderzoek komt.
Dat kan ook niet anders want er is door een bepaalde lobbygroep van MS concurrenten (ECIS)een antitrustklacht ingediend bij de EU en dan is er voor de EU ook plicht daarnaar een onderzoek te starten. Bovendie was dat niet een klacht puur over OOXML maar bijvoorbeeld ook dat Microsoft office producten onvoldoende interoperabel zijn voor concureerende bedrijven.
Even een quotekje van de EU zelf
The Commission's examination will therefore focus on all these areas, including the question whether Microsoft's new file format Office Open XML, as implemented in Office, is sufficiently interoperable with competitors' products.
Ik weet zelf niet precies hoe Microsoft hun office document formaat meer interoperabel kan maken dan door het door ISO/IEC te lante standaardiseren maar misschien denkt de EU daar anders over.
Dat zou me verbazen want eerder al heeft de EU aan Microsoft zelf juist expliciet geadviseerd om hun XML gebaseerd office formaten bij een standaardsorganisatie te laten standaardiseren:
Therefore, it is recommended that:-
Microsoft considers issuing a public commitment to publish and provide non-discriminatory access to future versions of its WordML specifications;
Er zijn trouwens al een paar onderzoeken geweest naar de OOXML standaardisatie binnen ISO vanwege ingediende klachten van tegenstanders van ooxml en het resultaat was tot nu toe telkens dat alle klachten zijn afgewezen.
Bij de afweging wat aan te schaffen/gebruiken kijk je per productgroep toch naar wat op dat moment de meest gebruikte open standaard is en desnoods de proprietary de-facto standaard, en wat de toekomstverwachtingen zijn. Voorheen was het zo dat emotioneel gezien een ISO standaard een betere toekomstverwachting had dan een willekeurige andere concurrerende standaard. Maar dat gevoel is in ieder geval bij mij weg: ISO is niet meer relevant.
Nu ben ik maar 1 techneut, en dus ook niet relevant. De vraag is hoeveel collega techneuten er ook zo over denken.
ODF is vrijwel kritiekloos een ISO standaard geworden.
Destijds was het een must riep men.
En nu is ISO waardeloos.
En wat wil men dan wel? Geen standaarden meer?
Als er nog géén standaard is dan is het wel handig als er eentje komt. Met ODF is een begin gemaakt van een goede open standaard.
Maar MS, bang voor verlies van hun monopolie, moest persé een eigen "open" standaard hebben. Er zijn toen erg vuile spelletjes gespeeld.
MS had toen óók kunnen meewerken aan de ODF-standaard en zou daarmee de verbetering en acceptatie ontzettend hebben bevorderd.
@thieu
Microsoft wilde in het begin wel meewerken aan ODF, maar vond en vindt het belangrijk dat backwards compatibility voor hun oude formaten gewaarborgd bleef. De andere partijen vanden van niet. De scheuring was toen een feit.
IMO, waar partijen samen komen voor een beslissing, moeten allen een beetje water bij de wijn doen.
Microsoft wilde in het begin wel meewerken aan ODF
Volgens mij is dat niet zo.
ODF is begonnen als een pure opvolger voor het OpenOffice formaat gebruikt in OOo en StarOffice.
Er was helemaal geen reden voor Microsoft om daarin te participeren zeker ook niet omdat Microsoft toen al bezig was met een eigen XML gebaseerd Office formaat.
ISO/IEC standaardisatie was toen deze formaten worden ontwikkeld trouwens ook helemaal niet aan de orde. Dat is pas een punt geworden toen de EU and zowel OASIS als Microsoft heeft gevraagd hun XML gebaseerde office formaten te standaardiseren
@hAl
Ik moet dan wel even verder in mijn geheugen graven, maar er staat me iets van bij dat er in den beginne gesprekken waren tussen OASIS en Microsoft. Door de weigering voor de ondersteuning van oude MS Office formaten in ODF is toen de samenwerking geklapt. Microsoft is toen zijn eigen format verder gaan ontwikkelen en OASIS is toen verder gegaan met ODF.
Zolang bedrijven elkaars concurrenten zijn in plaats van elkaars partners blijf je dit soort problemen houden. Het is een probleem van onze economie, het is een probleem van marktwerking. Effectief gezien is het gewoonweg zinloos en zonde van je tijd om twee verschillende standaarden te ontwikkelen die hetzelfde beogen...
Ik vind het wel positief dat Open XML een ISO standaard is geworden. Dit betekent namelijk dat ook Microsoft open standaarden inmiddels serieus neemt en ziet als een manier om hun positie in de toekomst veilig te stellen. Ze hadden echter veel beter kunnen aanschuiven als ODF member. Dit had waarschijnlijk voor veel meer en veel betere publiciteit gezorgd.
Microsoft wilde in het begin wel meewerken aan ODF, maar vond en vindt het belangrijk dat backwards compatibility voor hun oude formaten gewaarborgd bleef. De andere partijen vanden van niet. De scheuring was toen een feit.
Interessante wetenswaardigheid
Microsoft wilde in het begin wel meewerken aan ODF, maar vond en vindt het belangrijk dat backwards compatibility voor hun oude formaten gewaarborgd bleef. De andere partijen vanden van niet. De scheuring was toen een feit.
Een van de verschillen tussen ODF en Open XML is de 'backward compatibility'. Open XML is beter in staat om oude Office-documenten om te zetten naar het Open XML-formaat. Een groot voordeel, want er zijn - ook binnen de overheid - zeer veel bestanden die ooit in Microsoft Office zijn gemaakt.
Artikel Microsoft website
?:
- Hoeveel beter is OpenXML in het omzetten van oude Word documenten?
- Waarom kunnen bestanden niet goed worden overgezet naar ODF?
!:
Microsoft gaat ODF, PDF en XPS 'native' ondersteunen bij de volgende servicepack van 2007 Office system. Gebruikers kunnen dan bijvoorbeeld ODF als standaardformaat kiezen voor hun bestanden. Bovendien gaan we deelnemen aan de standaardisatiecommissies voor ODF.
- Hoeveel beter is OpenXML in het omzetten van oude Word documenten
In theorie kun de huidige binaire bestanden in Office Open XML omzetten zonder enig informatieverlies. Daardoor kan het formaat bijvoorbeeld gebruikt worden voor de conversie van archiefdocumenten in het binaire office formaat.
- Waarom kunnen bestanden niet goed worden overgezet naar ODF?
Omdat er dan potentieel informatie verlies optreedt of informatie veranderd. Niet alle elementen in de huidige formaten zijn 100% te mappen op vergelijkbare elementen in ODF. Overigens is een behoorlijk niveau conversie in de meeste gevallen wel haalbaar.
In theorie kun de huidige binaire bestanden in Office Open XML omzetten zonder enig informatieverlies.
de realiteit is altijd anders...
de realiteit is altijd anders...
Dat is zeker waar.
Je blijft bijvoorbeeld altijd afhankelijk van de programmatuur waarmee je de documetne converteert.
Ik heb voor wat betreft OOXML conversies alleen ervaring van bestandsconversies naar OOXML met het Compatibiliteitspakket voor de oude office versies en met MS Office 2007 en daarmee heb ik tot nu toe nog geen problemen gezien in het converteren van bestaande binaire office domumenten naar OOXML.
Hoeveel beter is OpenXML in het omzetten van oude Word documenten?
Zoveel als een standaard toelaat die beschreven is in een document van ruim zesduizend pagina's en die vol zit met specifieke MS-Office tags waarvan alleen MS precies weet wat ze doen.
en die vol zit met specifieke MS-Office tags waarvan alleen MS precies weet wat ze doen.
Noem eens zo'n tag dan ?
Er ligt mij zo één bij genaamd "autoSpaceLikeWord95", maar ik geloof dat die intussen is opgelost.
Maar je moet me maar vergeven, ik heb die 6000 pagina's vanmiddag op het werk laten liggen omdat de steekwagen niet beschikbaar was, anders had ik er *even* één voor je opgezocht.
Oh, en voor je nu weer begint dat er in ODF ook rare dingen zitten. Ja dat klopt, maar als ODF in de sloot springt hoeft OXML dat nog niet te doen.
Oh, en voor je nu weer begint dat er in ODF ook rare dingen zitten. Ja dat klopt, maar als ODF in de sloot springt hoeft OXML dat nog niet te doen.
De vraag is alleen waarom dergelijke elementen bij ODF, mede ontwikkeld door IBM, tijdens het standaardisatie proces kritiekloos zijn genegeerd terwijl tjdens het OOXML standaardisatieproces met name bijvoorbeeld IBM er bij Office Open XML miljoenen aan heeft uitgegeven om zo veel mogelijk discussiepunten te genereren in een poging het formaat te blokkeren.
Als IBM al die tijd, inspanningen en al dat geld in plaats van in ee anti-campagne tegen OOXML had uitgegeven aan het verbeteren van ODF dan zouden ze bij ODF misschien al een klaar geweest met het voltooien van ODF. Nu liggen ze bij ODF al meer dan een jaar achter op schema en vlot het nog steeds maar matigjes met het eindelijk voltooien van de ODF specs die eigenlijk gewoon eerder nog onvoltooid op de stoep van ISO/IEC zijn gemikt om maar de eerste te zijn.
bijvoorbeeld IBM er bij Office Open XML miljoenen aan heeft uitgegeven om zo veel mogelijk
We zullen het er maar niet over hebben waar Microsoft zoveel geld aan heeft uigegeven. Dat had MS óók kunnen stoppen in een samenwerking met ODF en de verbetering van die standaard. ...om maar de eerste te zijn.
Onzin. MS vertrouwde te lang op de lockin die hun office-pakket met zich meebracht en miste gewoon de boot. Anderen zagen wél het belang van een goede open standaard terwijl MS daar niet aan wilde meewerken. Als IBM al die tijd, inspanningen en al dat geld in...
Als MS van het begin had meegewerkt aan één goede documentstandaard dan....
Deze discussie is al zo vaak gevoerd. De Office Open XML zooi uit het verleden is ten minste...
Ik ben blij dat je dat tenminste toegeeft :-) Ik heb nooit begrepen waarom je in een nieuwe standaard zoveel legacy-zooi mee wilt nemen. Maak een goede converter voor oude doc's en begin met een goede en schone standaard. Met de ODF-standaard van zo'n 700 bladzijden maakt een goede programmeur (wat ik zelf overigens niet ben) in een paar uurtjes leuke dingen. Dan heb je met OOXML nog zo'n 5400 bladzijden te gaan en zit je je nog steeds verbijsterd af te vragen hoe je moet beginnen.
We zullen het er maar niet over hebben waar Microsoft zoveel geld aan heeft uigegeven. Dat had MS óók kunnen stoppen in een samenwerking met ODF en de verbetering van die standaard.
Let wel dat Micrsoft dus door bijvoorbeeld de EU is gevraagd om juist hun Office XML formaat te standaardiseren. Het is dus niet zo gek dat ze daar effort in steken.
Bovendien is Microsoft marktleider in Office producten en liggen hun belangen op de gebied echt op een heel ander niveau dan de belangen van IBM.
Onzin. MS vertrouwde te lang op de lockin die hun office-pakket met zich meebracht en miste gewoon de boot. Anderen zagen wél het belang van een goede open standaard terwijl MS daar niet aan wilde meewerken.
Volstrekte onzin. ODF is gewoon begonnen als het gestandaaridseerde OpenOffice formaat en er was niemand die uitspraak dat ze wilden dat Micrsoft zich ermee bemoeide. Men heeft ook pas Open Office uit de naam van het ODF formaat gehaald toen de EU aan OASIS vroeg het formaat bij ISO onder te brengen. HEt heette tijdens de standaardisatie in OASIS niet OpenDocument (een term uit een EU rapport) maar gewoon Open Office formaat dat werd gestandaardiseerd door het Open Office XML committee.
Als MS van het begin had meegewerkt aan één goede documentstandaard dan....
Deze discussie is al zo vaak gevoerd.
Er is dat ook altijd al duidelijk geweest dat er nooit sprake van is geweest dat iemand er enige effort in heeft gestoken om Microsoft erbij te betrekken. Die hadden namelijk al hun eigen XML formaat ontwikkeld. Het was zelfs duidelijk dat al tijdens de eerste meeting van het Open Office XML committee compatibiliteit met MS OFfice niet een prioriteit was voor het nieuwe Open Office formaat.
Er is dat ook altijd al duidelijk geweest dat er nooit sprake van is geweest dat iemand er enige effort in heeft gestoken om Microsoft erbij te betrekken.
Microsoft heeft nooit enige blijk gegeven van interesse in samenwerking. Ze verzinnen liever zelf wat om de vendor-lockin zo lang mogelijk in stand te houden. Waar ze zich al in samenwerkingen storten is dat alleen om het eigen belang te verdedigen of om vernieuwingen zo lang mogelijk uit te stellen.
Als Microsoft betrokken was geweest bij ODF dan was daarvan waarschijnlijk nu nog steeds geen eerste working draft opgeleverd geweest. Soms zijn concurrerende standaards in elk geval beter dan geen standaard.
Microsoft heeft nooit enige blijk gegeven van interesse in samenwerking.
Daar was ook geen reden voor.
Iedereen zou het belachelijk gevonden hebben als Microsoft zich had willen bemoeien met de opvolger voor het open office formaat terwijl ze zelf bezig waren met een opvolger voor hun eigen Office formaat.
De formaten hebben ook gewoon volstrekt andere uitgangspunten.
Microsoft heeft sterk het oog gehouden op de behoeftes van bestaande klantbasis en op het volledig ondersteunen van de benodigde office functionaliteiten.
OASIS heeft meer gekeken naar webdocumenten en methodes uit webstandaarden overgezet naar office documenten.
Microsoft heeft sterk het oog gehouden op de behoeftes van bestaande klantbasis en op het volledig ondersteunen van de benodigde office functionaliteiten.
Hetgeen een mooie vertaling is, voor het zo lang mogelijk in stand houden van een vendor lock-in situatie. Een onleesbare standaard van 6000 pagina's zodat de concurrentie in elk geval niet eenvoudig kan aansluiten.
Wat was ook al weer één van de definities van een monopolie? Het andere partijen moeilijk (zo niet onmogelijk) maken om de markt te betreden.
Een onleesbare standaard van 6000 pagina's zodat de concurrentie in elk geval niet eenvoudig kan aansluiten
Ik denk dat je dat verkeerd ziet.
Implementeren van OOXML verloopt juist door de uitgebreide specificaties veel vlotter dan bij ODF.
Het is niet voor niets dat bijvoorbeeld Apple op de iPhone eerst het lezen van OOXML ondersteunde terwijl de definiteve spec toch pas later is opgeleverd.
Voor implementerende partijen kan er nooit te veel documentatie zijn die het formaat beschrijft.
Ik denk dat je dat verkeerd ziet.
Ik denk dat jij denkt dat ik dat verkeerd zie, maar dat zie je verkeerd.
Implementeren van OOXML verloopt juist door de uitgebreide specificaties veel vlotter dan bij ODF.
De implementatie verloopt vlotter omdat er meer tijd wordt gestoken in de implementatie. Microsoft Office heeft een veel groter marktaandeel en het grootste deel van die markt heeft geen benul van ODF of OOXML. Die sturen gewoon een document via het internet. Toen Office 2008 net uit was, waren er direct al mensen die zich niet konden voorstellen dat ik een DOCX niet kon lezen, want "Het is toch gewoon Word?"
Vanaf het moment dat Microsoft besluit dat ISO OOXML de standaard opslagmethode is, moet de markt daar klaar voor zijn. De meeste concurrenten kennen Microsoft, dus die zullen daar terdege rekening mee houden.
Let wel dat Micrsoft dus door bijvoorbeeld de EU is gevraagd om juist hun Office XML...
Omdat XML de belofte inhield van een open standaard. Dat MS daar dan weer een bedrijfseigen geval van probeerde te maken is een ander geval.
ODF is gewoon begonnen als het gestandaaridseerde OpenOffice formaat
We praten weer langs elkaar heen geloof ik. Het één sluit het ander niet uit. Na het door jou genoemde begin is er een open standaard van gemaakt. ...iemand er enige effort in heeft gestoken om Microsoft erbij te betrekken.
MS is toch gewoon lid van ECMA? En kan zich dus gewoon met een voorgelegde standaard bemoeien. De ervaring heeft echter geleerd dat MS altijd nét iets anders wilt als alle andere bedrijven bij elkaar, ter bescherming van hun marktaandeel en lockin.
Dat is inderdaad wel het voordeel van OOXML. Daar beslist Microsoft wat de standaard is. Bij ODF moet eerst een consensus bereikt worden.
De vraag is alleen waarom dergelijke elementen bij ODF, mede ontwikkeld door IBM, tijdens het standaardisatie proces kritiekloos zijn genegeerd terwijl tjdens het OOXML standaardisatieproces met name bijvoorbeeld IBM er bij Office Open XML miljoenen aan heeft uitgegeven om zo veel mogelijk discussiepunten te genereren in een poging het formaat te blokkeren.
Dat is een goeie vraag. Waar was Microsoft destijds? Zij wisten dat ODF niet zo'n goede standaard was. Gelukkig probeert IBM een betere vinger aan de pols te houden bij OOXML, misschien resulteert dat wel in een goede foutloze standaard. Misschien hebben we het wel aan IBM te danken dat OOXML straks de betere van de twee is. Dus hAl, wees blij met IBM.
Bij ODF moet eerst een consensus bereikt worden.
Als sinds 2002 hebben Sun en IBM die momenteel samen het OpenOffice programmatrekken tesamen een enorme meerdereheid in de OASIS TC. In essentie is dus ODF nog steeds de belichaming van OpenOffice en andere partijen contribueren mogelijk wel maar hebben geen stem.
Elementen/aanpassingen ooit voorgesteld door de ODF foundation om compatibiliteit met de oude MS Office formaten te vergemakkelijken zijn dus Sun+IBM van tafel geveegd.
Bij Office Open XML is het anders. Daar heeft iedere organisatie maar 1 stem en is Microsoft weliswaar de belangrijke trekker van het OOXML formaat maar moeten zij altijd de andere leden meekrijgen om een specificatieaanpassingen goed te keuren.
Ook in ISO is het anders. Voor IS 26300 (ODF) heeft OASIS en daarmee dus Sun+IBM volledige controle over aanpassingen aan de specificatie. Bij IS 29500 (OOXML) heeft ISO/IEC JCT1 de controle over aanpassingen aan het formaat en mag Ecma daarbij aanschuiven als samenwerkende partner.
Bij OOXML is er dus ondanks de dominante positie van Micrsoft op de Office producten markt juist toch potentieel veel meer invloed mogelijk door de partijen die betrokken zijn bij het standaardisatie van het formaat. Zo kunnen bijvoorbeeld in ISO/IEC bijvoorbeeld een groep landen bijvorobeeld de EU voorstellen doen en laten aannemen om bijvoorbeeld features voor gehandicaten te verbeteren. Bij ODF kan dat dus niet omdat de ISO/IEC leden daar gen controle hebben over de formaat specificaties.
Als sinds 2002 hebben Sun en IBM die momenteel samen het OpenOffice programmatrekken tesamen een enorme meerdereheid in de OASIS TC.
Dat zeg ik. Er moet eerst een consensus bereikt worden tussen de partijen.
Bij OOXML is er dus ondanks de dominante positie van Micrsoft op de Office producten markt juist toch potentieel veel meer invloed mogelijk door de partijen die betrokken zijn bij het standaardisatie van het formaat.
Tja... potentieel wel ja... Maar er zit een verschil tussen consensus en je lapdogs vertellen wat er gaat gebeuren en wat ze moeten stemmen.
Ik denk dat o.a. Apple, Novell, Statoil, BP, Intel, Pioneer, Canon en de Gnome foundation heel blij zijn met de benaming die je ze geeft.
De participatie van veel van dergelijke bedrijven ontbreekt juist bij de ontwikkeling van ODF.
Nog ééntje dan, om het af te leren... "useWord2002TableStyleRules" ?
Ik ben nog op zoek naar "useFormatingLikeEdlin", misschien dat ik die niet ga vinden, dat is denk wel te oud.
Ik kan van alle tags die je noemt wel de complete definitie wel in kopieren maar ik neem deze maar even als voorbeeld:
2.15.3.63 useWord2002TableStyleRules (Incorrectly Display Top Border of Conditional Columns)
This element specifies whether applications should incorrectly calculate the top border of conditional columns (as specified by a tblStylePr element (§2.7.5.6) with a type attribute value of firstCol, lastCol, band1Vert, or band2Vert) under the following conditions:
* A conditional formatting has also been defined for the first row (a tblStylePr element with a type attribute of firstRow)
* That conditional formatting as been applied to the table using the tblLook element (§2.4.51)
Typically, table styles are applied according to the logic defined in §2.7.5. This element, when present with a val attribute value of true (or equivalent), specifies that the top border of those conditionally formatted columns should instead be displayed as the top border of the following row. [Example: Consider a WordprocessingML document with table style that defines two conditional formats:
* The first column has a one point border
* The first row has red shading
That style would be defined as follows:
<w:style w:type="table" w:customStyle="1" w:styleId="TableTest"> <w:name w:val="CompatibilitySetting"/> <w:tblStylePr w:type="firstRow"> <w:tcPr> <w:shd w:val="clear" w:color="auto" w:fill="FF0000"/> </w:tcPr> </w:tblStylePr> <w:tblStylePr w:type="firstCol"> <w:tcPr> <w:tcBorders> <w:top w:val="single" w:sz="4" w:space="0" w:color="auto"/> <w:left w:val="single" w:sz="4" w:space="0" w:color="auto"/> <w:bottom w:val="single" w:sz="4" w:space="0" w:color="auto"/> <w:right w:val="single" w:sz="4" w:space="0" w:color="auto"/> </w:tcBorders> </w:tcPr> </w:tblStylePr> </w:style>
If the first column and first row formatting is applied, the table would appear as follows:
<voorbeeldplaatje geknipt>
However, if this compatibility setting is turned on:
<w:compat> <w:useWord2002TableStyleRules /> </w:compat>
Then the condition described by this element causes the top border defined by the conditional format for the first column to be displayed as the top border for the second column, resulting in the following output:
<voorbeeldplaatje geknipt>
Er is dus van al deze elementen in Office Open XML een uitleg met voorbeeldplaatjes zodat het element voor compatibiliteit met oudere bestandsformaten prima kan worden gerenderd.
ODF heeft ook middelen om dergelijke compatibiteits elementen van oude formaten zoals de oude OpenOffice formaten in op te slaan.
Kun jij in ruil bijvoorbeeld even aangeven wat deze ODF elementen doen die je in je OpenOffice files kan vinden en hoe ik die zou moeten toepassen in dat OpenOffice document:
<config:config-item config:name="UseFormerLineSpacing" config:type="boolean">false</config:config-item>
of
<config:config-item config:name="AddParaTableSpacing" config:type="boolean">true</config:config-item>
De Office Open XML zooi uit het verleden is ten minste volledig beschreven en daardoor weliswaar onhandig maar in ieder geval wel interoperabel.
De ODF config items met zooi uit het verleden erin zijn niet beschreven en daardoor per definitie eigenlijk niet interoperabel. Je kunt de ODF zooi alleen nabouwen als je OpenOffice nabouwt. Op basis van de ODF standaard kom je daarmee namelijk niet ver.
Het is opvallend dat de interoperabele oplossing wordt afgekraakt maar de volstrekt niet interoperabele oplossing van ODF voor compatibiliteit met het verleden wordt genegeerd.
Het is opvallend dat de interoperabele oplossing wordt afgekraakt maar de volstrekt niet interoperabele oplossing van ODF voor compatibiliteit met het verleden wordt genegeerd.
Ik negeer niks. Wat heeft ODF er nu weer mee te maken? Ik heb dit al vaker geroepen. Het feit dat het in ODF niet goed is, maakt niet dat het voor Microsoft wel goed is.
Ik weet van die drie tags niet of ze daadwerkelijk een probleem zijn. Ze zijn alleen ter illustratie van onduidelijkheden uit het verleden. Ik betwijfel of er iemand is die het hele document al heeft geëvalueerd, dus of alle onduidelijkheden al boven water zijn.
De Office Open XML zooi uit het verleden is ten minste volledig beschreven en daardoor weliswaar onhandig maar in ieder geval wel interoperabel.
Heerlijk hAl. Een spliksplinternieuwe standaard. En versie 1 is al onhandig. Ik ben gewend dat de onleesbaarheid komt in versie 4 of 5.
De standaard is in essentie nieuw maar het formaat is dat eigenlijk niet niet en de achtergrond ook niet.
Er zijn al vele miljarden office documenten en office applicaties.
Ik negeer niks. Wat heeft ODF er nu weer mee te maken? Ik heb dit al vaker geroepen. Het feit dat het in ODF niet goed is, maakt niet dat het voor Microsoft wel goed is.
Het is wel relevant in het kader van dit artikel. IBM vind het blijkbaar prima zolang ze zaken als ODF waarze zelf in participeren fluitend door ISO kunnen loodsen maar vind het nogal bezwaarlijk als een concurrende organisatie een iets bij ISO wil neerleggen. Ze vinden het acceptabel als ISO grote gaten in ODF negeert en ongewijzigd accepteert maar maken bezwaar als ISO geten in OOXML probeert te dichten en een verbeterde versie vervolgens accepteert. Het is dus juist in het kader van de houding van IBM tijdens de twee standaardisatie processen en hun opmerkingen nu hele relvant om ODF en OOXML op dergelijk zaken te vergelijken. Je kunt dat volstrekt niet los zien.
De standaard is in essentie nieuw maar het formaat is dat eigenlijk niet niet en de achtergrond ook niet.
Er zijn al vele miljarden office documenten en office applicaties.
Het formaat OOXML is toch nieuw? Je kan terugwaartse compatibiliteit beter bereiken door een goede standaard op te bouwen waar de uitzonderingssituaties op een nette manier in passen. Nu moet je in je programma rekening gaan houden met allerlei idiote uitzonderingsregels.
Microsoft had hier eindelijk een kans om een 'garbage in/data out' slag te maken, maar ik gok dat de enige reden om dat niet te doen, is geweest om de concurrentie dwars te zitten.
Als je het dan niet kunt sluiten, maak het dan in elk geval zo ingewikkeld mogelijk. En in dit geval is die missie geslaagd.
Het formaat OOXML is toch nieuw?
Minder nieuw dan je denkt.
OOXML is in hoge mate gebaseerd op de MS Office 2003 XML formaten.
Dat was toen nog single file XML met baseencoded binaries zoals plaatjes erin (iets wat ODF ook nog steeds ondersteunt). Inmiddels is in OOXML het single file XML vervangen door een gezipt package file met daarin XML office files en embedded binary files voor o.a. multimedia objecten.
Hmm, dat wist ik niet. Ik had gehoopt dat Microsoft wel een schone nieuwe standaard neer zou zetten, maar die kiezen er dus ook gewoon voor om bestaande meuk op te poetsen zonder de ouwe troep te verwijderen. Lekker dan. :(
Volgens mij was juist een probleem van de Office 2003 formaten dat ze wel goed compatibel waren maar niet 100% en dat daarom veel klanten niet over wilden.
Daarom is in OOXML eerder meer compatibiliteit opgenomen dan minder
Beetje flauw. Als hij die worden NIET zou gebruiken zou je hem verwijten voor MS te willen spreken en om bronnen vragen.
@Puist
Je hebt nu iets van 7 reacties in deze thread maar nul over het onderwerp maar wel allen om mij als persoon af te zeiken en je bent hier verder blijkbaar voornamelijk mijn reacties te voorzien van een paar extra minnetje.
Ik zal het maar even heel duidelijk zeggen.
Je hebt hier geen enkel zinnige on topic bijdrage in de discussie maar komt hier blijkbaar alleen maar komt om personen zoals ik af te zeiken die wel bijdragen aan de informatie, de discussie of die hun opinie over dit onderwerp willen geven.
Kun jij in ruil bijvoorbeeld even aangeven wat deze ODF elementen doen die je in je OpenOffice files kan vinden en hoe ik die zou moeten toepassen in dat OpenOffice document
Hoi allemaal en hAl, ik ben er ook weer :-) Jullie resident spec nazi... en onthou, ik ben er om jullie te helpen!!!
Kun jij aangeven waar je die dingen ziet in de spec? Ik vind ze nl. niet (ODF 1.0 en 1.1 geprobeerd...).
Bvd
gr
Bolleke (doet paperclip/hondje na)
Zei ik net nog niet dat dit application defined item zijn en dat je ze juist niet gepsoecifceerrd zijn en dus eingelijk per definitie niet geimplementeerd kunnen worden.
ODF gebruikt is dus een manier om dezelfde soort compatiblitiets item te implementeren maar dan op een manier die eigenlijk per definitie 100% incompatibliteit oplevert. Bovendien is het een oplossing die door de generiek opzet weer nieuwe appklicatie settings kan introduceren en daarmee de incomatibiliteit naar de toekomst toe weer kan vergroten.
Voor Microsoft met vele miljarden bestaande documenten met dergelijk items erin zou een generieke oplossing die per definitie een applicatie specifieke versie produceert geen oplossing zijn. Het zou dan de hele tijd kritiek krijgen dat het eigen settings achterhield en een mogelijkheid tot meer MS specifieke settings zou introduceren en daarom het geen open standaard zou betekenen. Dergelijk kritiek gaat voorbij aan ODF wat dat in essentie wel heeft gedaan
Zei ik net nog niet dat dit application defined item zijn en dat je ze juist niet gepsoecifceerrd zijn en dus eingelijk per definitie niet geimplementeerd kunnen worden.
Maar... maar... waarom zou jij je als maker van applicatie X zorgen maken over de applicatie-specifieke (het woord zegt het al een beetje) settings van product Y??? En vice versa, uiteraard. Tenzij je een 1-op-1 OOo kloon aan het maken bent [en dat zou wel extreem onnuttig zijn] is dat toch helemaal jouw probleem niet? Settings die niet matchen met jouw productID kun je als implementator gewoon negeren, dat is het hele idee. Mocht een applicatie proberen het document onbruikbaar te maken door allerlei essentiele niet-gedocumenteerde informatie in de settings te proppen (zeg maar, de MS-strategie) dan valt die applicatie vanzelf af als "bruikbaar".
Ik wil wel toegeven dat ik dit instinctief ook niet de meest elegante manier vind om applicatie-specifieke settings op te slaan, maar aan de andere kant zou ik zo snel ook geen betere manier weten - dit is tenminste wel transparant en uitbreidbaar (applicatie X kan z'n eigen settings gewoon toevoegen, en die negeert OOo dan weer). Het is in elk geval 1000x beter dan ze in de standaard documentbeschrijving zelf op te nemen, daar hebben applicatie-specifieke dingen by nature gewoon niks te zoeken.
Maar... maar... waarom zou jij je als maker van applicatie X zorgen maken over de applicatie-specifieke (het woord zegt het al een beetje) settings van product Y??? En vice versa, uiteraard. Tenzij je een 1-op-1 OOo kloon aan het maken bent [en dat zou wel extreem onnuttig zijn] is dat toch helemaal jouw probleem niet? Settings die niet matchen met jouw productID kun je als implementator gewoon negeren, dat is het hele idee.
Als je niet beschikt over de compatiblity setting van OOo en of MS Office uit het verleden dan zal je document er dus anders uitzien dan het origineel. Voor archieven en documenten met een weetelijke betekenis kan dat heel relevant zijn.
Voor OOo is dat misschien minder belangrijk maar er zijn vele miljarden MS Office documenten. Gebruikers die deze naar te toekomst toe willen bewaren zullen zeker overwegen om dit naar een open op XML gebaseerd formaat te bewaren.
Het is wel zo dat deze compatibility elemente voor het grootste gedeelte van de documenten geen rol speelt of geen significante verschillen uitmaakt.
Het is dus een relatief onbelangrijk onderdeel van de specifatie (bedoeld voor specifieke partijen die zeer hoogwardige conversiebetrouwbaarheid als eis stellen) dat echter zwaar overbelicht is geraakt tijdens het standaardisatie proces door een rij negatieve publicaties van IBM erover.
Als je niet beschikt over de compatiblity setting van OOo en of MS Office uit het verleden dan zal je document er dus anders uitzien dan het origineel.
Nee, dus. Het zijn (ik zeg het nog maar een keer met nadruk) applicatie settings, geen document settings. Een aparte tag voor iets dat in een bepaalde hele specifieke situatie anders wordt gerenderd dan anders is onzinnig. Tijdens de conversie moet de applicatie daar dan een inline style oid van maken - dat is eenduidig en vervuilt je specificatie niet.
Je kunt nu wel net blijven doen alsof ODF dezelfde problemen heeft als OOXML maar het alleen anders noemt, maar dat is gewoon niet waar - we hebben het over twee compleet verschillende dingen.
Nee, dus. Het zijn (ik zeg het nog maar een keer met nadruk) applicatie settings, geen document settings
Het zijn document settings omdat ze mede bepalen hoe een document er voor de maken van dat document er uitheeft gezien. De seetings zijn misschien wel het gevolg van een applicatie specifieke eigenschap uit het verleden maar die applicatieeigenschap heeft dus het document beinvloed zodanig dat het nu relevant is voor het document.
Zonder dergelijks settings kun je het document niet hetzelfde bekijken als degene die het gemaakt heeft.
Met name voor conversie waarbij een zeer hoge mate van conversie betrouwbaarheid nodig is is dat toch relevant.
Het zijn document settings omdat ze mede bepalen hoe een document er voor de maken van dat document er uitheeft gezien. De seetings zijn misschien wel het gevolg van een applicatie specifieke eigenschap uit het verleden maar die applicatieeigenschap heeft dus het document beinvloed zodanig dat het nu relevant is voor het document.
Dat is jouw interpretatie. De specs zeggen dat het is voor applicatie-specifieke instellingen, bijvoorbeeld printersettings, venstergrootte, zoomlevel etc. Dat heeft dus niks te maken met de inhoud of weergave van het document zelf - althans, dat is de bedoeling. Als OOo dat soort dingen er /wel/ inpropt is dat een fout van de applicatie die zich dan niet goed aan de specs houdt. En dat bedoelde ik mede met dat ik het niet de meest elegante oplossing vind: het nodigt uit tot misbruik.
Maar goed, we halen weer eens 2 dingen door elkaar: de standaard die prima in dingen voorziet, en een applicatie die er zo te zien niet helemaal netjes mee omgaat. Je kunt niet "fouten" in OOo aanhalen als voorbeeld waarom ODF niet goed zou zijn. De manier van OOXML om hiermee om te gaan is echter wel degelijk "flawed by design". En dat je die inline styles niet zo snel tegenkomt in OOo-docs is waarschijnlijk omdat OOo niet zoveel legacy meuk en oude bugs bevat als MS Office, en dat lijkt me alleen maar positief.
Je kunt nu wel net blijven doen alsof ODF dezelfde problemen heeft als OOXML maar het alleen anders noemt, maar dat is gewoon niet waar - we hebben het over twee compleet verschillende dingen
Je kunt nou wel doen alsof ODF het anders doet maar die gebruiken ook uidelijk geen inline style.
Als in een ODF file staat dat "UseFormerLineSpacing" Dan moet je maar raden hoe het document er ooit uit heeft gezien als je het nog hetzelfee wilt tonen. Welke versie van OOo zal worden bedoeld met former ? Waarom gebruikt OOo geen inline style formatering ?
Een style oplossing is niet zo makkelijk als je denkt. Je weet namelijk bij een conversie vaak niet elementaire zaken die bepalen hoe een style effect heeft op het document (bijvoorbeeld de plaatsen van soft line, page en table breaks) die je alleen bij rendering kan zien. Vooraf is dus het effect van bepaalde zaken pas on run time rendering niveau duidelijk. Daarom hebben zowel OOXML als ODF dus elementen opgenomen om compatibel te zijn met eerdere versies.
Je kunt nou wel doen alsof ODF het anders doet maar die gebruiken ook uidelijk geen inline style.
ODF biedt die mogelijkheid prima; dat OOo het niet (goed genoeg) doet is iets anders.
Als in een ODF file staat dat "UseFormerLineSpacing" Dan moet je maar raden hoe het document er ooit uit heeft gezien als je het nog hetzelfee wilt tonen. Welke versie van OOo zal worden bedoeld met former ?
Dat is niet zo moeilijk: <= 1.1. Het lijkt me logisch dat als je een conversie .sxw > ODF uitvoert je rekening houdt met de nukken van OOo 1.1 - net zoals je bij een conversie MS Office 95 > ODF rekening houdt met de nukken van een oude versie van Word. Het is dan een tekortkoming van OOo dat ze het zo oplossen ipv een globale <line-spacing value="1.2em"> oid style eigenschap.
Waarom gebruikt OOo geen inline style formatering ?
Geen idee. Vraag het ze, zou ik zeggen. Ik heb al gezegd dat ik dat ook niet goed vind, al kan ik zo 1 2 3 natuurlijk niet zeggen wat hier de achterliggende gedachte is. In elk geval heeft dat dus niks met ODF an sich te maken, je hebt het nu over OOo. Die lossen het enigszins op een Microsoft-achtige manier op ook, en dat vind ik ook niet goed. ODF biedt echter alle mogelijkheden dit wel netjes te doen.
Dat is niet zo moeilijk: <= 1.1
Zo voor de hand liggend is dat niet per se omdat de setting geldt voor alle afgeleiden van OOo en dus ook voor StarrOffice 6.x en NeoOffice en wet ik veel wat.
Het is helemaal niet zeker dat de setting overal hetzelfde doet in dezelfde versie.
Beter naamgeving had dan geweest
UseLineSpacingBeforeOOo_1_1 of zoiets.
Grapig trouwens dat OOo nu er op de site deze belachelijk minimalistische text bij heeft gezet.
Is echter zwaar onvolledig in uitleg natuurlijk en er zijn ook andere setting waarbij ik de versie niet op de site kan vinden zoals bijvoorbeeld
UseOldNumbering
UseFormerTextWrapping
Verder is een style wijziging bij conversie gewoon niet 100% hetzelfde.
Zo heeft een style wijziging bijvoorbeeld een permanent karakter terwijl de compatiblity setting getriggerd wordt door een bepaalde situatie op runtime.
Het is helemaal niet zeker dat de setting overal hetzelfde doet in dezelfde versie.
Sterker nog, ik weet wel zeker dat-ie dat *niet* doet. Het is namelijk applicatie-specifiek.
Beter naamgeving had dan geweest UseLineSpacingBeforeOOo_1_1 of zoiets.
Nee, want het zijn settings voor OOo. Dat zou dus zwaar redundant zijn. Dat StarOffice ervoor kiest deze te respecteren is iets waar noch OOo, noch ODF iets aan kan doen.
Grapig trouwens dat OOo nu er op de site deze belachelijk minimalistische text bij heeft gezet.
Ze beschrijven een API. Ze hoeven daar niet uit te leggen wat wat doet, het is van belang voor programmeurs die met die API praten om te weten als ze per ongeluk compatible met OOo <1.1 willen zijn.
Verder is een style wijziging bij conversie gewoon niet 100% hetzelfde.
Zo heeft een style wijziging bijvoorbeeld een permanent karakter terwijl de compatiblity setting getriggerd wordt door een bepaalde situatie op runtime.
Wat je nu zegt is dat bugs tot sint-juttemis backwards ondersteund moeten blijven worden? Dan moet je lekker bij de oude versie van je pakketje blijven en moet je vooral niet upgraden. In nieuwe versies worden bugs gefixed. Deal with it.
Beter lijkt het mij om te zorgen dat bestaande documenten zoveel mogelijk 1 op 1 geconverteerd kunnen worden. Dat er vervolgens in de nieuwe versie van je applicatie dingen anders werken is onontkoombaar. Of vind je ook dat een Office95 document wanneer ingeladen in Office 2007 of hoe het ook heet niet gebruik zou moeten mogen kunnen maken van de nieuwe features?
Wat je nu zegt is dat bugs tot sint-juttemis backwards ondersteund moeten blijven worden? Dan moet je lekker bij de oude versie van je pakketje blijven en moet je vooral niet upgraden. In nieuwe versies worden bugs gefixed. Deal with it.
Alleen op plaatsen waar het van belang is dat de inhoud 100% zeker hetzelfde moet blijven.
Bij archieven en documenten met een wettelijke status bijvoorbeeld.
Nieuwe bestanden mogen de compatiblity features sowieso niet meer gebruiken en dus hoeven de meeste implementaties die ook helemaal niet te ondersteunen.
Er is echter wel voldaan aan het volledig onsluiten van de bestanden voor de toekomst. Er is geen element in de spec die nog een vendor lockin behelst omdat het een MS specifieke eigneschap is die niet beschreven is en ik denk dat dat voor MS belangrijk is. Hoe OOo dat in ODF heeft opgelost zou voor MS geen oplossing zijn. De anti-MS club zou overal volkladden dat Microsoft propriety features in OOXML had ingebouwd en het daarom geen open formaat zou zijn. Door alle mogelijke compatibility features in de standaard te gooien is dat niet het geval. Ook heeft MS aanverwante formaten als WPF en ISF vrijgegeven onder de OSP zodat echt elke onderdeeltje van OOXML vrij beschikbaar is voor iedereen te gebruiken.
Hoe OOo dat in ODF heeft opgelost zou voor MS geen oplossing zijn. De anti-MS club zou overal volkladden dat Microsoft propriety features in OOXML had ingebouwd en het daarom geen open formaat zou zijn.
We draaien in cirkels. Ik heb je geprobeerd uit te leggen dat we het over 2 verschillende dingen hebben, en jij blijft doen alsof het hetzelfde is. Applicatie-specifieke bugs horen NIET in een nieuwe standaard, hoogstens in een document dat de transitie beschrijft (niet te verwarren met een transitional schema). Er is werkelijk niemand die verwacht dat de genoemde bugs nog ondersteund worden - wat denk je dat er tot nu toe gebeurde als je zo'n oud document opslaat in een nieuwe versie van MS Word? Dan ben je of je bugs kwijt, of de betreffende stijlen worden inline gemaakt. Het is gewoon echt volstrekte flauwekul om dat in de standaard op te nemen.
Het is lief van MS dat ze al hun oude meuk beschreven hebben, maar dat was dus niet de bedoeling. Je kunt ook zonder dat prima een conversieslag maken naar een nieuw formaat, en dan is het fijn dat die rare dingen ergens beschreven staan (b.v. voor een conversie naar ODF is deze info ook erg handig ;)). Maar er is werkelijk niemand die ook maar ergens geeist heeft dat hun bestaande documenten bugs moeten blijven bevatten. Sterker nog, het wordt als extreme "bad practice" gezien om te vertrouwen op bugs in een applicatie of programmeertaal; bugs hebben namelijk de neiging gerepareerd te worden (ook in MS software). Als jij graag wilt denken dat het bestaan van dit soort onzinnige beschrijvingen van onzinnige elementen een pluspunt is voor OOXML, so be it. Maar als er ooit een IT beslisser is die dit soort meuk gebruikt om OOXML te kiezen boven ODF dan wil ik graag horen wie die persoon is en waar hij/zij werkt. Dan weet ik namelijk dat ik die toko in het vervolg moet mijden als ik aan het solliciteren ben, want daar snappen ze het dan duidelijk ook niet. Als je graag MS-spul wilt blijven gebruiken, zeg dat dan gewoon, maar kom niet met dit soort flauwekulargumenten.
Wel grappig dat je exact demonstreert waarom tegenstanders van OOXML vinden dat het verkapte vendor-lockin is. Bedankt daarvoor.
Voor Microsoft met vele miljarden bestaande documenten met dergelijk items erin zou een generieke oplossing die per definitie een applicatie specifieke versie produceert geen oplossing zijn.
Je snapt het niet. Het aangehaalde voorbeeld (<renderLikeWord0.1>) had ook heel anders moeten worden opgelost, nl. met inline styles [of het equivalent daarvan in OOXML]. Het is namelijk een hele specifieke override op wat het "eigenlijk" zou moeten doen, en als je dan gewoon beschrijft hoe dat eruit ziet:
<pseudo-code>
<table-row style="border-top: 1px solid #f00">
</pseudo-code>
is dat meer dan genoeg en net zo backwards compatible. Iedereen kan dit nu 1-op-1 weergeven, en als je met een nieuwere versie werkt en die border lelijk vindt haal je 'm weg, sla je opnieuw op en krijg je netjes:
<pseudo-code>
<table-row>
</pseudo-code>
Wat MS voorstelt is, om even een webanalogie erbij te halen, om een nieuwe tag te introduceren voor block-elementen die a la IE6 incorrect de margin optelt bij de totale breedte:
<divLikeIE6>
<pLikeIE6>
<blockquoteLikeIE6>
etc.
Dan dwing je dus elke implementator om extra meuk toe te voegen die alleen maar een andere brakke implementatie beschrijft.
Zoals het in ODF werkt is het meer een soort conditional comment:
<!--[if IE 6]><style type="text/css">
div { width: [de gecorrigeerde waarde]px; }
p { width: [de gecorrigeerde waarde]px; }
blockquote { width: [de gecorrigeerde waarde]px; }
</style><![endif]-->
Andere implementaties kunnen en zullen dit dus negeren, en iedereen ziet netjes hetzelfde (dit is een iets ander voorbeeld dan het <spaceLikeExcel0.4>-voorbeeld, maar snapt vast wat ik bedoel).
Dat hele ISO certificeren is failliet, dat is duidelijk gebleken uit de ooxml procedure, M$ geeft haar hand overspeeld, door intimidatie, corruptie & omkoping heeft men gedacht te kunnen winnen. Dat was niet zo want zelf geven ze nu toe dat .odt de winnaar is.
De markt (niet alleen IBM) denkt daar anders over. Zeker omdat er veel bewijs* ligt.
Wat mij betreft is het simpel: "Boontje komt om zijn loontje" of voor de mensen met een wat betere opleiding: "Een typische Pyrrusoverwinning".
*Lees vooral eens http://www.groklaw.net
Lees vooral eens http://www.groklaw.net
Ja, dat is een heel neutrale bron.
Pamela Jones, commonly known as PJ, is the creator and editor of Groklaw, an award-winning website that covers legal news of interest to the free and open-source software community.
En waarom zou dat geen neutrale bron zijn dan? OOXML is toch Open en wordt toch geïmplementeerd in Open Source projecten? Ik acht PJ niet als een typische MS hater en daarmee best tot enige objectiviteit in staat.
Ik acht PJ niet als een typische MS hater
Ik zie haar als 1 van de ergste MS haters die er in de wereld rondlopen.
Uit elke negatief bericht (een positief bericht over MS heb ik er nog nooit mogen ontwaren) spat gewoon het venein van het scherm af.
Als je dat objectiviteit noemt dat zit je wel heel ver aan een bepaalde kant.
Mij IP adressen zijn er gebanned van reageren (nadat ik eens een aantal positieve vergelijking had gemaakt tussen OOXML vergeleken met ODF. (of eigenlijk worden de IP adrssen gesandboxed zodat het lijkt of je reageert op de site maar niemand anders je berichten te zien krijgt.)
De groklaw site is juist in ieder geval verre van open maar juist erg mening onderdrukkend.
Tja, als je daar zo loopt te schelden als je hier soms doet kan ik me voorstellen dat je er uit geknikkerd wordt.
Er zijn ook wel eens medewerkers van Novell en/of de Gnome foundation gebanned toen zij een geluid van de andere kant van de overeenkomst van Novell en MS wilden laten horen.
Het verbaast me bijvoorbeeld ook niks dat de zeer extreme MS hater Schestowitz van Boycott Novell mede de newspicks van groklaw verzorgt. Ik werd bijvoorbeeld gesandboxed omdat ik volgens PJ een shill en een astroturfer was. Zo kun je dus iedereen wel benoemen die het niet me je eens is.
Haar lekkerlijke woorden in een reelijk recente discussie als een voorbeeldje
I don't want Groklaw ruined, so when I find what I believe are astroturfers
and shills pretending to be FOSS people, I do throw their fannies over the fence. I give
them every chance to cut it out and stay, but if they persist, they are outahere
Effectief betekent dat dat als je een aantal keer berichten post die het niet eens zijn met de dame in kwestie dat je account wordt gekilled en als je dan anoniem post dat je in een sandbox eindigt.
Ik zie haar als 1 van de ergste MS haters die er in de wereld rondlopen.
Iets wat ik weer bestempel als de grootst mogelijke onzin. Omdat jouw getroll daar in de ban is gegaan wil nog niet zeggen dat er leugens worden verkondigd. Want anders was ze allang tot de orde geroepen en had ze zich voor een of andere rechter moeten verantwoorden. De waarheid is voor jouw gewoon een beetje pijnlijk. Dat is alles.
Omdat jouw getroll daar in de ban is gegaan wil nog niet zeggen dat er leugens worden verkondigd. Want anders was ze allang tot de orde geroepen en had ze zich voor een of andere rechter moeten verantwoorden.
Waarom denk je dat. Mensen hebben gewoon recht op hun vrijheidvan meningsuiting. Dat heeft echter niets met leugens te maken. De site is gewon ontzetten gericht op het publiceren van negatieve informatie voor Microsoft en laat altijd heel selectief informatie weg. Als je zelf die informatie weer toevoegd wordt je gebanned.
De waarheid is voor jouw gewoon een beetje pijnlijk
Ik denk dat dat andersom is. De waarheid was voor Groklaw een beetje pijnlijk. Het is een site die probeert negetief niewuws te vinden over bpeaalde partijen en probeert dan dan nog is uit te vergroten door selectief selectieren, becommentariereen en het verwijderen van tegenovergestelde opinies of infomatie. Dat mag allemaal best maar het maakt de site wel eens van de meest extreme opinie sites die ik ooit heb gezien.
Overigens voor de echte geintereseerden.
De final tekst van de nieuwe ISO 29500 Office Open XML formaten standaard is door ISO ITTF net verspreid onder de ISO leden.
Hier nog een stukje achtergrond over hoe IBM tot de nieuwe standpunten is gekomen:
blog.actonline....-ibm-would.html
hAl, je bent fan van Microsoft en hebt een hekel aan IBM. Nu weten we het wel. Ik zie niet in hoe dit met deze discussie te maken heeft. Hou er alsjeblieft mee op, je verveelt mij (en ongetwijfeld velen met mij) mateloos.
Hoe bedoel je. Het door mij aangehaalde artikel beschrijft EXEACT datgene waar dit artikel over gaat.
Het is over IBM die openheid eist van de standaardorganisaties en vervolgens direct daarbij besluit met een gesloten groep van 70 niet nader genoemde personen achter gesloten deuren daarover te gaan praten.
Dat is juist in het kader van dit artikel opvallend te noemen.
Ook opvallend: IBM is volledig afwezig bij de ISO/IEC JTC1 SC34 bijeenkomst in Korea. Zonder afzeggingen zijn de experts van SC34 niet in Korea verschenen waar men wel plaatsen vor hen had gereserveerd.
In Korea heeft het SC34 committtee overigens hun liason text met OASIS flink veranderd omdat ze zeer geergerd zijn over ODF maintenance (waar IBM de belangrijkste rol in speelt). Zo worden door ISO/IEC nationale leden aangemelde defectsrapporten voor ODF niet opgepakt en worden wijzigingen door OASIS niet aan ISO/IEC voorgelegd. De nieuwe Liason tekst zou er voor moeten zorgen dat OASIS niet onbeperkt de ISO/IEC leden meer kan negeren. Het lijkt erop alsof juist ISO/IEC hier een forse uitbrander uitdeeld aan het OASIS committee waar IBM de lakens uitdeelt en dat IBM afwezig is omdat ze die ook al zagen aankomen en niet in een positie wilden komen om over deze teksten te hoeven stemmen.
Het zou bijvoorbeeld voor IBM's Rob Weir heel vervelend geweest zijn om als bij het ISO committee mee te stemmen mmet kritiek op het OASIS committe waar hijzelf medevoorzitter van is ofwel aom als enige daar tegen te stemmen en zich in het ISO/IEC SC34 committee te isoleren.
Grappig genoeg zij er ook net de eerste defect rapporten op de nieuwe ISO/IEC 29500 tekst ingebracht en deze worden direct door ISO zelf behandeld en daar zijn ze dus bij ISO/IEC een stuk positiever over.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
