Microsoft publiceert details over eigen implementatie odf en ooxml

Microsoft heeft documentatie over zijn implementatie van het odf-formaat in Office 2007 SP2 gepubliceerd en zal binnenkort dezelfde informatie over ooxml vrijgeven. Het bedrijf zegt de interoperabiliteit met andere software te willen verbeteren.

Met de informatie op de Microsoft-site Document Interop Initiative kunnen softwareontwikkelaars nagaan of en hoe bepaalde elementen uit de odf- en de ooxml-specificaties in Office 2007 met Service Pack 2 ondersteund worden. In die Office-release, die begin 2009 beschikbaar komt, worden versie 1.1 van de odf-specificatie en Ecma 376 Edition 1 van de ooxml-standaard ondersteund. Op dit moment zijn op de site alleen gegevens van odf beschikbaar, maar in de komende weken zou ook informatie over ooxml worden toegevoegd.

De informatie over implementaties is om verschillende redenen van belang, betoogt Microsoft. Zo zijn specificaties soms ambigu, wat verschillende implementaties mogelijk maakt oplevert, of er is sprake van een welbewuste keuze van de ontwikkelaar om de specificatie niet of anders te implementeren. Door inzichtelijk te maken welke keuzes de ontwikkelaars van Microsoft hebben gemaakt, moeten problemen in andere implementaties van de specificaties worden voorkomen.

Microsoft lost met de publicatie een belofte in die het in de lente van 2008 deed. Het Redmondse bedrijf stelde toen dat het support voor het opensourceformaat odf aan Office 2007 zou toevoegen en het odf zo volledig mogelijk zou ondersteunen.

Reacties (45)

[maartenba]

Even toelichten (was op een van de laatste DII workshops in Brussel): het is niet de bedoeling om in een "embrace" fase te komen, ook niet de bedoeling om ODF uit te roeien.

Waar dit initiatief om draait is het vrijgeven van hoe MS omgaat met verschillen tussen bv. ODF en hun rendering engine. Een eenvoudig voorbeeld zijn ongenummerde lijsten. Binnen OOXML en MS Word 2007 is het mogelijk de bolletjes van ongenummerde lijsten in te kleuren, terwijl de tekst zwart blijft. Deze implementation notes vertellen je dan dat er voor gekozen is om bij wegschrijven naar ODF, welke dit niet ondersteunt, alle bolletjes én de tekst zwart te maken. Waarom? Er wordt van uit gegaan dat de tekst zwart kleuren eerder is wa tde gebruiker wil dan deze gekleurd houden.

Dit soort zaken wordt nu gedocumenteerd, zodat je precies weet hoe Word gaat reageren op bepaalde bestandsformaten, en dat je hier rekening mee kan houden / weet van hebt.

