PKN poparł OpenXML
Komitet Techniczny 182 Polskiego Komitetu Normalizacyjnego zagłosował ZA przyjęciem formatu Microsoft Office OpenXML jako normy ISO 29500. Taki głos zostanie przekazany do ISO.
Polski komitet głosował za 17 głosami przy 3 wstrzymujących się i braku głosów przeciwnych. Informacja ta pochodzi z listy dyskusyjnej PTI oraz strony PKN.
Polskie głosowanie było pod wieloma względami bezprecedensowe, bo towarzyszyła mu potężna kampania społeczna przeciwko OpenXML oraz konsultacje zainicjowane przez sam KT PKN.
Dlaczego więc KT 182 zagłosował "za"? Moje prywatne zdanie jest takie że argumentacja przeciwników ISO 29500 była słaba i miejscami niezbyt merytoryczna. A przynajmniej niewystarczająco merytoryczna dla zablokowania standardyzacji OpenXML. Pisałem o tym na blogu SecurityStandard. Ale to jest moje prywatne zdanie - najchętniej przeczytałbym jakiś komentarz lub uzasadnienie pochodzące od samej Komisji.
Na marginesie warto dodać, że podobnie zagłosuje amerykański INCITS. Co ciekawe, polskie głosowanie najpierw odbyło się w Komitecie Technicznym 171 (ds Oprogramowania i Sieci Komputerowych), który zagłosował przeciwko OpenXML ale potem zostało przeniesione do KT 182 (ds. Ochrony Informacji w Systemach Teleinformatycznych).
- Zaloguj się lub zarejestruj by odpowiadać
- Generate PDF file
- Wersja do wydruku
Nawigacja
Popularne strony
Logowanie
Odpowiedzi
Cała dyskusja jest bardzo ciekawa. Zwłaszcza że powszechnie w SIWZ dla projektów dla administracji publicznej jest formułowane żądanie użycia J2EE czy innych technologii nie ms-owych. Jeżeli w jakimś SIWZ znajdę wymóg użycia OpenXML do opisywania dokumentów elektronicznych to przyjme to z radością i nieskrywaną satysfakcją. Oczywiście tak jednoznaczne wyznaczanie technologii czy standardów używanych w projektach informatycznych jest krzywdzące. Dlaczego nie łączyć kilku (albo albo). Pewnie uznacie to za naiwność, ale mam nadzieję ktoś kiedyś pozwoli spokojnie egzystować dwom światom (MS i JS) i da programistom takim jak ja spokojnie żyć i pisać oprogramowanie z uzyciem takich technologii jakie uważam za najbardziej uzasadnione. Na dzień dzisiejszy wygląda to tak, że oferta zawiera WIELKIE TAAAK dla dwusystemowości i pełnej przenaszalności projektu pomiędzy systemami operacyjnymi ... a życie jest życiem.
Może nie zrozumieli pytania? Jak można być tak niekompetentnym, żeby głosować za przyjęciem tej nędznej pseudospecyfikacji? To i tak straszny wstyd, że w ogóle trafiło pod głosowanie.
Duplikat usunąłem.
Co do konkretnych pytań:
Dlaczego robisz tę krecią robotę? Rozumiem, że "krecia robota" polega na tym, że piszę to co myślę o argumentach NOOXML zamiast te refleksje zachować dla siebie w imię "słusznej sprawy"? Otóż piszę o nich m.in. dlatego, że nie mam zamiaru się pod nimi podpisywać - tymczasem ISOC był wzywany do oficjalnego poparcia apelu, przeciwko czemu zaprotestowałem a dalej już samo poszło. Mam doświadczenie we flame wars jeszcze z Fido, więc nie mam zamiaru dać się zakrzyczeć.
Magiczny Word95. Pisałem o tym z 50x - podnoszenie tego argumentu jest jedną z przyczyn dla których uważam argumentację NOOXML za niepoważną. Flagi takie jak Word95 są flagami opcjonalnymi i panikowanie że ich obecność "uniemożliwi powstawanie niezależnych implementacji" albo "uniemożliwi odczytywanie DOCX programami innymi niż Microsoft" to klasyczny FUD. Obszerniejszą analizę tego problemu przedstawiałem u Vagli.
Microsoft wydał na kupienie głosów w krajach nordyckich i kampanię FUD w pozostałych. Zgadza się, domniemane praktyki korupcyjno-lobbyingowe Microsoftu są nieuczciwe. Należy je piętnować, niekoniecznie natomiast należy robić to samo z drugiej strony. Tymczasem w kategorii FUD przeciwna strona raczej bije Microsoft na głowę. Ja osobiście nie zamierzam stosować tych technik w obronie stosunkowo słabego standardu jakim jest ODF tylko dlatego że "nasz on".
Zastanawiam się zresztą czy spór nie jest w dużym stopniu jałowy, bo:
Więcej tutaj pytań niż odpowiedzi, ale niestety na takim etapie jest ten rynek. Chwała OpenOffice że zmusił Microsoft do wysiłku, podobnie jak konkurencja z Linuksem wymusiła na nich poważne podejście do bezpieczeństwa. Nie oznacza to jednak z automatu, że w każdym zastosowaniu OpenOffice i Linux są lepsze od MS.
Co do autospacelikeword95 i podobnych -- są opcjonalne i pewnie dokument da się zaimportować, choć będzie się wizualnie różnił od MS Office. I znowu pojawią się zarzuty względem otwartych rozwiązań biurowych -- "zrezygnowalibyśmy z MS Office, ale dokumenty się nie przenoszą"... Pułapka bez wyjścia.
Jak piszesz są to zapewne rzeczy w niedużym stopniu wpływające na layout i dokument da się przeczytać. Jednak pretensje do MS mam o to, że trąbiąc o tym jak otwarty jest ten OOXML "zapomina wspomnieć" o tych paru kawałkach, gdzie jednak jest zamknięty.
To jest zresztą pikuś. Popatrz na tego linka co wcześniej podałem. Tam z perspektywy programisty przedstawiona jest analiza arkuszy z nowego Excela. W wielu miejscach autorzy standardu wybrali najwyraźniej najmniej intuicyjne rozwiązanie, tak aby utrudnić powstanie jakiejkolwiek alternatywnej implementacji. Zmiana jednej komórki pociąga za sobą konieczność przebudowania całych tablic gdzieś indziej.
> Rozumiem, że "krecia robota" polega na tym, że piszę to
> co myślę o argumentach NOOXML zamiast te refleksje zachować
> dla siebie w imię "słusznej sprawy"
Nie, krecia robota polega na tym, że piszesz wyłącznie o dobrych stronach OOXML, a pomijasz krytykę twierdząc, że niektóre zarzuty wobec OOXML są również prawdziwe wobec ODF. W mojej opinii a priori zakładasz, że skoro część zarzutów jest mało istotnych, to i wszystkie są takie. Cóż z tego że masz swoją jedną ulubioną cechę (szyfrowanie i podpisywanie) jeśli będziesz ograniczony do jednej, zamkniętej implementacji z Microsoftu? Bo z powodów przytoczonych wcześniej, żadna otwarta implementacja nie będzie mogła działać idealnie, ergo nigdy nie przyjmie się na szeroką skalę. Czy Ciebie, jako badacza security nie niepokoi fakt, że instytucje rządowe i firmy mają same skazywać się na stosowanie zamkniętego softu w imię tylko tej jednej małej funkcji jak podpis elektroniczny?
Jeszcze dla uzupełnienia cytat z wypowiedzi na liście PTI pani Eli Andrukiewicz, przewodniczącej KT 182:
I dokładnie o tym pisałem m.in. na blogu Security Standard oraz na liście ISOC-PL.
Sensem tagów opcjonalnych w dowolnym standardzie jest to, że implementacja tego standardu może ich nie implementować i mimo to pozostawać zgodna ze standarem. Standard nie oznacza równania w dół, tylko wspólny obowiązkowy mianownik.
Nie jest prawdą, że nieudokumentowane rozszerzenia opcjonalne dyskwalifikują standard jako otwarty. W protokole ISAKMP (RFC 2408, sekcja 3.16) jest zdefiniowany mechanizm "Vendor ID Payload", który pozwala autorowi aplikacji dodawać do protokołu opcjonalną funkcjonalność robiącą co mu się podoba. Każdy producent VPN z nich korzysta - Checkpoint, Cisco itd. Część z nich jest publicznie znana (np. Dead Peer Detection), a część nie i nikt nie rozrywa szat że IPSec jest protokołem zamkniętym.
Dlatego afera z tagami Word95 wydaje mi się robiona na siłę, tym bardziej że Microsoft opisał do czego one służą - do zachowania wstecznej kompatybilności z dokumentami konwertowanymi ze starego formatu DOC. Nie widzę powodu, żeby Microsoft nie miałby tej kompatybilności maksymalizować, ułatwiając użytkownikom płynne przejście do nowego formatu.
Natomiast trzeba pamiętać, że standardyzacja OpenXML jest bronią obusieczną. Jeżeli administracja publiczna ogłosi przetarg na system zgodny z ISO 29500 to będzie on musiał być zgodny z ISO 29500 a nie z Microsoft Office 2007. Standardyzacja oznacza także odpowiedzialność dla Microsoftu.
Nie jest też prawdą że piszę "tylko o dobrych stronach OOXML" i "pomijam krytykę". Wyraźnie napisałem na blogu, że nie jestem w stanie ocenić dużej części argumentów NOOXML jak XML-owe namespaces itd bo się na tym nie znam. Oceniłem te z nich na których się znam i w tym podzbiorze znalazłem argumenty naciągane.
Ale odnoszę wrażenie, że grzechem jest w ogóle jakiekolwiek kwestionowanie argumentów anty-MSOOXML. Jest to jednak specyficzna forma politycznej poprawności, do której mam stosunek lekceważący ponieważ przedkłada ona wolę tłumu nad samodzielne myślenie i odczucia.
Grzechem jest rekomendowanie OOXML na podstawie drobnego wycinka argumentów za i przeciw.
Proszę zacytować fragment wypowiedzi, w których rekomenduję OOXML.
No cóż, fakt że jawnie nie piszesz, że popierasz OOXML, ale:
1) nazywasz kampanię przeciw OOXML "nagonką" i bagatelizujesz argumenty tej grupy
2) znajdujesz pewne wycinki specyfikacji wg których OOXML miałby być lepszym standardem
Zdaję sobie sprawę, że brzmi to jak "kto nie z nami, ten przeciwko nam", ale niestety tak jest w rzeczywistości. Jeśli tak jak proponujesz będziemy siedzieć cicho, bo "nikt nie zrobił rzetelnej analizy obu formatów" to popieramy standard MS bez żadnego zająknięcia. Zobacz jakimi kruczkami się posłużyli aby przepchnąć go jak najszybciej, aby nie dopuścić krytyki do głosu.
1) Zasada "kto nie z nami ten przeciwko nam" była jedną z głównych zasad bolszewików. Warto zobaczyć jak skończyli żeby nie powtarzać cudzych błędów.
2) Nikt nie każde "wam" siedzieć cicho. Pomiędzy milczeniem a histerycznym wrzaskiej jest cała masa wartości pośrednich.
3) Nazywam kampanię przeciw OOXML "nagonką" jak każdą kampanię, w której stosuje się argumenty nierzetelne i demagogiczne służące tylko i wyłącznie udupieniu danego standardu. Jak można inaczej nazwać np. seans nienawiści jaki urządzono szefowi projektu Gnome, Miguelowi de Izaca na Slashdocie po tym jak powiedział że OpenXML jest OK?
4) Nie zauważyłem, żeby ktoś "nie dopuszczał krytyki do głosu" w przypadku OOXML.
sorry za powójny post, miałem jakieś problemy z CAPTCHA.
> towarzyszyła mu potężna kampania społeczna przeciwko OpenXML
Tak, za to Microsoft nie robił żadnej kampanii wiedząc że jego doskonały standard OOXML sam się obroni. Kampania anty-OOXML kosztowała i tak pewnie mniej niż 10% tego co Microsoft wydał na kupienie głosów w krajach nordyckich i kampanię FUD w pozostałych (bo na razie nie ma dowodów na jawne kupowanie).
> argumentacja przeciwników ISO 29500 była słaba i miejscami
> niezbyt merytoryczna
O ile można się zgodzić, że miejscami była słaba i znaleziono problemy, których również ODF nie rozwiązuje, to Twoje zdanie jest niesamowicie wybiórcze. Skoro faktycznie była taka słaba, to pewnie mógłbyś obalić ich większość, ale przyczepiłeś się tylko do zabezpieczenia pola w arkuszach i podpisu elektronicznego.
Czemu jednak taktycznie pomijasz główne zarzuty, m.in. brak otwartości OOXML (wbrew nazwie -- to jest szczyt hipokryzji IMO). Mimo że ma 6000 stron to nie udało się w nich zmieścić opisu w jaki to magiczny sposób Word95 robi dzielenie wyrazów itp. odwołania do wcześniejszych zamkniętych pseudostandardów.
Nota bene brak podpisu w standardzie to żadna przeszkoda -- podpisywanie może odbywać się na dotychczasowych zasadach i przy użyciu istniejących standardów, np. OpenPGP. Czy coś takiego nie mogłoby znaleźć się w SIWZ?
Sam przecież wiesz, że jeśli ktoś umieści w SIWZ -- "zgodny z ISO 29500" dla wszystkich będzie to oznaczać produkt MS, mimo że on sam standardu tego nie spełnia! O zamkniętych pozostałościach można poczytać tutaj: http://ooxmlisdefectivebydesign.blogspot.com/
Dlaczego robisz tę krecią robotę -- naprawdę nie wiem. Rozumiem przywiązanie do wszelkich zagadnień związanych z szyfrowaniem i niedomaganie pod tym względem ODF, ale czyż nie prościej i lepiej byłoby poprawić ODF zamiast wprowadzać ewidentnie zepsuty pod innymi względami OOXML?
Zobacz to: http://di.com.pl/news/17418,Standaryzacji_OOXML_dziwne_przypadki.html
Co ciekawe, polskie głosowanie [...] zostało przeniesione do KT 182 (ds. Ochrony Informacji w Systemach Teleinformatycznych).
Europejska szkoła - czy pamiętacie, że sprawa patentowania oprogramowania w Europarlamencie była rozpatrywana przez komitet ds. rybołówstwa?