Keresés

Új hozzászólás Aktív témák

  • Gregorius

    őstag

    valóban jó minőségű és a magyar oktatás számára a bevett módokon csak nagy költséggel megvalósítható technológiákat kínálnak ingyen
    a magyar oktatás becsatornázása egy magáncég rendszerébe függőségekhez és későbbi, esetleg most még előre nem látható problémákhoz vezethet
    Nemtom mi a gond. Az ajánlat szerves része a nyújtott szolgáltatáson túl a függőség meg jópár egyéb kockázat is, a felhő alapvető természetét beleértve. Ennek fényében kell mérlegelni az ellentételezést.
    Tetszettek volna jobb ajánlatot tenni a "nem-magáncég" és/vagy "nem-nagy költségvetésű" konkurensek.

  • Gregorius

    őstag

    válasz joghurt #17 üzenetére

    Ezért éri meg a Microsoftnak akár komoly "támogatásokat" belefeccölni a magyar oktatási rendszerbe: Ha a kölök csak ezzel találkozik az iskolában, akkor Jucika felnőtt korában is kizárólag ezt fogja tudni használni.
    Miért nem tetszik jobb alternatívát adni? Akkor meg csak azzal fog.

    Nálunk egyébként a vonatkozó jogszabályok ellenére megteheti számtalan közhivatal, hogy kizárólag .doc formátumban tesz ki dolgokat
    És azt mégis hogy? Kedves állampolgárnak van papírja, van ceruzája, minden adott a feljelentéshez. Akár névtelenül. Az AbevJava nevű förmedvény sem kormányzati jótékonysági esemény miatt keletkezett a korábbi Windows-only rendszerből.

    Az EU közigazgatásban egyszerűen le kéne tiltani az USA-ból származó nem nyílt forráskódú megoldásokat.
    Itt lehet érdeklődni:
    http://www.europarl.europa.eu/meps/hu/search.html?country=HU
    Ne reménykedj sikerben, ennél egyértelműen előnyösebb dolgokban sem tudnak előbbre jutni.

  • Gregorius

    őstag

    válasz bambano #44 üzenetére

    a libre nem *szerintem* etalon, hanem kormányhatározat van róla, hogy a közigazgatásban etalon. be volt linkelve az erről szóló hír.
    Ha (párt)állambácsi a LibO-t írná elő etalonként, az nem cégfüggetlen megoldás lenne, hanem köztörvényes vendor lock-in. A szabványos formátumot írja elő, ami egész érdekes módon egy centit nem szűkít a szóba jövő irodai csomagok körén.
    A nyílt forrású irodai szoftver pusztán ajánlott, nem kötelező, ettől az ajánlástól viszont "műszakilag vagy gazdaságilag indokolt esetben" el lehet térni. Gyönyörű, politikusul megírt gumiszabály arra, hogy az aktivistáknak is benyaljanak és továbbra is mindenki azt használjon, amit akar.

    ezt, mint tényt, kellene végre lenyelni
    Nem tény az, csak maszatolás.

    [ Szerkesztve ]

  • Gregorius

    őstag

    válasz bambano #47 üzenetére

    persze, mert az ms vendor lockin szép és jó és nem köztörvényes...
    Na ne demagogizáljunk itten kéremszépen. Az hogy ne az MS legyen törvénybe írva az nem érv amellett, hogy ellenben más viszont legyen. Senki sem kötelez MS szoftver használatára. Használhatsz a közigazgatásban saját GarázsOffice™-t is, amennyiben az képes "nyilvánosan hozzáférhető, korlátozás nélkül alkalmazható és nemzetközi szabványügyi szervezet által elfogadott szabványra épülő" formátumú dokumentumot előállítani. Az hogy ez gazdaságilag mennyire racionális egy ettől független kérdés.

  • Gregorius

    őstag

    válasz bambano #68 üzenetére

    - a teljes szabványosítási folyamat szemenköpése volt, hogy szabványosították
    - nem xml.

    Megint ugyanazok az érvek, mint a múltkori topicban, de akkor tessék:
    "nyilvánosan hozzáférhető, korlátozás nélkül alkalmazható és nemzetközi szabványügyi szervezet által elfogadott szabványra épülő"
    Látsz a szövegben minősítést az elfogadás módjáról? Vagy bármit, ami kikötné, hogy csak X Y-nak tetsző módon elfogadott szabvány lehet? El lett fogadva. Szar ügy. A wikipedia sem válogat aranyérmes és aranyérmes között aszerint, hogy hány liter dopping volt benne, amit utólag betiltottak, akármennyire nem volt tisztességes az eljárás.

    ugye te is érzed, hogy a közigazgatás működésében gazdasági racionalizmust keresni eléggé sziszifuszi dolog?
    A gazdasági racionalitás egy igen bonyolult dolog. Ha a kedves ügyintéző ellenáll és szabotálja a munkát az is az. Azért is mert közvetlen kárt okoz és azért is mert kirúgatja magát és ki kell képezni a helyére egy újoncot (aki adott esetben ugyanúgy ellenállhat).

    Ami meg sem gazdaságilag sem technikailag nem jobb az lehet egyrészt politikai haszonszerzés (valamely társadalmi csoport igényeinek kielégítése), vagy korrupció. A kockázatok és mellékhatások tekintetében teccettek volna másra szavazni. Ha meg nincs jobb, akkor lehet saját jelöltet produkálni. A svédeknek egyszer már sikerült.

  • Gregorius

    őstag

    válasz MichaelSD #109 üzenetére

    Semmi nem indokolja az MS szoftverek alkalmazását oktatásban és a közszférában.
    Közszférában egyet azért mondok: tudtommal a LibreOffice - egészen az utóbbi időkig - elég vacakul áll a kollaborációval. Sok helyen használnak SharePoint szervert erre a célra, ami pöccre integrálódik MSOffice-szal. Irdatlan (értsd @#$% :((() sokba kerül a licensz, ellenben megszokták és működik.

    [ Szerkesztve ]

  • Gregorius

    őstag

    válasz bambano #116 üzenetére

    biciklistáknál kipakolták a vitrint mostanában...
    Biciklistáknál a főkolompos aktív érvényben lévő szabály ellen vétett.

    de mégegyszer: az ooxml nem szabványos xml. pont.
    Attól, hogy ezt hajtogatod még nem lesz igaz. A kormányok (a miénk is, másé is), az IT Café szerkesztősége, a wikipedia meg még sokan mások sem így gondolják. Még ha vannak is fenntartásaik. Az nincs benne a törvényben, hogy azt kell használni, amit TE szabványként fogadsz el. Ellenben az benne van, hogy nemzetközi szavbányügyi szervezet által elfogadott, amely kitételnek nem csak a sokat kritizált ISO hanem az ECMA is megfelel.
    A szabvány a követelmény, az hogy mennyire xml vagy nem az mellékes. Ugyanígy a minőségre sincs semmilyen előírás (sem a szabványra sem a szoftverre), bár ez nehezen is volna kivitelezhető.

    ráadásul nem is "korlátozás nélkül alkalmazható".
    Mert miért nem?

    [ Szerkesztve ]

  • Gregorius

    őstag

    válasz bambano #123 üzenetére

    Szeretettel várom a pontos megjelölését annak a szakasznak, ami nem implementálható és egyébként kötelező a szabványnak megfeleléshez. A szabvány teljes szövege innen letölthető:
    http://standards.iso.org/ittf/PubliclyAvailableStandards/

  • Gregorius

    őstag

    válasz #40553216 #126 üzenetére

    Most komolyan, újra csak az MS zárt és nagy eséllyel direkt akadályozó módon történt megvalósításával való együtt nem működésben a LO a hibás? Na ne má’!
    Azt mondtam, hogy a LO-nak nincs (nem volt?) integrált kollaborációs megoldása. Egy szóval nem mondtam, hogy pont az MS megoldásával kellene integrálódnia, főleg nem egy olyan förmedvénnyel, mint a SharePoint.

  • Gregorius

    őstag

    válasz #40553216 #132 üzenetére

    Ez egy egész érdekes táblázat figyelembe véve hogy két IE és két Win2003 szerver is van benne.

    A Windowsok között pedig sajnos igen nagy átfedés van. Pl. a Vista és a Server 2008 gyakorlatilag ugyanaz a kernel, az egyes generációk között is rengeteg az újrahasznált illetve nem átdolgozott kód. Nem véletlen, hogy ha jön egy sebezhetőség az szinte mindig minden Windowst érint.
    A ráépülő feature-ökben lehetnek különbségek, pl. asztaliban van pasziánsz, szerverben van DNS szerver. Ezekben viszont viszonylag ritkán szokott galiba lenni, a hibák többsége a közös magban van.

    #137
    A csoportélményre gondolsz?
    A közös real-time szerkesztésre gondolok. [link] Ez egy elég egzotikus feature, de pár helyen már találkoztam rá igénnyel.
    Aztán van amit az MSO nem támogat, pl. LO-val lehet szerver oldalon GUI-mentes fájl konverziót csinálni. Ez MSO-val sem kizárt, de egyrészt nem támogatott, másrészt finoman szólva instabil. A hivatalos MS megoldásért meg egy méretes, több millió zsébe fájó csomagot kellene licencelni, amit épeszű ember ezért az egy feature-ért nem ad ki.

    Vajon mi szüksége volt az MS-nek ennek szabványosítására, amikor annak ellenére, hogy a saját tulajdona volt minden hozzá kellő anyag, mégis csak az MS Office 15-ös verziójára ígérte a saját szutykával való teljes kompatibilitást?
    Szabványosítani azért kellett, mert egyre nagyobb igény volt rá a piacon (élén a kormányzatokkal). Az implementálás meg viszonylag követi a szabványok elfogadását:
    MSO2007: Ecma-367 kompatibilis (az Ecma elfogadása után az első verzió).
    MSO2010: ISO transitional kompatibilis. Az ISO elfogadása után az első verzió, a transitional nagyban egyezik az Ecma-val, de van pár breaking change.
    MSO2013: végre ISO strict kompatibilis. Ami tulajdonképpen a transitional részhalmaza a useWord97LineBreakRules meg hasonló finomságok nélkül.

    Az hogy az ISO strict megvalósítása ilyen sokáig tartott valóban szégyen.

  • Gregorius

    őstag

    válasz bambano #141 üzenetére

    ugye te most direkt kötözködsz annak tudatában, hogy a szabvány elleni egyik komoly kifogás az volt, hogy több, mint 6000 oldal, következésképp záros határidőn belül akkor se tudnám megmondani, melyik paragrafus, ha akarnám?

    majd ha működni fog az sszi webje, onnan letöltöd a részletes elemzését a szabványnak (ez nem sok, 2-3 oldal), és elolvasod, ha már anno nem tetted meg.
    Ha erre a linkre gondolsz (cím: Gondolatok az OOXML kapcsán)
    http://www.szszi.hu/kozlemenyek/sajto/2007/08/28/ooxml_gondolatok/
    amit a web archívból visszanéztem cikk, az 2007 környékére van datálva és pl. olyan állításokat tesz, miszerint a szabvány előírja a Windows Metafájl támogatását. Az összes utalás, amit az ISO szabványban wmf-re találtam nem kötelezően megvalósítandó és csak példát mutat be.
    Az az ominózus useWord97LineBreakRules, ami olyan gyakran előkerül és amit állítólag úgy kell implementálni "ahogyan a Word97" konkrétan két oldalon részletezve van az ISO 3rd edition/part 4/14.7.3.55 szakaszban (nálam 155. oldal), az Ecma 4th editionben ugyanitt.

    Akkor tudom komolyan venni hogy nem lehet implementálni a szabványt, ha valaki (akár te akár más) pontosan megnevezi hogy hol van a probléma, és ennek ellenére miért tudta mégis implementálni a Document Foundation a LibreOffice-ban, a Google Docs, a Go-oo a KOffice és még sokan mások.

    Valaki csak meg tudja mondani, hogy mi nem implementálható, elvégre megpróbálta, nem? Várni van időm. Megalapozott konkrét racionális állításokra is van, FUDra nincs.

    [ Szerkesztve ]

  • Gregorius

    őstag

    válasz bambano #147 üzenetére

    ott van a probléma, hogy a szabvány egyes részei zártak. úgy lehet implementálni a szabványt, hogy a zárt részeket kihagyod.
    És én pont arra várok már több poszt óta, hogy ezeket megnevezd. Akár önerőből, akár úgy hogy keresel valakit, aki nálad jobban tudja.
    De tegyük fel, hogy vannak ilyen részek. Tudsz olyan implementációt csinálni, ami megfelel a szabványban leírt konformancia követelményeknek anélkül, hogy ezt a bizonyos lehetetlen részt implementálnád? 4. kiadás 1. rész 2. fejezet definiálja, hogy szabványos implementációnak mit kell teljesítenie. Nem az egész szabványt. Ha az egyik program csak a WML Strictet, a másik csak a WML Transitionalt implementálja, akkor mindkettő tökéletesen megfelel a szabványnak, interoperálni viszont esélyük nincs. Teljesen egyenértékű implementációt meg még a legkifogástalanul megírt szabványok esetén (és az OOXML ettől nagyon távol van) is nagyon nehéz összehozni.

    #150
    Azon kívül ugye látható bizonyíték az MS azon vicces kijelentésével szemben, hogy az új verzió kernelét teljesen újraírták. Persze, a ctrl-c ctrl-v típusú szakdolgozatírás módszerével.
    Szimpla kampánydumáknak nem kell bedőlni. Valamennyire látszik, hogy átdolgozták, mert a kernelhibák gyakran vagy az XP és előtti vagy a Vista és utáni verziókat szokták érinteni, de értelmes ember ilyet csak akkor kezd a nulláról ha nagyon sok ideje van, borzasztóan unatkozik és nem akar vele záros határidőn belül pénzt keresni.

    Te szégyennek látod, sokan mások is, az MS is nyilván erre játszik rá. Pedig nem az, hanem szándékos tett. Hiszen ezalatt is a kompatibilitási problémákat azok, akik számítanak (a felhasználók, akik fizetnek), nem foglalkoznak azzal, hogy az esetleges alternatívák miért nem működnek rendesen.
    Nos ezzel kapcsolatban két észrevételem van:
    1. aki használt már életében Office Autmation-t (fogadja őszinte részvétem) annak lehet némi fogalma róla, hogy mekkora gányolás van a motorháztető alatt. Hihető, hogy ennyi ideig tartott szarkupacból valami várfélét építeni. És szégyen, hogy egyáltalán szarkupacból - ráadásul piacvezetőből - kellett. Valószínűleg ez az oka annak is, hogy a szabvány (i.e. a meglévő működés dokumentálása) is olyan lett, amilyen.
    2. ha szándékos, akkor viszont nehezen értem meg, hogy az MSO2013-ban mégis miért lett megvalósítva, miért nem húzták tovább az időt.

    További kérdés?
    Köszönöm érdeklődésed, fentebb a 2. pont.

    A szabványosítás folyamán az MS erőteljes nyomása:
    az 5419 oldalnyi specifikációt 254 nap alatt „dolgozták fel” az ISO-nál...

    Nem akarom sokadszorra leírni, úgyhogy a rövidített változat:
    A megfelelő eljárási szabályok szerint el lett fogadva. Az elfogadást megfelelő eljárási szabályok mentén meg lehet támadni, ahogy meg is történt. Ha még van folyamatban ilyen procedúra, az akár meg is semmisítheti a szabványt. Ugyanígy annak is megvan a saját procedúrája, hogy hogyan vonnak vissza egy elfogadott szabványt. Megjegyzem a jpeg szabvánnyal is majdnem ez történt.
    Az eljárási szabályok nyilván nem voltak elég jók, azért is lettek azóta felülvizsgálva, ez viszont utólag nem befolyásolja azokat a szabványokat, amelyeket a korábbi szabályok szerint fogadtak el.

    „Ez egy elég egzotikus feature, de pár helyen már találkoztam rá igénnyel.”
    Ezen egzotikus feature-re való igény kielégítésére ott a Windows ökoszisztéma. Máshová meg nem kell.

    Pontosan erre akartam kilyukadni. A kiinduló állítás (#109) "Semmi nem indokolja az MS szoftverek alkalmazását..." ezek szerint úgy folytatódik, hogy kivéve ahol mégis.

    #151
    Meg hogy a júzerek milyen fícsöröket kívánnának. Az MS a mai napig nem csinálta meg, hogy az elválasztás automatikus legyen. Nyilván a júzereknek nem kívánalom, mert úgy gondolja...
    És akkor akinek az elválasztás fontosabb a real-time kollaborációnál minden bizonnyal nem a MSO implementációt fogja favorizálni.

    Nem véletlenül létezik converter program a 2013 -as office ooxml -éről a 2010 -es office ooxml -ére.. :)
    Ha erre gondolsz ez csupán az ooxml strictre vonatkozik. Az ooxml transitionalt mindkettő tudja (elvileg) kezelni.

    #159
    nyilvánosan hozzáférhető, korlátozás nélkül alkalmazható és nemzetközi szabványügyi szervezet által elfogadott szabványra épülő" formátumú dokumentumot előállítani.
    Az ooxml körüli fiaskónak ha utánanézel, akkor rájönnél, hogy az pl pont teljesen alkalmatlan erre a célra.
    És ha végigolvasod az előző posztjaimat, akkor pontosan tudod, hogy mit kérek most már tőled is. Ha ennyire biztos vagy a dolgodban, bizonyára nem okoz nehézséget legalább egy konkrét példával előállni arra, hogy miért teljesen alkalmatlan. A szabvány szövege a korábbi linken elérhető.

    #164
    Egy csomó cikk született róla, és sokaknak nem tetszik a helyzet, mert ez a cucc csak nevében nyílt, és sok esetben nem kompatibilis az ms software -ekkel sem...
    Könyörgöm! Csak egyet, amiben konkrétum van, hogy miért nem lehet sehogy se szabványnak megfelelő terméket implementálni!

    #167
    Tehát a srict dokumentumokat elvileg olvassa, mégis egy konverter kell ahhoz, hogy tényleg. Akkor most mi is van?
    Talán az, hogy lehet azon filózni, hogy a konverter önálló termék vagy egy software update az O2010-hez.

  • Gregorius

    őstag

    válasz bambano #169 üzenetére

    #169
    szerintem is jó ötlet, hogy nem írod le még 500x, mert ettől nem válik igazzá. az a módszer, ahogy elfogadták ezt a szemetet, sima maffiamegoldás volt.
    Azt hiszem még mindig nem érted. Attól, hogy nem szép dolog maffiamódszerekkel megszerzett kétharmados többséggel ráereszteni a terrorelhárítást civil szervezetekre még lehet szabályos. A norvég hatóságok - a leggyakrabban emlegetett példa a meghekkelt procedúrára - adtak ki egy elég részletessajtóközleményt, amiben viszont konkrétan elismerik, hogy a szabvány valóban létrejött. Érdekes módon a legnagyobb rivális LibreOffice-osok is szabványként beszélnek róla. A #170-ben linkelt cikkben is. Szerinted akkor ezek szerint totál hülyék ők is?

    #170
    megvárom a reakciódat erre.... különös tekintettel azokra a részekre, ahol libreoffice -ról, vagy opensource -ról szó sincs, pusztán épp azt taglalják, hogy mekkora egy használhatatlan ócskaság az ooxml.
    Nekem ezzel az állítással nincs problémám, mint írtam többször is magának a szabványnak a minőségéről inkább nem mondok semmit, nem volna szalonképes. Láttam már sokkal jobbakat és sokkal jobban használhatókat is. A Microsofttól is. Olyat is, ami házi szabvány, tehát nemzetközi szervezeten nem ment át.

    Ami a konkrét dokumentumot illeti, ez már egy tisztességesebb cikk. Konkrét hivatkozás még ebben sincs, párat azért vissza lehet követni, pl. erre a dokumentumra, 16. oldal 32-es lábjegyzet. Az itt szereplő állítás (the technical specification contains references toan external web site (www.microsoft.com) which refers to web
    pages that are not currently available
    ) tényszerűleg igaz, viszont a szabvány szövegét végigkerestem az összes link vagy példában van, ami nem normatív, hanem illusztratív (tehát nem teszi lehetetlenné a szabvány implementálását) vagy van olyan is, ahol a hivatkozott adattartalom be van emelve a szabvány szövegébe, pl. 20.1.10.50 (part 1, page 2972).
    Olyat nem találtam, ami lehetetlenné teszi a szabvány implementálását. Szólj, ha te igen.

    Gondolom azért az korábban is nyilvánvaló volt számodra is - vagyis remélem - hogy az ms ezt a formátumot kizárólag azért hozta létre, mert erősödött a nemzetközi nyomás arra vonatkozóan, hogy hosszú távon is használható, olvasható maradjon minden dokumentum
    Ez nem kétséges. Bár én inkább úgy fogalmaznék, hogy a kormányzati/közigazgatási szektor nyomására és nem hosszú távon is használható, hanem szabványosított formátumú, de a lényeg ez. Szaftos állami tendereken minimum papíron meg kell felelni a követelményeknek és presztízsértéke is van a dolognak.

    Ami a tárolást illeti ez ugyan sovány vígasz, de józan ember ilyet nem word processor formátumban kellene tároljon, hanem lezárt, nem-interaktív, nyomdakész és nem mellesleg szabványos formában. Amilyen például a pdf (megkötésekkel) vagy az xps. Amiben hajszálpontosan be van pozícionálva az összes glyph meg grafikus elem, és be van ágyazva minden erőforrás, ami a pontos vizuális reprodukáláshoz kell.

    Na most... az odf már akkor is az volt, az ms -nek pedig lépnie kellett valamit, ezért összetákolta ezt a szart, hogy elmondhassa hogy neki is van bizony ilyenje, és így már mindenki örülhet... csak hát mégsem, mert ezt a formátumot továbbra is csak az ms tudja teljes körűen implementálni
    Elmondhatta volna, aztán első körben az ISO elhajtotta, mint macskát szarni, mondván ilyen tákolmánnyal ne vicceljünk kérem.
    A teljes körű implementáció nem szükséges a szabványnak való megfeleléshez. Az az interoperabilitáshoz volna szükséges. Valamilyen kiterjesztési mechanizmus általában van a jövőt állóság biztosítására, ami egyrészt lehetővé teszi az innovációt, másrészt akármennyire kontrolláltan, de sajnos teret ad vendor-specifikus kiterjesztéseknek. Pl. a html5-ben is van ilyen.

    #171
    A PDF dokumentumok tárolására szolgáló konténerformátum. Azt csomagolsz bele amit akarsz. Olyasmi mint az MKV a videóknál.
    A pdf konténerformátumban igen komolyan meghatározott, hogy mit csomagolhatsz bele. Mint ahogy az odf-ben és az ooxml-ben is. Sőt, a bináris MSO dokumentumok is tulajdonképpen egy általánoskonténerformátumra épülnek.

    #172
    Módosítom a véleményemet, amire ezt a választ adtad. Nem kell MS ökoszisztéma, ehhez sem. Mert természetesen az MS megoldása előtt már évekkel volt olyan szoftver, amely tudta ezt. Azaz igaz, hogy ez a fícsör benne legyen a MSO-ban, az legfőképp az MS érdeke, nehogy megtörjön a vendor lock-in.
    Nem biztos, hogy követlek, de ha most a real-time kollaborációról beszélsz, akkor kíváncsi volnék, hogy melyik ez a szoftver, amiben már évekkel előtte volt ilyen.

    A konverter fícsöre nem a strict kezelése, hanem csupán az olvasása. Amit az MSO2010 elvileg tud.
    A fentiek fényében ez számít?
    Nem hiszem, hogy érdemes ezen sokat rágódni. Az O2010 legfeljebb a 2nd editiont implementálhatja (ez volt a legfrissebb a megjelenéskor), az O2013-ig még a 3rd edition (2011) és a 4th edition (2012) is kijött. A leírás szerint "olvassa azokat a fájlokat, amit az O2013 gyárt strict módban", szóval simán lehet szintre hozás a 3rd és 4th editionnel. Mint ahogy az O2007 is megkapta ugyanezt a képességet az SP2-vel, pedig az gyárilag nem is támogatta a strictet (akkor még nem is volt).

    Egyrészt nem update, mert nem települ fel magától, és még csak marketingelve sincs nagyon, mert a hivatalos duma szerint a o2010 tudja olvasni az újabb szabványt.
    Erre most nem merek megesküdni, mert már nem használok O2010-et, de az O2003-hoz adott ooxml addon határozottan ajánlott frissítésként települt Windows Update-ről, pedig annak aztán semmi köze nem volt gyárilag az ooxml-hez. A többit ld. fent.

    A szabványokat azért találták ki, hogy adott piacok működését megfelelően biztosítsa. Azért vehetsz egy akármilyen gyártótól egy csillagcsavarhúzót, ami minden adott méretű csillagcsavarhoz passzolni fog, mert léteznek szabványok.
    Ideális esetben az lenne a cél, hogy a szabvány hatásköréig terjedően az implementációk interoperábilisek legyenek. A csillagcsavarhúzónál ez (gondolom én) az eszköz fejére vonatkozik. Ha a nyele ki van szögezve, az attól még teljesen szabványos, csak a gyakorlatban használhatatlan. Ráadásul egy szoftver/szoftveres szabvány van annyira bonyolult, hogy aminek van piaci értéke, abban - ugyanúgy, mint egy piaci szoftverben - legalább egy hiba is biztosan van. Már csak a nagy számok törvénye miatt is. Az ooxml-ben meg több is.

    Itt pedig meg kell említeni azt is, hogy az egyetlen beszállító is éppen maga a tulajdonos, aki egyáltalán valamilyen szintű támogatást képes biztosítani.
    Kis pontosítás: az úgynevezett tulajdonos az ISO, akire át lett ruházva a szabvány. Ha a Microsoft kontrollja alatt maradt volna a szabvány, akkor jól kinéztünk volna, mert maradt volna az ecma v1 szintű szabvány.

    ...Tökéletesen működő ooxml szűrőt/konvertert viszont nem fogsz tudni írni, hiszen számtalan akadálya van annak, hogy megtehesd.
    Ezeket az akadályokat még mindig várom tételesen. Abból a számtalanból legalább egyet.
    Teljesen interoperábilis megoldást persze hogy nem fogsz tudni írni egy másik konkrét termékkel szemben, de nem is erre van szükség, hanem szabványos megoldásra.

    Nem az a baj az ooxml -el hogy az ms találta ki, hanem az hogy önmagával sem kompatibilis hulladék formátum
    Hol?

    ami számtalan problémát okoz már ma is, és fog a jövőben is, ha így maradnak a dolgok.
    Számtalan probléma mindegyik szabványban van. A html5-ben is (mind a kettőben), a css-ben is, a javascript-ben is, hát még az ooxml-ben. Pont az a Word97nemtommi transitional feature volt az egyik, amit aztán a későbbi verzióban korrigáltak is. Én is remélem, hogy nem maradnak így a dolgok.

    #179
    Na mi a helyzet? Nem reagálsz semmit? Kaptál egy egész jó linket, ahol van sok hivatkozás is....
    Sajnálom, veled ellentétben én nem keresek pénzt azzal, hogy egész nap az ITCafén lógok, ezt más forrásból kell megoldanom. Esetleg megoszthatnád, hogy neked hogyan sikerül.

    [ Szerkesztve ]

  • Gregorius

    őstag

    válasz #40553216 #183 üzenetére

    „Nem biztos, hogy követlek, de ha most a real-time kollaborációról beszélsz, akkor kíváncsi volnék, hogy melyik ez a szoftver, amiben már évekkel előtte volt ilyen.”
    Abiword?

    Tök jó. Lehet intraneten is hosztolni? Spreadsheethez is van? Integrálható projektmenedzsment rendszerrel?

    Azt mondod, hogy a szabvány alapján akkor bárki tud majd ilyen konvertert csinálni? Mert ha az MS-nek szüksége van rá, hisz’ az utólagos belenyúlkálások miatt láthatóan van, akkor másnak is lesz. Nem?
    Azt mondom, hogy nem ez lenne az első példa, hogy szabvány különböző verzióiban érdemi változás van. Az ODF 1.2-ben is vannak új dolgok, amik az 1.0-ban még nem voltak benne, pl. digitális aláírás. Tehát ha van egy szoftvered ami az 1.0-s szabványt implementálja, az habár kompatibilis az 1.2-vel (tegyük fel hogy nem történt breaking change), de attól még frissítened kell a szoftvert, hogy az új funkciók is kihasználhatók legyenek.

    #184
    Te most azt írogatod egyfolytában, hogy a több mint hétezer soros szabványleírásból mutassam azt a sort, ami miatt nem lehet implementálni normálisan a formátumot.
    Veled ellentétben a linkelt cikkek kapcsán én már többször is megjelöltem a szabvány megfelelő részét egy-egy állítás kapcsán és megmutattam, hogy az adott rész nem teszi lehetetlenné a szabvány implementálását. Minden bizonnyal tudsz legalább egyet mutatni a sok implementálhatatlan rész közül, mert állítólag hemzseg az ilyenektől a szabvány.
    Nem neked kell megpróbálni implementálni, nem neked kell sorról sorra végignézni a szabványt, mindössze egy állítást kell találnod - a google a barátod - ami pontosan megnevezi azt a szakaszt a szabványban, ami normatív és nem implementálható. Ilyen állításod szerint minden bizonnyal létezik, mivel legalább egy embernek meg kellett próbálnia implementálni azt a konkrét szakaszt, ami elengedhetetlen a szabványos implementációhoz és nem sikerült neki.
    Ha meg továbbra is azon a színvonalon akarsz vitatkozni, mint amikor a multi benyögi, hogy ilyen meg olyan szabadalmát megsértették a témában de azt már nem mondja meg, hogy pontosan melyiket, akkor inkább ne is válaszolj.

Új hozzászólás Aktív témák