Massachusetts: 'Office Open XML gelijkwaardig aan OpenDocument Format'

De staat Massachusetts heeft versie 4 van de Enterprise Technical Reference Policy geratificeerd. Het gevolg hiervan is dat het Office Open XML-formaat en het OpenDocument Format gelijkwaardig zijn en beide gebruikt mogen worden.

De afgelopen negen maanden heeft de Information Technology-divisie van de Amerikaanse staat zich onder leiding van Interim Revenue Commissioner Henry Dormitzer en cio Bethann Popoli gebogen over 460 commentaren die waren binnengekomen op de conceptversie van de ETRP4. Een vaak terugkerende vraag was of de staat, door het gebruik van ooxml toe te staan, ook zijn medewerkers zou dwingen om gebruik te maken van Office 2007. In de definitieve ETRP-versie schrijven de it'ers uit Massachusetts dat dit niet het geval is en dat er een groeiend aantal programma's is dat kan omgaan met het Office Open XML-formaat. Verder is in de ETRP4 te lezen dat het belangrijkste doel van het nieuwe beleid rond bestandsformaten is, om niet langer afhankelijk te zijn van voor mensen onleesbare binaire formaten.

Dormitzer en Popoli hebben verder laten weten dat veel commentaren gingen over de kwaliteit van de ooxml-standaard. Volgens Dormitzer en Popoli zullen eventuele onvolkomenheden opgelost worden door de standaardisatiecommissie en vormen ze geen reden om geen gebruik te maken van het ooxml-formaat. Daarom heeft Massachusetts de conclusie getrokken dat beide bestandsformaten toegestaan zullen worden. Andrew Updegrove, actief binnen de Linux Foundation, is er niet blij mee dat de staat de volgens hem onvoldoende open ooxml-standaard heeft binnengehaald. De Computing Technology Industry Association, waarvan Microsoft lid is, is tevreden over de beslissing en meent dat de openheid van de ooxml-standaard innovatie, concurrentie en meer keuzemogelijkheden voor consumenten zal opleveren.

Het parlementsgebouw van Massachusetts (State House, Boston)

Reacties (39)

[martdj]

Volgens Dormitzer en Popoli zullen eventuele onvolkomenheden opgelost worden door de standaardisatiecommissie en vormen ze geen reden om geen gebruik te maken van het ooxml-formaat.

Als dit wordt vertaald als "we kunnen zonder meer Office 2007 gaan gebruiken" dan is dat nogal kortzichtig. Momenteel is OOXML nog geen ISO standaard, maar als het een ISO standaard zou worden, is wel zeker dat deze op bepaalde vlakken (met name opslag van data (meervoud van datum) en bepaalde mathematische constructies) aanzienlijk zal afwijken van de standaard zoals deze door de ECMA is goedgekeurd. Daarnaast heeft MS in Office 2007 zijn eigen OOXML standaard ook niet volledig geimplementeerd, schijnbaar door tijdgebrek. Het resultaat is dus dat als je Office 2007 zou gaan gebruiken en documenten gaat opslaan in het Office 2007 OOXML formaat, je ervan uit kunt gaan dat deze niet compatibel gaan zijn met programma's die de eventuele ISO OOXML implementeren en dan heb je dus nog steeds een vendor lock-in.

[Verwijderd]

Dat is nauwelijks een probleem omdat je XML standaarden gewoon kunt uitrusten met versies. Als de versie tijdens het ISO proces nog wordt aangepast zal er gewoon een nieuwere versie van OOXML ontstaan met een nieuwe set validatieschema's.
Zo is de de ISO Opendocument 1.0 versie ook aangepast vanwege de ISO standaarddisatie en is daar een 1.0SE (second edition) versie van gemaakt. Zolang de versies maar duidelijk herkenbaar zijn binnen het document kun je de juiste schema's toepassen.
Overigens kan het dus dat MS Office 2007 dus een tijdje nog de oude Ecma standaard verise ondersteunt en pas later na bijvoorbeeld een servicepack upgrade de ISO versie.

[kidde]

Overigens kan het dus dat MS Office 2007 dus een tijdje nog de oude Ecma standaard verise ondersteunt en pas later na bijvoorbeeld een servicepack upgrade de ISO versie.

Dus kan je niet zomaar Office2007 gebruiken, omdat dit geheel onzeker is op dit moment, hetgeen is wat martjd zegt. Tevens is OOXML slechts een subset van het bestandsformaat van MS Office 2007; MS Office kan momenteel uberhaupt niet in OOXML opslaan.

[Verwijderd]

OOXML is completer voor Office dan Opendocument voor bijvoorbeeld OpenOffice. Dat is dus niet een slim argument om nu te gebruiken.

Zo zitten in Opendocument geen formula's, geen digitale handtekeningen, geen macro's terwijl OOo die wel ODF documenten opslaat.
Dat is niet veel anders dan wat MS Office doet bijvoorbeeld bij macro's.

[Verwijderd]

Verder is in de ETRP4 te lezen dat het belangrijkste doel van het nieuwe beleid rond bestandsformaten is, om niet langer afhankelijk te zijn van voor mensen onleesbare binaire formaten.

Wat een flutredenering. Het is echt niet zo dat veel mensen die formaten gaan zitten lezen. Het gaat dan hoogstens om een beperkt aantal ontwikkelaars die over het algemeen heel goed om kunnen gaan met complexere data en codes.
Verder zijn de binaire office formaten van Microsoft tegenwoordig ook al open voor dus qua specificaties hoef je het ook al niet te doen.

[martdj]

Dat is natuurlijk geen flutredenering. Het probleem met binaire bestandsformaten is dat je het oorspronkelijke programma danwel een convertor nodig hebt om zo'n bestand te kunnen lezen. Kan jouw MS Office (als je dit gebruikt) WordPerfect 5.1 bestanden lezen? Misschien nog net wel, maar Speedscript bestanden (C64) 100% zeker niet. Dat betekent dus dat als je je teksten in zo'n bestandsformaat gesaved hebt ze nu verloren zijn.
Daarentegen kun je zowel ODF als OOXML bestanden met een standaard zip programma unzippen (zip is ook een standaard) en met een standaard textprogramma ala notepad lezen. Er staat een hoop garbage tussendoor, maar de teksten staan er gewoon als ASCII karakters in en dat is een grote winst t.o.v. de oude situatie.

Adion: Daar heeft het wel degelijk mee te maken. ASCII is een internationale standaard. Een binair formaat waar de specificaties vrij van beschikbaar zijn is dat niet. Dat betekent dat je ASCII altijd zult kunnen lezen en je voor dat binaire formaat, waarvan je mag hopen dat tegen de tijd dat je het nodig hebt die specificaties ook nog beschikbaar zijn, een programma moet gaan schrijven om dat uit te kunnen lezen. Dat is een heel groot verschil.
Waar je natuurlijk gelijk in hebt is dat de term "binair bestandsformaat" die ik van hAl overnam ongelukkig is. Het gaat natuurlijk om de proprietary office formaten.

hAl: Och ja, tuurlijk. Ik gebruik gewoon mijn hex editor en ga de output daarvan tegen de specificaties van Microsoft aanhouden om te ontcijferen wat er staat...

[Reactie gewijzigd door martdj op 28 juli 2024 18:44]

[Adion]

De fout is hier een beetje dat dit niets met het al dan niet binair zijn van het bestandsformaat te maken heeft.
Mits de specificatie vastligt, duidelijk is en vrij beschikbaar is kunnen zowel binaire, text als op xml gebaseerde formaten in de toekomst gelezen worden.
Verder is zelfs een text-bestand binair, en hangt het al dan niet leesbaar zijn ervan volledig af van de documentatie van andere standaarden (zoals ASCII).
Voor de basis aan engelse letters ligt dit vrij goed vast, maar voor andere talen (en zeker de niet-westerse) zal je toch nog meer moeten vastleggen ivm de encodering.

[kidde]

Verder is zelfs een text-bestand binair

Niet waar, de representatie van een text bestand is binair, de manier waarop deze opgeslagen is dus, maar het bestand zelf is slechts een abstract iets, wat ook in qubits (dus niet binair) opgeslagen zou kunnen zijn.

[Verwijderd]

Je hebt helemaal niet het originele programma of een converter nodig om een binair bestand te lezen. Je kunt ook de specificaties gebruiken die Microsoft tegenwoordig beschikbaar stelt

