mboost-dp1
Microsoft
Det er jo netop fordi de vil være sikre på det gamle OOXML spiller godt sammen med det nye, at det tager længere tid at implementere det.
Man kunne også vend det rundt og så sige.
Ms sidder lige nu med det problem at der i mange europæiske lande e blevet vedtaget at odf er fremtidens åbne format. Hvis MS ikke skal miste sine markedsandele så bliver de nød til at understøtte odf.
Det spændende bliver om det ikke vil gøre at man mange steder vil kigge på selve officepakken. Og her vil OpenOffice blive et meget naturligt alternativ. Her har man dokumentunderstøttelsen øjeblikkeligt og man kan samtidigt åbne Microsofts formater på en rimelig måde.
I forhold til B103 kan man jo ikke engang tjekke MS's OOXML format, da der ikke findes et produkt der kan bruge det.
Måske har Ms spillet for højt spil og må nu kæmpe for at beholde sin position
Ms sidder lige nu med det problem at der i mange europæiske lande e blevet vedtaget at odf er fremtidens åbne format. Hvis MS ikke skal miste sine markedsandele så bliver de nød til at understøtte odf.
Det spændende bliver om det ikke vil gøre at man mange steder vil kigge på selve officepakken. Og her vil OpenOffice blive et meget naturligt alternativ. Her har man dokumentunderstøttelsen øjeblikkeligt og man kan samtidigt åbne Microsofts formater på en rimelig måde.
I forhold til B103 kan man jo ikke engang tjekke MS's OOXML format, da der ikke findes et produkt der kan bruge det.
Måske har Ms spillet for højt spil og må nu kæmpe for at beholde sin position
#thj01
I teorien har du ret Open Office kunne være et alternativ, men så længe den ikke kan integrere på samme måde mad mange firmaer/kommuners backend Microsoft servere, er det meget lidt anvendeligt for disse firmaer/kommuner.
For private mennesker gør det ikke den store forskel, en det er noget helt helt andet for firmaer samt de offentlige instancer.
Hvilket jo netop skyldes alle de ændringer der skulle laves til OOXML formatet, inden det kunne blive ISO godkendt.
Jeg tvivler, men det må tiden vise.
I teorien har du ret Open Office kunne være et alternativ, men så længe den ikke kan integrere på samme måde mad mange firmaer/kommuners backend Microsoft servere, er det meget lidt anvendeligt for disse firmaer/kommuner.
For private mennesker gør det ikke den store forskel, en det er noget helt helt andet for firmaer samt de offentlige instancer.
I forhold til B103 kan man jo ikke engang tjekke MS's OOXML format, da der ikke findes et produkt der kan bruge det.
Hvilket jo netop skyldes alle de ændringer der skulle laves til OOXML formatet, inden det kunne blive ISO godkendt.
Måske har Ms spillet for højt spil og må nu kæmpe for at beholde sin position
Jeg tvivler, men det må tiden vise.
OOXML har altid været sværere at implementer end ODF.
Enhver udvikler med bare lidt kendskab til systemdesign/design-generelt, og xml/schema ville hurtigt kunne udlede hvilken standard der er nemmest at implementere.
Det helt store problem er at OOXML er lavet af 4 forskellige lejre, som på ingen måde har snakket med hinanden om standarden.
Derfor er f.eks. regneark meget forskelligt fra alm. rtf-dokumenter , og udleder derfor ekstra meget kode.
Jeg er fuldstændig ligeglad med hele ISO/ECMA hykleriet, fra et rent teknisk set er OOXML noget skrammel! Det er en om'er Microsoft.
Enhver udvikler med bare lidt kendskab til systemdesign/design-generelt, og xml/schema ville hurtigt kunne udlede hvilken standard der er nemmest at implementere.
Det helt store problem er at OOXML er lavet af 4 forskellige lejre, som på ingen måde har snakket med hinanden om standarden.
Derfor er f.eks. regneark meget forskelligt fra alm. rtf-dokumenter , og udleder derfor ekstra meget kode.
Jeg er fuldstændig ligeglad med hele ISO/ECMA hykleriet, fra et rent teknisk set er OOXML noget skrammel! Det er en om'er Microsoft.
6 skrev:#5
Du glemmer at OOXML nok også kan noget mere end ODF, mig bekendt. Derfor tager det længere tid at implementere.
Som hvad? Jeg har ikke fundet noget endnu.
Faktisk virker ODF overlegen da ODF benytter MathML som er en W3C standard , modsat OOXML som benytter OMML som er noget de selv har fundet på.
MathML er allerede implementeret i en editor kaldet Amaya som er standard godkendt, hvor mig bekendt har hverken equation editor eller MathType support for OMML eller MathML endnu!
(Og jeg har faktisk hørt at MathType ville benytte MathML, og ikke OMML).
Vi snakker features nu ikke? Og ikke bare festsange!
En torn der sprang i mit øje: Det er svære at implementere, men derimod sværere. Overskriften skal lige rettes :)
Personligt håber jeg på at Microsoft en dag vil indse at de vil for meget i en verden hvor andre laver løsninger som er meget holdbare, og som kan spare dem for at bruge ressourcer på at udvikle selv.
Personligt håber jeg på at Microsoft en dag vil indse at de vil for meget i en verden hvor andre laver løsninger som er meget holdbare, og som kan spare dem for at bruge ressourcer på at udvikle selv.
#7
Sjovt du lige nævner den, eftersom det valg faktisk er et af de kritik punkter der nævnes her:
http://en.wikipedia.org/wiki/OpenDocument#Criticis...
Men en af tingene er manglende implementation af makroer, citat fra ovenstående side:
Different applications using ODF as a standard document format have different methods of providing macro/scripting capabilities. There is no macro language specified in ODF. Users and developers differ on whether inclusion of a standard scripting language would be desirable.
Nej jeg har ikke ville spilde min tid på at læse hele ODF standarden igennem, men normalt er Wikipedia et sted som fans af ODF nok skal holde opdateret, så jeg forventer det er korrekt information.
Bare for at nævne en enkelt ting der øjensynligt mangler. Og hvis det nu er i ODF formattet alligevel, er det så ligeså avanceret som f.eks. VBA kode i Excel ?
p.s. God weekend :)
Sjovt du lige nævner den, eftersom det valg faktisk er et af de kritik punkter der nævnes her:
http://en.wikipedia.org/wiki/OpenDocument#Criticis...
Men en af tingene er manglende implementation af makroer, citat fra ovenstående side:
Different applications using ODF as a standard document format have different methods of providing macro/scripting capabilities. There is no macro language specified in ODF. Users and developers differ on whether inclusion of a standard scripting language would be desirable.
Nej jeg har ikke ville spilde min tid på at læse hele ODF standarden igennem, men normalt er Wikipedia et sted som fans af ODF nok skal holde opdateret, så jeg forventer det er korrekt information.
Bare for at nævne en enkelt ting der øjensynligt mangler. Og hvis det nu er i ODF formattet alligevel, er det så ligeså avanceret som f.eks. VBA kode i Excel ?
p.s. God weekend :)
Og hvis det nu er i ODF formattet alligevel, er det så ligeså avanceret som f.eks. VBA kode i Excel ?
Jeg går da stærkt ud fra at VBA heller ikke er en del af OOXML ?
Altså, Visual Basic er jo ikke gratis eller på nogen måde open-source.
Men de kunne vel forholdsvis nemt implementer yet-another-programming-language som f.eks. python eller ruby som scripting sprog.
Jeg hænger mig mere til at script sprog skal afhænge af klienten, og ikke så meget dokument standarden bagved.
P.S. I lige måde
#10
Det kunne de helt sikkert, men hvis det ikke er defineret i standarden, ender du op med du skal havde 117 fortolkere installeret for at kunne køre programmerne, og det er ikke hensigtsmæssigt.
Du laver et dokument der bruger python som script sprog, en anden med Ruby, en tredje med perl, en 4. med commodore 64 basic osv. (okay den sidste ikke så relevant)
Hvordan vil du så sikre at jeg som bruger ikke skal installere et utalt af script fortolkere, som alle sammen har deres spisfindigheder osv.
Hvis der er frit valg imellem 117% sprog, hvorfor så ikke også 117 dokumentformater ?
Men de kunne vel forholdsvis nemt implementer yet-another-programming-language som f.eks. python eller ruby som scripting sprog.
Det kunne de helt sikkert, men hvis det ikke er defineret i standarden, ender du op med du skal havde 117 fortolkere installeret for at kunne køre programmerne, og det er ikke hensigtsmæssigt.
Jeg hænger mig mere til at script sprog skal afhænge af klienten, og ikke så meget dokument standarden bagved.
Du laver et dokument der bruger python som script sprog, en anden med Ruby, en tredje med perl, en 4. med commodore 64 basic osv. (okay den sidste ikke så relevant)
Hvordan vil du så sikre at jeg som bruger ikke skal installere et utalt af script fortolkere, som alle sammen har deres spisfindigheder osv.
Hvis der er frit valg imellem 117% sprog, hvorfor så ikke også 117 dokumentformater ?
Hvordan vil du så sikre at jeg som bruger ikke skal installere et utalt af script fortolkere, som alle sammen har deres spisfindigheder osv.
Det sammen kan man vel spørge om mht. VBA?
Et dokument-format skal vel være platforms uafhænging ?
(Mig bekendt er der kun vba understøttelse på windows.)
3 skrev:I forhold til B103 kan man jo ikke engang tjekke MS's OOXML format, da der ikke findes et produkt der kan bruge det.
Hvad er MS's OOXML format? Vel ikke det der er "standarden". ECMA-OOXML, ISO-OOXML og MS-OOXML (implementationen), hvoraf ISO-OOXML man ikke kan se endnu.
I princippet kan man jo heller ikke tjekke ODF formatet :) Så vidt jeg har læst mig til implementerer nyere OpenOffice ODF1.1 (hvor ODF1.0 er standarden), og tidligere OpenOffices ikke har en fuld ODF1.0 impl.
4 skrev:I teorien har du ret Open Office kunne være et alternativ, men så længe den ikke kan integrere på samme måde mad mange firmaer/kommuners backend Microsoft servere, er det meget lidt anvendeligt for disse firmaer/kommuner.
Ligesom Microsoft Office ikke integrerer godt med andre end Microsoft backend servere. Jeg har tidligere skrevet om det, men hvorfor er sådan en integration godt? Pointen er vel åbne standarder så man ikke får noget lock-in til det ene eller det andet. At man historisk er i en situation er ikke en undskyldning for ikke at gøre noget ved det :)
#10+#11
Indeholder begge dokument-standarder ikke allerede masser af muligheder for extensions? (Så vidt jeg lige kan læse i Disky's link, så er formler i regneark i ODF f.eks. en udvidelse). Hvorfor er det et problem om der er 1 eller 117 udvidelser? Det vigtige er vel at de udvidelser som bruges i forbindelse med "åbne" dokumenter også er åbne og tilgængelige for alle. Lidt ligesom browser plugins, så er der alle mulige mærkelige plugins, men det er ret få som man bare må have for at "nettet virker".
#14
Har du overvejet hvor meget hardware og software der idag bruger denne integration ?
Derfor er det et krav nye produkter skal understøtte det.
Fordi 117 udvidelser, kan kræve 117 fortolkere, eftersom ingen er blevet enig om hvad for en fortolker man skal benytte.
Hvis man kan bruge 117 fortolkere, kan vi ligeså godt havde 117 dokument formater.
Hvor mange af disse fortolkere er overhovedet iso certificeret, som værende en standard ?
Ja man har brug for en browser + flash + silberlight + windows mediaplayer + quicktime + + + +
Synes du selv det er smart ?
Jeg har tidligere skrevet om det, men hvorfor er sådan en integration godt? Pointen er vel åbne standarder så man ikke får noget lock-in til det ene eller det andet
Har du overvejet hvor meget hardware og software der idag bruger denne integration ?
Derfor er det et krav nye produkter skal understøtte det.
Hvorfor er det et problem om der er 1 eller 117 udvidelser? Det vigtige er vel at de udvidelser som bruges i forbindelse med "åbne" dokumenter også er åbne og tilgængelige for alle.
Fordi 117 udvidelser, kan kræve 117 fortolkere, eftersom ingen er blevet enig om hvad for en fortolker man skal benytte.
Hvis man kan bruge 117 fortolkere, kan vi ligeså godt havde 117 dokument formater.
Hvor mange af disse fortolkere er overhovedet iso certificeret, som værende en standard ?
Lidt ligesom browser plugins, så er der alle mulige mærkelige plugins, men det er ret få som man bare må have for at "nettet virker".
Ja man har brug for en browser + flash + silberlight + windows mediaplayer + quicktime + + + +
Synes du selv det er smart ?
#4
Hvis odf bliver standarder så må det offentlige jo ikke bruge den slags løsninger mere - og de fleste firmaer ville nok også betakke sig. Den eneste årsag til at MS's produkter er så integreret er jo at de har været defacto standarder, men det er EU og mange lande jo ved at ændre på.
MS og andre firmaers produkter bliver nød til at indrette sig på et ikke MS domineret marked
#9
Jeg synes det er interesant at en del ooxml forsvarer ikke sætter sig ind i sagerne - og nej OS folk er ikke mere til wikipedia end andre. Det ville også bare klæ dig at sætte dig ind i problemfelterne.
MS er begyndt at sætte sig ind i det og de må erkende at de skal bruge uhensigtsmæssigt meget tid på at få styr på den kode de selv har lavet og de ændringer de skal lave for at gøre den "åben". Denne gang kan de ikke skjule det fordi der er tusindvis af øjne rettet mod deres nye åbne kode. Det kommer til at koste denne gang hvis de ikke gør deres arbejde ordentligt. Det er OOXML der skal til at vise dets værd - ikke ODF
#14
Man kunne også tænke. Det er nok den der ecma/ISO standard han snakker om, Men ligemeget hvad - så er det MS programmører der skal sidde og lave arbejdet.
Den standard som MS har fået kørt igennem ISO processen overholder de ikke selv - og har nu sagt at det kommer de heller ikke til i denne version af MSO. Det burde være nok til at give de fleste kolde fødder i forhold til deres åbne format.
Det er ikke lykkes at lave et hæderligt filter endnu af nogle eksterne - på trods af at MS hjælper til (novel) - og det er da klart når ms ikke engang kan selv.
#14
Intet kan integreres ordentlig med NOGET MS produkt - fordi det er closed Source. OOO kan integreres med alt der er OpenSource. Og så er vil tilbage ved selve humlen i problemstillingen.
I teorien har du ret Open Office kunne være et alternativ, men så længe den ikke kan integrere på samme måde mad mange firmaer/kommuners backend Microsoft servere, er det meget lidt anvendeligt for disse firmaer/kommuner.
Hvis odf bliver standarder så må det offentlige jo ikke bruge den slags løsninger mere - og de fleste firmaer ville nok også betakke sig. Den eneste årsag til at MS's produkter er så integreret er jo at de har været defacto standarder, men det er EU og mange lande jo ved at ændre på.
MS og andre firmaers produkter bliver nød til at indrette sig på et ikke MS domineret marked
#9
Nej jeg har ikke ville spilde min tid på at læse hele ODF standarden igennem, men normalt er Wikipedia et sted som fans af ODF nok skal holde opdateret, så jeg forventer det er korrekt information.
Jeg synes det er interesant at en del ooxml forsvarer ikke sætter sig ind i sagerne - og nej OS folk er ikke mere til wikipedia end andre. Det ville også bare klæ dig at sætte dig ind i problemfelterne.
MS er begyndt at sætte sig ind i det og de må erkende at de skal bruge uhensigtsmæssigt meget tid på at få styr på den kode de selv har lavet og de ændringer de skal lave for at gøre den "åben". Denne gang kan de ikke skjule det fordi der er tusindvis af øjne rettet mod deres nye åbne kode. Det kommer til at koste denne gang hvis de ikke gør deres arbejde ordentligt. Det er OOXML der skal til at vise dets værd - ikke ODF
#14
Hvad er MS's OOXML format? Vel ikke det der er "standarden". ECMA-OOXML, ISO-OOXML og MS-OOXML (implementationen), hvoraf ISO-OOXML man ikke kan se endnu.
Man kunne også tænke. Det er nok den der ecma/ISO standard han snakker om, Men ligemeget hvad - så er det MS programmører der skal sidde og lave arbejdet.
Den standard som MS har fået kørt igennem ISO processen overholder de ikke selv - og har nu sagt at det kommer de heller ikke til i denne version af MSO. Det burde være nok til at give de fleste kolde fødder i forhold til deres åbne format.
Det er ikke lykkes at lave et hæderligt filter endnu af nogle eksterne - på trods af at MS hjælper til (novel) - og det er da klart når ms ikke engang kan selv.
#14
Ligesom Microsoft Office ikke integrerer godt med andre end Microsoft backend servere.
Intet kan integreres ordentlig med NOGET MS produkt - fordi det er closed Source. OOO kan integreres med alt der er OpenSource. Og så er vil tilbage ved selve humlen i problemstillingen.
17 skrev:Jeg ville ønske i ville droppe det politiske aspekt, og fokuser på det tekniske aspekt istedet.
Nu har i, på begge sider, whinet over den del i næsten et år.
.. og jeg, personligt, har ikke i sinde at stoppe foreløbig!
15 skrev:Har du overvejet hvor meget hardware og software der idag bruger denne integration ?
Derfor er det et krav nye produkter skal understøtte det.
Nu taler du om integration bredere end dokumentformater, eller? En gentagelse, men, at man historisk er i en dårlig situation er ikke nogen undskyldning for ikke at forbedre det. Derfor er det ikke et krav at nye produkter skal understøtte "det" (det=integration mod propritære formater).
15 skrev:Fordi 117 udvidelser, kan kræve 117 fortolkere, eftersom ingen er blevet enig om hvad for en fortolker man skal benytte.
Hvis man kan bruge 117 fortolkere, kan vi ligeså godt havde 117 dokument formater.
Hvor mange af disse fortolkere er overhovedet iso certificeret, som værende en standard ?
Jeg siger bare at dine alternativer er ingen udvidelser, eller 117 udvidelser. Hvis du ikke vil tillade udvidelser i et dokumentformat, så kræver det at alle er enige om hvad et dokumentformat skal indeholde. Det er man tilsyneladende ikke siden der allerede er to :)
Som jeg også skriver, så er jeg enig med dig i at "fortolkerne" også skal være standardiserede, inden det giver mening at man kan bruge dem til åben dokument-udveksling.
16 skrev:Intet kan integreres ordentlig med NOGET MS produkt - fordi det er closed Source. OOO kan integreres med alt der er OpenSource. Og så er vil tilbage ved selve humlen i problemstillingen.
Integration kræver ikke open source, det kræver kendte "interfaces" (lidt svært at definere hvad det er). At man implicit kender interfaces i opensource gør at man altid kan integrere på implementations niveau ja. Det kunne være rarere at integrere på "standard" niveau :)
#17
Nu er vi nogen der " i et års tid" har forsøgt at analysere ooxml formatet og fundet frem til det ikke var i orden - rent teknisk. Der er vi blevet whinet i ørene at det ikkek duer med kun et åbent format.
Nu står vi i den situation at MS rent teknisk ikke kan få deres "vidunderformat" til at virke,
De har i 3 år NÆGTET at implementere ODF. Nu gør de det - og så kan det så være whining - men fakta er at hvis de ikke gør det så vil flere lande i Europa og Asien ikke kunne bruge MS produkter fordi de rent LOVGIVNINGS mæssigt er forpligtiget på at skulle bruge odf.
Dette har intet med teknik at gøre (ud over det faktum at de nu selv sidder og erkender at deres format er noget lort og ikke hænger sammen) - det er ren og skær firmapolitik og overlevelse.
Hvis man ingen erfaringer får med OOXML så kan B103 ikke gå ind og verificere OOXML som et reelt produkt og VUPTI - DK har ODF som standard.
MS har satset HØJT i dette spil og lige nu ser det ud som om at de har malet sig selv op i en krog.
Jeg er den SIDSTE der vil "lægge" pennen i dette område. Ikke fordi det er MS, men fordi den software politik der ligger under ikke stemmer overens med min holdning og filosofi.
Jeg ville ønske i ville droppe det politiske aspekt, og fokuser på det tekniske aspekt istedet.
Nu har i, på begge sider, whinet over den del i næsten et år.
Nu er vi nogen der " i et års tid" har forsøgt at analysere ooxml formatet og fundet frem til det ikke var i orden - rent teknisk. Der er vi blevet whinet i ørene at det ikkek duer med kun et åbent format.
Nu står vi i den situation at MS rent teknisk ikke kan få deres "vidunderformat" til at virke,
De har i 3 år NÆGTET at implementere ODF. Nu gør de det - og så kan det så være whining - men fakta er at hvis de ikke gør det så vil flere lande i Europa og Asien ikke kunne bruge MS produkter fordi de rent LOVGIVNINGS mæssigt er forpligtiget på at skulle bruge odf.
Dette har intet med teknik at gøre (ud over det faktum at de nu selv sidder og erkender at deres format er noget lort og ikke hænger sammen) - det er ren og skær firmapolitik og overlevelse.
Hvis man ingen erfaringer får med OOXML så kan B103 ikke gå ind og verificere OOXML som et reelt produkt og VUPTI - DK har ODF som standard.
MS har satset HØJT i dette spil og lige nu ser det ud som om at de har malet sig selv op i en krog.
Jeg er den SIDSTE der vil "lægge" pennen i dette område. Ikke fordi det er MS, men fordi den software politik der ligger under ikke stemmer overens med min holdning og filosofi.
#16
Har du overvejet hvad den spådom medfører ?
Når man nu ikke længere kan havde et avanceret excel ark, der f.eks. henter pivot data fra en MsSQL server og gør ting ved det.
Så er man nød til at få special udviklet software der kan gøre det samme.
Og hvem tror du skal betale for det ? Korrekt hele befolkningen, og en ting er sikkert det bliver meget meget dyrere, end et par Office Licenser.
Nå ja for det gør du jo helt bestemt, nå nej jævnfør ovenstående :)
Tyv tror hver mand stjæler :)
Lol, du siger vi skal sætte os ind i det, gør det lige selv.
Der er blevet rettet MANGE ting i ooxml pga. Iso, derfor er det ikke implementeret, præcist ligesom nyeste ODf heller ikke er !
Tænk lige over det.
Siden open source nu er så godt i dine øjne, så kom med eksempler på noget der er ligeså let at installere og konfigurere som Microsoftes løsninger, og som kan det samme eller mere.
Hvis du ikke kan dette, er open source altså ubrugeligt som alternativ, på nuværende tidspunkt. Men det er måske derfor alle ODF fan's de brokker sig helt vildt, eftersom de ved at nu hvor deres format ikke er det eneste godkendte, er de lidt på den, da de på mange områder er håbløst bagefter.
Ja alt andet ville være extremt snævertsynet, hvis ODF ikke fuldt ud kan bruges til det som Microsoft'es formater kan i dag, er det ikke udskiftbart, og derfor ikke anvendeligt.
Man er nød til at se tingene i lidt bredere perspektiv end bare om man kan skrive et brev til moster Olga.
Så du vil skifte, og være skyld i udviklingen af en masse nyt software som vi skatteydere skal betale for. Tro mig når man betaler top skat i stor stil, gider man ikke betale mere, bare pga. nogle idiologiske ideer.
Tak
Men det kan man mig bekendt ikke på nuværende tidspunkt på samme måde, derfor må åben standard verdenen tage sig sammen og få det implementeret, så det kan bruges i stedet for Microsoft'es produkter, indtil da er det bare ikke et alternativt.
Det gælder sjovt nok også ODF, det er heller ikke anvendeligt som alternativ for det man har i dag i form af Microsoftes lukkede formater. At skifte ene og alene pga. ODF er åbent er dumt, og dyrt.
Og denne lovgivning kan kommer til at koste borgerne mange penge, rigtigt mange penge.
Den udtalelse, kan du selvfølgelig dokumentere i form af en officiel udtalelse fra en højstående medarbejder i Microsoft, ikke ?
Juuhuu og så skal vi betale mere i skat :( (heldigvis har vi en regering der har skattestop, lad os håbe venstrefløjen bliver holdt væk i mange år endnu, de er ganske enkelt for dyre i drift)
Hvis odf bliver standarder så må det offentlige jo ikke bruge den slags løsninger mere - og de fleste firmaer ville nok også betakke sig.
Har du overvejet hvad den spådom medfører ?
Når man nu ikke længere kan havde et avanceret excel ark, der f.eks. henter pivot data fra en MsSQL server og gør ting ved det.
Så er man nød til at få special udviklet software der kan gøre det samme.
Og hvem tror du skal betale for det ? Korrekt hele befolkningen, og en ting er sikkert det bliver meget meget dyrere, end et par Office Licenser.
Det ville også bare klæ dig at sætte dig ind i problemfelterne.
Nå ja for det gør du jo helt bestemt, nå nej jævnfør ovenstående :)
Tyv tror hver mand stjæler :)
Den standard som MS har fået kørt igennem ISO processen overholder de ikke selv
Lol, du siger vi skal sætte os ind i det, gør det lige selv.
Der er blevet rettet MANGE ting i ooxml pga. Iso, derfor er det ikke implementeret, præcist ligesom nyeste ODf heller ikke er !
Tænk lige over det.
Intet kan integreres ordentlig med NOGET MS produkt - fordi det er closed Source. OOO kan integreres med alt der er OpenSource. Og så er vil tilbage ved selve humlen i problemstillingen.
Siden open source nu er så godt i dine øjne, så kom med eksempler på noget der er ligeså let at installere og konfigurere som Microsoftes løsninger, og som kan det samme eller mere.
Hvis du ikke kan dette, er open source altså ubrugeligt som alternativ, på nuværende tidspunkt. Men det er måske derfor alle ODF fan's de brokker sig helt vildt, eftersom de ved at nu hvor deres format ikke er det eneste godkendte, er de lidt på den, da de på mange områder er håbløst bagefter.
Nu taler du om integration bredere end dokumentformater, eller?
Ja alt andet ville være extremt snævertsynet, hvis ODF ikke fuldt ud kan bruges til det som Microsoft'es formater kan i dag, er det ikke udskiftbart, og derfor ikke anvendeligt.
Man er nød til at se tingene i lidt bredere perspektiv end bare om man kan skrive et brev til moster Olga.
Derfor er det ikke et krav at nye produkter skal understøtte "det" (det=integration mod propritære formater).
Så du vil skifte, og være skyld i udviklingen af en masse nyt software som vi skatteydere skal betale for. Tro mig når man betaler top skat i stor stil, gider man ikke betale mere, bare pga. nogle idiologiske ideer.
Som jeg også skriver, så er jeg enig med dig i at "fortolkerne" også skal være standardiserede, inden det giver mening at man kan bruge dem til åben dokument-udveksling.
Tak
At man implicit kender interfaces i opensource gør at man altid kan integrere på implementations niveau ja. Det kunne være rarere at integrere på "standard" niveau :)
Men det kan man mig bekendt ikke på nuværende tidspunkt på samme måde, derfor må åben standard verdenen tage sig sammen og få det implementeret, så det kan bruges i stedet for Microsoft'es produkter, indtil da er det bare ikke et alternativt.
og fundet frem til det ikke var i orden - rent teknisk.
Det gælder sjovt nok også ODF, det er heller ikke anvendeligt som alternativ for det man har i dag i form af Microsoftes lukkede formater. At skifte ene og alene pga. ODF er åbent er dumt, og dyrt.
produkter fordi de rent LOVGIVNINGS mæssigt er forpligtiget på at skulle bruge odf.
Og denne lovgivning kan kommer til at koste borgerne mange penge, rigtigt mange penge.
Dette har intet med teknik at gøre (ud over det faktum at de nu selv sidder og erkender at deres format er noget lort og ikke hænger sammen)
Den udtalelse, kan du selvfølgelig dokumentere i form af en officiel udtalelse fra en højstående medarbejder i Microsoft, ikke ?
og VUPTI - DK har ODF som standard.
Juuhuu og så skal vi betale mere i skat :( (heldigvis har vi en regering der har skattestop, lad os håbe venstrefløjen bliver holdt væk i mange år endnu, de er ganske enkelt for dyre i drift)
Har du overvejet hvad den spådom medfører ?
Når man nu ikke længere kan havde et avanceret excel ark, der f.eks. henter pivot data fra en MsSQL server og gør ting ved det.
Så er man nød til at få special udviklet software der kan gøre det samme.
Og hvem tror du skal betale for det ? Korrekt hele befolkningen, og en ting er sikkert det bliver meget meget dyrere, end et par Office Licenser.
Det er VBA, som vist heller ikke er en del af OOXML standarden.
Så begge formater mangler det eksempel :)
21 skrev:Når man nu ikke længere kan havde et avanceret excel ark, der f.eks. henter pivot data fra en MsSQL server og gør ting ved det.
Så er man nød til at få special udviklet software der kan gøre det samme.
Nu kan man godt lige netop det eksempel du nævner med OpenOffice pakken, et lidt gammelt eksempel men se: her. Medmindre selvf. "avanceret" ikke specifikt referer til hvad du nævner her :)
21 skrev:Ja alt andet ville være extremt snævertsynet, hvis ODF ikke fuldt ud kan bruges til det som Microsoft'es formater kan i dag, er det ikke udskiftbart, og derfor ikke anvendeligt.
Man er nød til at se tingene i lidt bredere perspektiv end bare om man kan skrive et brev til moster Olga.
Du stiller det op som om det er alt eller intet. I det "bredere perspektiv" er der mange delsystemer, hvor ODF sagtens kunne erstatte en del af disse. Derudover er kernen vel netop at man kan skrive brev til hinanden (udveksle dokumenter). Ikke hvordan man internt kan integrere(optimere?) sine arbejdsgange.
21 skrev:Så du vil skifte, og være skyld i udviklingen af en masse nyt software som vi skatteydere skal betale for. Tro mig når man betaler top skat i stor stil, gider man ikke betale mere, bare pga. nogle idiologiske ideer.
"Idiologiske" he he. En anden påstand (tilpas ens ubegrundet) kunne være at alt det software ville skabe en masse jobs, som ville skæppe så godt i statskassen, at du kunne slippe for at betale topskat?
21 skrev:Men det kan man mig bekendt ikke på nuværende tidspunkt på samme måde, derfor må åben standard verdenen tage sig sammen og få det implementeret, så det kan bruges i stedet for Microsoft'es produkter, indtil da er det bare ikke et alternativt.
Jeg forstår ikke hvad du mener her. Nyheden handler om at der pt. ikke er nogen der implementerer en standard. Hvordan kan du sige at Microsoft har en fordel i den sammenhæng?
21 skrev:Siden open source nu er så godt i dine øjne, så kom med eksempler på noget der er ligeså let at installere og konfigurere som Microsoftes løsninger, og som kan det samme eller mere.
Alle disse programmer har JEG lettere ved at installere i Linux, end ethvert Microsoft-program i Windows: http://packages.ubuntu.com/hardy/allpackages
Og hvad angår at kunne mere: Jeg savner funktioner i MS Office, som findes i OOo, men ikke den anden vej.
Jeg kan ting i Linux som jeg ikke kan i Windows, det problem har jeg ikke den anden vej.
Faktisk kan jeg også bedre bruge MySQL end MS-SQL, men hvis det er funktionalitet jeg vil have tror jeg nu nok at PostgreSQL kan følge godt med, men jeg er så mere vant til at bruge DB2 hvor MySQL ikke kan følge med.
Firefox langt bedre end IE på næsten samtlige punkter (IMHO).
Skal jeg blive ved?
Skal jeg blive ved?
Nej, men du skal bede din virksomheds top-chef og logistik's chef om en vudering istedet for.
For at gøre Disky glad altså (jeg er personligt ligeglad).
Derudover skulle nogle nok fortælle Disky om den region der hedder Asien, og forklare hvor dårligt windows og de fleste office produkter er til asiatiske lande.
Jeg ved da ihvertfald at korea ikke er storbrugere af Office :)
Jeg synes, det siger det hele, at OOXML er sværere at implementere grundet, at den skal være bagud kompatibel med Office 2007.
Når andre programmer skal kunne åbne OOXML, forventer folk vel, at de kan åbne de samme dokumenter som Office 2007 - altså også være bagud kompatible - og det med en ikke fri standard.
Når andre programmer skal kunne åbne OOXML, forventer folk vel, at de kan åbne de samme dokumenter som Office 2007 - altså også være bagud kompatible - og det med en ikke fri standard.
#0
[jeg vil tillade mig at kalde ECMA 376 for OOXML 2006 og ISO 29500 for OOXML 2008 for at gøre tingene lidt tydeligere]
Overskriften er jo forkert.
Påstanden er formentlig rigtig.
Men der er ikke noget belæg for det i artiklen.
Artiklen siger at:
start på ODF projekt + tid for ODF implementation / antal folk på ODF projekt < start på OOXML 2008 projekt + (tid for OOXML 2008 implementation - besparelse ved genbrug af OOXML 2006 kode + ekstraarbejde for at sikre OOXML 2006 kompabilitet) / antal folk på OOXML 2008 projekt
Man kan altså ikke reducere den ligning til:
tid for ODF implementation < tid for OOXML 2008 implementation
[jeg vil tillade mig at kalde ECMA 376 for OOXML 2006 og ISO 29500 for OOXML 2008 for at gøre tingene lidt tydeligere]
Overskriften er jo forkert.
Påstanden er formentlig rigtig.
Men der er ikke noget belæg for det i artiklen.
Artiklen siger at:
start på ODF projekt + tid for ODF implementation / antal folk på ODF projekt < start på OOXML 2008 projekt + (tid for OOXML 2008 implementation - besparelse ved genbrug af OOXML 2006 kode + ekstraarbejde for at sikre OOXML 2006 kompabilitet) / antal folk på OOXML 2008 projekt
Man kan altså ikke reducere den ligning til:
tid for ODF implementation < tid for OOXML 2008 implementation
#14
Hvis ikke alle har de extensions så er det så som så med interoperabiliteten. Og hvis alle skal have dem, så kan de jo lige så godt komme med i standarden. Browser plugins er et mindre problem, fordi det i de langt de fleste tilfælde er optional.
Hvorfor er det et problem om der er 1 eller 117 udvidelser? Det vigtige er vel at de udvidelser som bruges i forbindelse med "åbne" dokumenter også er åbne og tilgængelige for alle. Lidt ligesom browser plugins, så er der alle mulige mærkelige plugins, men det er ret få som man bare må have for at "nettet virker".
Hvis ikke alle har de extensions så er det så som så med interoperabiliteten. Og hvis alle skal have dem, så kan de jo lige så godt komme med i standarden. Browser plugins er et mindre problem, fordi det i de langt de fleste tilfælde er optional.
#16
Der er noget du har misforstået. Dokument formatet er ikke eneste integration.
Nu har vi jo alene her på newz.dk haft flere tilfælde, hvor OOXML modstandere frit har opfundet argumenter mod OOXML lige ud af den blå luft ...
Der er forskel på åbne protokoller/formater og åben kode. MS har lavet et åbent format. De har mig bekendt aldrig ytret intentioner om at gøre Office koden åben.
Og som det fremgår tydeligt af original artiklen så er problemet OOXML 2006 - OOXML 2008 kompabiliteten.
Som jeg har forsøgt at forklare mange gange er der ingen som kan lave en bidirectional lossless konvertering mellem to inkompatible formater.
Og det er jo noget sludder.
FF snakker fint med IIS fordi HTTP protokollen definerer interfacet.
Java programmer snakker fint med SQLServer fordi JDBC API'et definerer interrfacet.
Og der er sikkert masser af andre eksempler.
Hvis odf bliver standarder så må det offentlige jo ikke bruge den slags løsninger mere - og de fleste firmaer ville nok også betakke sig.
Der er noget du har misforstået. Dokument formatet er ikke eneste integration.
Jeg synes det er interesant at en del ooxml forsvarer ikke sætter sig ind i sagerne
Nu har vi jo alene her på newz.dk haft flere tilfælde, hvor OOXML modstandere frit har opfundet argumenter mod OOXML lige ud af den blå luft ...
MS er begyndt at sætte sig ind i det og de må erkende at de skal bruge uhensigtsmæssigt meget tid på at få styr på den kode de selv har lavet og de ændringer de skal lave for at gøre den "åben".
Der er forskel på åbne protokoller/formater og åben kode. MS har lavet et åbent format. De har mig bekendt aldrig ytret intentioner om at gøre Office koden åben.
Og som det fremgår tydeligt af original artiklen så er problemet OOXML 2006 - OOXML 2008 kompabiliteten.
Det er ikke lykkes at lave et hæderligt filter endnu af nogle eksterne - på trods af at MS hjælper til (novel) - og det er da klart når ms ikke engang kan selv.
Som jeg har forsøgt at forklare mange gange er der ingen som kan lave en bidirectional lossless konvertering mellem to inkompatible formater.
Intet kan integreres ordentlig med NOGET MS produkt - fordi det er closed Source.
Og det er jo noget sludder.
FF snakker fint med IIS fordi HTTP protokollen definerer interfacet.
Java programmer snakker fint med SQLServer fordi JDBC API'et definerer interrfacet.
Og der er sikkert masser af andre eksempler.
#20
Det er jo så frit opfundet af dig. Det står der ikke i artiklen.
Det er jo så frit opfundet af dig. Det står der ikke i artiklen.
Jeg tror ikke at sandsynligheden for at det sker er ret stor !!
Nu står vi i den situation at MS rent teknisk ikke kan få deres "vidunderformat" til at virke,
Det er jo så frit opfundet af dig. Det står der ikke i artiklen.
Dette har intet med teknik at gøre (ud over det faktum at de nu selv sidder og erkender at deres format er noget lort og ikke hænger sammen)
Det er jo så frit opfundet af dig. Det står der ikke i artiklen.
Hvis man ingen erfaringer får med OOXML så kan B103 ikke gå ind og verificere OOXML som et reelt produkt og VUPTI - DK har ODF som standard.
Jeg tror ikke at sandsynligheden for at det sker er ret stor !!
#0
Men tilbage til artiklens indhold.
Jeg mener at ISO bør give MS tommelskruerne på.
Sådan lidt a la "I ville gerne have OOXML standardiseret. Det har I fået nu. Så forventer vi at I gør en indsats for at implementere den. Kan det ikke komme med i SP2 09H1, så må I putte det i SP2A 09H2.".
Selvfølgelig har MS nogle praktiske problemer. De skal beslutet sig for hvordan de vil håndtere OOXML 2008 - OOXML 2006 kompabiliteten. Og de skal have puttet ændringerne ind i deres R&D schedule. Og for et produkt så komplekst som MSO er der formentligt den veldefineret pipeline 3-5 år frem i tiden. Og det er ikke nemt at putte noget ekstra ind.
Men de sagde ikke nej, da der skulle laves ændringer i standarden, så nu må de tage ansvaret som ISO støttende firma. De må finde nogle flere ressourcer, lave om i planerne og få det med. Det er ikke nemt, men ingen har sagt at tilværelsen skal være nem.
Men tilbage til artiklens indhold.
Jeg mener at ISO bør give MS tommelskruerne på.
Sådan lidt a la "I ville gerne have OOXML standardiseret. Det har I fået nu. Så forventer vi at I gør en indsats for at implementere den. Kan det ikke komme med i SP2 09H1, så må I putte det i SP2A 09H2.".
Selvfølgelig har MS nogle praktiske problemer. De skal beslutet sig for hvordan de vil håndtere OOXML 2008 - OOXML 2006 kompabiliteten. Og de skal have puttet ændringerne ind i deres R&D schedule. Og for et produkt så komplekst som MSO er der formentligt den veldefineret pipeline 3-5 år frem i tiden. Og det er ikke nemt at putte noget ekstra ind.
Men de sagde ikke nej, da der skulle laves ændringer i standarden, så nu må de tage ansvaret som ISO støttende firma. De må finde nogle flere ressourcer, lave om i planerne og få det med. Det er ikke nemt, men ingen har sagt at tilværelsen skal være nem.
#28
Der har været ønske om at få det understøttet siden - for meget lang tid siden. MSO understøtter de mest underlige formater, men bare ikke en standard der har været både ISO og OASIS.
MS bedste argument for at bruge MSO var at der var jo kun der du kunne repræsentere dukumenterne som du skrev dem, Havde de implementeret odf tidligere ville odf-basis programmer være kommet ind i virksomheder og det offentlige langt tidligere.
Kommercielle virksomheder agerer også ud fra indtjening og udkonkurrering af konkurrenter. MS har et par domme for at ikke at spille efter loven
#0
MS har haft et ½ år til at få styr på koderne (dvs fra september til marts.) Det er en absurd tanke at MS skal bruge over ½ år på at få koden i orden. Der VAR problemer med formatet og der er ER problemer med formatet. Enhver der bruger de OOXML konverterer der er til rådghed ved at det ikke virker.
Det er for ringe at MS ikke efter ISO nederlaget i september retter ind og laver om på de indsigelser der er kommet. Mange af de "ændringer der skal laves i OOXML formatet er kun på løfteplan endnu.
For mig er det interessant at Novel og MS har haft en samarbejdsaftale, hvor MS og Novell arbejder tæt sammen - også med de "lukkede koder". Jeg må ærligt tilstå at jeg regnede med at der var en "monster" konverter på markedet i løbet af kort tid, Men det er bare blevet til en lille "misse-tat".
#31
Nej det er jo netop forbandelsen. Når man ikke giver indsigt, vokser der fortolkninger ud af det. OpenSource ligger åbent for alle der vil arbejde med det. Man kan kritisere, forholde sig til, ændre, engagere sig, ......
CS (Closed Source) har det med lukke sig ind og lade ting ære usagte. MS har lagt en lort i hjørnet. De fleste lagde ikke mærke til det, men nu skal MS til at bevise at de kan få deres format til at virke IRL. Og der er MANGE der vil gøre ALT for at finde huller i deres software. Det tror jeg er første gang MS står i den situation. HVIS MS bøffer den og ikke formår at få deres konverter/format i orden vil alle vide det.
HVIS MS ikke kan holde deres løfter angående deres formats/applikationers (MSWord f.eks) interoperabilitet, hvordan f.... skal vi andre så kunne stole på dem til at stå for de informationer det offentlige arbejder med??
Normalt lugter en lort kun i starten - så kommer der en skal på. Lige nu er der masser der pærer rundt i den - og det er reelt og godt det bliver gjort, Mit store spørgsmål er så om MS kan "klare" mosten - Jeg tror ikke de kan.
Det er vel åbenlyst at MS understøtter ODF fordi der er kunder som ønsker det. Sådan agerer komemrcielle virksomheder.
Der har været ønske om at få det understøttet siden - for meget lang tid siden. MSO understøtter de mest underlige formater, men bare ikke en standard der har været både ISO og OASIS.
MS bedste argument for at bruge MSO var at der var jo kun der du kunne repræsentere dukumenterne som du skrev dem, Havde de implementeret odf tidligere ville odf-basis programmer være kommet ind i virksomheder og det offentlige langt tidligere.
Kommercielle virksomheder agerer også ud fra indtjening og udkonkurrering af konkurrenter. MS har et par domme for at ikke at spille efter loven
#0
MS har haft et ½ år til at få styr på koderne (dvs fra september til marts.) Det er en absurd tanke at MS skal bruge over ½ år på at få koden i orden. Der VAR problemer med formatet og der er ER problemer med formatet. Enhver der bruger de OOXML konverterer der er til rådghed ved at det ikke virker.
Det er for ringe at MS ikke efter ISO nederlaget i september retter ind og laver om på de indsigelser der er kommet. Mange af de "ændringer der skal laves i OOXML formatet er kun på løfteplan endnu.
For mig er det interessant at Novel og MS har haft en samarbejdsaftale, hvor MS og Novell arbejder tæt sammen - også med de "lukkede koder". Jeg må ærligt tilstå at jeg regnede med at der var en "monster" konverter på markedet i løbet af kort tid, Men det er bare blevet til en lille "misse-tat".
#31
Det er jo så frit opfundet af dig. Det står der ikke i artiklen.
Nej det er jo netop forbandelsen. Når man ikke giver indsigt, vokser der fortolkninger ud af det. OpenSource ligger åbent for alle der vil arbejde med det. Man kan kritisere, forholde sig til, ændre, engagere sig, ......
CS (Closed Source) har det med lukke sig ind og lade ting ære usagte. MS har lagt en lort i hjørnet. De fleste lagde ikke mærke til det, men nu skal MS til at bevise at de kan få deres format til at virke IRL. Og der er MANGE der vil gøre ALT for at finde huller i deres software. Det tror jeg er første gang MS står i den situation. HVIS MS bøffer den og ikke formår at få deres konverter/format i orden vil alle vide det.
HVIS MS ikke kan holde deres løfter angående deres formats/applikationers (MSWord f.eks) interoperabilitet, hvordan f.... skal vi andre så kunne stole på dem til at stå for de informationer det offentlige arbejder med??
Normalt lugter en lort kun i starten - så kommer der en skal på. Lige nu er der masser der pærer rundt i den - og det er reelt og godt det bliver gjort, Mit store spørgsmål er så om MS kan "klare" mosten - Jeg tror ikke de kan.
33 skrev:MS har lagt en lort i hjørnet. [...] Normalt lugter en lort kun i starten - så kommer der en skal på. Lige nu er der masser der pærer rundt i den - og det er reelt og godt det bliver gjort, Mit store spørgsmål er så om MS kan "klare" mosten - Jeg tror ikke de kan.
En af de mere interessante analogier på newz, hvis i spørger mig... ;-)
#34
Analogier er altid interessante - jeg har ført brugt den der hedder skidt i nællerne.
Men til billedet hører nu bare at deres gamle binære doc formater gør at mange har minus tillid til MS i denne sag, de domme der er afsagt og de retsager der er under optræk vækker heller ikke ligefrem tillid.
for at gå tilbage til analogierne
det er interessant om denne kovending angående ODF skyldes - Vi ønsker at giver brugerne mere frihed eller "nød lærer nøgen kvinde at spinde"
Hvis det er den sidste er det nok ikke den kvinde man skal betro sin tegnebog til! (og her var endnu en lille analogi)
Analogier er altid interessante - jeg har ført brugt den der hedder skidt i nællerne.
Men til billedet hører nu bare at deres gamle binære doc formater gør at mange har minus tillid til MS i denne sag, de domme der er afsagt og de retsager der er under optræk vækker heller ikke ligefrem tillid.
for at gå tilbage til analogierne
det er interessant om denne kovending angående ODF skyldes - Vi ønsker at giver brugerne mere frihed eller "nød lærer nøgen kvinde at spinde"
Hvis det er den sidste er det nok ikke den kvinde man skal betro sin tegnebog til! (og her var endnu en lille analogi)
#28
For det første venter MS naturligvis på ISO's godkendelse inden de går igang.
Ellers kunne de risikere at ende op med 3 versioner: 2006 (ECMA), 2007 (første revidering til ISO) og 2008 (endelig ISO).
For det andet er din forståelse for software udvikling i Office skala absurd.
Man kommer ikke bare lige rendende og putter noget ind i en release i sidste øjeblik.
Hvis man kigger på Office 2007, så må de have haft et projekt forløb som:
engang 2002-2003 - start
november 2005 - release beta 1
april 2006 - release beta 2
november 2006 - release final
Det er aldeles umuligt at få release en ikke-triviel ændring på 6 måneder.
Nu kender jeg ikke MS's processer, men det vil sandsynligvis tage 6 måneder alene at få det estimeret, budgetteret og ressourcer allokeret.
Alle der ved en lille smule om data konvertering ved at det er en håbløs opgave at konvertere mellem to komplekse formater. Det er hverken ODF's eller OOXML's skyld.
Det var der sikkert mange som troede. Der er også mange som tror at det bringer uheld hvis en sort kat løber over vejen. Hvilket har ca. det samme videnskabelige fundament.
Så man kan tillade sig at beskylde closed source for hda som helst, fordi det er deres eget valg at folk ikke selv kan checke ??
Det er efter min mening en noget anløben moral. Man bør kun beskylde folk for noget som man positivt ved er rigtigt - ikke for noget som man ikke kan afvise.
Jeg vil godt tillade mig at spå at:
- MS får implementeret OOXML 2008 (ISO OOXML)
- MS får lavet en stort set perfekt konvertering mellem 2006 (ECMA) og 2008 (ISO)
- konvertering til/fra ODF muligvis bliver bedre end de eksisterende men at der altid vil være nogle issues
MS har haft et ½ år til at få styr på koderne (dvs fra september til marts.) Det er en absurd tanke at MS skal bruge over ½ år på at få koden i orden.
For det første venter MS naturligvis på ISO's godkendelse inden de går igang.
Ellers kunne de risikere at ende op med 3 versioner: 2006 (ECMA), 2007 (første revidering til ISO) og 2008 (endelig ISO).
For det andet er din forståelse for software udvikling i Office skala absurd.
Man kommer ikke bare lige rendende og putter noget ind i en release i sidste øjeblik.
Hvis man kigger på Office 2007, så må de have haft et projekt forløb som:
engang 2002-2003 - start
november 2005 - release beta 1
april 2006 - release beta 2
november 2006 - release final
Det er aldeles umuligt at få release en ikke-triviel ændring på 6 måneder.
Nu kender jeg ikke MS's processer, men det vil sandsynligvis tage 6 måneder alene at få det estimeret, budgetteret og ressourcer allokeret.
Der VAR problemer med formatet og der er ER problemer med formatet. Enhver der bruger de OOXML konverterer der er til rådghed ved at det ikke virker.
Alle der ved en lille smule om data konvertering ved at det er en håbløs opgave at konvertere mellem to komplekse formater. Det er hverken ODF's eller OOXML's skyld.
Jeg må ærligt tilstå at jeg regnede med at der var en "monster" konverter på markedet i løbet af kort tid
Det var der sikkert mange som troede. Der er også mange som tror at det bringer uheld hvis en sort kat løber over vejen. Hvilket har ca. det samme videnskabelige fundament.
Nej det er jo netop forbandelsen. Når man ikke giver indsigt, vokser der fortolkninger ud af det.
Så man kan tillade sig at beskylde closed source for hda som helst, fordi det er deres eget valg at folk ikke selv kan checke ??
Det er efter min mening en noget anløben moral. Man bør kun beskylde folk for noget som man positivt ved er rigtigt - ikke for noget som man ikke kan afvise.
HVIS MS bøffer den og ikke formår at få deres konverter/format i orden vil alle vide det.
Jeg vil godt tillade mig at spå at:
- MS får implementeret OOXML 2008 (ISO OOXML)
- MS får lavet en stort set perfekt konvertering mellem 2006 (ECMA) og 2008 (ISO)
- konvertering til/fra ODF muligvis bliver bedre end de eksisterende men at der altid vil være nogle issues
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund