– Excels ODF-støtte dårlig

[kjeklulf]

Uansett hvordan du vrir og vender på dette, burde Office kunne lese dagens ODF-filer samt lage de slik at andre skal kunne lese de. Dette skaper bare trøbbel med kompatibiliteten til ODF-formatet. Excel sin måte å gjøre ting på er på ingen måte standardisert (den oppfyller vel ikke OOXML-standarden engang), og ikke støttet av noen andre programmer som leser ODF. Din argumentasjon faller på sin egen urimelighet.

 

Jeg gjentar meg selv her men: MS måtte ta et valg. De tok det valget som er det eneste som er dokumentert og ferdig standardisert. Uansett hva de hadde valgt hadde de blitt kritisert. Og: måten Excel gjør det på /er/ standardisert og fritt tilgjengelig. Msoxl: som namespace-prefiks viser til ECMA OOXML som er en ECMA standard og fritt tilgjengelig for alle. Det er den standarden OO.org bruker når den leser Office 2007-filer som er lagret i standard format. Støtten ligger altså (som sagt mange ganger) inne for filer som ikke er lagret i ODF-formatet. KOffice RC 2.0 har etter det jeg har forstått allerede lagt inn mulighet for å lese ODF-filer laget av MS Office SP2 (på samme måte som den har støtte for å lese ODF-filer laget av OO.org i ulike versjoner).

 

Dette handler da om funksjoner som faller utenfor ODF-formatet. Hva er argumentene på de delene av ODF 1.1/1.0 standarden som ikke er implementert? Og viss dere leser litt om dette temaet er det nettopp det som har blitt kritisert i denne omgang.

 

Det er merkelig hvordan dette argumentet snus på hodet hver gang det er MS det er snakk om. "Hvis alle bare gjør som OO.org gjør (selv om det ikke er standardisert) så unngår vi alle problemer". IE anyone?

[Del]

Dette viser nok en gang at Microsoft har store problemer med å implementere en anerkjent standard.

 

Rent bortsett fra at de HAR implementert en anerkjent standard, men de har IKKE implementert en udokumentert utvidelse som ikke er en del av standarden.

 

Isåfall kan man vel like så godt hyle at OpenOffice ikke har implementert standarden. Det er same shit.

Kanskje du skal ta deg tid til å lese noe av det andre skriver, og sjekke det allerede fremlagte kildematerialet før du poster. Jeg skjønner du ivrer etter å støtte MS, men her er det faktisk også snakk om feil implementering av ODF 1.1, hvilket noen klarer å vri til at det var rom for tolkning.

[nercix]

IE var ikke først ute å støtte standarden, HTML (IE 1.0 var vel ute _litt_ før HTML 2.0), og støtter den ikke enda.

 

OO.org sin måte å gjøre ting på er så godt som standardisert, noe Microsoft sin måte å gjøre ting på absolutt ikke er, eller kommer til å bli. Å bruke ECMA OOXML namespacet (som er en Microsoft standard, der deler ikke støttes av Microsoft selv) kommer ALDRI til å være akseptert i ODF 1.2. Dette går ut på å ødelegge standarden før den er standardisert.

 

Merkelig hvor den egentlige kritikken ved flere anledninger har blitt hoppet over i denne tråden. Det faktum at noen blindt støtter Microsoft i denne saken er meget mistenkelig.

 

En direkte feil og ufullstendig ODF 1.1, er det Microsoft har fått til. Utvidelser som er brukt i OOo kommer til å bli standardisert, med base små endringer. Dette finnes ingen argumenter for å forkrøple en god standard som ODF, og det tilogmed før den er komplett.

[kjeklulf]

Du er klar over at Weir dokumenterte at Excel var det eneste som la inn celler feil? La oss gjenta: <snip>

 

Som vanlig er din taktikk kverulering og forvirring.

 

Og i følge kommentarene til hans innlegg er det uenighet om hvordan denne delen av standarden skal tolkes, blant annet fra en som er medlem av OpenDocument TC og som ikke har noe med MS å gjøre. Jeg kjenner ikke standarden godt nok til å avgjøre hvem som har rett (og om noen egentlig har rett). Jeg har imidlertid ikke mer tiltro til Rob Weir enn du har til de vanlige MS-bloggerne.

 