(check overigens ook even mijn blog voor een verslag van dit DII event, leesvooral de stukken rond roundtable discussion - http://blog.maartenballia...ussels-Quick-summary.aspx)

[Reactie gewijzigd door maartenba op 24 juli 2024 11:59]

[Verwijderd]

Bedankt dat je juist wel de moeite hebt genomen. Ik hoopte al dat iemand een voorbeeld zou geven van de verschillen die nu gedocumenteerd zijn, maar ik vreesde al bij het lezen van de titel alleen maar gezeur over embrace, extend & extinguish tegen te komen. Gelukkig is er ook nog iemand die er inhoudelijk op verder gaat.

[Ook al Bezet]

Inderdaad, hoe meer informatie we hierover hebben hoe beter lijkt me toch.

Het feit dat MS office nu eindelijk odf standaard gat ondersteunen lijkt me sowieso een goede zaak. Hoe meer bedrijven elkaars standaarden ondersteunen hoe beter en makkelijker het is voor de consument. Aangenomen dat ze elkaar ook blijven ondersteunen. Als we straks met verschillende odf formaten zitten die niet onderling compatibel zijn zijn we natuurlijk nog verder van huis.
Wel jammer dat MS eerst zo nodig weer een nieuw eigen bestandsformaat moest maken.

[Reactie gewijzigd door Ook al Bezet op 24 juli 2024 11:59]

[Verwijderd]

Wel jammer dat MS eerst zo nodig weer een nieuw eigen bestandsformaat moest maken.

Ze hadden al eigen bestandsformaten. Dat waren alleen geen ISO standaarden. En ODF ondersteunt niet alle features die bijvoorbeeld Word biedt. Dan kan je kiezen: de functionaliteit van Word beperken, of een bestandsformaat maken dat die features wel ondersteunt. Ik zou het wel weten.

[maartenba]

Er komen nog meer van dit soort zaken aan, ook hoe zij zelf hun eigen OOXML standaard hebben geïmplementeerd. Voorbeeldje uit dat document is dat bv. OOXML definieert dat voor data validation in Excel een error message van onbeperkte lengte mogelijk is. Helaas laat Excel zelf maar 244 tekens toe, op meer tekens opent hij het document niet.

Dit soort zaken is érg nuttig als je zelf ontwikkelt aan libraries welke documenten genereren, omdat deze gedrag van de "consuming" applicatie verklaren. Hopelijk volgen andere (al dan niet open-source) vendors dit voorbeeld, het maakt interoperability enkel maar makkelijker.

[kidde]

Even toelichten (was op een van de laatste DII workshops in Brussel): het is niet de bedoeling om in een "embrace" fase te komen, ook niet de bedoeling om ODF uit te roeien.

Nee, het idee van Microsoft is om binnen de wettelijke grenzen waarde voor haar aandeelhouders te creëren. Onder andere door geld te verdienen aan standaarden, dus ook aan ODF.
Iemand moet dat geld betalen, en in het geval van Microsoft draaien de klanten dus de maatschappij daarvoor op. Dat Microsoft Office ondersteuning gaat bieden voor ODF wil dus zeggen dat ze denken dat ze er geld aan kunnen verdienen juist door ODF niet uit te roeien.

[Toontje_78]

Maar de reclamefilmpjes van MS die af en toe voorbij komen zijn evenwel toch briljant.

Mensen zijn altijd bang (gemaakt?) voor grote organisaties, of het bedrijven zijn of het Rode Gevaar. Of het terrecht is of niet doet niet zozeer ter zake.

Relativerend gezien is MS een bedrijf als alle andere, en (met name het verhemelde en verguisde) Windows is een simpele laag tussen de gebruiker en de machine. Ja, Windows heeft minpunten (virusgevoeligheid indien slecht geconfigureerd, systeembelastend), net zoals alle andere OS-en (Linux met name heeft matige driver ondersteuning en een relatief kleine gebruikersbasis, waardoor er veel software niet direct voor beschikbaar is maar slechts door een extentie als Wine.)

Kortom, laat je niet gek maken!

[graey]

Ik ben geen 'anti-MS volk', dat is hetzelfde als tegen Nederlanders zijn omdat ze zo gierig/zuinig zijn of [vul hier je stereotypering danwel vooroordeel in].
Het lijkt me echter wel redelijk om sceptisch te zijn; Microsoft bestaat uit veel divisies, sommige research-teams zijn heel 'open' bezig en komen echt met innovatieve ideeen, hier en daar worden 'normale' producten of research-resultaten die het aan het maken zijn naar een normaal product ook steeds meer multiplatform gemaakt of gedocumenteerd (denk bijvoorbeeld aan .Net (Silverlight) en Mono (Moonlight)).
Aan de andere kant heb je onder andere het Office-team, dat aan de ene kant zijn best lijkt te doen om heel erg open te zijn met het bestandsformaat OpenXML (klinkt open), aan de andere kant nemen ze hun eigen 'open' specificatie van OpenXML niet altijd even nauwkeurig op in hun eigen implementatie in Office 2007. Als ze dan nu misschien aan het omslaan zijn (zoals deze berichtgeving een beetje laat zien) dan wil ik eerst nog wel eens zien of het deze keer ook echt vrucht kan brengen, want het verleden leert duidelijk dat dat nog wel eens tegenvalt terwijl het eerst wel heel erg belovend kan klinken.

[Verwijderd]

Dit is best relevant omdat voorheen iedereen achter de OpenOffice.org voorgegeven ODF variant aanliep ook als deze lichtjes van de standaard afweek.
MS heeft echter gekozen om van die lijn af te wijken en de standaard stricter te volgen en alleen het OOo voorbeeld te volgen als dat binnen de standaard past.
Verder is voor het onbeschreven spreadsheet stuk in de ODF specificatie door MS gekozen om de ooxml formula's in de ODF files toe te passen. (dat levert veel implementatie voordelen op voor applicaties die reeds compatibel zijn met excel)

En MS Office 2007 zal straks in 1 keer de meest geimplementereerde ODF applicatie worden dus het is best relevant als er ODF van een nieuw smaakje op de markt komt.

Voorkomen moet worden dat we interoperabiliteits issues krijgen en je straks niet uitwisselbare ODF varianten gaat krijgen

[Maurits van Baerle]

Verder is voor het onbeschreven spreadsheet stuk in de ODF specificatie door MS gekozen om de ooxml formula's in de ODF files toe te passen. (dat levert veel implementatie voordelen op voor applicaties die reeds compatibel zijn met excel)

Het enige vervelende is dat MS eigen versie van de formules niet compatible is met draft-ODF1.2 zodat we straks incompatibiliteit hebben tussen MS-ODF en de rest van de ODF implementaties.

[Verwijderd]

Aangezien MS ervoor gekozen heeft om ODF 1.1 te gaan ondersteunen is dat geen problematisch issue.
ODF 1.2. is nog maar een draft. Ik heb gezien dat de OASIS TC hoopt deze in de loop van 2009 te voltooien en als OASIS standaard geaccepteerd te krijgen en dan duurt het nog minstens tot 2010 voor deze nieuwe versie door ISO behandeld kan worden.

[Maurits van Baerle]

En wat heb je daar aan? MS is nu al incompatible met andere ODF applicaties die draft-ODF1.2 gebruiken en straks gaat ISO die incompatibiliteit nog eens bevestigen.

Het enige waar MS nu op afstevent is dat over een paar jaar een rechter zal verordenen dat ze zich aan de recente standaard moeten houden en ze gedwongen worden om hun Excel weer aan te passen.

Nou moet je op zich nooit belangrijke berekeningen aan Excel toevertrouwen maar je zult het als bedrijf maar wel gedaan hebben. Welke cijfers zullen we vertrouwen, die uit Excel 97, Excel 2003 of Excel 2010?

[Verwijderd]

Het is dus ook belachelijk dat OOo of OOo derivaten nu op een (onbekende welke verse) draft versie zitten.
Dat kan dus echt niet qua interoperabiliteit.
Je kunt op de OOo site niet eens vinden welke draft versie van ODF ze eigenlijk ondersteunen. Dat is toch belachelijk. Ze claimen standaard te onder steunen maar ondersteunen een draft versie en het is niet eens duidelijk welke.

Juist dit soort interoperability is het waar het in dit artikel over gaat. MS geet dusnu juist al die info over hun implementatie van ODF die in de OOo implementatie volstrekt ontbreekt en waar al menig conculega zich aan gestoten heeft (kOffice en Gnome office producten bijvoorbeeld).

[graey]

Ik denk juist dat de kans zeer reeel is dat Microsoft eerst ODF vrij aardig ondersteunt, dat het een beetje gaat neigen naar een eigen implementatie, dat vervolgens er toch interoperabiliteitsproblemen ontstaan, waarmee het gaat lijken alsof 'men' van Microsoft aan het afwijken is waardoor Microsofts implementatie zal overleven (al dan niet redelijk gedocumenteerd) en Microsoft haar monopoliepositie redelijk tot goed zal kunnen handhaven. Begrijpelijk ook, want Office is (misschien nog wel meer dan Windows) een goede bron van inkomsten voor Microsoft, en als ze dat zo kunnen houden zullen ze dat graag doen.
(trema's lukken niet lekker op dit systeem, sorry)

[Reactie gewijzigd door graey op 24 juli 2024 11:59]

[kidde]

Die strategie lijkt me te riskant; om de volgende redenen:

-De stap naar een andere applicatie die zich wel volledig ODF naleeft is klein;
-De reden dat mensen ODF gebruiken is juist om aan de afhankelijkheid van leveranciers te ontkomen. Die mensen hebben dus al door dat afhankelijkheid van een leverancier niet goed is. Ze zullen dus wel oppassen om opnieuw van een enkele leverancier afhankelijk te worden.
-Microsoft doet er haar best voor zich te houden aan standaarden de laatste tijd; de ervaring met Internet Explorer heeft geleerd dat mensen anders gaan klagen, en indien er niets door Microsoft ondernomen wordt weglopen.
-Gaan ze toch afwijken van de standaard, dan zullen ze o.a. door de EC gedwongen worden die afwijkingen ook te openbaren, documenteren en beschikbaar te maken onder redelijke voorwaarden, met risico op een boete. Iets dat een bedrijf zich in tijden van recessie waarin de consument bestedingen uitstelt niet kan permitteren lijkt me zo.

Maar ja, ik heb het vaker bij het verkeerde eind gehad omtrent voorspellingen rond Microsoft dus je weet maar nooit.

[kidde]

omdat voorheen iedereen achter de OpenOffice.org voorgegeven ODF variant aanliep ook als deze lichtjes van de standaard afweek.

Overdrijven is een kunst. Ooit vroeg ik op een KOffice lijst waarom men niet de OpenOffice implementatie voor .doc gebruikte. "Omdat die een ongelooflijke troep is" kreeg ik als antwoord. Dus ik heb hem gedownload, en voor mijn ongetrainde oog leek het erop dat men bij KOffice gelijk had. Het feit dat de schaarse commentaren in het Duits waren zij al best veel.
Ook China, Korea en anderen liepen niet achter de OpenOffice variant van ODF aan maar kwamen zelf met UOF.

Dat Microsoft de specificatie strikt gaat volgen is dus alleen maar fijn voor mensen zoals ontwikkelaars van KOffice en anderen gok ik zo.

En MS Office 2007 zal straks in 1 keer de meest geimplementereerde ODF applicatie worden

Een interessant statement. Ten eerste is dat niet zeker omdat het aantal gebruikers van vrije software met geen mogelijkheid te bepalen is; afgezien van alle 6 miljard bewoners van de aarde vragen. Ten tweede is het aantal gebruikers van Microsoft Office 2007 met geen mogelijkheid te bepalen; tenzij je dezelfde tactiek toepast.

Voorkomen moet worden dat we interoperabiliteits issues krijgen en je straks niet uitwisselbare ODF varianten gaat krijgen

Pasgeleden richtte OASIS een werkgroep op met precies dat doel. Ik neem aan dat Microsoft met deze doelstelling ook in die werkgroep zit? Ze staan er namelijk nog niet bij. Zou toch zonde zijn als de krachten niet gebundeld werden om de maatschappij ten dienst te zijn.

[Panic1]

ODF bestaat toch uit een hoop ISO normen enzo? En de specificaties voor ODF worden toch door een externe organisatie vastgelegd?

MS zal uiteraard op termijn aanpassingen aan de ODF standaard willen doorvoeren, maar daarin verschilt het in niks met opensource projecten die hun bijdrage leveren. Het zal eerder aan de integriteit van deze ODF standaardenorganisatie liggen dat er proprietaire extensies van MS in de standaard worden toegelaten.
Ok, MS heeft met OOXML wel ervaring opgedaan om eigen standaarden door te drukken, maar de backlash heeft de ISO organisatie geen deugd gedaan. Laat ons hopen dat de les in de toekomst niet vergeten geraakt.

MS speelt in op de vele overheden en instanties die momenteel overschakelen op open standaard documentformaten, om zijn klanten en omzet niet te verliezen. Logisch, toch?

Als ze inderdaad Embrace/Extend/Extinguish van plan zijn, dan is het weer geen open standaard, en dan schakelen de overheden toch gewoon opnieuw over? Dan zou het allemaal voor niks zijn geweest...

** crossing my fingers ** :-)

[kidde]

Het zal eerder aan de integriteit van deze ODF standaardenorganisatie liggen dat er proprietaire extensies van MS in de standaard worden toegelaten.

OASIS - de standaardenorganisatie achter ODF - heeft hier al rekening mee gehouden; dit kan namelijk al.

[Verwijderd]

ODF bevindt zich in de 'embrace' fase.

nu is het aan microsoft om eenzijdig extensies toe te voegen en zo over te gaan naar de 'extend' fase. deze niet compatible extensies kunnen in eerste instantie uitgelegd worden als "onduidelijkheden in de ODF specificatie". later komt daar het argument bij dat ms dingen nodig heeft die niet in de spec staan cq dat de spec zich te langzaam ontwikkelt. dit leidt vervolgens tot incompatibliteiten. open office en andere open source editors werken niet langer met ODF dat door een microsoft produkt gegenereerd is.

hierna zal de ODF variant van ms leidend worden omdat ze een monopolie hebben op de client side (MS Word). De ODF variant van MS zal, na onenigheid met de ODF standaard organen, hernoemd worden tot MS-ODF. MS-ODF raakt op een gegeven moment 'deprecated' . MS zal adviseren geen MS-ODF meer te gebruiken maar over te stappen op Open XML v7.3 ('extinguish').

http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

[Niemand_Anders]

Voordat je Microsoft begint af te kraken moet je misschien eerst eens kijken hoe de verschillende open source office producten ten opzichte van elkaar verschillen.

Nog steeds ziet een ODF documentie geschreven met KWord (Koffice 1.6) er in OO writer (zowel Linux als Windows versie (beide 3.0)) er anders uit. M.a.w. is er nog geen enkele 100% implementatie van ODF beschikbaar en helaas zijn ook een aantal onderdelen niet voldoende beschreven.

Daarnaast zijn ODF en Open XML opslag formaten en geen 'werk' formaten. En daar zitten eigenlijk grotendeels de verschillen. Op het moment dat jij in OO Calc een werkblad als XLS opslaat krijg je een waarschuwing of je dat wel zeker weet omdat OO Calc niet alle informatie kwijt kan in het XLS document.

Een zelfde probleem heeft Microsoft ook met ODF. Hoe sla je iets op wat nog niet beschreven is in een specificatie? Denk bijvoorbeeld eens aan een macro. Inderdaad een eenzijdige extensie, maar wel een welke belangrijk is voor bedrijven.

Ik zeg niet dat Open XML of ODF beter is dan de ander, en hoewel beide veel op elkaar lijken, hebben ze ook verschillen. Vrijwel alle implementaties zullen hun werk formaten afstemmen op hun primaire opslag formaat.

En nog voordat iemand ook nog maar iets heeft kunnen testen, zie ik hier alleen maar vooroordelen voorbij komen.

Het belangrijkste, wat vaak vergeten wordt, is dat beide formaten op XML zijn gebaseerd. Daarnaast worden op de interop website juist de 'undocumented' features beschreven. Iets wat zowel bij Koffice als OpenOffice/StarOffice niet gebeurt.

Want OpenOffice 3.0 heeft ODF 1.1 geïmplementeerd, terwijl de ISO alleen 1.0 als standaard heeft verklaard. Echter heeft OpenOffice niet beschreven wat ze *niet* hebben geïmplementeerd.

Een voorbeeld op een ander terrein. Als alle fabrikanten behalve Microsoft zich aan de standaarden houden, waarom behaalde dan niet direct de 100% score in de Acid 3 test welke gebaseerd is op W3C standaarden? Hetzelfde is nu al te zien met de verschillende ODF implementaties. Niemand heeft ODF 1.0 volledig volgens de specificaties geïmplementeerd! Voorlopig is Microsoft de enigste welke dat ook daadwerkelijk publieke op papier zal gaan zetten.

[kidde]

. M.a.w. is er nog geen enkele 100% implementatie van ODF beschikbaar

Dat komt door de opdracht die het standaardisatieorgaan kreeg.
ODF was bedoeld als zijnde bestandsformaat voor meerdere office-suites.
Als je met meerdere groeperingen een standaard gaat maken hebben al hun kantoor-applicaties unieke eigenschappen. Als die allemaal in de standaard terechtkomen is het logisch dat het even duurt voordat alle 'deelnemers' die eigenschappen hebben geïmplementeerd.

In het geval van OOXML was Microsoft door derden gevraagd haar bestandsformaat te standaardiseren zodat het voor andere derden open was. Daarom vroeg Microsoft aan ECMA een standaard te schrijven die 100% compatibel was met de bestaande formaat-versie van Microsoft office. Daarom zijn er in OOXML geen features opgenomen die niet door Microsoft Office ondersteund worden.

Een zelfde probleem heeft Microsoft ook met ODF. Hoe sla je iets op wat nog niet beschreven is in een specificatie?

Zelfde als voor OOXML: In een extensie; een mogelijkheid die zowel ODF als OOXML ondersteunen. Of opslaan in een andere standaard en daarnaar verwijzen zou ik zo gokken.
Zo werken ISO/CEN-normen normaal: Wie bijv. in EN-755 van maatafwijkingen van profielen zoekt naar chemische samenstelling van diezelfde profielen wordt doorverwezen naar EN-573, en wie iets wil weten over de leveringsvoorwaarden naar EN 12020. Niet moeilijk, werkt al jaren prima zo.

Denk bijvoorbeeld eens aan een macro.

Er zou voor macro's een aparte ISO-standaard moeten zijn. De standaard voor ISO-standaard voor moertjes is tenslotte ook niet aan de standaard voor boutjes toegevoegd. Zelfde voor 'formules', plaatjes e.d.
Verwijst een document naar een macro, zou ik zelf zeggen: ISO norm maken voor die macro, macro zippen en aan de XML-'container' toevoegen, en document laten verwijzen naar het macro-bestand.
Heeft een bepaalde applicatie geen ondersteuning voor dat formaat, zoekt de klant een applicatie die dat wel heeft of de klant leert ermee te leven.
Dat is ook zo als je een leverancier hebt die profielen levert volgens EN-755 maar niet volgens EN-12020.

Daarnaast worden op de interop website juist de 'undocumented' features beschreven

Dat is een interne tegenstelling: Hoe kan je iets dat niet uitgelegd is beschrijven?

Afgezien van die opmerkingen: Is het erg dat iemand niet 100% van een standaard implementeert? Natuurlijk niet, zou ik zelf zeggen. Want dat is het doel niet van een standaard.

In DIN 1 staan vele formaten conische pennen. Wil dat zeggen dat een fabrikant ze allemaal moet leveren? Natuurlijk niet, dat was nooit het doel van DIN. Idee is dat als iemand één formaat levert alle andere mensen 'gaten' kunnen leveren waar deze pen inpast.

Idee van een standaard voor Office-formaten is dat als programma A een textbestand met opmaak opslaat, dat programma B dat kan lezen. Dat A ook spreadsheets kan opslaan en B deze niet kan lezen is niet relevant. Feit is dat A en B zich aan de standaard houden.

Daarin ligt ook het antwoord op de vraag: Wat als je iets toevoegt dat niet in de standaard staat? Als een leverancier een maat conische pennen wil leveren die niet in DIN 1 staat, doet hij of zijn best die toe te voegen aan DIN1, of hij gaat zelf zijn eigen standaard vrijgeven onder bruikbare voorwaarden. Zijn die voorwaarden niet bruikbaar, dan zal niemand die standaard gebruiken. Althans, zolang die markt is gevrijwaard van misbruik door bedrijven met een economische machtspositie. Dat laatste geld helaas niet voor de kantoor-applicatie markt; maar zo zou het moeten werken in een vrije markt.

Wil Microsoft de mogelijkheid bieden dingen op te slaan in ODF die niet in ODF gespecificeerd zijn, is het Microsofts taak binnen OASIS te zorgen dat ODF hier ondersteuning voor gaat bieden. Dat kan, want Microsoft is OASIS-lid.

Wil het KOffice team dat OOXML ook ondersteuning biedt voor frame-based formaten, is het zaak dat ze lid worden van ECMA en hiervoor hun best gaan doen.

Dat kan, want KDE kan theoretisch lid worden van ECMA; al hebben ze hier waarschijnlijk te weinig geld voor. Helaas kunnen alleen de gevestigde bedrijven er vervolgens over stemmen (en bestuursleden voor ECMA aanwijzen etc.); maar zo zit ECMA nou eenmaal in elkaar (het heeft geen maatschappelijke doelstelling zoals ISO, maar is een bedrijven-belangenorganisatie).

Het voornaamste probleem met de Office-bestandsformaatstandaarden is dus dat ze te groot en niet atomair genoeg zijn.

[Ook al Bezet]

Want OpenOffice 3.0 heeft ODF 1.1 geïmplementeerd, terwijl de ISO alleen 1.0 als standaard heeft verklaard. Echter heeft OpenOffice niet beschreven wat ze *niet* hebben geïmplementeerd.

Kleine correctie, OOo 3.0 gebruikt geen ODF 1.1 (wat trouwens al wel door OASIS als standaard is geaccepteerd) maar 1.2.
Je punt blijft daarmee natuurlijk wel staan.

[PolarBear]

nu is het aan microsoft om eenzijdig extensies toe te voegen

Welke dan?

[Superstoned]

Ach, het afspelen van proprietary video formaten, binary code voor automatisering van taken, gepatenteerde effecten, ze hebben genoeg creatieve advocaten die met dingen kunnen komen die het de concurrent (en klant) moeilijker maken.

[tuXzero]

+1 Van mij. Dit omdat alhoewel dit misschien niet het geval is, of misschien wel regelrecht onjuist. Het wel een werkelijk risico is (Microsoft is een bedrijf net als vele andere, en het hoogste doel is winst, you do the path.).

En daarom heeft het meerwaarde, want als we willen dat de office markt concurrerende prijzen en kwaliteit bied moeten we ervoor zorgen dat EEE geen vluchtweg voor concurrentie wordt. Niet alleen voor Microsoft maar voor elk bedrijf.

[graey]

You may do the path, but I'll just go for the math and be happy with that. ^^

[d-snp]

Met als resultaat een betere standaard. Dat de opensource wereld niet rap genoeg is om met de ontwikkelingen van microsofts 'extend' praktijken mee te hobbelen is toch zeker haar probleem? Doorgaans zijn de extensies die microsoft biedt (zoals bijvoorbeeld bij java) wel nuttig. En hier geld nu ook nog eens dat alles wat ze doen open is, waardoor het perfect mogelijk is om aan te geven wat er veranderd, waarom, en wat je kunt doen om er in mee te gaan of om het openlijk te veroordelen.

Daarnaast is volgens mij iedere poging tot EEE van microsoft op niets uitgelopen, vaak omdat justitie er een stop voor zette, of gewoon doordat de community adequaat reageerde.

[dgompie]

Welke extensies aan Java waren nuttig? De Java integratie naar het COM systeem van Microsoft? Geen ander OS ondersteunt COM, dus het breekt het write-once run-every principe (een klein beetje).

[kidde]

Dat de opensource wereld niet rap genoeg is om met de ontwikkelingen van microsofts 'extend' praktijken mee te hobbelen

Het was toch echt andersom dit keer: Microsoft was niet rap genoeg om met de ontwikkelingen van open standaarden mee te hobbelen.

Sterker nog: In ODF is al aan Microsoft gedacht, en exact daarom is er al de mogelijkheid in opgenomen om extenties binnen een ODF bestand toe te voegen!
Normaal gesproken was dit binnen ODF niet gedaan, maar aangezien dit binnen OOXML wel kon is die mogelijkheid ook aan ODF toegevoegd.

[Verwijderd]

Hehe, zou eens tijd worden.
Nu kunnen ze bij OpenOffice en de rest ook weer verder met odf en ooxml.

Dank u, M$

[Toontje_78]

Niets mis met het zo breed mogelijk ondersteunen van lezen (en schrijven) van verschillende formaten. Dat komt de functionaliteit alleen maar ten goede.

Het blijft toch dat verschillende programmas hetzelfde formaat met details verschil inlezen, met name tabs in mijn ervaring. Zolang het lettertype, regelafstand en andere bewerkelijker te behandelen stijlen goed overgenomen worden is het werkbaar.

[Verwijderd]

Niets mis met het zo breed mogelijk ondersteunen van lezen (en schrijven) van verschillende formaten. Dat komt de functionaliteit alleen maar ten goede.

True, maar dat maakt het toch enkel vreemd dat MS nu pas ODF implementeert?

[CAPSLOCK2000]

Ik vind dit een geweldige actie van Microsoft.
Het is helemaal waar dat specificaties vaak niet helemaal duidelijk zijn. Het gewoon ontzettend moeilijk om alles exact duidelijk te maken. Je hebt eigenlijk altijd een uitleg nodig die verklaart wat de bedoeling is.
Je kan het vergelijken met een wiskunde boek. Daar staan ook niet alleen maar formules in, maar ook tekst waarin uitgelegd wat de formules betekenen. Ook voor programma code geldt het. Broncode zonder commentaar is een stuk moeilijker te lezen, en nog veel moeilijker te debuggen. Pas als je weet wat de auteur bedoelt kan je weten of hij het goed heeft opgeschreven.

Het maakt mij niet uit wat voor bestandsformaten en protocollen Microsoft gebruikt, als ze het maar goed documenteren (en die documentatie ook publiceren)!


Open source software heeft het voordeel dat het source beschikbaar is, en je dus kan nagaan hoe iets geimplementeerd is. Maar, zoals ik al eerder zij, ook dan is goede documentatie van belang.
Omdat open source software developers veelal over mailinglijsten, irc en blogs communiceren wordt een groot deel van hun communicatie opgeslagen zodat je kan teruglezen waarom bepaalde beslissingen genomen zijn. Verder is bekend wie iets geschreven heeft, en je kunt de schrijver dus altijd proberen te e-mailen.
Een antwoord krijgen is natuurlijk een tweede, en al die een-mans projectjes produceren natuurlijk ook niet erg veel communicatie.


Maar goed, ik ben blij met deze constructieve opstelling van Microsoft.

[webhalla]

Het is van belang dat Microsoft Office ODF bestanden goed kan lezen. Als Sun doorgaat met het ontslaan van hun medewerkers in het tempo van de laatste tijd, dan kunnen de OOo gebruikers tenminste hun bestanden straks weer terug converteren.

[smokalot]

MicroSoft heeft helaas nog nooit aangekondigd ook ODF ondersteuning toe te voegen aan Office voor de mac, dus zo serieus zijn ze nou ook weer niet met de ODF ondersteuning.

Gelukkig werkt OpenOffice.org 3.0 wel prima op de mac, en kun je daar wel alle bestanden lezen en schrijven.

[Verwijderd]

Pardon? Office op de Mac een nihiel gedeelte? Moet je eens bij ons komen kijken... Stapels Macs, en allemaal draaien ze Office.

[Ronald]

Als julie de enige zijn, dan kan het nog steeds een nihiel gedeelte zijn.

Cijfers graag!