Ny Office 2013 understøtter både Strict Open XML og ODF 1.2

Med den næste udgave af kontorpakken kommer Microsoft for første gang til fuldt ud at understøtte både selskabets eget åbne dokumentformat og den nyeste version af rivalen ODF.

Rutinerede Version2-læsere har næppe glemt 'Dokumentformatkrigen', som i flere år affødte rødglødende debattråde. Nu imødekommer den ene part i krigen, Microsoft, ét af de tilbagevendende kritikpunkter.

Den næste version af Office-pakken kommer nemlig til at understøtte Microsoft egen dokumentformatstandard Open XML i den såkalde strict-version. Det skriver Microsofts chef for Office-standarder, Jim Thatcher, i et blogindlæg.

Det kommer i praksis næppe til at betyde noget for slutbrugerne, men det er alligevel en væsentlig ændring i forhold til sagen om åbne dokumentformater. Det var nemlig Strict-versionen af Open XML, som Microsoft fik godkendt som en ISO-standard.

Microsofts egen software, både Office 2007 og Office 2010, understøttede imidlertid kun den særlige Transitional-udgave af Open XML-formaterne.

Det var et tilbagevendende punkt i især den danske debat om dokumentformater, fordi modstanderne var imod den nuværende model, hvor både Strict Open XML og Open Document Format (ODF) blev godkendt til brug i den offentlige sektor i Danmark.

Læs også: Våbenhvile i dokumentformat-krig holder stik

Problemet var nemlig ifølge modstanderne af at inkludere Open XML, at det ikke gav mening, så længe Microsofts egen software ikke understøttede lige netop den version, som var accepteret som ISO-standard, men derimod en midlertidig version, Transitional Open XML.

Transitional Open XML var afhængig af nogle særlige Microsoft-specifikke komponenter, som kritikerne mente, at kun Microsoft kunne implementere. De er udskiftet i Strict Open XML.

Læs også: Dokumentformatkrig i baglås: Nu er hverken ODF eller OOXML godkendt

Office 2013 får også fuld understøttelse for at åbne, redigere og gemme i den nye version 1.2 af ODF, men til gengæld har Microsoft angiveligt fjernet muligheden for at gemme i den gamle version 1.1 af ODF. Man kan dog stadig åbne og redigere dokumenter i ODF 1.1.

Office 2013 har i øvrigt også fået udvidet understøttelse for PDF-formatet, så man nu kan redigere et PDF-dokument og enten gemme det som en ny PDF eller som et af de øvrige dokumentformater.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#5 Jakob Damkjær

Dette er ikke korrekt. Der er ikke noget i Transitional, der ikke er "frit tilgængeligt".

Sandt nok, men hvis jeg ikke husker helt forkert var der nogle dele af det hvis patentdæknings status var lidt uklar og der var nogle detaljer der på et tidspunkt pegede tilbage til tidligere office versioners implementeringer.

Men lad det nu fortabe sig i historiens tåge ;)

Men selv om det var en lang debat (og jeg til tider kaldte dig devilspawn ;) hvilket jeg undskylder for) så må det her vel siges at være det bedste udfald, fuld understøttelse af den stricte ISO standard version (er ODF 1.2 ISO godkendt endnu ?).

Er der nogen udmelding om hvornår det kommer til Office365 ?

Du skal have tak for godt og vedholdende arbejde på emnet ;) (I know... there must be something in the water).

  • 0
  • 0
#6 Peter Johan Bruun

Hej Jesper

Mit indlæg var et lønligt håb om at man som udvikler endeligt kunne få adgang til en offentlig MS-certificeret formatteringsstandard, hvor man efter brug kan producere et "hjemmelavet" excel regneark der kan læses af alverdens excel 2013 brugere. Lige nu kan man kun være sikker på at et hjemmelavet format kan indlæses i ens egen nationale Windows/Mac udgave af Office pakken.

Derudover kan jeg med et åbent format sikkert også producere formler, formateringer og meget mere som kan give regnearks en langt bredere anvendelse end det er muligt med et simpelt CSV-format.

At lave formaterede data til excel er en jungle. Her er nogle af mine erfaringer.

Når man sidder og udvikler på en iPad applikation, der skal sende en xcl-liste med formler og meget andet, slår komma separerede formater uden tvivl ikke til, men det er den laveste fællesnævner så det er altid der man ender.

Tager man og genererer et ganske almindeligt validt XML dokument, kan Excel 2010 godt tygge den igennem og man har et lidt bedre udseende ved import. Men stadig er det lidt usikkert om formatet kan indlæses i alle lande specifikke udgaver, når man påtænker tids-, tal-, valutaformatering, etc.

(Som en bibemærkning skal det siges at Excel 2011 til mac ikke er istand til at læse alle valide XML formater.)

