ISO OOXML szavazás - mi következik most?

Egyéb

Ma szavaz az ISO Genf-ben az OOXML-ről. A Standards Blog oldalain Andrew Updegrove leírja, hogy hogyan számlálják össze a szavazatokat, mi a különbség a "P" (Participate - közreműködő) és "O" (Observer - megfigyelő) ISO tagok befolyása közt.

A folyamat:

1. Összeszámolják, hogy a "P" szavazatokat, és megállapítják, hogy a "P" tagok legalább 50%-a szavazott-e

- ha nem, akkor a határozat megbukott
- ha igen, akkor jöhet a második lépés

2. Kivonják a tartózkodásokat

3. Megvizsgálják, hogy a "P" szavazatok 2/3-a megvan-e

- ha nincs, akkor a határozat megbukott
- ha igen, akkor jöhet a negyedik lépés

4. Megállapítják, hogy a "P" és az "O" tagok által leadott összes szavazat 25%-a vagy több "Nem" szavazat-e

- ha igen, akkor a határozat megbukott
- ha nem, akkor a határozat átment

5. A szavazólapokat és megjegyzéseket elküldik Ken Holman-nek, az SC 34 elnökének. Szintén elküldik őket az Ecma-nak és az összes JTC1 tagnak.

6. Az Ecma-nak és a Microsoft-nak 2008. január 14-ig van ideje kitalálni a javaslatait, hogy hogyan felel meg a megjegyzésekre.

7. Az SC 34 átnézi a javaslatokat és kialakítja a véleményét arról, hogy mit kellene tenni az egyes megjegyzésekkel. Megállapítják, hogy van-e megoldhatatlan probléma.

- ha van, akkor a folyamat végetér
- ha nincs, akkor megfontolják, hogy hogyan lehetne megoldani a problémákat

8. Megtartják a Ballot Resolution Meeting-et Genf-ben, 2008. februárjában.

9. Szükség esetén újraszavazás.

A teljes és pontos folyamatleírás itt.

( trey | 2007. 09. 03., h – 08:33 )

Nem az volt.

Valaki tudja, kik a "P" és az "O" tagok?

Szerk: megvan.

JTC 1/SC 34 - Document description and processing languages

* Participating countries: 36
* Observing countries: 12

Mi csak megfigyelők vagyunk.

--
trey @ gépház

( Caro | 2007. 09. 03., h – 08:45 )

"4. Megállapítják, hogy a "P" és az "O" tagok által leadott összes szavazat 25%-a vagy több "Nem" szavazat-e"
Itt a "Nem" tartalmazza a "Nem, megjegyzésekkel" szavazatokat?

jol van, akkor kibetuzom:

9.8 Votes on Fast-track DISs
The period for fast-track DIS (or DAM) voting shall be six months,
consistin of a 30-day JTC1 National Body review period followed by a
five-month ballot period. NMs may reply in one of the following ways:
-Approval of the technical content of the DIS as presented (editorial or
other comments may be appended);
-Disapproval of the DIS (or DAM) for technical reasons to be stated, with
proposals for changes that would make the document acceptable (acceptance
of these proposals shall be referred to the NM concerned for confirmation
that the vote can be changed to approval);
-Abstention (see 9.12).

ebbol is ez erdekes:
"Disapproval of the DIS (or DAM) for technical reasons to be stated"

most jon-e? :)

( asch v | 2007. 09. 03., h – 09:38 )

Ez a folyamat legalább definiálva van. Persze biztos lehet rajta "csomót keresni" :-).

ha mással nem, akkor az odfben nem létező binary blobbal :D

>> Azt nem tudom, hogy ez OOo bug-e, vagy az ODF mint szabvany hibaja
remélem ezzel nem arra célzol, hogy a mindenkori ooo nem hajszálpontosan és csak az elfogadott szabványt implemetálja :)

>> akarmelyike is, lehet javitani.
+1. lesz valamikó', vagy el lehet hajtani a népeket :)

hát nemtom engem biztos felb***na ha defect-ként jelentenének le egy formátumkérdést... de ott biztos über emberek vannak, akik nemcsak tökéletesen programoznak hanem még fel sem lehet őket idegesiteni.

de ha már szóbakerült, érdekelne. kiderült végül mi van abban a bináris cuccban?

"Image Data
The image data can be stored in one of the following ways:
The image data is contained in an external file. Use the xlink:href and associated attributes described below to link to the external file.
The image data is contained in the element. The then element contains an element that contains the image data in BASE64 encoding (as defined in [RFC2045]). In this situation the xlink:href attribute is not required."

Ez nem azt jelenti, hogy ugyan binary a stuff, de RFC2045 szerint bárki imlementálhatja? (ezt komolyan kérdezem, lehet, hogy félreértem, nem flamelni akarok)

ez számomra is világos, de akkor nem értem, hogy mi a gond. A tárolás módja ismert (szabványos).
az object adatai vannak binárisan tárolva. (kép, gondolom a formátum miatt)

legalábbis nekem ezt jelenti:
"The element contains an element, which contains the binary data for the object in BASE64 encoding."

