U mnie straciło wszystko.

Rownie dobrze moglbys powiedziec, ze norma ISO okreslajca standard ethernetu (802.costam) jest sprzeczna z norma ISO okreslajaca Token Ring (numerka nie pamietam).

Są pewne rozbieżności, ale takie właśnie było założenie MSO 2007.

Nie wiadomo do końca, ale ponieważ były dokonywane zmiany w specyfikacji ECMA, to pewnie są miejsca, w których się różnią. W tej chwili można chyba zasadnie mówić o dwóch formatach: “MSO2k7 OOXML” i “ISO OOXML”, a co dalej to się na pewno jeszcze okaże.

docx raczej nie jest w pełni zgodny z OOXML (zresztą OOXML chyba jeszcze nie jest skończony?).

Z tym OOXML to było tak:
Pierwszą normą promowaną jako OOXML były formaty zastosowane w MSOffice2007.
Drugą odmianą OOXML była ta, która została przedstawiona do ISO za pierwszym razem (już wtedy mówiło się o niezgodności tej wersji OOXML z formatami MSOffice).
Trzecia wersja OOXML powstała po odmowie ISO tzw. “szybkiej ścieżki” standaryzacji i wprowadzeniu wielu poprawek. Ta wersja została niedawno “standardem” ISO.

Obawiam się jednak, że Microsoft zgodnie ze swoim zwyczajem znów nie uszanuje swoich własnych norm i w następnej wersji MSOffice zaimplementuje OOXML w sposób, jaki mu się spodoba (oczywiście nie udokumentowując zmian). Z drugiej strony, takie działanie, na dłuższą metę, może obrócić się na niekorzyść OOXML względem ODF. OOXML już teraz postrzegany jest jako trudny do zaimplementowania w oprogramowaniu. Po ew. wprowadzeniu przez Microsoft nieudokumentowanych dziwactw, implementacja OOXML byłaby jeszcze trudniejsza (i potencjalnie gorsza jakościowo).
Współcześnie, celem producentów programów biurowych jest zapewnienie interoperacyjności swoich produktów a nie współpraca z takim czy innym konkretnym programem innego producenta. Producent stanie przed wyborem:
czy
zaimplememntować mniej nadający sie do tego celu, uzależniony de facto od jednego producenta, niedojrzały OOXML – do którego trudno mieć zaufanie, ale za to obecny w MSOffice,
czy
osiągnąć założony cel za mniejsze pieniądze, implementując (w większości przypadków – dopracowując implementację) bardziej powszechny i spełniający założenia interoperacyjności, otwarty i niezależny ODF.

Odpowiedź na to pytanie wbrew pozorom wcale nie jest oczywista. Przykładem mogą być standardy sieciowe w Internecie – standardy istnieją i obowiązują, lecz rzadko są stosowane. Zarzucenie rynku kiepską technologią spowodowało zniewolenie umysłowe webmasterów, którzy ignorując obowiązujące standardy, w czambuł dostosowują serwisy do tej technologii, bez względu na rzcjonalne przesłanki.

Fakt ustanowienia OOXML standardem ISO jest już nazywany “tragedią standaryzacji”. Sądzę, ze to jest najlepsze określenie tego, co się wydarzyło. Pamiętam czasy, kiedy rozwojem technologii informatycznych w większym stopniu rządził rynek aniżeli standardy, (z których zresztą wiele jeszcze nie istniało). W momencie, gdy niektórzy producenci zaczęli stosować praktyki monopolistyczne, lekarstwem na nie oraz ostoją interoperacyjności i rozwoju technologii informacyjnych stały się standardy techniczne.
Niestety, wygląda na to, że instytucje standaryzacyjne nie oparły się tym praktykom (nota bene inny przykład HTML5). W obliczu ich kompromitacji, “polem walki” znów stał się rynek, w którym bardziej liczy się powszechność implementacji i dostępność technologii aniżeli jej jakość (statystycznie, wydaje się obowiązywać prawo Kopernika zastosowane do towaru: “Towar gorszy wypiera lepszy”). Tak więc wszystko zależy od świadomości problemu i priorytetów strategii firm programistycznych. Dostrzegł to, jako businessman, Shuttleworth publicznie wyrażając niechęć do inwestowania w OOXML i wskazując niebezpieczeństwo (rynkowe, nie ideowe) wynikające z pohopnego alokowania kapitału w OOXML kosztem ODF i w perspektywie – uzależnienia się od jednego producenta.
ODF ma dużą przewagę czasową nad OOXML. Przy efektywnym jej wykorzystaniu, na rynku powinno w krótkim czasie pojawić się bardzo dobre jakościowo narzędzie dla programistów oraz upowszechnić:
- dobra i lekka przeglądarka ODF,
- wtyczki do przeglądarek internetowych oraz IE,
- porządna wtyczka do MSOffice, umożliwiająca ustawienie formatów ODF jako domyślnych,
- konwertery formatów (stacjonarne i sieciowe),
- być może także serwisy internetowe służące konwersji OOXML na ODF, utrzymywane przez producentów programów wspierających ten format.
Wtedy ODF, gdy przez swoją powszechność stałby się standardem de facto (a takie rynek lubi), Microsoft zostałby ze swoimi programami “na lodzie” i sam szybko zaimplementowałby w nich ODF, zapominając o OOXML.
Miejmy nadzieję, że ostatnie wydarzenia zmotywowały programistów i ich szefów do przyspieszenia prac nad pełną implementacją ODF w swoich produktach.