Når man så prøver sig lidt med et "Excel 2004 regneark i xml" som måske kunne bringe en tættere på et standard format med formateringsmuligheder, er det en gætteleg umiddelbart for hvordan det skal udformes. Jeg har endnu ikke kunnet finde en generel beskrivelse for formatet, og jeg har derfor analyseret et gemt (.xml 2004) regneark for at kunne producere et tilsvarende. Det lykkedes nogenlunde på min mac og måske også Vista maskinen....

Men om et sådant (.xml 2004 regneark) kan læses i alle excel versioner og efter 2004 versionerne, er jeg stadig i tvivl om, eftersom jeg ikke har MS dokumentation til rådighed der underbygger mine forhåbninger.

Så derfor er beskrevne åbne formater, så forb..... vigtige for at et produkt som MS Excel kan få større udbredelse og anvendelese end det allerede er tilfældet i dag. I den kontekst giver Microsofts tiltag rigtig god mening. Så jeg håber endnu :-)

/pjb

PS: Hvis nogen skulle ligge inde med links til allerede eksisterende offentligt tilgængelige MS Excel standarder ville jeg blive en lykkeligere iOS udvikler !

  • 0
  • 0
#7 Jesper Lund Stocholm Blogger

Sandt nok, men hvis jeg ikke husker helt forkert var der nogle dele af det hvis patentdæknings status var lidt uklar og der var nogle detaljer der på et tidspunkt pegede tilbage til tidligere office versioners implementeringer.

For de u-indviede er historikken som følger:

2007:

Microsoft indleverede et forslag til ISO-standard for OOXML. Dette forslag var identisk med den standard, som ECMA havde godkendt i december 2006.

I forslaget var der funktionalitet som "AutoSpaceLikeWord95" og lignende, som kun Microsoft reelt kunne implementere.

I september blev den første afstemning om OOXML og den faldt med et brag. Mange lande - herunder Danmark - følte at det var uacceptabelt, at der var funktionalitet i en ISO-standard som kun én leverandør kunne implementere, så vi krævede, at funktionaliteten enten blev beskrevet eller fjernet.

2008:

Ultimo februar blev der stemt igen om et nyt forslag. Dette forslag var en intensiv bearbejdning af det oprindelige forslag, og funktionaliteten som kun Microsoft kunne implementere var nu specificeret i forslaget.

I forslaget var også noget nyt, nemlig opdelingen af i "Transitional" og "Strict". Formålet var at adskille "forældet" funktionalitet fra de steder, hvor ny funktionalitet på et tidspunkt var blevet tilføjet. Dette inkluderede bla. at datoer i regneark i Transitional skrives som "numeriske datoer" mens de skrives som "ISO datoer" i Strict.

Forslaget blev godkendt.

Der er altså ikke længere noget funktionalitet i OOXML, som kun Microsoft kan implementere.

Angående patenterne, så er det eneste jeg kan komme på den såkaldte "i4i-retssag" om strukturel opmærkning af XML-data. Det viste sig, at der var et patent, der dækkede noget funktionalitet i Word. Microsoft betalte en ordentlig røvfuld penge til firmaet og har senere fjernet denne funktionalitet fra Word. I OOXML-udvalget i ISO (som CIBER jo har deltaget i fra første færd) har vi valgt ikke at fjerne funktionaliteten fra standarden.

  • 1
  • 2
#8 Jesper Lund Stocholm Blogger

Så derfor er beskrevne åbne formater, så forb..... vigtige for at et produkt som MS Excel kan få større udbredelse og anvendelese end det allerede er tilfældet i dag. I den kontekst giver Microsofts tiltag rigtig god mening. Så jeg håber endnu :-)

Jeg er sådan set enig i langt de fleste af dine betragtninger, men pointen er sådan set, at Microsoft Office's kommende understøttelse af Strict OOXML ikke bidrager mere til løsning af de problemer du nævner end Transitional allerede har løst for dig.

Derfor spørger jeg lige igen: hvad er det du mener du kan løse med Strict som du mener var umuligt med Transitional alene?

  • 0
  • 2
#10 Jesper Lund Stocholm Blogger

Så derfor er beskrevne åbne formater, så forb..... vigtige for at et produkt som MS Excel kan få større udbredelse og anvendelese end det allerede er tilfældet i dag.

... og så er jeg i øvrigt lodret uenig i denne formulering. For mig er formålet med standardisering af dokumentformatet i Microsoft Office det stik modsatte - nemlig at gøde jorden for, at Microsoft Office får en mindre udbredelse end det har i dag.

  • 2
  • 2
#11 Jakob Damkjær

... og så er jeg i øvrigt lodret uenig i denne formulering. For mig er formålet med standardisering af dokumentformatet i Microsoft Office det stik modsatte - nemlig at gøde jorden for, at Microsoft Office får en mindre udbredelse end det har i dag.

Enig men hvis microsoft laver den bedste editor af OOXML vil de stadig ha stor udbredelse... tror bare aldrig fx. google apps vil understøtte det da OOXML er en konkurrende ""metaplatform"" (double airquotes for ekstra meget meta) til googleapps for google er lige så lidt interesseret i at folk investere i dokumenthåndteringssystemer der benytter OOXML og ikke googleapps som de er i udbrud af pest og den spanske syge på googles campus.

Tror dog stadigvæk at der ikke vil være mange firmaer der vil kunne tilbyde samme integration på tværs af en organisation som microsoft med Sharepoint exchange og en flerplatform basis af windows 8 med office (som lige blev lidt mere konkurrancedygtig da den nu til dels er baseret på en åben iso standard).

  • 0
  • 0
#12 Eskild Nielsen

Person A gemmer document a, Person B gemmer document b

Person C forsøger at danne document c ved cut&paste af dokumenterne a og b.

Dette skal kunne lykkes uanset om de personer har forskelligt officeprogram, OS og locale - vel at mærke uden at de 3 parter har adgang til disse oplysninger om hinanden.

For 15-20 år siden havde jeg fornøjelsen af at være person c, Officeprogrammet var Winword 6 i 3 forskellige nationale versioner.

Dokumentet var ca 300 sider og ca halvdelen af alle feltreferencer skulle rettes i hånden.....

  • 0
  • 0
#13 Baldur Norddahl
  • 0
  • 0
#17 Jesper Lund Stocholm Blogger

Det kan godt være at det bare er fordi jeg opfatter Microsoft Office som referenceimplementationen - men er det ikke lidt uheldigt?

Er det ikke mere ordet "referenceimplementationen", der er uheldigt at anvende? Der er mig bekendt ikke nogen af de store kontorpakker, der

  1. Implementerer den fulde funktionalitet af deres standardiserede "native" dokumentformat
  2. kun implementerer det standardiserede dokumentformat

Hvis du vil have en idé om, hvad du bør implementere i et dokumentformat ifht interop med Microsoft Office, så har Microsoft frigivet detaljerede informationer om, hvor de afviger ODF og OOXML.

Hvis du vil kigge på, hvordan det forholder sig for OpenOffice.org eller LibreOffice, så er du basalt set på røven. Jeg har igennem lang tid forsøgt at finde en beskrivelse af deres afvigelser fra fx ODF, men det er aldrig lykkedes mig. Så hvis du kan hjælpe her, så vil mange sikkert være dig tak skyldig.

... du kan jo selvfølgelig altid checke trunk ud for OOo eller LibO og lede lidt i den. Sidst jeg hentede trunk for OOo var den på lige over 1GB data i alt.

:o)

  • 0
  • 1
#18 Baldur Norddahl

Uanset om det er OOXML eller ODF finder jeg det uheldigt hvis jeg ikke kan regne med at de dominerende kontorprogrammer kan læse mine filer.

Jeg arbejder ikke med at lave kontorparker. Jeg laver backend løsninger. Vi har allerede løsninger der lader brugeren downloade diverse data som CSV eller Excel-regneark. Det vil være en skuffelse hvis jeg bruger tid på at implementere et system baseret på en ISO-standard, bare for at finde ud af at folk ikke kan indlæse resultatet i deres kontorpakker alligevel.

Nu vil jeg sandsynligvis slet ikke give mig i kast med en sådan opgave. Vi bruger opensource biblioteker udviklet af andre til formålet. Jeg fornemmer bare at disse biblioteker kunne levere bedre kvalitet hvis udviklerne kan stole på ISO-standarterne.

  • 0
  • 0
#19 Jesper Lund Stocholm Blogger

Uanset om det er OOXML eller ODF finder jeg det uheldigt hvis jeg ikke kan regne med at de dominerende kontorprogrammer kan læse mine filer.

Principielt set kan jeg godt være enig med dig - men det er en problemstilling uden løsning ... i hvert fald indtil leverandørerne beslutter sig for, at de vil implementere de fulde standarder.

Som du måske kan huske, så stillede Videnskabsministerens ekspertpanel en lang række spørgsmål til leverandørerne af kontorpakker. Konkret var det IBM, Microsoft, ORACLE, Google, Apple og LibreOffice (så vidt jeg husker). Ét af spørgsmålene var, om de implementerede den fulde specifikation af dokumentformaterne de hævdede at understøtte. Alle som én svarede udenom dette spørgsmål og skrev i stedet variationer over "Vores implementering er efter vores overbevisning i fuld overensstemmelse med standarderne, og hvis der er fejl i vores implementation, så retter vi dem selvfølgelig".

Det vil være en skuffelse hvis jeg bruger tid på at implementere et system baseret på en ISO-standard, bare for at finde ud af at folk ikke kan indlæse resultatet i deres kontorpakker alligevel.

