Gå til innhold

Anbefaler Open XML fremfor ODF


Anbefalte innlegg

Kan godt hende jeg klarer skaffe kilden til alle likningene, altså før de ble bilder. Jeg vet ærlig talt ikke hva de forskjellige har brukt, men det kan jeg jo spore opp. Så vhis du får latex eksemplene jeg linket deg over på word sitt standrard likningsformat (den standardeditoren bruker), så ville det vært en god start, jeg er egentlig mer opptatt av enhetlig formatering enn at det skal se bra ut.

Hva slags nummerering er det du snakker om her egentlig? Og hva er det som gjøre at man "fort ender opp med at likninger nummereres forskjellig"?
Når de opptrer som forskjellige objekter, er det fort gjort at nummereringen blir uavhengig.
Lenke til kommentar
Videoannonse
Annonse
Gjest Slettet-Pqy3rC

Til "Kjekulf" og "Del"

Gratulerer med en morsom diskusjon om tekstbehandleres fortreffelighet (eller det motsatte...). Det meste har vel egentlig lite med et åpent filformat og gjøre, selv om en kan se nytten av dette ved at prosesser utenom tekstbehandlerne kunne ha hjulpet redigering om formatet hadde vært åpent.

Som et apropos til diskusjonen har jeg en gang vært ansvarlig for en manual på ca 1400 sider, skrevet som deldokumenter av ulike forfattere i MS Word. Jobben med å prøve å holde felles stiler ved hjelp av et hoveddokument på noe sånt er forferdelig. Det er fullt mulig at min kunnskap er for liten og at dette skapte problemer, erfaringen var i alllefall at word dokumenter er fast bestemt på å leve sitt eget liv - uavhengig av hva som befinner seg i "hoved dokumentet".

 

Nåvel, mitt syn på årsaken til MS sin OOXML strategi;

 

Jeg kan bare se én grunn til OOXML: De vil tåkelegge hva MS Office produserer ved hjelp av sitt eget OOXML format. Dette fører at de lettere fortsatt kan beskytte sitt eget produkt ved hjelp av allerede oppnådde markedsandeler, noe som hadde vært langt vanskeligere med et ODF samarbeid. Målet er at kun MS Office kan bearbeide MS Office produserte dokumenter, noe som gir en grei måte å beholde markedet på. MS slipper konkurranse om å lage det beste produktet så lenge folk må kjøpe MS Office "fordi andre bruker det".

Dette er en klar indikasjon på at MS kun er ute etter å tviholde på sin markedsposisjon og dermed ikke har noen interesse av å beholde sin markedsposisjon på grunn av at de leverer et bedre produkt enn andre.

 

OOXML er en strategisk løsning for MS som selskap og ikke et steg i riktig retning for forbrukerene.

Lenke til kommentar

Angående hoved- og deldokumenter: Den funksjonen bør aldri brukes. Det er en sikker måte å ødelegge dokumenter på og slikt arbeid bør heller gjøres med et skikkelig mal-grunnlag.

 

Angående OOXML: Jeg er, overraskende nok, ikke enig med deg. OOXML-spesifikasjonen vil bli overlatt ISO (om den blir godkjent som standard) og MS vil ikke senere kunne "gjøre det om" til et nytt proprietært format. Det er ikke slik ISO fungerer. Selv om vedlikeholdet av spesifikasjonen vil gå til ECMA skal alle endringer godkjennes i ISO og du kan banne på at de vil følge godt med.

 

Det er klart MS ønsker å holde på sin markedsposisjon, noe annet ville vært rart. Jeg tror imidlertid de har skjønt at tiden for lukkede dokumentformater er over og at de har forstått at de ikke har noe valg. Hadde de hatt det ville de ikke hatt noen grunn til å gå igjennom denne prosessen med å skifte filformater. Nettopp ved å åpne opp formatet kan de konkurrere på produkt og ikke på format og det vil de bli nødt til å gjøre.

 

OOXML er en strategisk løsning for MS som selskap. Om det er et steg i riktig retning for forbrukerne vil tiden vise. OOXML vil uansett være noe man på et eller annet nivå må forholde seg til i årene som kommer.

Lenke til kommentar
Angående OOXML: Jeg er, overraskende nok, ikke enig med deg. OOXML-spesifikasjonen vil bli overlatt ISO (om den blir godkjent som standard) og MS vil ikke senere kunne "gjøre det om" til et nytt proprietært format. Det er ikke slik ISO fungerer. Selv om vedlikeholdet av spesifikasjonen vil gå til ECMA skal alle endringer godkjennes i ISO og du kan banne på at de vil følge godt med.

Akkurat som de fleste OOXML-fans er du raskt ute for å påpeke at videreutvikling skal skje oss "uavhengige" ECMA, ok, viss vi nå for diskusjonens skyld tar ECMA sin uavheninghet for god fisk, så sitter vi allikevel igjen med et aldri så lite problem:

Microsoft har så godt som avvist at det blir aktuelt å gjøre endringer i MS Office sitt MS-OOXML format for å være kompatibel med endringer som ECMA/ISO gjør i OOXML, og det trengs ikke noe geni for å skjønne at MS Office sitt MS-OOXML format vil bli "defacto"-versjonen av "OOXML", selv om den ikke er kompatibel med en eventuell OOXML ISO-standard.

 

Det er klart MS ønsker å holde på sin markedsposisjon, noe annet ville vært rart. Jeg tror imidlertid de har skjønt at tiden for lukkede dokumentformater er over og at de har forstått at de ikke har noe valg.

Ja og nei. Ja de har forstått at markedet ønsker seg bort fra det format-helvete som MS har presset frem i årevis nå, ja MS er et selskap som tjener fantasi-beløper på sin tilnærmede monopol-situasjon, men nei de har ikke forstått at de ikke har noe valg, derimot har de funnet fram til en perfekt mellomting, så de fortsatt kan kontrollere "lockin-faktoren" i MS Office sine formater og forsinke interoptabiliteten som ODF ville medført samtidig som de kan rope høyt om dette fantastiske ÅPNE formatet de skal sende til ISO-godkjenning (men som de ikke engang bruker selv) og fremstå som åpne oss de mange utvitende rundt i verden.