Som vanlig er din taktikk å fjerne fokus fra saken og beskylde andre for kverulering og forvirring når de er uenige med deg.

 

Beklager men ditt presisjonsnivå er svært langt unna det punkt hvor jeg tar dette som god fisk. Kan du dokumentere din påstand? Det kan godt være riktig, men MS-bloggere har presentert blank løgn bevisst tidligere i propagandaøyemed.

 

Som sagt: Jeg har ikke sett det dokumentert eksplisitt på KOffice sine sider. Du får nå velge å tro akkurat hva du vil forøvrig.

 

Du har nå i et par år desperat forsøkt å fremstille MS som et annet selskap, som nå spiller på lag. Er det ikke på tide at virkeligheten trenger inn hos deg også? Ser du virkelig ikke hvordan MS motvillig flytter seg fra skanse til skanse?

 

Den eneste muligheten for å få ryddet opp i ODF kaoset MS nå skaper er at en meget tydelig beksjed gies over hele verden. Eksempelvis i fora som dette bør det gå klart frem at vi ikke finner oss i den type adferd fra MS. Da vil markedspresset bli stort nok til at de bøyer av. Det skal bli spennende å se hvor godt du lykkes med å forhindre at en klar holdning kommer fram denne gangen kjeklulf. Jeg er redd du får lett match. Personlig er jeg nemlig dritlei av å diskutere og grave meg ned i dokumentformater. Dette er griseenkelt hvis man tar på seg forbrukerhatten.

 

Vel, noen kaller det å ta på seg forbrukerhatten. Andre vil heller se det som å ta på seg aluminiumshatten.

 

Selvsagt har MS endret seg (fordi de må og fordi det lønner seg å gjøre det kundene dine ønsker), og like selvsagt kunne de funnet smidigere løsninger. Selvsagt er de mest opptatt av sine egne kunder og like selvsagt er Rob Weir (og IBM) opptatt av å skaffe seg flest mulig av MS sine kunder.

[nercix]

 

 

Myth #1: You can't exchange spreadsheet files between applications that use OpenDocument format.

 

People are already routinely exchanging OpenDocument spreadsheet files, including formulas, between different applications. The OpenDocument specification itself, plus the hard work of many developers means that people are already quite successfully exchanging spreadsheets. That's in spite of concerns and carefully-crafted "problems" of years ago. It's also important to note that some of the old tests (such as those of NewsForge) used carefully-crafted formulas to cause problems, or used a very old version of KOffice, which had a poor formula engine. Much has been improved since then, in particular, the KOffice formula engine has since been completely replaced with a much better implementation.

 

And remember that if you "can't" exchange spreadsheet files using OpenDocument, the alternatives are worse. People who say "OpenDocument can't exchange spreadsheet formulas, because the definition isn't published in a final form" often use Excel's ".xls" - yet this is an essentially undocumented format! OpenFormula is already far better defined than ".xls" format, and in any case, this format is being abandoned by all spreadsheet developers. The other likely alternative is Microsoft's XML format, but this is much less mature than ODF's format (see below for more). What's worse, both of those formats are completely controlled by a single vendor who has a financial incentive to inhibit open competition. Not a good idea if you wish to be sovereign from any particular supplier.

 

So, go ahead and use OpenDocument right now, even for spreadsheets; typical spreadsheet formulas already exchange very well between OpenDocument applications.

 

 

Eneste informasjonen jeg fann om Microsoft sitt påfunn på koffice-devel: er her

[Del]

Selvsagt har MS endret seg (fordi de må og fordi det lønner seg å gjøre det kundene dine ønsker), og like selvsagt kunne de funnet smidigere løsninger. Selvsagt er de mest opptatt av sine egne kunder

