Massachusetts zet deur weer open voor Microsoft-documenten

De Amerikaanse staat Massachusetts gaat het gebruik van Microsofts Open XML-formaat waarschijnlijk toestaan. Twee jaar terug deed het de kantoorformaten van de softwaregigant in de ban ten faveure van open bestandstypen.

Indertijd maakte de beslissing veel reacties los bij Microsoft, open-sourcebedrijven en het analistengilde, en het is aannemelijk dat de belofte van de softwaregigant om zijn formaten te gaan standaardiseren een reactie op het besluit van Massachusetts was. Een nieuw voorstel van de ict-dienst van de staat vermeldt nu Open XML, naast het ODF-formaat, als toegestaan bestandsformaat. Voorheen mochten overheidsdocumenten enkel in ODF worden opgemaakt. Toen Microsoft Open XML anderhalf jaar geleden bij het standaardiseringsorgaan Ecma deponeerde, zette Massachussets de deur reeds op een kier en gaf aan dat het formaat in de toekomst wellicht toegelaten kon worden. Inmiddels heeft Open XML een Ecma-certificaat maar is het nog in afwachting van het Iso-stempel, wat ODF al wel reeds in de wacht sleepte.

Volgens de ict-dienst van Massachustetts is het voorstel een reactie op het verzoek van gebruikers om meer flexibiliteit. Ondanks het in stelling brengen van een ODF-plugin voor Microsoft Office werd geklaagd over de afwezigheid van toegankelijkheidsfeatures voor mindervaliden in alternatieve software zoals OpenOffice.org en StarOffice. Volgens technologieadvocaat Andrew Updegrove is het echter een fundamenteel verkeerde beslissing om een standaard die slechts in een enkel pakket, Microsoft Office, is geïmplementeerd, dezelfde status te geven als ODF, 'dat inmiddels door een stuk of dertig pakketten wordt ondersteund'. Hij pleit er voor om dit soort beslissingen niet aan 'carrièretechneuten' over te laten maar aan wetgeving onderhavig te maken, waarbij hij er overigens aan voorbijgaat dat pogingen in die richting in de VS tot dusver zijn gestrand. Updegrove en anderen hebben tot 20 juli de tijd om zich tegen het voorstel uit te spreken.

Reacties (33)

[Bundin]

The work to standardize OpenXML has been carried out by Ecma International as part of an open, cross-industry collaboration via Technical Committee 45 (Ecma TC45), which includes representatives from Apple, Barclays Capital, BP, The British Library, Essilor, Intel, Microsoft, NextPage, Novell, Statoil, Toshiba, and the United States Library of Congress.

With more and more organizations around the world interested in achieving document processing interoperability, and creating digital archives using open formats, the Office Open XML (Open XML) formats provide an international open standard for word-processing documents, presentations, and spreadsheets that can be freely implemented across multiple applications and platforms, both today and in the future. Multiple vendors such as Corel, Microsoft and Novell already announced implementations of the Open XML standard in very popular applications such as WordPerfect, Open Office and Microsoft Office 2007.

bron: http://www.ecma-internati...eases/PR_TC45_Dec2006.htm

Mijn interpretatie: Ecma's commissie is nu de "baas" over de OpenXML standaard, het is bij Ecma in beheer, niet bij MS. Ook is de standaard compleet open (in tegenstelling dan hierboven beweerd). Enige problemen met implementatie in andere pakketten dan MS Office heeft dus niets met MS te doen.

[Reactie gewijzigd door Bundin op 24 juli 2024 22:04]

[Pruttelpot]

@ Jellinek:

Da's niet geheel correct hoor, de OpenXML standaard is gecertificeerd door ECMA, en niet in beheer oid. Novell en Corel hebben beide overeenkomsten met MS gesloten voor het bevorderen van de interoperabiliteit, je weet wel, die contracten die bekend staan als "Patent aanklacht bescherming cq afpersing door MS".

