Microsoft: OOXML er da nemt at implementere

Hvis Office eksempelvis implementerer tabeller på en anden måde end specifikationen, dokumenteres det klart på websitet, fortæller han.

Lige præcis derfor er OOXML ikke det rette valg for Danmark som den standard den danske stat skal vælge. For alle de folk der bruger MS Office, vil ikke lægge mærke til at deres dokument indeholder specielle MS implementationer og de vil mene at de andre office pakker der implementere OOXML er defekte og ikke overholder OOXML standarden, hvilket er forkert. => Det styrker ikke konkurrencen at vælge OOXML, snarrer tværtigmod.

Kan man ikke lave en ny netavis KUN for udviklere og lignende, hvor alle noobs og evangelister holdes uden for? Jeg er i hvert fald snart væk fra version2.

Kan man ikke lave en ny netavis KUN for udviklere og lignende, hvor alle noobs og evangelister holdes uden for?

Ytringsfrihed??? Siden hvornår er det ophørt?

Husk nu at her i landet der kun er ytringsfrihed så længe man har den rette mening.

Jeg bed mærke i følgende indledning til denne artikel:

Microsoft: OOXML er da nemt at implementere Hvis bare man benytter biblioteker til Java eller .Net, ...

Det kan godt være at en stor del af de udviklere der skal læse og/eller oprette nye dokumenter [læs: dokument/regneark/...] kan nøjes med .Net eller Java API'erne. Men hvad med alle de andre sprog (PHP, ILERPG, Cobol, Python, Ruby, C, C++, LotusScript, Perl, ...)? Der skal nok komme API'er til flere af disse andre sprog også hen ad vejen, men det kommer til at tage lang tid.

Nogle helt andre udviklere der står overfor store problemer er dem der ikke kan nøjes med de generelle API'er til at læse og/eller skrive formaterne. Der er dem der har behov for at manipulere formaterne helt ned på laveste plan og dé har behov for at gennemlæse hele specifikationen, forstå den og sørge for at få den implementeret på en sådan måde at de har gennemtænkt alle mulige kombinationer af layout. Enig... dét kan også være rigtig svært med ODF, men dén specifikation er trods alt noget nemmere at overskue og komme igang med.

Enig... dét kan også være rigtig svært med ODF, men dén specifikation er trods alt noget nemmere at overskue og komme igang med

Helt enig, og så syntes jeg (helt min egen smag) at XML'en i ODF er pænere og lettere at forstå end i OOXML. Jeg vil i hvert fald have lettere ved at skrive et program der kan skrive ODF filer end OOXML, netop fordi jeg forstår ODF's XML lettere.

Hej Rene,

Lige præcis derfor er OOXML ikke det rette valg for Danmark som den standard den danske stat skal vælge.

Udtalelsen fra MS undrer mig en smule - jvf min erfaring med at arbejde med OOXML. Mig bekendt er der nemlig ikke nogen områder, hvor Microsoft Office "gør det forkert" ifht OOXML.

Det MS sikkert har sagt er, at der er naturligvis dele af en specifikation, hvor hver applikation måske kun understøtter en givet mængde af funktionalitet eller værdier i en liste.

Et par eksempler:

Der er principielt ikke nogen øvre grænse for, hvor mange ark et regneark kan indeholde. Men Microsoft har en øvre grænse på - vist nok - 1024.

Der er principielt ingen grænse for, hvor mange rækker et ark i et regneark kan have, men Excel har en øvre grænse - vist nok - på 65352.

<fonts>-elementet er schema-mæssigt et child-element til <WorkBook>-elementet men har en attribut "minOccurs=0". Derfor er elementet principielt ikke krævet. Microsoft Office kræver en tilstedeværelse af dette element.

Der er altså ikke tale om, at man gør noget forkert - men at man ikke understøtter hele den aktuelle range i en standard. Et andet eksempel kunne være, at man kan specificere cm-bredden på en tabel. Datatypen til dette er xsd:double, men en eller anden applikation har nok en øvre grænse på måske 100 centimeter (og det er nok sat højt).

Det er disse begrænsninger, der beskrevet i "Implementer's notes".

Ovenstående er ganske normalt. Både for ODF (1.2) og OOXML er det fx muligt at specificere anvendt hash-funktion, hvor listen i begge tilfælde er "uendelig". Men hverken Microsoft Office eller OpenOffice.org understøtter et uendeligt antal algoritmer - de understøtter typisk kun en håndfuld i alt.

Hej Rene,

Helt enig, og så syntes jeg (helt min egen smag) at XML'en i ODF er pænere og lettere at forstå end i OOXML.