Dessverre er det ikke slik. En dominerende markedsaktør har lite insentiv til å lage et best mulig produkt for sine kunder, det handler i hovedsak om å hindre andre inn på markedet. Hvis du har over 90% av markedet er det lite å hente på å lokke nye kunder med bedret funksjonalitet, men mye å tape på å miste markedsandeler. Dette er elementære markedsmekanismer. Jeg vil anta Bolson kan gi deg utførlig innføring dersom du synes dette er litt mye å ta inn over deg.

[kjeklulf]

IE var ikke først ute å støtte standarden, HTML (IE 1.0 var vel ute _litt_ før HTML 2.0), og støtter den ikke enda.

 

Det var da heller ikke poenget mitt. Poenget var: Man kan ikke ha som utgangspunkt at "bare alle velger vår ustandardiserte variant så er alle problemer løst". Det funket dårlig med IE og det funker like dårlig i andre situasjoner. Særlig når denne ustandardiserte varianten er udokumentert og utgått (heller ikke OO.org eller Lotus bruker den lenger som standard).

 

OO.org sin måte å gjøre ting på er så godt som standardisert, noe Microsoft sin måte å gjøre ting på absolutt ikke er, eller kommer til å bli. Å bruke ECMA OOXML namespacet (som er en Microsoft standard, der deler ikke støttes av Microsoft selv) kommer ALDRI til å være akseptert i ODF 1.2. Dette går ut på å ødelegge standarden før den er standardisert.

 

"Så godt som standardisert" er ikke bra nok, ikke når den i tillegg er utgått, udokumentert og ikke nødvendigvis lik fra implementasjon til implementasjon. Det er like dumt som å si at IE sine løsninger er "så godt som standardisert".

 

Hvilke deler av ECMA OOXML er det du mener Microsoft ikke støtter med Office 2007? ECMA er en standardiseringsorganisasjon. Det er de som eier ECMA OOXML, ikke Microsoft.

 

Å bruke ECMA OOXML namespacet vil ikke være nødvendig for formler når ODF 1.2 kommer og ODF endelig får en formelspesifikasjon (dvs, det kan fortsatt være nødvendig om det er formler som finnes i ECMA OOXML og som ikke finnes i ODF 1.2).

 

Dessuten: å bruke namespace på denne måten /er/ den aksepterte metoden for elementer som ikke finnes i standarden og det vil gjelde også for ODF 1.2.

 

Merkelig hvor den egentlige kritikken ved flere anledninger har blitt hoppet over i denne tråden. Det faktum at noen blindt støtter Microsoft i denne saken er meget mistenkelig.

 

En direkte feil og ufullstendig ODF 1.1, er det Microsoft har fått til. Utvidelser som er brukt i OOo kommer til å bli standardisert, med base små endringer. Dette finnes ingen argumenter for å forkrøple en god standard som ODF, og det tilogmed før den er komplett.

 

Det er ingen som blindt støtter MS her, snarere blind motstand fra enkelte som ikke har satt seg inn i sakene (det gjelder ikke Del, han har satt seg inn i en del av dette, vi er bare uenige om konklusjonene). Jeg har satt meg rimelig godt inn i denne saken (og hele komplekset rundt ODF/OOXML de siste to årene). Jeg har lyttet til begge sider og har forståelse for argumentene som brukes fra begge sider. I dette tilfellet skjønner jeg at MS har valgt en løsning som er standardisert og dokumentert (ECMA OOXML namespacet) framfor løsninger som er utgått og udokumentert eller uferdige og ustandardisert. Jeg skjønner at de har valgt en løsning som passer deres kunder (og dem selv) best, samtidig som de godt kunne gjort det på en smidigere måte. Like godt skjønner jeg at Rob Weir og IBM hadde ønsket at MS hadde valgt en løsning som passet IBM sine kunder (og IBM selv) best. Noen kunder ville tapt uansett hvilken løsning MS hadde valgt, og de ville blitt kritisert uansett.

[ze5400]

-udugelig programmering

-ignorering av standarder

= microsoft

 

Tja - Udugelig programmering tror jeg vi kan stryke.

Som mange her sikkert husker lakk kildekoden til Windows NT4, samt deler av Win2Ks kildekode.

En liten gjennomgang av deler av koden finner vi her:

http://www.kuro5hin.org/story/2004/2/15/71552/7795

 

Utdrag ang. kodekvalitet:

Quality

Despite the above, the quality of the code is generally excellent. Modules are small, and procedures generally fit on a single screen. The commenting is very detailed about intentions, but doesn't fall into "add one to i" redundancy.

There is some variety in the commenting style. Sometimes blocks use a // at every line, sometimes the /* */ style. In some modules functions have a history, some do not. Some functions describe their variables in a comment block, some don't. Microsoft appears not to have fallen into the trap of enforcing over-rigid standards or universal use of over-complicated automatic tools. They seem to trust their developers to comment well, and they do.

 

Microsoft har nok gjort seg skyldige i småslem kommentering, men ikke dårlig kode - om vi skal ta infoen på nettstedet for god fisk.

 

 

Tror vi kan stryke ignorering av standarder også.

Om jeg ikke misforstår har Microsoft fulgt standarden til punkt og prikke - men de har utvist latskap når det gjelder å få til en implementering som er kompatibel med allerede eksisterende kontorpakker.

 

Det er ikke helt heldig - men ikke noe noen burde gidde å lage furore utav. En liten sak alt i alt.

 

Dessuten - de har lovd å støtte ODF1.2 når det er standardisert - og da nytter ikke dette "trikset" lengre.

[kjeklulf]

Dessverre er det ikke slik. En dominerende markedsaktør har lite insentiv til å lage et best mulig produkt for sine kunder, det handler i hovedsak om å hindre andre inn på markedet. Hvis du har over 90% av markedet er det lite å hente på å lokke nye kunder med bedret funksjonalitet, men mye å tape på å miste markedsandeler. Dette er elementære markedsmekanismer. Jeg vil anta Bolson kan gi deg utførlig innføring dersom du synes dette er litt mye å ta inn over deg.

 

Og igjen går man seg vill i fortolkninger. "Best mulig for sine kunder" som jeg skrev er ikke nødvendigvis ment som kun "på den måten som først og fremst kommer våre kunder til gode". Det betyr også "slik at vi kan sørge for at de fortsatt er våre kunder". Ellers er vi ikke nødvendigvis uenige, jeg bare har trukket en helt annen konklusjon enn deg i hele ODF/OOXML-spørsmålet: Nettopp på grunn av det du sier er jeg opptatt av at OOXML blir standardisert i en organisasjon hvor nasjonene og ikke korporasjonene har kontroll. Nettopp derfor bør ISO ha ansvar for vedlikehold av både OOXML og ODF. Dessverre ønsker ikke Oasis (og SUN/IBM) dette for ODF.

[nercix]

Det er Microsoft sin framgangsmåte når det gjelder standarder som skaper IE-tilstander, og ikke det faktum at OOo implementerer draft av ODF 1.2. Poenger er her at ODF 1.2 kommer til å bli standardisert, og da i stor grad slik som den er foreslått i dag. Microsoft går rett i mot dette, og gjør ting på sin egen måte.

 

[Jeg er på diverse mailinglister og har titt og stødig hørt om problemer med å lese OOXML etter ECMA-standarden da Office 2007 ikke lagde filer som var 100% kompatible med denne.]

 

Msoxl i diverse dokumenter kan potensielt leve videre i lang tid, og man kan ikke forvente at fremtidens kontorpakker implementerer OOXML i tillegg til ODF, for å kunne støtte ODF fullt ut. Dette virker mer som ett forsøk på å snikinnføre OOXML, som de allikevel burde klart da det uheldigvis vart en ISO-standard.

 

Du har åpenbart ikke satt deg inn i dagens problemstilling da det er en ukorrekt og ufullstendig implementasjon av det som ER definert i ODF 1.1, som er kritisert av IBM.

[kjeklulf]

Poenger er her at ODF 1.2 kommer til å bli standardisert, og da i stor grad slik som den er foreslått i dag. Microsoft går rett i mot dette, og gjør ting på sin egen måte.

 