Det var jaggu tre fluer i en smekk det, ikke rart Ballmer har sånt et fett glis.

 

At du i det hele tatt kan påstå noe sånt som at MS aldri kunne "gjøre om formatet" viser bare din egen uvitenhet og ignoranse.

Embrace, extend and extinguish er en velkjent MS-strategi for nettopp å undergrave definerte standarder, og her snakker vi tilogmed om et format hvor MS selv er den eneste betydelige pådriveren - barnemat for EEE!

Denne artikkelen inneholder en del utdrag fra MS sin strategi rundt åpne standarder, se også min personlige "favoritt", denne interne e-posten fra Bill Gates himself. Se vedlegg.

Å tro at et sånt selskap er egnet til selv å utvikle et *åpent* format er i beste fall naivt.

PX02991.pdf

Lenke til kommentar
Gjest Slettet-Pqy3rC
Angående hoved- og deldokumenter: Den funksjonen bør aldri brukes. Det er en sikker måte å ødelegge dokumenter på og slikt arbeid bør heller gjøres med et skikkelig mal-grunnlag.

He, he - Det hadde jeg ingen forutsetning for å vite den gangen dette arbeidet ble gjort. Såvidt jeg husker endte det hele opp med at jeg i sene nattetimer henta alt inn i et dokument og formaterte om side for side... Man lærer så lenge man lever.

Note; Dog litt sløvt av MS å ha en funksjon i systemet som virker så usedvanlig dårlig, bedre om de hadde droppa hele greia.

 

Det er klart MS ønsker å holde på sin markedsposisjon, noe annet ville vært rart. Jeg tror imidlertid de har skjønt at tiden for lukkede dokumentformater er over og at de har forstått at de ikke har noe valg.

Jeg er forsåvidt enig med deg i dette, men jeg tror at dersom MS virkelig ville ha et "åpent format" hadde et samarbeid med andre (altså ODF) vært det beste for alle parter (samt fullt mulig å få til).

Ved å lansere sitt eget format (OOXML) antar jeg at MS har en "skjult agenda" om å beskytte seg selv, jeg finner dessverre ingen annen vektig grunn som skulle hindre MS i å bli med i ODF samarbeidet.

Lenke til kommentar

Det er mange som har anbefalt at den funksjonen fjernes. Har ikke sjekket om den fortsatt er der i 2007 men unngå den for all del:

 

http://word.mvps.org/FAQs/General/WhyMasterDocsCorrupt.htm

 

Når det gjelder OOXML som format er det selvsagt snakk om både teknikk og politikk. Det var umulig for MS politisk å gå inn å arbeide sammen med SUN og IBM om ODF den gang det arbeidet startet. MS hadde jo startet arbeidet med sine XML-baserte formater og ville ha et format som var best mulig tilpasset sine eksisterende formater. På samme måte takket IBM nei til å sitte i TC45 som er den komiteen i ECMA som har ansvaret for OOXML.

 

Vi snakker om tre av verdens største IT-selskaper her og det jeg reagerer mest på er troen på at SUN og IBM er de som bare vil folkets beste. MS vil ikke ha mer kontroll over OOXML enn det SUN og IBM har over ODF.

Lenke til kommentar
Akkurat som de fleste OOXML-fans er du raskt ute for å påpeke at videreutvikling skal skje oss "uavhengige" ECMA, ok, viss vi nå for diskusjonens skyld tar ECMA sin uavheninghet for god fisk, så sitter vi allikevel igjen med et aldri så lite problem:

Microsoft har så godt som avvist at det blir aktuelt å gjøre endringer i MS Office sitt MS-OOXML format for å være kompatibel med endringer som ECMA/ISO gjør i OOXML, og det trengs ikke noe geni for å skjønne at MS Office sitt MS-OOXML format vil bli "defacto"-versjonen av "OOXML", selv om den ikke er kompatibel med en eventuell OOXML ISO-standard.

 

For det første: Jeg er ikke mer "fan" av OOXML enn av ODF. Jeg mener begge formatene har noe for seg og at forskjellene er såpass store at de bør kunne aksepteres som standarder begge to. Dessuten: Ved å overlate ansvaret for standarden til ISO har man større innsyn og transparens enn om MS skulle fortsette med sine binære formater.

 

For det andre: Jeg har hørt mange snakke om det såkalte MSOOXML-formatet men ennå ikke sett en eneste kilde på at det finnes elementer i standardformatet i Office 2007 som ikke er spesifisert i forslaget fra ECMA. Har du noen linker til noen faktiske forskjeller tar jeg det i mot med takk.

 

For det tredje: Hvor har MS avvist at det blir aktuelt å endre noe i sine standardformater etter forslagene fra ECMA/ISO? Det MS har sagt er at utviklingen er overlatt ISO og at de naturlig nok ikke kan gi noen garantier for all fremtid. Det kommer an på hva ISO/ECMA gjør med formatet. Det er stor forskjell på "ikke aktuelt" og "kan ikke garantere for all fremtid".

 

For det fjerde: Det er opp til ISO hvem som skal ta ansvaret for videreutvikling av OOXML hvis det blir en godkjent standard. ECMA har foreslått at de skal ta dette ansvaret og det er akkurat på samme måte som ISO har overlatt ansvaret for ODF til Oasis OD TC (med Sun og IBM i hvert sitt førersete). Sun har jo til og med tatt forbehold om sine patenter i ODF hvor de fraskriver seg alle patenter knyttet til ODF så lenge de selv er med i utarbeidelsen.

 

Ja og nei. Ja de har forstått at markedet ønsker seg bort fra det format-helvete som MS har presset frem i årevis nå, ja MS er et selskap som tjener fantasi-beløper på sin tilnærmede monopol-situasjon, men nei de har ikke forstått at de ikke har noe valg, derimot har de funnet fram til en perfekt mellomting, så de fortsatt kan kontrollere "lockin-faktoren" i MS Office sine formater og forsinke interoptabiliteten som ODF ville medført samtidig som de kan rope høyt om dette fantastiske ÅPNE formatet de skal sende til ISO-godkjenning (men som de ikke engang bruker selv) og fremstå som åpne oss de mange utvitende rundt i verden.

 

Her var det mye som ikke hang på greip. Hvor er denne lock-in faktoren du snakker om? Hvor er dokumentasjonen på at de ikke bruker dette formatet selv? Hvis du har fulgt litt med i debatten vil du se at de norske innsigelsene i stor grad er imøtekommet og at alle referanser til de tidligere binæreformatene nå er dokumentert i standarden for kompatibilitetshensyn ved konvertering fra gamle dokumenter. De brukes ikke i nye dokumenter som skal følge forslaget til OOXML-standard.

 

At du i det hele tatt kan påstå noe sånt som at MS aldri kunne "gjøre om formatet" viser bare din egen uvitenhet og ignoranse.

 

Det er en velkjent teknikk å lese halve setninger og plukke ut enkeltdeler for å sverte den man er uenig med. Det er samtidig like uredelig og det blir ikke sant selv om du skriver det. Jeg har aldri sagt at ikke MS (og ISO og ECMA) kan gjøre om på formatet. Det jeg har sagt er at MS ikke kan gjøre om dette formatet (om det blir godkjent som ISO-standard) til et proprietært format som kun de har spesifikasjonene til eller rettighetene til. Det er ikke sånn ISO-standarder fungerer. Hvis du tror det er mulig har du skjønt lite av hva standardiseringsarbeid og ISO faktisk innebærer.

Lenke til kommentar
At du i det hele tatt kan påstå noe sånt som at MS aldri kunne "gjøre om formatet" viser bare din egen uvitenhet og ignoranse.

 

Jeg har aldri sagt at ikke MS (og ISO og ECMA) kan gjøre om på formatet.

Skjønte du ikke hva jeg mente med "gjøre om formatet"? Du skrev: <quote>MS vil ikke senere kunne "gjøre det om" til et nytt proprietært format. Det er ikke slik ISO fungerer</quote>

Altså er det ikke snakk om en naturlig videreutvikling jeg sier at du har benektet, men en undergraving av åpenheten i formatet, altså noe ala en Embrace, extend and extinguish-operasjon. Det er noe vi har sett MS gjennomføre flere ganger tidligere, dette har lite med ECMA/ISO, bare om Microsoft sine forretnings-metoder og din påstand om at MS ikke ville kunne undergrave den åpenheten som måtte eksistere i OOXML, men det er ikke OOXML-spesifikt, EEE-taktikk kan de like gjerne bruke mot ODF, noe som kan vise seg å bli høyst aktuelt.

 

Hele svaret ditt er egentlig så fullt av misforståelser, over-forenkling, svada og ignoreringer at jeg like gjerne kunne sitert mitt opprinnelige innlegg som svar på ditt svar, men jeg vil vertfall oppklare de to gode bemerkningene du kommer med:

 

Hvor er dokumentasjonen på at de ikke bruker dette formatet selv?

http://www.ecma-international.org/news/TC4...%20complete.htm

Kortversjonen er at alle endringer ECMA har gjort etter at Microsoft sendte inn formatet, er forskjeller mellom MS-OOXML og ECMA-OOXML.

Microsoft utviklet OOXML, de implementerte det i MS Office, så sendte de det til ECMA for godkjenning. Og etter at MS Office 2007 ble lansert har ikke Microsoft endret sin implementering.

Selv om du neppe fattet omfanget av det du skrev kan jeg jo bruke deg også som kilde:

Hvis du har fulgt litt med i debatten vil du se at de norske innsigelsene i stor grad er imøtekommet

Ja riktig, ECMA har gjort *endringer* i spesifikasjonen, Microsoft har *ikke* oppdatert sine egne implementeringer til å følge endringene.

I *tillegg* så er det sånn at MS Office benytter seg av diverse funksjonalitet som ikke er dokumentert i noen OOXML-spesifikasjon, dette dreier seg om diverse binærobjekter, makroer, DRM-mekanismer, ActiveX-serialisering, OLE-objekter og SharePoint metadata.

 

Det MS har sagt er at utviklingen er overlatt ISO og at de naturlig nok ikke kan gi noen garantier for all fremtid. Det kommer an på hva ISO/ECMA gjør med formatet. Det er stor forskjell på "ikke aktuelt" og "kan ikke garantere for all fremtid".

Selvfølgelig har ikke MS avvist det for all fremtid, men i det øyeblikk MS Office 2007 ble sendt ut i markedet stengte i praksis MS av muligheten for å rette seg etter endringer, siden det bra sikkert ville skapt masse problemer for brukerne.

Det viktigste er nå dog motivasjonen, og MS har neppe noen som helst motivasjon for å rette seg etter endringene, her kan jeg henvise til min beskrivelse av MS sin strategi rundt åpne standarder, du siterte den ikke, men den ligger i slutten av det forrige innlegget mitt, viss du skulle ha oversett den...

Viss du mener at den beskrivelsen er helt på jordet kan vi like gjerne stoppe denne debatten øyeblikkelig, for da er det langt mer grunnleggende oppfatninger vi må diskutere før de "politiske" aspektene rundt "standarden OOXML".

 

Angående det du skriver om patenter og styring har jeg dette å si:

- Alt rundt OpenDocument Format er ikke perfekt.

- Begge formennene i ECMA sin "Technical Committee" for OOXML er ansatt i Microsoft.

http://www.ecma-international.org/memento/TC45.htm

- Les: http://www.noooxml.org/patents

 

Det er en velkjent teknikk å lese halve setninger og plukke ut enkeltdeler for å sverte den man er uenig med. Det er samtidig like uredelig og det blir ikke sant selv om du skriver det.

Ikke "fordi jeg skriver det", men fordi fakta viser det. Er du uenig i det så får du heller presisere uriktighetene, jeg utelukker ikke upresise formuleringer.

Nå må du gjerne opplyse meg om hvilke deler av innlegget ditt jeg "halverte".

Lenke til kommentar
Skjønte du ikke hva jeg mente med "gjøre om formatet"? Du skrev: <quote>MS vil ikke senere kunne "gjøre det om" til et nytt proprietært format. Det er ikke slik ISO fungerer</quote>

Altså er det ikke snakk om en naturlig videreutvikling jeg sier at du har benektet, men en undergraving av åpenheten i formatet, altså noe ala en Embrace, extend and extinguish-operasjon. Det er noe vi har sett MS gjennomføre flere ganger tidligere, dette har lite med ECMA/ISO, bare om Microsoft sine forretnings-metoder og din påstand om at MS ikke ville kunne undergrave den åpenheten som måtte eksistere i OOXML, men det er ikke OOXML-spesifikt, EEE-taktikk kan de like gjerne bruke mot ODF, noe som kan vise seg å bli høyst aktuelt.

 

Hvordan skal MS kunne gjøre om OOXML til et lukket format når det er under ISO sin kontroll? Har du satt deg noe som helst inn i hvordan ISO fungerer? Er du klar over hva som kreves at et format for at det skal være godkjent i ISO? Er du klar over at en hver teknisk endring i OOXML (etter en eventuell godkjenning) må opp til avstemning på akkurat samme måte som for å få godkjent standarden?

 

I så måte er jeg mer bekymret over SUN som har frasagt seg sine patent-rettigheteter til elementer i ODF så lenge de selv er med å utvikle standarden. Det betyr at hvis SUN trekker seg ut av OD TC i Oasis vil all videreutvikling av ODF kunne blokkeres.

 

Dine dommedagsprofetier lar seg altså ikke gjennomføre. Men: Det er jo enklere å komme med noen løse påstander man har plukket opp et eller annet sted enn å sette seg inn i hvilke regler som faktisk gjelder og hva som er fakta.

 

http://www.ecma-international.org/news/TC4...%20complete.htm

Kortversjonen er at alle endringer ECMA har gjort etter at Microsoft sendte inn formatet, er forskjeller mellom MS-OOXML og ECMA-OOXML. Microsoft utviklet OOXML, de implementerte det i MS Office, så sendte de det til ECMA for godkjenning. Og etter at MS Office 2007 ble lansert har ikke Microsoft endret sin implementering. Selv om du neppe fattet omfanget av det du skrev kan jeg jo bruke deg også som kilde:

Hvis du har fulgt litt med i debatten vil du se at de norske innsigelsene i stor grad er imøtekommet

Ja riktig, ECMA har gjort *endringer* i spesifikasjonen, Microsoft har *ikke* oppdatert sine egne implementeringer til å følge endringene.

 

ECMA har ikke gjort en eneste endring i formatet. De har kommet med et forslag til ISO om endringer i formatet. Det er fortsatt det opprinnelige OOXML-forslaget som er gjeldende ECMA-standard helt til ISO eventuelt godkjenner endringene gjennom BRM i slutten av februar. Det er altså ikke opp til ECMA men til ISO. Etter at BRM eventuelt godkjenner eller avviser endringene vil det blir en fire ukers periode hvor de ulike NB får tid til å sette seg inn i endringsforslaget og vurdere om de skal endre sin stemmegiving. Først da vil det eventuelt bli et nytt OOXML-format.

 

I tillegg: det er svært få endringer i selve formatet av de kommentarene som har kommet inn til ECMA. Det er drøyt 1000 unike kommentarer og av disse var langt de fleste mangler ved spesifikasjonen og ikke endringer i selve formatet. Med det menes at de fleste kommentarene gikk på at enkelte funksjoner var underdokumentert, at eksempler var uklare, at spesifikasjonen burde deles opp, tydeliggjøring av hva som skal brukes osv. Det er altså pr i dag ikke noe forskjell i det formatet som er gjeldene standard fra ECMA og det Office 2007 bruker som lagringsformat.

 

Når en eventuelt endret standard blir gjeldende kan formatovergangen løses på flere måter, og dette er jo ikke noe annerledes enn det gjøres med for eksempel OpenOffice og ODF. OpenOffice lagrer nå som standard i ODF 1.1 som ikke er gjeldende standard i ISO. Skal du lagre i gjeldende ISO-standard må du velge det spesielt. I MS Office kan overgangen løses enten på samme måte eller ved hjelp av en enkel update til Office. Jeg regner med at det siste er mest aktuelt.

 

I *tillegg* så er det sånn at MS Office benytter seg av diverse funksjonalitet som ikke er dokumentert i noen OOXML-spesifikasjon, dette dreier seg om diverse binærobjekter, makroer, DRM-mekanismer, ActiveX-serialisering, OLE-objekter og SharePoint metadata.

 

Dette avslører vel at du bare refererer til noe du har lest på en nettside og ikke satt deg inn i spesifikasjonen. Det er mange referanser til både OLE-objekter og ActiveX-objekter i spesifikasjonen. Dette er eksempler på bruk av ulike objekttyper, akkurat på samme måte som ODF gjør det. Hvis du leser i ODF-spesifikasjonen vil du finne referanser til OLE-objekter der også.

 

Ellers har jeg jo bedt deg om dokumentasjon på at det er noe forskjell i MS-OOXML som du kaller det og gjeldende ECMA-OOXML. Det ser jeg at du fortsatt ikke har klart å finne fram.

 

Selvfølgelig har ikke MS avvist det for all fremtid, men i det øyeblikk MS Office 2007 ble sendt ut i markedet stengte i praksis MS av muligheten for å rette seg etter endringer, siden det bra sikkert ville skapt masse problemer for brukerne.

 

Hvor i all verden får du dette fra? Som sagt tidligere: De endringene som er i selve formatet er svært få. Konvertering av disse funksjonene lar seg enkelt løse med en update til Office. Hvis du synes slike endringer skaper "masse problemer for brukerne", hva da med OpenOffice som lagrer i en standard som ikke er gjeldende ISO-standard? Lager ikke dette "masse problemer for brukerne"? OpenOffice har da klart å gjøre masse endringer de, selv om de er i akkurat samme situasjon?

 

Det viktigste er nå dog motivasjonen, og MS har neppe noen som helst motivasjon for å rette seg etter endringene, her kan jeg henvise til min beskrivelse av MS sin strategi rundt åpne standarder, du siterte den ikke, men den ligger i slutten av det forrige innlegget mitt, viss du skulle ha oversett den... Viss du mener at den beskrivelsen er helt på jordet kan vi like gjerne stoppe denne debatten øyeblikkelig, for da er det langt mer grunnleggende oppfatninger vi må diskutere før de "politiske" aspektene rundt "standarden OOXML".

 

Hvorfor skulle ikke MS oppdatere Office 2007 til å gjenspeile de endringene som eventuelt gjøres i OOXML? Hvorfor i all verden skulle de bruke enorme summer på å utvikle OOXML hvis de ikke skal bruke det? MS har utviklet OOXML fordi de har skjønt at tiden for lukkede dokumentformater er over. Fordi svært mange etterhvert har krevd at offentlig informasjon skal være tilgjengelig for alle, uansett system. De har rettet seg etter markedets ønsker og krav, fordi det er det eneste lure i 2008.

 

I 1998 (da den e-posten du siterer ble skrevet) var situasjonen en helt annen. Verden har gått fremover og MS følger etter. Om det er fordi de ønsker det eller ikke har noe valg er forsåvidt ikke veldig interessant spør du meg. Det at du må sitere 10 år gamle e-poster for å få frem et billig poeng viser vel at du ikke har fått med deg særlig mye av hva som har skjedd i software-verden de siste 10 årene, og at du bare skyter med løskrutt.

 

Angående det du skriver om patenter og styring har jeg dette å si:

- Alt rundt OpenDocument Format er ikke perfekt.

- Begge formennene i ECMA sin "Technical Committee" for OOXML er ansatt i Microsoft.

http://www.ecma-international.org/memento/TC45.htm

- Les: http://www.noooxml.org/patents

Begge lederne for Oasis OD TC er ansatt i henholdsvis Sun og IBM, og hva så?

 

ISO har svært klare og tydelige regler for patenter når det gjelder standarder de godkjenner. ISO har selv uttalt at det ikke er noe i OOXML som bryter med de reglene ISO har:

 

IPR decisions have previously been delegated by all the ISO and IEC members (NBs) to the CEOs of IEC and ISO, and they in turn have examined them and found no outstanding problems.

 

Alex Brown er leder for JTC1/SC34 i ISO og er den som vil ha ansvaret for gjennomføringen av BRM i slutten av februar. Ingen standard blir godkjent i ISO om den ikke følger ISO sine regler. Igjen: Dette viser at du har svært manglende forståelse for hvordan ISO fungerer.

 

Ikke "fordi jeg skriver det", men fordi fakta viser det. Er du uenig i det så får du heller presisere uriktighetene, jeg utelukker ikke upresise formuleringer.

Nå må du gjerne opplyse meg om hvilke deler av innlegget ditt jeg "halverte".

 

Det var akkurat det jeg viste deg. Du hevder jeg har påstått at "MS aldri vil kunne gjøre om formatet". Det har jeg aldri påstått. Jeg får bare gjenta det jeg skrev i forrige innlegg:

 

Det jeg har sagt er at MS ikke kan gjøre om dette formatet (om det blir godkjent som ISO-standard) til et proprietært format som kun de har spesifikasjonene til eller rettighetene til. Det er ikke sånn ISO-standarder fungerer. Hvis du tror det er mulig har du skjønt lite av hva standardiseringsarbeid og ISO faktisk innebærer. Det er ISO som har rettighetene til OOXML i det øyeblikk den eventuelt blir godkjent.

 

I tillegg, som nevnt over: Alle tekniske endringer i en eventuelt godkjent OOXML må godkjennes på nytt av de ulike NB i ISO, på akkurat samme måte som under en vanlig godkjenning av en standard.

Endret av kjeklulf
Lenke til kommentar

@kjeklulf:

 

Du skal få et område hvor ikke MS OOXML følger Ecma OOXML. I ECMA OOXML er det flere plasser referert til å bevare "formatteringen" av gamle dokumenter. At dette ikke burde vært i standarden, men i en egen standard knyttet til konvertering skal ikke nevnes mer her. Men til saken. ECMA OOXML sier f.eks.

 

ECMA Open Office XML document say “2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full Width Character Spacing)”

 

Om man skulle åpne et Word 95 dokument og lagre det i MS OOXML vil man få beskjed om at deler av formatteringen ikke støttes. Samme skjer i Excel som Rob Weir peker på. Hva det skyldes er skal jeg ikke spekulere i, enten ikke komplett implementering eller ikke implementert etter standard.

 

Dokumentet her kan være verdt å lese, selv om det klart representerer et bestemt syn.

 

Jeg kan ikke på stående fot gi deg flere, men jeg vet at personer som har lagret MS OOXML dokumenter, åpnet disse og redigert de i henhold til ECMA OOXML ikke har klart å åpne dokumentet i Office 2007 etterpå. Ja jeg har ennå ikke klart å finne noen som har klart det. Igjen vet jeg ikke om det skyldes "feil" implementering eller at angjeldende funksjonalitet ikke var støttet i MS OOXML implementeringen.

 

Når det gjelder synspunktet at OOXML formatet ikke må endres for å ivareta innvendingene, er det avhengig av hva man mener med format. Forhold knyttet til datorepresentasjon, språk, nasjonalitet, "namespace" med mer, vil etter min mening klart medføre endringer i formatet.

 

Grokdoc's liste over problemstillinger/mangler ved ECMA OOXML viser at mye her er formatrelatert. Det er mange av de samme som er påpekt i merknadene til ECMA OOXML. Jeg er fullt ut klar over at Groklaw hoder til på ene siden av gjerdet, men det er faktaene som er interessante. Og personer på andre siden sier jo intet om sine mangler.

 

Når det gjelder vedlikeholdsprosessen, synes jeg følgende sitat fra Groklaw og Rob Weir gir grunn til ettertanke.

Rob Weir has discovered something so awful about the maintenance of MSOOXML, should it become an ISO standard, I wanted to make sure everyone knows about it, and then I have some projects to tell you about that are trying to respond to Microsoft's gaming of the ISO approval process.

 

In Weir's article, " Bait and Switch", he informs us that Microsoft is going back on public promises regarding control of the standard, should it be approved, promises which Ecma echoed [PDF]. You can't take your eyes off Microsoft for even a minute, can you?

 