Men i virkelighedens verden, så vil man jo (forhåbentlig) aldrig sætte sig ind i et lokale med standarden og implementere den uden at krydschecke med de konkrete implementeringer i markedet. Nu har vi i CIBER efterhånden nogle gange prøvet at lave dokumenter i vores løsninger, og jeg har endnu ikke oplevet, at det gik uden gnidninger. Der er ALTID etellerandet hjørne, hvor en kontorpakke kræver en værdi indenfor et bestemt interval, kun understøtter 8 ud af standardens 12 værdier for graftyper, har implementeret en funktion i regneark, der ikke er beskrevet i standarden, kræver en (ligegyldig) DOCTYPE-erklæring i en stump XML, kræver tilstedeværelse af et XML-element eller attribut (selvom den ingen funktionalitet har i det konkrete tilfælde) eller lignende.

Mig bekendt er der kun én af leverandørerne, der konsistent har leveret oversigter over deltaerne ifht implementering og standard. Det er et helvede at arbejde i sådan et økosystem ... butwhatareyougonnado?

  • 0
  • 0
#20 Baldur Norddahl

Ok, det forstår jeg godt. Man kan sammenligne det med situationen for HTML/CSS. Men der er det netop lykkedes at forbedre situationen markant. Det skyldes større fokus fra producenterne af browsere samt standardiserede tests (ACID1/2/3) som producenterne kan måle sig op imod.

Har man inden for OOXML eller ODF arbejdsgrupperne overvejet en tilsvarende tilgang for at sikre bedre kompatibilitet imellem implementeringerne?

Det er ikke altid praktisk muligt at teste dit dokument op imod samtlige platforme. Det ville være bedre hvis der fandtes en pendant til validator.w3.org som man kan bruge.

  • 0
  • 0
#21 Jesper Lund Stocholm Blogger

Man kan sammenligne det med situationen for HTML/CSS. Men der er det netop lykkedes at forbedre situationen markant. Det skyldes større fokus fra producenterne af browsere samt standardiserede tests (ACID1/2/3) som producenterne kan måle sig op imod.

En lille kommentar:

Der er en lille ting, som ofte glemmes, når man taler om interop ifht HTML og CSS og den meget større konvergens i understøttelse vi har set i markedet de sidste 5 år. Denne ting er det famøse -element. For sideløbende med højere interop via de centrale HTML/CSS-teknologier, har vi set en opblomstring af features, der anvender -skraldespanden. Derfor giver det fin mening at snakke om forbedringer - men kun for det indhold, hvor man ikke anvender indlejrede objekter.

Har man inden for OOXML eller ODF arbejdsgrupperne overvejet en tilsvarende tilgang for at sikre bedre kompatibilitet imellem implementeringerne?

Der har været en smule. I ODF-sammenhænge har man lavet nogle test-regneark, der giver sådan en ACID-smiley for udregning af formler, men det er mig bekendt det eneste man har lavet. I OOXML-sammenhænge har flere af os længe advokeret for, at vi egentlig i standardiseringsregi burde udvikle nogle test-suiter, men den sørgelige sandhed er, at de kommercielle interesser, der på godt og ondt driver standardiseringsarbejdet, har ikke ønsket at donere nogen resourcer til det.

Det er ikke altid praktisk muligt at teste dit dokument op imod samtlige platforme. Det ville være bedre hvis der fandtes en pendant til validator.w3.org som man kan bruge.

Der har igennem tiden været flere af disse. For ODF har man haft validatoren fra opendocumentfellowship, men den har aldrig været rigtigt god. Alex Brown har også lavet en validator af både ODF og OOXML som i dag nok er den mest komplette og jeg har også lavet en validator til OOXML-dokumenter.

Den store forskel på "min verden" med dokumentformater og fx HTML og CSS er kompleksiteten. Der er en verden til forskel på at schema-validere et dokument på baggrund af "en håndfuld elementer og attributter" som vi har det i HTML og så at gøre det samme på baggrund af en spec på 1300 sider som ODF er eller 6000 for OOXML. Dertil kommer jo også den lille detalje, at schema-validering af flow-layout dokumenter som ODF/OOXML-filer kun giver en lille bitte del af en "fuld" conformance-test ifht alle normative krav i standarden.

PS: der er også denne, men jeg har ikke selv erfaring med at bruge den.

http://officeshots.org/

  • 1
  • 0
#22 Baldur Norddahl

Tak for udførligt svar. Jeg kan ikke andet end at heppe på at der bliver udviklet nogle test-suiter af både den ene og den anden art.

At standarten er på 6000 sider gør det kun endnu vigtigere at have noget at teste op imod. Ellers er der kun ringe chance for at to implementeringer gør det ens.

  • 0
  • 0
Log ind eller Opret konto for at kommentere