Zie: http://support.microsoft.com/kb/840817/en-us

Royalty-Free File Format Programs
Microsoft Office Binary File Formats
Microsoft makes its .doc, .xls, and .ppt binary file format specifications available under a royalty-free covenant not to sue to anyone who wishes to implement all or part of these specifications in their products

[MneoreJ]

Niet echt open, hè? Microsoft maakt die informatie beschikbaar als hun dat uitkomt.

Bovendien lost dit het oorspronkelijke probleem niet op. Wat als Microsoft en haar specificaties ophouden te bestaan? (Komt ons natuurlijk bijzonder onwaarschijnlijk voor, maar je snapt het idee.) Sommige formaten zijn makkelijker toegankelijk voor mensen zonder kennis van het formaat dan andere. Welke informatie zal over 100 jaar toegankelijker zijn: een bestand met ASCII tekst of een .doc?

[Verwijderd]

Microsoft maakt die informatie beschikbaar als hun dat uitkomt.

Waar concludeer jij dat uit ?
Jij leest blijkbaar een heel ander artikel.

[kidde]

If you want to receive the documentation, contact Microsoft at the following e-mail address to initiate the agreement sign-up process:
[e-mail] (mailto:[e-mail])
When you write to Microsoft, provide the following information:
• The specific file format specifications that you are interested in
• Your company or agency name
• Your mailing address
• Your city

Etc. etc.

Dus Microsoft beslis of je het krijgt of niet, en het is dus niet vrij beschikbaar, voor zover een slecht-geinformeerde onwetende consument als ik begrijp.

[Reactie gewijzigd door kidde op 28 juli 2024 18:44]

[Verwijderd]

Staat er dan behalve signup een voorwaarde verbonden of kosten ?
Ik zie geen enkel informatie waaruit zou blijken dat je op verzoek de spec niet krijgt.

Volgens mij staat er toch
to anyone who wishes to implement all or part of these specifications in their product

[merethan]

cg_emulate_word97

"Office Open XML gelijkwaardig aan OpenDocument Format"

ya right. Waar hebben die hun hersens? In hun hol?

(Voor wie de clou niet snapt: Implementeer 'cg_emulate_word97' uit die "open" standaard maar is als je geen Microsoft heet)

[Verwijderd]

Een goede implementatie zou bijvoorbeeld zijn:
if <cd_emulate_word97>
then alert.popup("This is a converted legacy document which might not render as it did when it was created in word 97")

Maar aan de andere kant hoe implementeer jij in jou applicatie deze geldige en ook bestaande en in het echt voorkomende geldige OpenDocument code:
<config:config-item-set config:name="ooo:view-settings">
<config:config-item config:name="AddParaTableSpacing" config:type="boolean">true</config:config-item>
<config:config-item config:name="UseFormerObjectPositioning" config:type="boolean">false</config:config-item>
<config:config-item config:name="UseOldNumbering" config:type="boolean">false</config:config-item>
</config:config-item-set>

[PolarBear]

Altijd weer de cg_emulate_word97. Maar wat doet het, kan je zonder die functie geen nieuwe documenten aanmaken en openen? Hoe vaak wordt het gebruikt. Is het echt een struikelblok? Vertel me dat eens...

[YaPP]

Het is idd slechts een greep uit de beschikbare voorbeelden, maar het slaat wel op een groter probleem: Delen in de OOXML specificatie zijn onvolledig of onduidelijk. Hierdoor kan niemand een programma maken wat het document er hetzelfde uit laat zien (denk aan de HTML problemen tussen browsers), of zelfs dezelfde uitkomst geeft op spreadsheet formules! Dat lijkt me toch redelijk essentieel voor een standaard.

Hierdoor krijg je dezelfde problemen als je nu hebt met het openen van word bestanden in OpenOffice, en omgekeerd. Dan kun je zeggen, nou pechgehad, maar het doel van een open standaard is juist dat soort problemen voorkomen! Overheden worden dus lekker gemaakt dat het allemaal werkt, maar ondertussen zijn we geen stap verder gekomen.