Ale spójrz na to inaczej: jak by nie było w Ubuntu standardowo są takie programy jak Tomboy i F-spot (które podobno nie są standardowymi programami z Gnome), które oparte są o technologię .NET…

Co za problem ? Wywalić OO z Ubuntu po instalacji i zainstalować standardowe OpenOffice z debów które będzie zawierało wsparcie dla standardu. Albo jeszcze lepiej zasugerować takie rozwiązanie np. ludziom od Linux Mint.

A co z plikami doc, xls i ppt ? Też będą przez Pana Astronautę nieobsługiwane, bo zły Microsoft upublicznił dokumentację do tych formatów później niż powinien ?

ps. Dzisiaj zgłosiłem via launchpad błąd nieuruchamiania się kalkulatora w 8.04. Ciekawe czy ta “not poorly defined” firma raczy poprawić ów błąd do czasu wydania wersji ostatecznej ?

W twierdzeniu że OOXML jest “niewolnym standardem własnościowym” Microsoftu jest mniej więcej tyle samo racji, ile w twierdzeniach że wczoraj Polska utraciła niepodległość i stała się “województwem Unii Europejskiej”

Myślę, że może też być inaczej. Rządy i inne instytucje już przechodzą na otwarte rozwiązania – nie tylko standardy. Na Linuksa nie ma MSO więc będzie to OO. Jeśli na jakimś kompie będzie potrzebny Windows to pojawi się pytanie OO czy MSO. Skoro MSO jest niezgody ze standardami to jest do du… kosza
-
Więc dla mnie jeśli szybko rozpowszechni się standardowe pliki OOXML (nie te z MSO) to, paradoksalnie, format ma większą szansę upaść. Poza tym jeśli instytucje zobaczą jakie są z tym jaja to może pomyślą zanim wybiorą rozwiązanie.

+1. Dokładnie to samo miałem napisać.

ale czyż nie lepiej byłoby gdyby MS od razu zaimplementował odf. Widać nie mają w tym swojego interesu, a że mają monopol (póki co) na rozwiązania biurowe, to go wykorzystują forsując OOXML

Byłbym ostrożniejszy twierdząc, że “wysyłając do kogoś *doc mamy gwarancję, że na pewno go otworzy” Z pewnością uzależnione jest to od środowiska użytkowników, do których się wysyła. Ja ostatnio wysłałem szablon w formacie ODF oraz Word97 (pisany w oryginalnym Wordzie) w otoczeniu kilku plików *pdf. PDFy zostały odczytane a z szablonem Worda były duże kłopoty. Więcej wypełnionych formularzy otrzymałem w formacie *odt aniżeli *doc.
Zaryzykuję zatem tezę, że (przynajmniej w tym środowisku użytkowników do którego pisałem) to raczej nie od formatu pliku a od poziomu znajomości obsługi komputera zależy możliwość jego obsługi przez użytkownika.

I nigdy nie wydalo ci sie dziwne, ze olbrzymia wiekszosc uzywanych przez ciebie standardow – chociazby praktycznie wszystko zwiazanenie z internetem powyzej warstwy drugiej OSI – nie jest ustandaryzowana przez ISO, tylko przez inna instytucje, a konkurencyjne standardy ISO jesli nawet sa, to nikt ich nie uzywa?

To oczywiste. Ale skoro rozsądni ludzie zaczęli przechodzić na otwarte rozwiązania to miejmy na dzieję, że będą też na tyle rozsądni by poznać OOXML. Poza tym jeśli OO będzie w stanie obsługiwać oba standardy a MSO tylko jeden no to wybór jest jeszcze oczywistszy

Czyli dokladnie ten sam cel co ze standaryzacja ODF-a. Kali ustandaryzowac dobrze, Kalemu ustandaryzowac zle? ;->