ODF 1.2 er ikke ferdig og den vil ikke bli standardisert før langt ut i 2010. Arbeidet med SP 2 startet i fjor sommer. Jeg forstår godt at MS ikke kunne basere seg på dette uferdige formatet da. Dessuten: IBM (og Rob Weir direkte) har ved flere anledninger vært invitert til workshops for å diskutere mulige løsninger, sammen med en lang rekke eksperter utenfra. IBM og Rob Weir takket nei til dette. Tror du virkelig de gjorde det fordi de var mest mulig opptatt av gode løsninger for deg og meg som brukere?

 

[Jeg er på diverse mailinglister og har titt og stødig hørt om problemer med å lese OOXML etter ECMA-standarden da Office 2007 ikke lagde filer som var 100% kompatible med denne.]

 

Ja, jeg har også hørt det i mange tilfeller men jeg har ennå til gode å se noe konkret som ikke er tilbakevist av andre eksperter (som ikke er tilknyttet MS). Når det er sagt: ingen implementasjon av noen kompleks standard er 100%. Til det er standardene alt for omfattende og det vil alltid være rom for tolkninger av enkelte elementer. OO.org sine implementasjoner av ODF har heller aldri vært 100% (f.eks. har de brukt dialekter av SVG).

 

Msoxl i diverse dokumenter kan potensielt leve videre i lang tid, og man kan ikke forvente at fremtidens kontorpakker implementerer OOXML i tillegg til ODF, for å kunne støtte ODF fullt ut. Dette virker mer som ett forsøk på å snikinnføre OOXML, som de allikevel burde klart da det uheldigvis vart en ISO-standard.

 

Det er ikke snakk om å "støtte ODF fullt ut", det er snakk om støtte for elementer som ikke finnes i standarden (som formler for ODF 1.0/1.1). Alle standarder inneholder instruksjoner for hva som skal gjøres med slike elementer. Namespace prefix er måten det gjøres på i ODF og vil være det også i neste versjon.

 

Altså: Når MS Office lagrer filer i ODF-formatet så kan filene inneholde elementer som ikke er spesifisert i ODF-standarden, rett og slett fordi MS Office og OOXML er mer funksjonsrikt. Alternativene for MS er da som følger: Vi fjerner disse elementene når du lagrer og du vil aldri se dem igjen, eller vi legger disse elementene i et namespace slik at du kan se dem om du har en applikasjon som har lagt inn støtte for å lese disse elementene. MS har valgt det siste.

 

Og det viktigste av alt: Dette er /akkurat/ det samme som skjer om du lagrer en fil i OO.org i et annet format enn ODF for å åpne den i en annen applikasjon. Hvis filen inneholder elementer som ikke finnes i det andre formatet så kan elementet allikevel bevares for å kunne vises i applikasjoner som støtter dette elementet. Her ønsker åpenbart noen at det skal være et sett med regler for MS og et sett med regler for alle andre.

 

Du har åpenbart ikke satt deg inn i dagens problemstilling da det er en ukorrekt og ufullstendig implementasjon av det som ER definert i ODF 1.1, som er kritisert av IBM.

 

Joda, jeg har satt meg inn i det. Det er to kritikk-punkter: at de ikke støtter formler på samme måte som OO.org, og tolkningen av hvordan referanser skal noteres i følge standarden. Det første har vi vært igjennom (og har ikke noe med standarden å gjøre) og det andre er det uenighet om etter det jeg har forstått ut fra kommentarene på bloggen til Rob Weir. Uenigheten kommer fra et uavhengig medlem av OpenDocument TC.

 

Når det er sagt: Det er garantert feil i MS sin implementasjon av ODF. Like garantert som det er feil i OO.org sin implementasjon av ODF. Ingen implementasjoner av slike komplekse standarder er noen gang 100 %.

Endret 9. mai 2009 av kjeklulf

[nercix]