De specificatie is afgeraffeld, sterker nog: het is letterlijk een geheugendump van de Office-datastructuren in XML notatie, inclusief alle bugs, workarrounds, en inconsequenties. (ter info: dat is een .doc bestand ook: info). Ik ben dan ook erg benieuwd hoe OOXML er uit gaat zien na Office 2007... Ook daarover (afaik!) geen garanties.

Ik heb er geen bewaar tegen dat een betere XML standaard van Microsoft gekozen wordt tot document standaard. Microsoft heeft vreemd genoeg nog geen letter veranderd van de huidige 6000 pagina's tellende specificatie, na alle kritiek die er over is geweest. Dat vind ik wel een bezwaar! Met de ISO-fasttrack wil Microsoft namelijk dit bestandsformaat ook zonder aanpassingen promoten tot dé document standaard.

[Reactie gewijzigd door YaPP op 28 juli 2024 18:44]

[Verwijderd]

Ik heb er geen bewaar tegen dat een betere XML standaard van Microsoft gekozen wordt tot document standaard. Microsoft heeft vreemd genoeg nog geen letter veranderd van de huidige 6000 pagina's tellende specificatie, na alle kritiek die er over is geweest.

Zo mogen de standaard nu nog niet veranderen omdat iederen nu gesubmit is bij ISO en iederen op dezelfde versie commentaar mag leveren. Microsoft heeft al aangegeven samen met Ecma bezig te zijn om aanpassingen te maken aan de standaard.
Zo heeft Brian Jones (die voor Microsoft in de Ecma technical committee zit) bijvoorbeeld al de door jou genoemde spreadsheet formule onduidelijkheden erkend en gezegd deze te willen aanpassen in de ballot resolution voor de uiteindelijke ISO standaardisering: http://blogs.msdn.com/bri...adsheet-formula-bugs.aspx
In de uiteindelijke ISO standaard zullen dus vele fouten zijn gecorrigeerd uit de huidige Ecma versie.
Verder kan Ecma ook nog toezeggingen doen over toekomstige versies. Zo wachten we bij OpenDocument nu toch ook al ruim twee jaar sinds Opendocument een standaard werd op het toevoegen van formule's en een digitale handtekening (zaken die al wel in OOXML zitten)

[johnbetonschaar]

ya right. Waar hebben die hun hersens? In hun hol?

Nee, waarschijnlijk in hun portemonnee... Wie wil er nu geen goedkope software-licentie-dealtjes?

[Reactie gewijzigd door johnbetonschaar op 28 juli 2024 18:44]

[Verwijderd]

Het is eigenlijk sowieso een slechte beslissing om in de wet en regelreging specifieke office document formaten verplicht te stellen.
Het was beter geweest om slechts een voorwaarde op te nemen dat er open formaten gebruikt hadden moeten worden.

Nu was het meer een lobby race tussen Opendocument aanhangers en Office Open XML aanhangers. Een slechte zaak.

[Brupje]

en vervolgens is er geen communicatie meer mogelijk omdat iedereen een zelf gekozen open formaat gebruikt.

[Verwijderd]

Onzin natuurlijk, open is open en dan is communicatie altijd mogelijk.

En ook dan zullen er altijd populaire en minder populaire standaarden zijn.

[Brupje]

jah zien we aan het HTML formaat, overal net iets anders.

[Verwijderd]

En daardoor is communicatie niet mogelijk?

Als standaraden echt Open zijn kunnen er zonder problemen meerdere naast elkaar bestaan.

Een echte Open standarad kun je altijd implementeren.

[maxxware]

HTML = HTML. Dat is een vast beschreven standaard. Het verschil zit hem erin dat bepaalde browsers (met name IE) dusdanig van de standaard afwijken dat er feitelijk 2 websites gebouwd moeten worden: 1 met standaard HTML, en eentje met het IE-dialect.

[mashell]

De ultieme oplossing is natuurlijk dat de overheid haar eigen maar open formaat definieerd en uitsluitend dat accepteert.

[Verwijderd]

En dan krijg je het probleem van de bijbelse stad Babel, waar iedereen zijn eigen taal spreekt en niemand elkaar begrijpt.

[xAn52]

het belangrijkste doel van het nieuwe beleid rond bestandsformaten is om niet langer afhankelijk te zijn van voor mensen onleesbare binaire formaten.