OpenXML is NIET compleet open, een groot deel van de markup is compleet niet aanwezig in de documentatie. Sterker nog, OXML lijkt een one-way standard te zijn, office kan het namelijk niet schrijven en dat lijkt er niet in te zitten op korte termijn ook.
Op basis van de huidige documenten kan je eenimplementatie schrijven wat Office kan inlezen, maar je kan geen implementatie schrijven waarmee je door office gegenereerde documenten kan inlezen.

Open? My ass. Een basaal deel. Niks meer.

[SirBlade]

Ja, laten we vooral technologie-beslissingen laten nemen door politici ipv door techneuten en de markt dan hoeven we in ieder geval niet bang te zijn voor verbeteringen of vooruitgang. Het zou wel makkelijk zijn voor MS en andere grote bedrijven, een paar donaties tijdens verkiezingscampagnes en de software van concurrenten wordt illegaal.

[kidde]

Hoezo, de kamer neemt toch ook beslissingen over tal van dingen waar men totaal geen verstand van heeft. Zoals het wel of niet toestaan van UMTS masten, een lagere maximumsnelheid om files (hopelijk, maar mislukt) te voorkomen, welke maatregelen tegen fijnstof wel en niet gesubsidieerd worden, wat de voorwaarden voor het beveiligingssysteem van de HSL (ERMTS) zijn, en ga maar door. De politici hebben niet overal verstand van, daar hebben ze adviseurs voor.

Nu is het zo dat de druk bij werknemers ligt die werken in opdracht van de politeik, en deze moeten beslissen wat wel en niet mag (welke standaarden wel en niet) aan de hand van bestaande akkoorden en besluiten. Op hun is zeer grote druk uitgeoefend door Microsoft, IBM en SUN, en deze mensen zijn niet op deze taak voorbereid en hebben daar nogal onder geleden.
Echter, het zou moeten zijn dat adviseurs aan de heren politici laten weten welke standaarden wel / niet voldoen, en de politici dit dan vastleggen, omdat de adviseurs / politici beter om kunnen gaan met de druk en zin/onzin van lobbyisten en publiek dan ICT'ers die in dienst worden genomen om besluiten uit te voeren zonder daarbij politieke beslissingen te kunnen nemen.
Politici moeten namelijk verantwoording afleggen aan de kiezers, ICT-werknemers die besluiten uitvoeren niet.

[Cyphax]

De vraag is of het wel echt een technologie-beslissing is die niet genomen kan worden door mensen zonder technologische achtergrond. In dit geval heeft men in Massachusetts gewoon een bepaalde eis neergezet en het is aan de hand van de beschrijving van Microsoft wel te zien of aan die eis is voldaan of niet.

OOXML is wellicht toch wat minder open dan ODF, en het is intern ook onduidelijker maar het is WEL XML, en het is gewoon te openen omdat het uiteindelijk gewoon tekst is in plaats van één of ander ongedocumenteerd binair formaat (.doc).
Het probleem met binaire formaten zoals .doc is dat je geen garantie hebt dat het in de toekomst goed te lezen blijft door nieuwe programmatuur (en dat de oude programmatuur blijft werken) en het dus zou kunnen dat je over 100 jaar met een documentje zit waarvan niemand eigenlijk meer weet wat het is. Als je een XML-bestand opent kun je dat nog wel zien. Het enige wat je niet zeker weet in het geval van OOXML is of het er over 100 jaar nog zo uitziet als nu - misschien is de layout niet in orde.

Dit neemt allemaal niet weg dat ik liever ODF gebruikt zie worden omdat het niet beheerd wordt door een bedrijf (met winstoogmerk) maar het is al een stap vooruit dat men een open formaat eist. En dat Microsoft meespeelt. Het zal best lastig zijn om bijv. OpenOffice.org zo te maken dat OOXML goed gelezen kan worden maar het is denk ik makkelijker dan bij het oude .doc-formaat.

[Verwijderd]

Het probleem met binaire formaten zoals .doc is dat je geen garantie hebt dat het in de toekomst goed te lezen blijft door nieuwe programmatuur (en dat de oude programmatuur blijft werken) en het dus zou kunnen dat je over 100 jaar met een documentje zit waarvan niemand eigenlijk meer weet wat het is. Als je een XML-bestand opent kun je dat nog wel zien.