OpenOffice 3.0 vart sluppet Oktober i fjor, og da var det som er foreslått i ODF 1.2 implementert (så vidt jeg har forstått). Man kan også vente på en helt ferdig spesifikasjon før man lager støtte for den, men da får man ikke testet de ulike delene i praksis. Alternativet er jo noe som du omfavner, nemlig å vente på ferdig spesifikasjon og gi MS tid til å implementere den (Gjør de det like fort som med HTML/CSS osb. har vi «full» støtte i 2040!). Videre mener du altså at man må slippe alt man har i hendene for å hjelpe MS med å implementere en standard?

 

MS bør klare dette på lik linje med alle andre som lager programvare. Man bør også merke seg forskjellen på å med overlegg gjøre feil og det å gjøre feil. Dette handler om det å ha ulike tilnærminger når det gjelder elementær funksjonalitet, noen som er dømt til å gi problemer.

[kjeklulf]

OpenOffice 3.0 vart sluppet Oktober i fjor, og da var det som er foreslått i ODF 1.2 implementert (så vidt jeg har forstått). Man kan også vente på en helt ferdig spesifikasjon før man lager støtte for den, men da får man ikke testet de ulike delene i praksis.

 

Tror du ikke MS allerede nå tester ulike varianter av hvordan de skal implementere ODF 1.2 når den en gang blir standardisert? Er det i dette tilfellet riktig å sende ut en implementasjon av en uferdig standard til sine kunder for at de skal teste det for dem? OO.org har hatt en vesentlig grunn til å legge inn støtte for ODF 1.2: den inneholder en formelspesifikasjon som ikke finnes i tidligere utgaver av ODF. Jeg skjønner fortsatt godt at MS heller valgte å vise til sin egne ferdige standard fremfor en annen som er uferdig og ustandardisert. Jeg skjønner at IBM er forbannet for dette men det skyldes at de først og fremst er opptatt av seg selv, på samme måte som MS.

 

Alternativet er jo noe som du omfavner, nemlig å vente på ferdig spesifikasjon og gi MS tid til å implementere den (Gjør de det like fort som med HTML/CSS osb. har vi «full» støtte i 2040!).

 

MS har noen hundre millioner kunder. Hver eneste dag produseres det millioner av Office-filer som skal kunne utveksles med andre brukere og fungere opp mot andre systemer (databaser, dokumenthåndtering etc. etc.). MS kan ikke forandre formatene annenhver uke alt etter hva en komite bestemmer seg for. I dette tilfellet støtter jeg dem i at de har valgt en løsning som er tryggest for deres kunder (og dem selv) og som samtidig er standardisert, åpen og fritt tilgjengelig for andre som ønsker å bruke den (som de allerede gjør for filer i standard Office 2007-format). Jeg synes samtidig de kunne gjort det på en smidigere måte, uten at jeg kjenner alle tekniske detaljer for hvordan det kunne gjøres.

 

Videre mener du altså at man må slippe alt man har i hendene for å hjelpe MS med å implementere en standard?

 

Nei, det er ikke det jeg mener i det hele tatt. Spørsmålet var ikke hvordan de skulle implementere en standard men hvordan de skulle implementere elemener som /ikke finnes i standarden/. MS har jo alltid fått kritikk for at de ikke lytter til andre og bare gjør som de selv vil, og nå får de altså kritikk for at de inviterer andre til å komme med synspunkter og forslag. Damned if you do, damned if you don't.

 

Altså, Microsoft sier for en gangs skyld: "Hør her, vi vil gjerne høre deres synspunkter og meninger og vi vil gjerne ha deres forslag til hvordan vi kan løse disse utfordringene på best mulig måte for alle", og så sier IBM "Nei takk, dette får dere fikse selv". Og MS er de som får kritikken? Er det rart man får følelsen av irrasjonalitet når enkelte diskuterer MS?

 

Man bør også merke seg forskjellen på å med overlegg gjøre feil og det å gjøre feil. Dette handler om det å ha ulike tilnærminger når det gjelder elementær funksjonalitet, noen som er dømt til å gi problemer.

 

Hva er det MS har gjort feil "med overlegg" her? De har valgt en løsning som passer seg selv best, som passer de fleste av sine kunder best og som er standardisert og ferdig. De har valgt en løsning som er i tråd med gjeldende (og framtidig) ODF-standard. Den er forutsigelig og enkel å implementere for andre (som sagt mange ganger: OO.org har allerede implementert den løsninger for filer som er lagret i standard Office 2007-format). Er feilen at de ikke har valgt den løsningen som passer IBM best?