Of de Office Suite open source is of niet doet niet ter zake. Is ook een veel beter uitgangspunt. Uiteindelijk gaat het erom of het geproduceerde document overal leesbaar is. Niet of de software overal gecompileerd kan worden.

Hm, blijkbaar heb ik iets misgelezen. We bedoelen bijna hetzelfde.

[Reactie gewijzigd door xAn52 op 28 juli 2024 18:44]

[YaPP]

Het was beter geweest om slechts een voorwaarde op te nemen dat er open formaten gebruikt hadden moeten worden.

Met die voorwaarde waren ze ook begonnen, wat juist de hele kermis over OOXML gestart heeft. Microsoft wil namelijk niet buiten de boot vallen, en is begonnen met OOXML en probeert dit aan te prijzen als een open formaat.

Massachusetts heeft een lange tijd aangegeven dat OOXML niet aan de voorwaarden voldoet van een open formaat. Waarom ze dat nu wel ineens doen is mij een raadsel, er is namelijk geen enkele letter van de specificatie aangepast sinds deze gepubliceerd is.

In plaats daarvan zijn in de afgelopen maanden krijgen een hoop vage kleine landen ook ineens stemricht (en stemmen allemaal pro microsoft). Op de officiële stemming wordt IBM bij de deur geweigerd omdat de zaal al vol zat... ...met Microsoft mensen.. (hoe is het uberhaubt dat je met een officiele utinodiging geen plek hebt?) Het lijkt er meer op dat deze standaard wordt doorgedrukt dan dat het serieus een open standaard is.

[Reactie gewijzigd door YaPP op 28 juli 2024 18:44]

[Verwijderd]

Op de officiële stemming wordt IBM bij de deur geweigerd omdat de zaal al vol zat... ...met Microsoft mensen.. (hoe is het uberhaubt dat je met een officiele utinodiging geen plek hebt?)

Een niveau groklaw opmerking. (als je overigens probeert op groklaw over dit onderwerp onderstaand commentaar te leveren wordt je overigens weggemodereerd)

Het ging daar om de Portugese technisse commissie van de nationale ISO vertegenwoordiging . Deze commissie nodigde voor het advies over OOXML een nieuwe leden uit tot een maximum van 20 (een aantal vastgesteld door de nationale ISO vertegenwoordiging). IBM werd geweigerd tot de commisie omdat er toen al twintig plaatsen in de commissie bezet waren. Overigens stemde van de 12 nieuwe leden in portugal de helft voor en de helft tegen het aangenomen voorstel om te adviseren voor standaardisatie waarbij de gevonden bevindingen/commentaren worden doorgegeven zodat de door Ecma nog verbeterd kunnen worden.

[Verwijderd]

Massachusetts heeft een lange tijd aangegeven dat OOXML niet aan de voorwaarden voldoet van een open formaat. Waarom ze dat nu wel ineens doen is mij een raadsel, er is namelijk geen enkele letter van de specificatie aangepast sinds deze gepubliceerd is.

Mischien omdat OOXML gewoon een open standaard is.
Er is in de licentie geen enkele belemmering om de standaard te implementeren.

Ondanks de commentaren van bepaalde Opendocument voorstanders dat OOXML niet open zou zijn kunnen ze dergelijke beweringen niet hard maken of of enigerlei manier aantonen. Er is ook nog niemand met een voorbeeld bestand in OOXML dat een willekeurig iemand niet zou implementeren vanwege een licentiebeperking. Dat zou een simpele manier zijn om aan te tonen dat de licentie niet open zou zijn.

[Verwijderd]

Nee, geen beperking. Behalve in de implementatie dan. Toen Kroes MS dwong protocollen te openen, leverde MS na lang uitstellen een vracht documentatie in zonder 1 regel commentaar.

Enig idee hoe groot de documentatie is die bij ooxml zit ? Nee ? Nou mocht je m eens willen lezen dan kun je je winkler prins alvast bij het grof vuil doen anders heb je geen plek in je boekenkast.

[Verwijderd]

Ik weet dat heel goed want de documentatie staat hier op mijn PC en in gebruik die ook ter referentie in dit soort artikelen.

[kidde]

Het was beter geweest om slechts een voorwaarde op te nemen dat er open formaten gebruikt hadden moeten worden.