+1

Udtalelsen fra MS undrer mig en smule - jvf min erfaring med at arbejde med OOXML. Mig bekendt er der nemlig ikke nogen områder, hvor Microsoft Office "gør det forkert" ifht OOXML.

Bare fordi du ikke kender til tilfælde kan de jo godt eksistere.

Godt vi har direktøren for interoperabilitet hos Microsoft til at sætte tingene på plads. Han må om nogen vide noget om emnet.

Så som det er nu er der altså 0 der implementerer OOXML. Ifølge denne artikel...

Hej Anders,

Bare fordi du ikke kender til tilfælde kan de jo godt eksistere.

Jeps

Godt vi har direktøren for interoperabilitet hos Microsoft til at sætte tingene på plads. Han må om nogen vide noget om emnet.

Enig - men husk på, at der er en journalist imellem "os" og "ham".

Jeg vil rigtigt gerne se eksemplerne han omtaler, så måske kan journalisten tage fat i Vijay igen og spørge ham om dette. Det er jo også relevant ifht vores arbejde i WG4.

Tanja?

»Jeg synes det er et vigtig og et godt spørgsmål. Ikke mange mennesker ved, hvorledes OOXML skal implementeres. Det er grunden til, at vi har offentliggjort specfikationen på Documentinteropinitiative.org, hvor Microsoft åbent lægger kortene på bordet for, hvordan vi implementerer den 6000 sider ECMA/ISO-standard, og hvordan vi afviger fra standarden. I nogle tilfælde har vi afvigelser, og de er erklæret som implementationsnoter.«

Kort kursus i kritik når der er små »« rundt om noget er det fordi det er et citat.

Please please fortæl mig hvordan du vil fortolke dette citat som andet end microsoft office ikke implementere ooxml fuld ud. Jeg ved godt det er nemmere at se bort fra virkeligheden når den ikke passer ind i manuset.

Så mm du påstår at version2.dk fejlrepresentere intervievet eller med vilje oversætter fejlagtigt så er grundlæggende set microsoft der kommunikere at selv ikke de kan inplementere ooxml...

Men det passer jo ret godt med microsofts metode: så længe du siger eller skriver noget microsoft synes om så er du et geni på rulleskøjter, men det øjeblik du ikke passer ind i manuset så er du inkompetent jubel idiot... Selv hvis er hånden der giver en platformen man kommunikere fra (Version2.dk) eller formanden for DS's udvalg for dokumentformater...

Men det ved alle der ikke er født igår, hvis du er iseng med microsoft så er det kun et spørgsmål om tid inden du bliver øm.

Så det korte af det lange er at der er ooxml og der er microsoft ooxml...

/Jakob

og hvordan vi afviger fra standarden

er et meget interessant ting, men det er absolut ikke let at finde ud af, hvordan og hvor de afviger på Documentinteropinitiative.org, for at sige det meget kort, så er det ganske simpelt umuligt at finde, hvis man ikke i forvejen er 100% inde i, hvad OOXML standarden består af.

For normale mennesker, burde MS da kunne lave en liste over alle de steder, hvor de har valgt at implementere mere eller mindre end det der står i OOXML. Den må for min skyld gerne være mega lang, hvis der blot er en komplet liste over alle deres afvigelser. Men jeg har meget meget svært ved at finde det på Documentinteropinitiative.org eller bare noget der giver mig en tilnærmelsesvis liste.

Altså så skjuler de deres afvigelser ved at gøre det mere eller mindre umuligt at finde ud af om du kan være sikker på at det dokument du lige har lavet i MS Office nu også virker i andre pakker der HAR implementeret OOXML efter standerden => valget bliver at man får fat i MS Office, for at være sikker på ikke at miste data => Vi har ikke øget konkurrencen i Danmark ved at vælge OOXML.

Hej Rene,

så er det ganske simpelt umuligt at finde, hvis man ikke i forvejen er 100% inde i, hvad OOXML standarden består af.

Så er implementer's notes åbenbart ikke for dig.

Idéen og værdien af implementer's notes er at give støtte til de mennesker, der rent faktisk skal implementere skidtet. Derfor giver en samlet liste over afvigelser ikke mening (med mindre man vil bruge den politisk, naturligvis). Det giver meget bedre mening at kunne slå det element op, som man sidder og skal implementere i sit eget program. Så for mit eget vedkommende, da jeg skulle lave XLSX-filer fra bunden, kunne jeg slå de konkrete elementer op, som jeg skulle bruge. Her kunne jeg så se, hvordan Microsoft Office behandlede dem.