[Nordmoen]

As I don’t have a computer with Windows and I don’t have MS Office 2007 to test, I did some tests with SP2 trough the exchange documents with friends who have Office 2007 with SP2 installed and here are my 2 cents for all the tests that are appearing (and being published every second on the Internet):

 

Microsoft Office 2007 does not support encryption (password protection) in ODF documents !

 

I generated a simple text document (.odt) in ODF using OpenOffice and saved it with password protection. I sent the document (and password) to several friends and the result was the same: MS Office cannot open the document because it is password protected (some of those friends also have installed on their computers other tools that support ODF and on 100% of those tools it worked).

 

I also asked them to generate a document in Office 2007 with password protection and send me, but they said that when trying to do this, MSOffice presented a warning message saying that you cannot use password protection using the ODF format.

 

I would really like to find a good technical explanation for this, since the encryption and password protection are fully specified in ODF 1.0/1.1 (item 17.3 of the specification), and they are using existing algorithms, very familiar to any developer.

 

Kilde

Endret 9. mai 2009 av Nordmoen

[kjeklulf]

Forsåvidt interessant men et par problemer her:

 

Det er riktig at Office 2007 ikke kan åpne en passordbeskyttet fil laget med OO.org 3.0 (både i ODF 1.0/1.1 og 1.2-format). Man får den feilmeldingen som er beskrevet over. Samtidig: disse filene er ikke gyldige ODF-filer i følge validatoren som ligger her:

 

http://opendocumentfellowship.com/validator

 

Det er dermed usikkert om problemet ligger i MS Office eller i OO.org.

 

Edit: Dette avsnittet er delvis feil:

 

Det går fint å lagre et passordbeskyttet Word-dokument i MS Word 2007 og lagre det i ODF-format, i motsetning til det som står i sitatet over. Denne filen er gyldig ODF i følge validatoren og OO.org åpner den helt fint, bortsett fra at den hopper over hele passordet og åpner filen direkte. Snodig nok åpner også MS Word 2007 filen direkte, uten spørsmål om passord.

 

Testet en gang til. Hvis man først lagrer som ODF, setter inn passord og lagrer på nytt med samme navn fjernes passordet uten at man får noen advarsel. Hvis man først setter inn passordet og så lagrer får man beskjed om at passordet vil bli fjernet, som beskrevet i linken over. Denne delen av implementasjonen er åpenbart ikke god nok.

 

Edit 2:

 

Det kan jo være på sin plass å sitere en av kommentarene i bloggen du linker til. Kommentaren er skrevet av Orcmid som er nick for Dennis Hammilton som sitter som individuelt medlem i OpenDocument TC i Oasis (og ikke er tilknyttet noen av de store korporasjonene):

 