En laat dat nou precies zijn wat ETRP4 doet... Bij wijze van service wordt aangegeven welke bestandsformaten op dit moment volgens de makers van ETRP4 aan de eisen voldoen.

[Reactie gewijzigd door kidde op 28 juli 2024 18:44]

[4VAlien]

Dit is niet zozeer een wet als wel een document wat standaarden definieert. Verder is het voor de gebruikssituatie in Massachusets zo dat er blijkbaar maar twee formaten concurreren, en die zijn in gebruik gelijkwaardig. Het niet noemen van welke standaard dan ook lijkt me onverstandig, omdat je dan inderdaad de situatie van Brupje krijgt. Ook ben ik van mening dat overheden niet per se open source hoeven te werken, alleen dat ze er voor zorgen dat documenten uitwisselbaar zullen zijn met latere systemen zonder patent beperkingen of custom made dure converteersystemen voor obscure formaten.

[Reactie gewijzigd door 4VAlien op 28 juli 2024 18:44]

[Verwijderd]

Wel heel apart dat een formaat waarvan bewezen is dat het grote fouten bevat als gelijkwaardig kan worden beschouwd. Onderzoek heeft al laten weten dat er zodanige fouten in M$'s OOXML zitten dat het tot bedreigende situaties kan leiden.
Een van de redenen is dat berekeningen en formules in de standaard zijn opgenomen die gecopieerd zijn uit Excel. En Excel maakt rekenfouten. Er wordt geen rekening gehouden met eenheden.
Daarnaast is er geen ondersteuning in OOXML voor "exotische" charactersets in bepaalde omstandigheden. De Chinezen klagen daar bijvoorbeeld over. Dit komt mede omdat Microsoft niet alle standaarden ondersteund.

OOXML is snel uit de grond gestampt om mensen toch open en microsoft afhankelijk te houden. Om iets te hebben dat kan vechten tegen ODF. Maar dit is op een zo snelle manier gebeurt dat het slordig en zeker niet foutloos is gebeurd. En toch wordt dit dan als gelijkwaardig gezien?

[Verwijderd]

Een lekker stapeltje onwaarheden bij elkaar
De problemen met de spreadsheet formula's staan hier nader en helder uitgelegd:
http://blogs.msdn.com/bri...adsheet-formula-bugs.aspx
Er is geen enkele indicatie van een gerelateerd probleem tussen die zaken en excel wat jij als reden aanvoert. Waar jij vandaan haalt dat deze fouten veroorzaakt worden door excel zou ik daarom graag willen weten.
Bovendien is het al duidelijk dat deze issues opgelost zullen worden voordat OOXML een ISO standaard wordt.

[kidde]

Ok, een fout opgelost, nog veel meer dan 40 te gaan.

[Verwijderd]

Er zullen meer fouten worden opgelost hoewel die lijst niet per se allemaal fouten bevat maar ook gewoon keuzes en ook incorrectheden.
Zo zijn er goede redenen om bijvoorbeeld niet te kiezen voor hergebruik van W3C spec SVG en MathML voor een Office documenten. Bijvoorbeeld mathml kan niet interegreren met markup van de rerst van Office. Je kunt dus in MathML (en dus in ODF) in een math gedeelt geen voetnoten, commentaar, revisiemarkeringen of plaatjes opnemen en in de variant die in Office Open XML zit kan dat dus wel.
Verder zijn er diverse commentaren in die grokdoc lijst over de licentie maar heeft nog niemand iets aangetoond want je met die licentie niet kan wat je wel met ODF zou kunnen. Er wordt wel een verschil geclaimd maar er is geen daardwerkelijk verschil aangetoond.

Verder zijn er naast die lijst van problemen nog honderden kleine editorial foutjes gevonden die ook zullen worden opgelost. Het zal dus zeker een paarmaanden duren na de sluiting van de ballot periode voordat de ballot resolutie meetig ingegaan wordt en in die tijd zullen er veel foutjes verbeterd worden.
Overigens kun je bijvoorbeeld in de versie 1.0 second edition van OpenDocument lezen hoeveel foutjes er nog verbeterd zijn in OpenDocument tijdens de ISO standaardisatie die dus wel gewoon in de originele OASIS v1.0 standaard zaten (en ODF is ook nog steeds niet vrij van fouten)