Here's part of what Weir writes:

 

So much for the promises. What makes this story worthy of a blog post is that we now know that, as these promises were be made to NB's, at that same time Ecma was planning something that contradicted their public assurances. Ecma's "Proposal for a Joint Maintenance Plan" [pdf] outlines quite a different vision for how OOXML will be maintained.

 

A summary of the proposed terms:

 

* OOXML remains under Ecma (Microsoft) control under Ecma IPR policy.

* Ecma TC45 will accept a liaison from JTC1/SC34 who can participate on maintenance activities and only maintenance activities.

* Similarly, Ecma TC45 documents and email archives will be made available to the liaison (and through him a set of technical experts), but only the documents and emails related to maintenance.

* No mention of voting rights for the liaison or the experts, so I must assume that normal Ecma rules apply -- only Ecma members can vote.

* Future revisions of OOXML advance immediately to "Stage" 4" of the ISO process, essentially enshrining the idea that future versions will given fast-track treatment

 

A critical point to note is that "maintenance" in ISO terms is not the same as what the average software engineer thinks of as "maintenance". The work of producing new features or enhancements is not maintenance. The act of creating OOXML 1.1 or OOXML 2.0 is not maintenance. What is maintenance is the publication of errata documents for OOXML 1.0, a task that must be completed within 3 years.

 

Bait and switch indeed. Now, I'm a simple soul, so I could well be missing something, but it looks to me like at February's meeting, any unresolved technical issues can have Microsoft promising to fix the issue, hence winning approval, after which it, through, Ecma, controls how and when it is deemed "fixed", since voting is by rubber stamp Ecma.

 

Slik jeg oppfatter dette, betyr det at ISO sitt innsyn og kontroll over OOXML vil i stor grad bli illusorisk. Men som Groklaw og Weir, kan jeg også ha misset noe.

Lenke til kommentar
Du skal få et område hvor ikke MS OOXML følger Ecma OOXML. I ECMA OOXML er det flere plasser referert til å bevare "formatteringen" av gamle dokumenter. At dette ikke burde vært i standarden, men i en egen standard knyttet til konvertering skal ikke nevnes mer her.

 

Slike elementer må være i standarden fordi de sier noe om hvordan funksjoner i eldre binære dokumenter skal tolkes. I det opprinnelige forslaget fra ECMA var det tydelig spesifisert at disse elementene kun skulle brukes til konvertering (for forståelsen) og ikke til nye dokumenter som skulle følge OOXML. I det siste forslaget fra ECMA er alle slike funksjoner spesifisert direkte og ikke bare med henvisning til tidligere formater. De er også plassert i et anneks for utgåtte funksjoner.

 

Dette sier altså ingenting om at det er noe forskjell på det såkalte MS-OOXML og ECMA-OOXML.

 

Men til saken. ECMA OOXML sier f.eks.
ECMA Open Office XML document say “2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full Width Character Spacing)”

 

Om man skulle åpne et Word 95 dokument og lagre det i MS OOXML vil man få beskjed om at deler av formatteringen ikke støttes.

 

Samme skjer i Excel som Rob Weir peker på. Hva det skyldes er skal jeg ikke spekulere i, enten ikke komplett implementering eller ikke implementert etter standard.

 

For det første: Hva skiller dette fra ODF 1.0 som er gjeldende standard fra ISO og OpenOffice som lagrer i ODF 1.1?

 

For det andre: Dette er svart på mange ganger tidligere. Disse henvisningene er med for å sikre kompatibilitet med eldre dokumenter i binære formater og skal ikke brukes på nye dokumenter. De er også spesifisert tydelig i siste forslag fra ECMA.

 

For det tredje: Det Rob Weir påpeker har ikke noe med det såkalte MS-OOXML og ECMA-OOXML å gjøre. Det handler om at det opprinnelige forslaget fra ECMA ikke ivaretar 100 % alle funksjoner fra tidligere binære dokumenter. Så vidt jeg har sett har heller aldri ECMA eller MS sagt at det vil være en 100 % likhet ved konvertering fra de gamle formatene.

 

Dokumentet her kan være verdt å lese, selv om det klart representerer et bestemt syn.

 

Dette dokumentet bare gjentar de tingene jeg tidligere har vist til og som sagt er for eksempel autoSpaceLikeWord95 og liknende funksjoner nå grundig dokumentert i forslaget fra ECMA. Du kan lese mer om det her:

 

http://blogs.msdn.com/brian_jones/archive/...settings-1.aspx

 

Jeg kan ikke på stående fot gi deg flere, men jeg vet at personer som har lagret MS OOXML dokumenter, åpnet disse og redigert de i henhold til ECMA OOXML ikke har klart å åpne dokumentet i Office 2007 etterpå. Ja jeg har ennå ikke klart å finne noen som har klart det. Igjen vet jeg ikke om det skyldes "feil" implementering eller at angjeldende funksjonalitet ikke var støttet i MS OOXML implementeringen.

 

Jeg har også lest om mange som hevder dette men jeg har ennå ikke sett et eneste dokumentert tilfelle. Pekere mottas med takk.

 

Når det gjelder synspunktet at OOXML formatet ikke må endres for å ivareta innvendingene, er det avhengig av hva man mener med format. Forhold knyttet til datorepresentasjon, språk, nasjonalitet, "namespace" med mer, vil etter min mening klart medføre endringer i formatet.

 

Grokdoc's liste over problemstillinger/mangler ved ECMA OOXML viser at mye her er formatrelatert. Det er mange av de samme som er påpekt i merknadene til ECMA OOXML. Jeg er fullt ut klar over at Groklaw hoder til på ene siden av gjerdet, men det er faktaene som er interessante. Og personer på andre siden sier jo intet om sine mangler.

 

Jeg har da ikke sagt at formatet ikke må endres. Det jeg har sagt at det er svært få av endringene i det nye forslaget fra ECMA som handler om endringer i selve formatet. De aller fleste endringene går på helt andre ting, som vist til i mitt forrige innlegg. Hva som står på Grokdoc om det opprinnelige forslaget er lite interessant nå etter at ECMA har kommet med et nytt forslag som er oversendt alle NB i ISO. De skal nå i ro og mak vurdere dette fram til BRM i slutten av februar.

 