Derfor vender du tingene på hovedet, når du vil tage et dokument du har lavet og så se, om det kan åbnes i andre programmer. Til det skal du nemlig ikke brugge Microsofts noter - men noter for det program, som du ønsker at åbne dokumentet i.

Derfor vender du tingene på hovedet, når du vil tage et dokument du har lavet og så se, om det kan åbnes i andre programmer. Til det skal du nemlig ikke brugge Microsofts noter - men noter for det program, som du ønsker at åbne dokumentet i.

Det hjælper jo bare ikke hvis office har skrevet noget i xml'en som ikke overholder ooxml. Så kan jeg kigge nok så meget i de noter for det program, som jeg ønsker at åbne dokumentet i.
Jeg tror det var hans pointe.

Hans klage gik vist ikke på om han selv kunne lave gyldig xml

Hej Anders,

Det hjælper jo bare ikke hvis office har skrevet noget i xml'en som ikke overholder ooxml.

Jeg er helt enig - og derfor kunne det også være rigtigt interessant at se de eksempler, som blev nævnt i interviewet.

Hans klage gik vist ikke på om han selv kunne lave gyldig xml

Lige præcis. Jeg vil se om et dokument skabt i MS Office har nogle ting som MS har valgt at afvige med i forhold til standarden.

For mig at se er det meget let at lave sådan en liste når man sidder med videnen omkring hvor man afviger fra OOXML standarden. Hvis det ikke er tilfældet at man selv har styr på det, så har MS et helt andet problem og det kaldes for rod. Men jeg satser på at de selv har styr på det.

Det handler ikke kun om politik.

Hvis jeg sidder og skal vælge kontorpakker til x antal maskiner og jeg vil sikre at de alle kan læse/skrive OOXML dokumenter også selv om de har forskellige kontorpakker, så er det da super relervant at vide, hvor præcis MS Office afviger fra den vedtagne OOXML standard. Ud fra den liste kan jeg så lave en episk vurdering af om MS Office er en valid kandidat til at løse opgaven. Med den viden om at MS selv udtaler at de afviger fra standarden, så må man gå ud fra at MS Office ikke kan være en kandidat, før man er klar over, hvor og hvormeget de afviger fra standarden. Det må du da kunne forstå Jesper?

Noget helt andet er når jeg skal generer et OOXML dokument, så skal jeg også gerne bruge den liste, så jeg kan se om de ting jeg har genereret i mit OOXML dokument kan forventes at virke i MS Office.

Jeg gider ikke bruge timer/dage på at lede alle elementer jeg anvender efter OOXML standarden for at finde ud af om og hvormeget MS Office afviger i brugen af de elementer jeg bruger efter standarden. En liste over, hvor de afviger vil være guld værd til at nedsætte mit tidsspild.

Men som du selv skriver, så er der jo mulighed for at anvende denne liste politisk, og jeg ser intet problem i det.

MS siger at de implementerer OOXML fuldt, og hvis de så tilmed har en liste der siger noget andet, så har de en markedsføringsafdeling som ikke snakker med udviklingsafdelingen, men det er der jo ikke noget nyt i.

Listen vil set fra MS'es side gøre det for let og alt for gennemskueligt at se, hvor MS afviger og det er jo farligt for MS og deres kamp for OOXML standarden.

Hej Rene,

Lige præcis. Jeg vil se om et dokument skabt i MS Office har nogle ting som MS har valgt at afvige med i forhold til standarden.

Super - det bruger du så de medfølgende schemas til.

Hvis jeg sidder og skal vælge kontorpakker til x antal maskiner og jeg vil sikre at de alle kan læse/skrive OOXML dokumenter også selv om de har forskellige kontorpakker, så er det da super relervant at vide, hvor præcis MS Office afviger fra den vedtagne OOXML standard. Ud fra den liste kan jeg så lave en episk vurdering af om MS Office er en valid kandidat til at løse opgaven.

Det er naivt at tro, at det er nok med sådan en liste. Enhver leverandør - også andre end Microsoft - laver en milliard antagelser, når de skal implementere fx OOXML eller ODF. Det er ikke kun karakteristisk for Microsoft. Derfor giver listen du ønsker ikke den forventede værdi. Du kan jo nemlg ikke sige noget om andre applikationers opførsel med den.

Et eksempel:

I spec for digitale signaturer, er følgende beskrivelse:

"[i]The <dsig:document-signatures> root element serves as a container for an arbitrary number of <xmldsig:Signature> elements. If the <dsig:document-signatures> element contains multiple <xmldsig:Signature> elements, then there should be a relation between the digital signatures they define, for instance, they may all apply to the same set of files.
Applications may require that a digital signature includes a certain set of files. That is, they may consider a digital signature to be valid if, and only if,
• the digital signature itself is valid, and
• if the <Reference> child elements of the <Signature> element reference a certain set of files.
In particular, application may require that a digital signature references all files contained in a package.[/i]"

Læg mærke til den store brug af "may" og "should"-verber. Disse er valg en leverandør kan lave i deres implementering. Selvom Microsoft i deres OOXML implementer notes forklarer, hvordan de har implementeret i Microsoft Office, så giver det på ingen måde i sig selv et retvisende billede af, hvordan interop vil virke imellem applikationer.

Interoperabilitet er jo nemlig ikke let - det er svært. Det er jo bla. derfor man i ODF regi har lavet OIC TC og diverse plug-fests. I ISO-regi tænker man lignende tanker i et samarbejde imellem WG1 og WG5 i SC34.

Eksempelvis nægter IBM jo kategorisk at sige, at de har implementeret OOXML i Symphony. I stedet siger de, at de "target Microsoft Office 2007 output". Derfor vil en antagelse om "uheldig opførsel" af MSO dokumenter på baggrund af listen sandsynligvis ikke være retvisende for Symphony - for de bruger ikke spec med Microsoft Office output direkte (siger de).

Noget helt andet er når jeg skal generer et OOXML dokument, så skal jeg også gerne bruge den liste, så jeg kan se om de ting jeg har genereret i mit OOXML dokument kan forventes at virke i MS Office.

Præcist! Og dette er netop den relevante use case for implementer notes. Så kan man jo argumentere frem og tilbage om, hvorvidt listen skulle være en alfabetisk liste eller et "sejl" af OOMXL-specifikationen. Jeg ved ikke, om du har prøvet at implementere fx ODF eller OOXML, men min erfaring med dette er, at det er en stor fordel, at den kontekst jeg sidder og kigger i standen i modsvares af den kontekst, som eventuelle begrænsninger findes i. Med andre ord: hvis jeg skal implementere dato-understøttelse i regneark i OOXML (som var én af mine opgaver), så slår jeg naturligvis op i spec for at se, hvordan det skal laves. I det afsnit findes al den information jeg skal bruge. Når jeg så skal se, om det også vil virke i fx Microsoft Office, så er der samme opbygning og struktur som den standard jeg lige har siddet og kigget i.

Jeg gider ikke bruge timer/dage på at lede alle elementer jeg anvender efter OOXML standarden for at finde ud af om og hvormeget MS Office afviger i brugen af de elementer jeg bruger efter standarden.

Joeh - men sådan er vi jo så forskellige og har forskellige kompetencer. I mine øjne er det en fordel, at jeg ved implementering af <workBook>-elementet kan finde det i implementer notes på præcist samme sted som i spec. For OOo-opførsel er mit eneste valg at "bruge timer/dage" på at gennemtrævle den 1Gb kildekode, der ligger bag OOo for at hitte ud af, hvorfor den dog ikke vil læse den MathML-klump jeg har lavet. Jeg har ikke specielt gode C++kompetencer, så her er det en ubetinget fordel for mig, at jeg kan slå elementet op i implementer notes.

En liste over, hvor de afviger vil være guld værd til at nedsætte mit tidsspild.

Det er jo godt for dig - men at lave listen på baggrund af implementer notes er jo trivielt - så det kan du jo bede en 14-årig bruge en times tid på for dig.

At der ikke er nogen, der har lavet den indtil nu indikerer lidt for mig, at den nok ikke er så super vigtig.

Men som du selv skriver, så er der jo mulighed for at anvende denne liste politisk, og jeg ser intet problem i det. Listen vil set fra MS'es side gøre det for let og alt for gennemskueligt at se, hvor MS afviger og det er jo farligt for MS og deres kamp for OOXML standarden.

Som jeg sagde ovenfor - at lave denne liste på baggrund af implementer notes er trivielt - så hvis den gav reel værdi - selv som angrebsvektor på MS - tror du så ikke, at den var blevet lavet allerede?

Var det ikke en idé, at du selv lavede denne liste? Det kunne jo så være, at du var tuen, der væltede OOXML-læsset.

:o)

Interessante observationer fra Svend Hylleberg, tidligere formand for Konkurrencerådet.

En konkurrencemæssig fejltagelse (http://svendhylleberg.blogs.business.dk/2009/11/20/en-konkurrencem%C3%A6...)