vagy mán tényleg nem értek semmit

Bocs, de én csak arra reagáltam, hogy melyik dokumentumban hol talál illetve nem talál róla infót. Ezzel kapcsolatban jegyeztem meg, hogy "óh, be jó lenne, ha ilyen dokumentum lenne az OOXML-ről is". Ha van, akkor szépen kérlek, linkeld, mert érdekelne. Köszi.

--
trey @ gépház

[Absolutely off]
Ehhehe... No ez a hozzaszolas tetszett toled :)
Finoman, elegansan ironikus. Szivesen olvasnek tobb ilyet.
(Meg ha a nezeteiddel nem is ertek egyet.)
[/Absolutely off]
[ps]
A so:r lassit. Bar nem hiszem hogy 8 percig fogalmaztam volna =O
Mentsegemre szoljon, hogy most jutottam vegig Dirk Gently-n.
[/ps]

>> Azt nem tudom, hogy ez OOo bug-e, vagy az ODF mint szabvany hibaja
remélem ezzel nem arra célzol, hogy a mindenkori ooo nem hajszálpontosan és csak az elfogadott szabványt implemetálja :)

Termeszetesen nem. A szabvanynak nem kell eloirnia, hogy egy adott funkciot a program hogyan valosit meg. Remelem, nem kell ezt tovabb magyarazni.

vagy el lehet hajtani a népeket

A link egy teljesen mas temara vonatkozik (tereles). Raadasul ha valaki rossz helyen tesz fel egy kerdest, azt termeszetesen elkuldik. Asszem ezt sem kell tovabb magyarazni.

Ez van. Azért az remélem mindenki számára világos, hogy ebben az esetben nincs is normális megoldás a problémára. Van valami, ami szart se ér (már bocs). Valaki egyszer elkezdte ezt belerakni (Lotus vagy MS, nem tudom) azóta meg igénylik a felhasználók, de attól még az elgondolás elvileg hibás. Pont úgy mint az egész DRM...

Na végre, valaki gondolkodik is. Pont ez az. Mi a cél?

1. egy doksiról eldönteni, hogy eredeti -e? Ott a digitális aláírás erre. A fogadó fél abban érdekelt, hogy korrekt legyen az ellenőrzés, azaz meg fogja szerezni a korrekt publikus kulcsot.

2. Mancika véletlenül ne piszkálja el a képleteket? Arra is jó, de csak akkor, ha Mancika abban érdekelt, hogy a hibás képletek miatt ne szívjon. Bár ehhez a jelszó behozása tényleg felesleges, és csak fals biztonságérzetet ad.

Nem működik abban az esetben, ha a doksi fogadója egyben a támadó is. Tehát az nem játszik, hogy csinalsz egy excel sheet-et, ami kiszámol valamit, csak ne lehessen kiszedni belőle a képletet. Ha a támadó gépén futó program hozzáfér a képlethez akkor elvileg a támadó is.

Ez most teljesen cég független. Az van, hogy valaha valamelyik idióta kitalálta ezt a feature-t (UI szinten jelszóval védeni módosítások vagy olvasás ellen valamit vakon megbízva a fogadó oldali software-ben) ami elvileg hibás (példa2: nem nyomtatható PDF, LOL, de azt hiszem a PDF sepckóban is van ilyen agyament attribútum, hogy nem szabad kinyomtatni). Sajnos igény van rá és az egyre nyíltabb formátumok kialakulásával egyre nyílvánvalóbb hogy felesleges hülyeség a feature.

Az itt a baj, hogy senki sem szól az átlag usernek, hogy figyu, attól ezt még bárki átírhatja. Egyes szerencsétlenek azt hiszik, hogy biztonságos így kiadni pl. excel sheet-eket és nem fogja tudni senki kibányászni belőle pl. a képleteket.

Nem idióta találta ki és nem hülyeség ez a feature...

Az egész mögött azaz elgondolás rejtőzik, hogy ha egy ilyen védett dokumentumot (de ez akár lehet egy védett levél is Exchange alapú rendszerben, Outlook levelező klienssel) lelehet védeni kinyomtatás, copy-paste, screenshot, exportálás (levelezésnél továbbküldés) és egyéb alap próbálkozások ellen, akkor a felhasználó bár nyilván megteheti továbbra is, hogy akár újra begépeli a védett szöveget, vagy egyszerűen felhívja a pletykatársát és elújságolja neki telefonon a dokumentumban szereplő szöveget, de egy esetleges kérdőre vonás esetén kevésbé hivatkozhat arra, hogy nem gondolt ennek tiltó jellegére, nem tudta, hogy az információ _bizalmas_ és nem szabad továbbítani, megosztani másokkal, stb.

Vannak olyan emberek, akiket egy piros felkiáltójel elrettent. Azok ellen tökéletes. Nem feltétlen a 100%-os biztonság a lényeg. Pl a cégek vezetői jósészt nem nagy IT lumenek, egy védett doksi láttán szívrohamot kapnak, és gyorsan bezárják, nehogy kitudódjon.