Når det gjelder vedlikeholdsprosessen, synes jeg følgende sitat fra Groklaw og Rob Weir gir grunn til ettertanke.
Snip...

 

Slik jeg oppfatter dette, betyr det at ISO sitt innsyn og kontroll over OOXML vil i stor grad bli illusorisk. Men som Groklaw og Weir, kan jeg også ha misset noe.

 

Dette har jeg også svart på tidligere. Dette er ikke noe annerledes for ECMA og OOXML enn det er for Oasis og ODF. ISO har ikke hatt noe med ODF 1.1 (som er Oasis sin gjeldende standard) eller ODF 1.2 (som Oasis arbeider med nå) å gjøre i det hele tatt. De har overlatt utviklingen til Oasis og eventuelle nye forslag må godkjennes på vanlig måte i ISO.

 

Her er forøvrig en replikk til Rob Weirs innlegg fra Brian Jones hos MS (for likevektens skyld):

 

http://blogs.msdn.com/brian_jones/archive/...-wants-war.aspx

Lenke til kommentar
Gjest Slettet-Pqy3rC
Jeg mener begge formatene har noe for seg og at forskjellene er såpass store at de bør kunne aksepteres som standarder begge to.

 

Her er vi monumentalt uenige.

 

Hvorfor i allverden er 2 (TO!) standarder for samme greia bra? Vi har ikke "en standard" med to ulike eh... måter å gjøre det på. Dersom OOXML blir antatt som ISO standard mener jeg at ODF må fjernes.

 

Det ekstra arbeidet (i timer) det vil ta for utviklere å følge opp 2 ulike spesifikasjoner i årene fremover er mer enn nok grunn til at MS/SUN/IBM (og hvem-som-helst) bør legge politiske hensyn til siden og gå inn for én standard. MS ville (av ukjente årsaker) ikke være med på toget (ODF) når det gikk.

 

Jeg mener det er svært skuffende av MS å prøve å true sin versjon igjennom istedenfor å bli med på samarbeidet om ODF. Det viser lite vilje overfor forbrukere og er respektløst ovenfor oss alle. Mitt inntrykk er at MS her ikke viser seg som noen lagspiller, men en egenrådig grinebiter som ønsker å gjøre ting vanskeligere for oss.

Lenke til kommentar

Det kan du selvsagt mene, og jeg forstår at det er ulike syn på det. På den annen side: Vi har en lang rekke standarder som delvis overlapper hverandre. Det gjelder for eksempel bildeformater (jpeg, gif, png, svg) og programmering (C, C++, C#, Prolog, Fortran, Cobol og flere andre). Ingen ville vel sagt man burde fjerne alle disse og erstattet det med en enkelt standard. Ulike, men delvis overlappende standarder for ulike behov. Det er helt naturlig og ofte svært fornuftig.

 

Når det gjelder prosessen i forbindelse med ODF så er det vel ingen andre enn de som selv deltok som kjenner alle sannheter om hvorfor det ble slik eller sånn. En ting jeg har sett hevdet (men ikke dokumentert) er at MS ønsket å utvide scopet for ODF slik at det også skulle omfatte innholdet fra MS sine binære formater. Dette var visstnok ikke hverken mulig eller ønskelig for de som var arkitektene bak ODF (som var basert på Sun sin StarOffice). Som sagt har jeg ikke sett det dokumentert så ta det for det det er verdt.

 

Når det er sagt: MS stemte for at ODF skulle bli en standard i ISO selv om de selv ikke var med på utarbeidelsen. Det kan tyde på at de enten ikke tok ODF særlig på alvor eller at de mente det var riktig med to ulike standarder som dekket ulike behov. IBM på sin side takket nei til å være med på utarbeidelsen av OOXML i ECMA.

 

Dette viser vel at det ikke bare er én stor og stygg ulv (MS) og to snille lam (Sun og IBM) som kjemper for forbrukernes interesser. IBM har jo stor egeninteresse av at ODF blir det dominerende formatet i fremtiden.

Lenke til kommentar

Hva er årsaken til at dokumentformatet må inneholde informasjon for gamle formater? Hvorfor kan ikke dette være et tillegg til Office og Openoffice, der man kan ha et valg for konvertering av gamle formater til nytt format? Slik at den informasjonen ligger i programmet og ikke i det nye dokumentformatet?

 

Ørjan...

Lenke til kommentar

Det er vel så enkelt som at 99 % av de som tar i bruk det nye formatet i første omgang er brukere av tidligere versjoner av MS Office. Noe av poenget med formatet i første omgang er jo nettopp å sørge for best mulig kompatibilitet med de binære formatene. Dette er ikke annerledes enn at ODF 1.2 vil innholde beskrivelser av hvordan elementer fra ODF 1.0 skal tolkes i applikasjonen (det siste punktet er en antakelse).

 

Edit: Fjernet et avsnitt.

Endret av kjeklulf
Lenke til kommentar
Gjest Slettet-Pqy3rC
Det kan du selvsagt mene, og jeg forstår at det er ulike syn på det. På den annen side: Vi har en lang rekke standarder som delvis overlapper hverandre. Det gjelder for eksempel bildeformater (jpeg, gif, png, svg) og programmering (C, C++, C#, Prolog, Fortran, Cobol og flere andre).

Nå er vel neppe alle disse "standardene" ISO standardiserte (tror jeg). Dessuten er det tvilsomt om "kaos" på noen felt er grunn god nok til å innføre nye duplette standarder på andre områder.

Når det gjelder prosessen i forbindelse med ODF så er det vel ingen andre enn de som selv deltok som kjenner alle sannheter om hvorfor det ble slik eller sånn.

Sant nok. Håpløst at folk ikke klarer å samarbeide uansett om årsaken er politisk eller teknisk.

Dette viser vel at det ikke bare er én stor og stygg ulv (MS) og to snille lam (Sun og IBM) som kjemper for forbrukernes interesser. IBM har jo stor egeninteresse av at ODF blir det dominerende formatet i fremtiden.

Jeg påstår ikke at SUN/IBM er noe bedre enn MS, men ODF var enkelt og greit først ute.

Jeg finner ingen grunn til at det skal være bedre å innføre en ekstra dokumentstandard enn å samarbeide om å gjøre den som allerede finnes best mulig for alle parter.

Lenke til kommentar
Nå er vel neppe alle disse "standardene" ISO standardiserte (tror jeg). Dessuten er det tvilsomt om "kaos" på noen felt er grunn god nok til å innføre nye duplette standarder på andre områder.

Bortsett fra gif så er de nok dessverre det. Jeg er enig i at dette i seg selv ikke er noen grunn til å ha dublette standarder, det var bare for å vise at det er helt vanlig med ulike standarder som overlapper hverandre. Jeg mener også at forskjellene (slik de er utformet nå, ikke slik de kunne vært utformet) er så store at det forsvarer at det er to delvis overlappende standarder.

Sant nok. Håpløst at folk ikke klarer å samarbeide uansett om årsaken er politisk eller teknisk.

Der er vi nok helt enige. :)

Jeg påstår ikke at SUN/IBM er noe bedre enn MS, men ODF var enkelt og greit først ute. Jeg finner ingen grunn til at det skal være bedre å innføre en ekstra dokumentstandard enn å samarbeide om å gjøre den som allerede finnes best mulig for alle parter.

Det er klart det burde vært mulig men for oss utenforstående er det umulig å sette seg inn i alle de vurderingene som gjorde at det ble som det ble. IBM og Sun hadde sitt å forsvare, MS hadde sitt å forsvare. Jeg kan tenke meg mange grunner (fra begge sider) til at det gikk som det gikk og at ODF og MS ble en umulighet, og at dermed også IBM og OOXML ble en umulighet. Situasjonen nå er nå en gang som den er og det er det ingen av oss som får gjort noe med. ;)

Endret av kjeklulf
Lenke til kommentar

Når det gjelder Microsoft sine bevegelsesgrunner for ooxml så er det åpenbart for alle som var involvert i prosessen. De som taper på det er like åpenbart forbrukerne. Dette anser jeg også som grundig dokumentert. Det eneste som vil kunne redde oss unna lock-in der er masse skattekroner til oppsyn fra det offentlige i de land som er i stand til å gjøre noe med det.

 

Det kan du selvsagt mene, og jeg forstår at det er ulike syn på det. På den annen side: Vi har en lang rekke standarder som delvis overlapper hverandre. Det gjelder for eksempel bildeformater (jpeg, gif, png, svg) og programmering (C, C++, C#, Prolog, Fortran, Cobol og flere andre).
Bildeformatene har forskjellige formål, men det er jo nok et område hvor MS så rom for å komme med nye formater med lock-in som hovedmotivasjon. C# er et klasseeksempel på embrace, extend and extinguish akkurat som J#. Dessverre har de hatt betydelig suksess med C#. Hvordan folk tør å satse sin karrière på C# er ubegripelig for meg. Cobol og Prolog er etterlevninger fra fortiden. C, C++ og Fortran fyller i dag forskjellige roller, og har en naturlig berettigelse. Har du virkelig ikke peiling, eller er du bare desperat etter å få ooxml til å se ut som en helt naturlig sak?
Lenke til kommentar
Når det gjelder Microsoft sine bevegelsesgrunner for ooxml så er det åpenbart for alle som var involvert i prosessen. De som taper på det er like åpenbart forbrukerne. Dette anser jeg også som grundig dokumentert. Det eneste som vil kunne redde oss unna lock-in der er masse skattekroner til oppsyn fra det offentlige i de land som er i stand til å gjøre noe med det.

 

Vel, du var ikke involvert i prosessen og jeg var ikke involvert i prosessen. Som sagt er det mange ulike grunner som kan ligge bak at resultatet ble som det ble. IBM hadde mye å tjene på at ODF ikke ble MS-vennlig, MS hadde mye å tjene på å ha et konkurrerende og delvis overlappende format. Du har ennå ikke klart å dokumentere hvordan OOXML skal føre til noen lock-in. Hva skattekroner fra det offentlige har med saken å gjøre skjønner jeg ikke.

 

Bildeformatene har forskjellige formål, men det er jo nok et område hvor MS så rom for å komme med nye formater med lock-in som hovedmotivasjon. C# er et klasseeksempel på embrace, extend and extinguish akkurat som J#. Dessverre har de hatt betydelig suksess med C#. Hvordan folk tør å satse sin karrière på C# er ubegripelig for meg. Cobol og Prolog er etterlevninger fra fortiden. C, C++ og Fortran fyller i dag forskjellige roller, og har en naturlig berettigelse. Har du virkelig ikke peiling, eller er du bare desperat etter å få ooxml til å se ut som en helt naturlig sak?

 

Du klarte virkelig å misse hele poenget. Jeg gjentar: dette var eksempler på at det er helt vanlig at det finnes flere standarder innenfor samme område som delvis overlapper hverandre. Jeg mener det er såpass stor forskjell på ODF og OOXML (slik de er utformet nå) at det forsvarer at det er to ulike standarder.

 

Ellers legger jeg jo merke til at du hopper over å svare på de spørsmålene du har fått tidligere og jeg får gjenta de her nok en gang:

 

Hva slags "ulik nummerering" er det du snakker om når det gjelder innsatte bildeobjekter i Word?

 

Kan du beskrive forskjellene i hvordan Word og OpenOffice behandler direkte formatering i forhold til stiler? Du har jo sagt at de er på forskjellige nivåer men ikke et ord om hva dette faktisk innebærer.

 

Hva har OpenOffice sitt konverteringsfilter for binære MS Office-filer med ODF-formatet eller OOXML-formatet å gjøre? Hva har OOXML sine eventuelle konverteringsproblemer fra de binære MS Office-formatene med ODF-spesifikasjonen å gjøre?

 

Har du klart å gjenskape problemet med at captions får ulik formatering ved å sette inn ved høyreklikk og fra Insert-menyen? Eller har du funnet noen andre som har opplevd det samme? Eller kan det tenkes at det er en bruker som har formatert de etter at de er satt inn?

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...