Denk je dat?
Valt tegen hoor. De leesbaarheid is afhankelijk van de karakterset... in feite is XML net zo binair als een .doc.
Dat XML (doorgaans) in 8-bit ASCII/ANSI wordt opgeslagen, en dat dat bij ons ingeburgerd is als tekstformaat is geen garantie dat dat altijd zo blijft.
Over 100 jaar gebruikt iedereen misschien een of andere wide characterset zoals unicode, en kun je een huidig XML-bestand misschien helemaal niet meer openen in een standaard tekst-editor. Misschien gebruik en we dan uberhaupt geen 8-bit bytes meer, maar baseren we alles op 16-bit of 32-bit datatypen ofzo.
Vergezocht? Nee hoor... Lang geleden gebruikte men 5-bit karaktersets... tegenwoordig denken we allemaal in 8-bit bytes, dus het lezen van iets dat niet in bytes op te delen is, is zeer lastig. Met een hex-editor is er niks te maken van een 5-bit tekstbestand.
Of wat te denken van bv PETSCII, gebruikt door Commodore? Op alle Commodore-machines was dat prima te lezen, daar was het de standaard... maar zo'n bestandje op een ander systeem lezen was niet zo makkelijk. Over 100 jaar zijn we waarschijnlijk vergeten wat PETSCII ook alweer was, dus alle tekstbestanden zijn dan voorgoed verloren, ook al waren het XML-bestanden.

Lees ook eens http://tronweb.super-nova.co.jp/characcodehist.html

XML is in feite een wassen neus. Je zult altijd metadata moeten opslaan, en dan liefst niet in digitale vorm, want anders heb je altijd een kip-en-ei probleem. Je kunt er niet vanuitgaan dat ASCII/ANSI of unicode altijd blijft bestaan, of dat we over 100 jaar nog steeds met 8-bit bytes werken. Of met bits in het algemeen? Quantumcomputers werken bv weer met een ander type eenheid.
In feite is ieder bestandstype niet meer dan een reeks bits, en als je verder niet weet hoe je van die bits leesbare symbolen kunt maken, dan kun je lang puzzelen.

Het is dus zaak om documentatie op papier te bewaren. Geschreven taal heeft al lang bewezen dat het veel duurzamer is dan digitale informatie.

Afgezien daarvan geeft het commentaar op de OOXML-standaard ook al aan dat je eigenlijk geen kont aan XML hebt. Okee, je kunt wel wat ruwe tekst filteren uit een XML-bestand... Maar wat die tags betekenen kun je nooit opmaken uit het XML-bestand zelf.
Ruwe tekst uit een .doc filteren kan ik ook wel... gewoon alles dat geen letter, cijfer of leesteken is, weggooien. Kom je ongeveer op hetzelfde uit als een XML zonder tags.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:04]

[Verwijderd]

@Pruttelpot

waar heb je het over? MS Office 2007 gebruikt als DEFAULT het Open XML formaat. Laden en Saven! Voor Office 2000, XP en 2003 kan je een gratis compat pack downloaden, iets wat ook automatisch kan als je office heb geupdate.

En dan 'Een groot deel van de markup niet aanwezig'... Waar dan? Eerst wordt er gezeurd dat er te veel markup spec is, nu dat er delen niet zijn gedocumenteerd. Heb je uberhaupt de standaard ooit ingezien. Je kan hem gratis downloaden bij ECMA.

Duidelijk weer een gevalletje slecht geinformeerd.

[Cameleon73]

Zeker een gevalletje slecht geïnformeerd. Lees b.v. dit artikel maar 'ns. Aangezien er maar een 30 dagen 'geen contradictie' periode was (voor de Ecma standaard) is er nog niet eens heel diep gekeken naar deze 'standaard'. Maar een paar schrijnende gevallen:

• Internal inconsistencies and omissions. For example, book 4 section 2.18.4 lists styles such as "apples", "scaredCat", and "heebieJeebies", but does not fully define these styles. Bron
• OOXML does not conform to ISO 8601:2004 "Representation of Dates and Times." Instead, OOXML section 3.17.4.1, "Date Representation," on page 3305, requires that implementations replicate a Microsoft bug that dictates that 1900 is a leap year, which in fact it isn't. Similarly, in order to comply with OOXML, your product would be required to use the WEEKDAY() spreadsheet function, and therefore assign incorrect dates to some days of the week, and also miscalculate the number of days between certain dates. Bron
• I was reading through the Office Open XML draft yesterday, and came across a whole host of scary elements. These are all from Part 4 of the draft specs, entitled Markup Language Reference, and, yes, those are the real page numbers. It is not a short documemt, and this may partly explain why. For example:
  • autoSpaceLikeWord95 (Emulate Word 95 Full Width Character Spacing) - pages 1378-1379
  • footnoteLayoutLikeWW8 (Emulate Word 6.x/95/97 Footnote Placement) - pages 1416-1417
  • lineWrapLikeWord6 (Emulate Word 6.0 Line Wrapping for East Asian Text) - pages 1426-1427

Veel plezier met implementeren van deze 'standaard'!

[Reactie gewijzigd door Cameleon73 op 24 juli 2024 22:04]

[Verwijderd]

Dit gaat niet in op de puntjen genoemd in pruttelpot zijn post.

Verder ben ik volledig bekend met deze zaken.

Punt 1 - ach.
Punt 2 - Dit is vanwege backward compat. Staat standaard uit, en is niet het enige ondersteunde datum formaat. IMHO slecht voorbeeld. Of moeten we alle oude documenten maar vergeten?
Punt 3 - Dit staat niet in het normatieve gedeelte van de spec.

[Cameleon73]