Jomar, I respectfully disagree with you about 17.3 (http://wiki.oasis-open.org/oic/SpecAnalysis/1.1/17/17.3). As far as I can tell, there is insufficient information to implement ODF Package Encryption without looking at the OpenOffice.org implementation. There is no way to know what the tricks are from the specification.

 

Note that the sample manifest (http://wiki.oasis-open.org/oic/SpecAnalysis/1.1/17/17.7/sample) doesn’t even honor the schema, omitting the required checksum and checksum name attribute values for password hashes. Also, actually putting the checksum in the file — as OO.o does — appears to be a security exposure if implemented the way 17.3 and 17.7.4-17.7.6 read (http://wiki.oasis-open.org/oic/SpecAnalysis/1.1/17/17.7/17.7.4), but that is a longer story and apparently not exactly what OO.o does anyhow.)

Endret 9. mai 2009 av kjeklulf

[abcd423417984]

Man kan også vente på en helt ferdig spesifikasjon før man lager støtte for den, men da får man ikke testet de ulike delene i praksis.

 

Jo, det er akkurat det man bør. Ellers ender man opp med 802.11n draft og ecmascript 4 tilstander hvor alt arbeidet plutselig går i dass fordi draftet til standarden blir endret eller forkastet.

 

Det eksisterer nok eksempler på hvorfor det å implementere en uferdig standard er en jævla dårlig idè.

[Nordmoen]

Kommer ikke inn på opendocument validator siden :S

 

Edit:

Prøvde OpenOffice.org sin validator (her)

 

Med "Strict Validation" ODF 1.0/1.1 får jeg:

This file is NOT valid

 

Result details:

upload:///Test test.odt/meta.xml[2,865]:Error:unexpected attribute "meta:non-whitespace-character-count"

upload:///Test test.odt:Info:validation errors found

upload:///Test test.odt:Info:Generator: MicrosoftOffice/12.0 MicrosoftWord

 

Har ikke OO.org på denne pc-en men hvis de har like god støtte som Google så får du ikke feil med "Strict Validation".

 

Ellers så er filen valid(sånn til Ms sitt forsvar)

Endret 9. mai 2009 av Nordmoen

[G]

Grei beskjed i artikkel, men dette kommer nok ikke som noen stor overraskelse for de fleste av oss som leser HW.no jevnlig.

[nercix]

Man kan også vente på en helt ferdig spesifikasjon før man lager støtte for den, men da får man ikke testet de ulike delene i praksis.

 

Jo, det er akkurat det man bør. Ellers ender man opp med 802.11n draft og ecmascript 4 tilstander hvor alt arbeidet plutselig går i dass fordi draftet til standarden blir endret eller forkastet.

 

Det eksisterer nok eksempler på hvorfor det å implementere en uferdig standard er en jævla dårlig idè.

802.11n endte jo opp bra. Ecmascript er slik det er fordi ECMA har gjort ein dårleg jobb. OASIS må gjerne få kritikk for den standaren de har laget (eller stor grad fekk frå Sun). Den manglar elementær funksjonalitet når det gjeld rekneark, og manglar sikkert også noko funksjonalitet andre stadar. Microsoft har ikkje hatt nokon god tilnærming til heile standaren, og har historisk sett vanskeleg for å gjere. Når ein implementerer eit filformat bør ein etterstrebe kompatibilitet med andre som nyttar dette filformatet. Dette burde ikkje vere vanskeleg, då mange implementasjonar av standaren har open kjeldekode.

 

Elles vonar eg at Microsoft har klart å legge til ei saftig feilmelding når brukaren prøvar å lagre noko som .ods...

Endret 10. mai 2009 av nercix

[dizx]

Når ein implementerer eit filformat bør ein etterstrebe kompatibilitet med andre som nyttar dette filformatet. Dette burde ikkje vere vanskeleg, då mange implementasjonar av standaren har open kjeldekode.

 

Elles vonar eg at Microsoft har klart å legge til ei saftig feilmelding når brukaren prøvar å lagre noko som .ods...

 

Det her er en så latterlig diskusjon. Diskusjonen eksiterer ene og alene forde den har noe med Microsoft og gjøre. MS har tilpasset seg dagens konkurransesituasjon. Bare for noen få år siden var det propretiære doc formater som gjaldt. Disse spesifikasjonene er idag helt åpne, og hvem som helst kan lage sin egen implementasjon.

 

Saken koker ned til:

• - ODF 1.1 har ikke støtte for formler
  - ODF 1.2 er ikke ferdig
  - ODF 1.1 har støtte for egne namespaces
  - MS Office 2007 sp2 ODS benytter en dokumentert åpen standard for og legge inn formler; MsOxl
  - OpenOffice benytter allerde denne åpne standarden (MsOxl) for og åpne XLSX filer idag.
  - I neste versjon av OpenOffice kommer de til og støtte og åpne ODS fra MS Office som har formler i MsOxl format, da de allerede har laget implementasjon for dette
  - Andre kan og implementere MsOxl da dette er åpen standard
  - MS kommer til og støtte ODF 1.2 når standarden blir ferdig
  

Der utrolig hvordan enkelte ser ut til og miste gangsynet helt når det dreier seg om Microsoft