Sorry ... maar ik vraag me af wat jij verstaat onder een standaard. Dit betekent simpelweg nl. dat als ik OOXML zou willen ondersteunen, ik gedwongen wordt om MS Office te reverse engineeren (!) Anders krijg ik nooit Office 2003/2007 documenten goed verwerkt.
En 'backwards compatibility' vind ik een slecht argument. Zeker als je een nieuwe standaard bedenkt (bedenk wel, we hebben het hier over OOXML ... een standaard die pas net met 2007 wordt geïntroduceerd. En -zoals o.a. hier te lezen valt- zijn er ook oplossingen denkbaar waarin de compatibiliteit behouden blijft ... zonder een bug in de standaard op te nemen:

The “legacy reasons” argument is entirely bogus. Microsoft could have easily have defined the XML format to require correct dates and managed the compatibility issues when loading/saving files in Excel. A file format is not required to be identical to an application's internal representation.

Oh, en alle zaken die niet expliciet in de standaard staan omschreven, vallen ook niet onder de 'covenant not to sue' van MS. Dus zometeen hebben we 10 OOXML plugins, waarvan er maar één 'goed' werkt: die van MS. Eenmaal raden wat de gemiddelde consument daarvan denkt?

edit:
typevautje

[Reactie gewijzigd door Cameleon73 op 24 juli 2024 22:04]

[psyBSD]

Dit was te verwachten... doen alsof je bent voor vrijheid, maar uiteindelijk gaat het toch allemaal weer om geld.

[hansg]

Waar haal je dat uit? Massachusetts geeft heel duidelijk aan dat ze alleen documenten willen hebben die op open standaarden gebaseerd zijn. Microsoft conformeert zich vervolgens aan een open standaard (wel op een rare manier: door zijn eigen formaat tot standaard te laten verheffen in plaats van te conformeren aan een bestaande standaard). Massachusetts geeft vervolgens aan dat dat formaat daarom ook gebruikt mag worden. Nergens wordt gesproken over kortingen of zoiets.

Dat is toch geheel volgens de regels? Je zou het geschreeuw hier gehoord moeten hebben als Massachusetts besloten had dat het Microsoft formaat, ondanks dat het nu een formele standaard is, toch niet mocht!

Je conclusie dat het dus alleen maar om geld gaat slaat derhalve helemaal nergens op. Tenzij je daarmee eigenlijk wil zeggen dat OpenXML eigenlijk helemaal geen formele standaard is en ook niet gebruikt zou mogen worden volgens de definitie die Massachusetts hanteert?

[maxxware]

Vreemd... OOXML is een 'open standaard', maar om echt te kunnen werken met OOXML in te zien moet een NDA worden ingevuld. Dat toont aan dat OOXML geen echte open standaard is.

[J.J.J. Bokma]

Bron? OOXML is al een Ecma standaard (Ecma 376), en wordt wellicht ook een ISO standaard.

Kan jij vertellen waar ik op:

http://www.ecma-internati...ns/standards/Ecma-376.htm

Die NDA moet invullen?

Typisch weer FUD en fanboy geleuter. 'T zou fijn zijn als mensen voor ze driftig beginnen te posten eerst even hun anti-MS gevoel uitzetten en reageren op feiten, niet op wat ze willen dat het is.

[Cameleon73]

Ok, die NDA clausule komt me ook niet bekend voor. Maar OOXML is zeker niet zonder kritiek. En dat het een Ecma standaard is, heeft meer met lobbyen te maken dan met standaardisering.

[maxxware]

http://ptsefton.com/blog/2007/02/09/odf-converters

Quote: "The Open Document Foundation's ACME376 plugin

I wrote about the the Open Document Foundation's outlandish claims about a magic way of saving Word documents into ODF last year.

I had someone at the mysterious 'foundation' contact me and offer to let us participate in a Beta program if we signed an NDA. I wouldn't have signed, but I heard nothing more. Obviously anyone who has tried this thing has done so is still under an NDA 'cos there's still no usable information on their file format converter..."

[servies]

Wat ik er van begrepen heb via Groklaw is dat ze een uitbreiding op de regel hebben gemaakt zodat niet alleen meer van open standaarden zijn toegestaan maar ook "de facto" standaarden...
En gut... wat is OpenXML nu eigenlijk... Feitelijk is het geen open standaard door alle verwijzigingen naar gesloten standaarden. Het is wel een de facto standaard omdat het door zoveel mensen wordt gebruikt.
En het microsoft formaat is overigens nog steeds GEEN formele standaard!

[hansg]

Voor iets een de facto standaard is moet het naar mijn idee door veel mensen gebruikt worden. En OpenXML mag dan in de nieuwste versie van Office zitten, maar ik ken werkelijk niemand die die al gebruikt. En zelfs dan nog: het is bij mijn weten niet de default (correct me if I'm wrong), dus zo ontzettend veel gebruikers zal het niet hebben.

Niks de facto standaard dus.

[Vaudtje]

Als je een beetje op je vrijheid let, kan dat dus geld besparen, bijvoorbeeld omdat je dan van wurgcontracten op basis van vendor lock-in af bent.

[Mei]

Netjes dit Duidelijk stellen dat je het ergens niet mee eens bent en als het probleem opgelost is het geheel alsnog overwegen. Mooi op gelost door Massachusetts

[Rinzwind]

Uhm welk platform buiten MS Office kan Open XML volledig openen?
Implementatiedetails zijn closed. Een reference implementatie zou eigenlijk noodzaak moeten zijn die door iedereen in te zien is.

ODF kan elk pakket implementeren.

[kidde]

Erger nog, er is momenteel niet één applicatie die kan opslaan in het MS OOXML dat nu als draft bij de ISO ligt. Deze draft, bijna gelijk aan ECMA376, is namelijk slechts een kreupele subset van het formaat dat de nieuwste versies van MS Office gebruiken om in op te slaan. Microsoft Office kan helemaal geen documenten opslaan in de semi-open OOXML standaard.

Het formaat waarin de nieuwste MS Office versies opslaan is dus niet open, en zonder ODF plugin is het dus helemaal [b]niet[/u] mogelijk om met MS Office bestanden in een open formaat op te slaan.

Overheden die hierin trappen, eindigen dus met MS Office dat alleen bestanden produceert die alleen met MS Office te lezen zijn, en zodoenden heeft Microsoft Corp. effectief het standaardisatieproces misbruikt om haar bestandsformaten bij regeringen te krijgen en daarmee de lock-in te handhaven.

bron

[Reactie gewijzigd door kidde op 24 juli 2024 22:04]

[J.J.J. Bokma]

Dat lock-in geleuter weer. Als men op OOo overstapt, zit men ook daar aan vast. Het is een feest dat er een open formaat gebakken is, maar welk programma ondersteund, naast OOo alle toeters en bellen van OOo?

Kijk maar eens naar HTML en CSS, al heel lang een open "standaard", toch zijn er zelfs *nu* nog implementatie verschillen, en dingen die de ene browser wel doet, en de andere niet. En nee, dan doel ik niet alleen op MS/IE.

En zo zijn er diverse andere open bestandsformaten waar het helemaal van het programma afhangt wat er wel en niet ondersteund wordt, en hoe complexer het formaat, hoe groter de kans op verschillen.

Dat vendor lock-in is gewoon 100% fud en fanboy geleuter wat mij betreft. Al te vaak meegemaakt dat dingen bij een update van OSS omvielen, net als bij closed-source, dat is nu eenmaal iets wat bij programma's op een of andere manier te vaak voorkomt.

[kidde]

KOffice ondersteunt ODF-onderdelen die niet door OOo ondersteund worden. Dat Microsoft bijna een ODF converter heeft en KOffice ODF ook bijna volledig ondersteunt, toont aan dat de enige die leutert jij zelf bent.

En tuurlijk, een spreadsheet-programma en een word-processor ondersteunen allebei verschillende onderdelen van een office-bestandsformaat (Duhh!) Dat hangt van de doelen van de applicatie af. Deze aparte programma's hoeven niet gekoppeld te zijn in een suite om een standaard te ondersteunen.

Over lock-in geleuter kan ik je het volgende vertellen: Een aantal mensen heeft gebruik gemaakt van de Office 2007 30-dagen trial, en kan sinds die trial voorbij is hun bestanden niet meer openen zonder te betalen voor de volledige versie van Microsoft Office. Iemand die dit weg-redeneert door mensen die dit aankaarten een fanboy te noemen, heeft geen flauw idee van hoe de industrie en overheden werken. Bedenk eens wat er gebeurd als die dit probleem zouden hebben voordat je het zonder na te denken gelul noemt.

Dat je vendor lock-in FUD noemt geeft al helemaal blijk dat je geen flauw idee hebt van wat zich in de industrie afspeelt, want er is namelijk geen enkele onzekerheid (uncertainty) of twijfel (doubt) dat vendor lock-in nadelige gevolgen heeft. Voorbeeldje: Bij DSM is men ingesloten in DIN-formaten voor de flenzen, dat verander je niet zo makkelijk. Echter, de buizen zijn op ASME gestandaardiseerd, en dat kost een hele hoop geconverteer van maten etc, wat fouten kan opleveren. en klauwen vol geld. In Amerika is men 'ingesloten' in het imperiale stelsel van maten, overschakelen op het SI lukt haast niet. Het kost het bedrijfsleven miljarden aan fouten in conversies (denk aan het marskarretje van 1 miljard dat niet werkte door een verkeerde conversie).

In het geval van de maten was er niet eens een venrdor lock-in, omdat de standaarden geheel open waren (zonder patenten en licenties), en toch is men nog ingesloten geraakt en kan men haast niet meer overschakelen, en kost het miljarden. Kan je nagaan wat er gebeurd als een bedrijf dit proces met opzet probeert te verergeren.
Als jij dat als FUD af wilt doen, geef je aan dat het jou niet boeit dat er volstrekt onnodig (dodelijke) ongelukken gebeuren in de industrie, dingen verkeerde maten hebben wegens conversiefouten, en dat dit allen miljarden kost. Daarmee diskwalificeer je jezef volledig als iemand die serieus te nemen valt; alleen een fanboy heeft zo weinig oog voor wat er in de realiteit speelt.

Ed: Over lock-in en vendor-afhankelijkheid gesproken: Ik herinner me een stelletje programmeurs die vrij goed in VB(6?) waren toen Microsoft de support stopte en deze programmeurs het nakijken hadden. Niemand behalve Microsoft kon de support continueren, vanwege het gesloten karakter van VB. Gelukkig echter zijn er open (GPL zelfs) cross-platform scripttalen als Perl, waar mensen kennelijk zelfs hun brood mee verdienen om dan bijv. in Mexico te gaan wonen. Ga eens na hoe iemand zich gevoeld had die zijn brood verdiende met VB programmeren, en dan opeens door een bedrijf gedwongen wordt een nieuwe andere taal te leren.

[Reactie gewijzigd door kidde op 24 juli 2024 22:04]

[Verwijderd]

Over lock-in geleuter kan ik je het volgende vertellen: Een aantal mensen heeft gebruik gemaakt van de Office 2007 30-dagen trial, en kan sinds die trial voorbij is hun bestanden niet meer openen zonder te betalen voor de volledige versie van Microsoft Office.

Afgezien van het feit dat het nogal voor de hand ligt dat je bij het opslaan moet kiezen voor het oude Office-formaat als je het na de 30-dagen trial nog wilt openen in je oude versie... (of voor een formaat als RTF, dat ook in andere pakketten werkt).
Er is gewoon een gratis pakket van Microsoft om OOXML te openen in oudere versies van Office: http://support.microsoft.com/kb/923505/
(Lijkt me veilig om aan te nemen dat ze al een oudere versie van Office hebben).

Dus tsja, het kan best zonder betalen.
Microsoft heeft ook altijd gratis viewers aangeboden voor Office-documenten, maar helaas is de versie voor Office 2007 er nog niet. Maar verder kan iedereen dus op zich Office-documenten bekijken zonder te betalen (desnoods linux live-cd -> wine -> MS Office Viewer).

[Reactie gewijzigd door Verwijderd op 24 juli 2024 22:04]

[Niemand_Anders]

Elk pakket kan ook OpenXML implementeren. Novell doet dit zelfs voor OpenOffice. Inderdaad is het binaire formaat van Excel nooit vrij gegeven, maar dat geld wel voor meer formaten. OpenXml heeft net als ODF de mogelijkheid om streams op te nemen in een document.

Een voorbeeld, standaard kan MS Office ook geen Visio diagrammen tonen, en als je deze embed, zie je gewoon niets. OpenXML betreft ook Excel en PowerPoint en dus kun je straks gewoon Excel en PowerPoint objecten inlezen met OpenOffice.

Er blijft echter wel 1 groot nadeel. OpenOffice mist gewoon een scripting taal zoals VBA.
Het zal mij dus niet verbazen als Novell via Mono (.NET) scripting mogelijkheden aan OpenOffice gaat toevoegen. Zodat Office 2007 documenten inclusief redelijke macro support bekeken kunnen worden.

[Pruttelpot]

@Niemand_Anders:

Dat is niet correct wat u daar beweerd waarde heer.

De OOXML specificatie die MS heeft aangeboden bij het Ecma en nu dus bij het ISO, is een zwaar verkreupelde versie van degene die in Office zit.
Met de specificatie die ze nu open noemen kom je in hetvoglende scenario terrecht:
Een ander pakket implementeerd (wat overigens bijna niet mogelijk is dorodat er teveel gesloten delen inzitten, zo is de Powerpoint en Excel import nog steeds gewoon gesloten en zal die dat zeer waarschijnlijk blijven ook) deze "standaard" waarbij enkel de basis van ooXML geiomplementeerd kan worden, je maakt er een document in, opent hem in Office, maakt wat wijzigingen en voila, willekeurig ander pakket kan op basis van de doos MS vrijgegeven "standaard" het document niet meer openen, office werkt namelijk niet volgens de specificatie die ze nu laten standaardiseren.

Wat MS nu doet is enkel en alleen de overheid pootje lichten, een standaard met een open specificatie is het namelijk niet, het is een zeer basale omschrijving van api's, met zeer beperkte uitwerking van bijvoorbeeld de markup. Een implementatie hiervan maken kan, maar dan krijg je een soort van kladblok functionaliteit eruit en zal je nooit en te nimmer bestanden kunnen inlezen gemaakt door MS Office.

[kidde]

Elk pakket kan ook OpenXML implementeren.

Theoretisch wel ja, maar in de praktijk niet.

OpenXML refereert naar het gedrag van gesloten applicaties in plaats van naar technische details, de standaard is zo complex dat deze maar amper te implementeren valt wegens de contradicties en tegenstrijdigheden, en dat is nog afgezien van het patentenmijnveld dat mogelijk zou kunnen ontstaan, aangezien Microsoft nogal wat XML patenten bezit. Dit is de reden dat de zogenaamd 'open' standaard van Microsoft tegen spam het niet gehaald heeft, bedrijven waren te bang voor patentinbreuk.

Het onderhoud van de standaard is enkel en alleen in handen van Microsoft, dus ten allen tijde kunnen wijzigingen zonder voor-aankondiging worden opgenomen, die op het moment van aankondiging al geimplementeerd zullen zijn in MS Office, zodat de concurrentie altijd achterloopt. Bovendien is OpenXML ook nog eens afhankelijk van enkele platform specifieke zaken die alleen op Windows werken.

[Reactie gewijzigd door kidde op 24 juli 2024 22:04]

[Erkens]

Er blijft echter wel 1 groot nadeel. OpenOffice mist gewoon een scripting taal zoals VBA.
Het zal mij dus niet verbazen als Novell via Mono (.NET) scripting mogelijkheden aan OpenOffice gaat toevoegen. Zodat Office 2007 documenten inclusief redelijke macro support bekeken kunnen worden.

Volgens mij heb je niet goed gekeken hoor

Je hebt zelfs keuze:

• OpenOffice.net Basic
• Python
• BeanShell
• JavaScript

Gewoon bij Tools->Macros

[Verwijderd]

ODF kan niet zomaar door elk pakket geimplementeerd worden in de praktijk. Dat komt omdat ODF ook niks meer of minder is dan een rechtstreekse dump naar XML van het interne OpenOffice model. Precies dus zoals OpenXML ook een 'standaard' geworden is: ook dat is gewoon een dump van Word's interne model.

AbiWord's interne model is bijvoorbeeld fundamenteel anders op een aantal punten, waardoor ODF nooit 100% goed geimporteerd kan worden. Althans niet zonder AbiWord zwaar om te hacken zodat het in feite gewoon OpenOffice wordt intern.

[humbug]

Volgens mij riekt dit niet zozeer naar omkoperij maar naar ontevredenheid met de software die ODF ondersteund. Als je personeel steen en been klaagt dat de door jou beschikbaar gestelde pakketen niet voldoen, kun je leuk "principieel" zeggen dat ze er maar mee moeten blijven werken, maar misschien is het verstandiger om water bij de wijn te doen en weer de vertrouwde software te gaan gebruiken. Zeker nu ook die software van een Open bestandsformaat gebruik maakt.

[kidde]

Vraagje: Geld dat ook voor stemmachines? Dat als ze niet aan je pcincipiele idealen (van veiligheid) voldoen, je maar water bij de wijn moet doen en verder gaan met de vertrouwde (zuigende) software, en mensen niet in informatieverwerking kunnen vertrouwen alleen maar omdat het personeel steen en been klaagt?

Zelfde voor pinautomaten: Dat het personeel het best overweg kan met het meest onveilige besturingssysteem ter wereld, en steen en been klaagt als er iets anders opstaat, moet men daarom water bij de wijn doen en gewoon maar de vertrouwde onveilige software op pinautomaten installeren?