Jiří Kosek: příprava specifikací je boj

S pomocí Jirky Koska nahlédneme pod pokličku standardizačních organizací a poodhalíme, jak uvnitř fungují. Zaměříme se na W3C, která je webu nejbližší. Je W3C nezávislá? Stojí na straně dobra a je jejím jednoznačným posláním nastolit plně funkční web, nebo je situace složitější?

Kdy a proč jsi začal pracovat pro standardizační organizace? Co tě k tomu přivedlo?

Když jsem v polovině 90. let začal dělat s webem, s SGML a s XML, musel jsem číst specifikace, protože rozumné literatury moc nebylo. Při čtení specifikací jsem v pracovních návrzích nacházel chyby, tak jsem je začal hlásit a postupně jsem se propadl až do tohohle velkého kolotoče.

Takže to nebylo plánované?

Ne, plánované to nebylo. První standardizační organizací, jejímž oficiálním členem jsem se stal, byla OASIS (dělá zejména aplikační standardy postavené na XML). K tomu došlo v roce 2004. Už asi od roku 1998 jsem většinu dokumentů psal ve formátu DocBook; přidával jsem podporu češtiny do open source stylů, které umí DocBook převádět do dalších formátů. Později jsem začal přidávat i další nové funkce.

Někteří vývojáři, kteří se na tomto projektu podíleli, byli zároveň členy technického výboru OASIS, který vyvíjel schéma DocBooku. Zeptali se mě, jestli bych se taky nechtěl stát členem. Zaplatil jsem roční členský poplatek a od té doby jsem členem OASIS.

Jiří Kosek

Jiří Kosek (1975)

  • Již řadu let se aktivně podílí na práci standardizačních organizací OASIS, W3C a ISO.
  • Napsal knihy o HTML, PHP a XML.
  • Jeho webová stránka www.kosek.cz byla řadu let jedinečným zdrojem informací pro všechny zájemce o webové technologie.
  • Učí na VŠE předměty Tvorba webových stránek a aplikací a XML – teorie a praxe značkovacích ja­zyků
  • Je propagátorem formátu DocBook, na jehož vývoji se podílí.
  • Sehrál důležitou roli při sbírání podkladů pro hlasování o přijetí OOXML za Českou republiku.

U dalších organizací to probíhalo podobně?

Zaslal jsem několik připomínek k návrhům W3C a později jsem na společném workshopu potkal někoho, komu se připomínky líbily. Chtěl mě mít v pracovní skupině, ať jim místo zasílání připomínek rovnou pomůžu ony pracovní návrhy dělat lépe. Tak jsem se stal invited expertem W3C.

Nakonec jsem začal pracovat i pro ISO. Asi před pěti jsem přesvědčil Český normalizační institut (dnes přejmenovaný na Úřad pro technickou normalizaci, metrologii a státní zkušebnictví), aby mě jmenovali přidruženým členem pracovní skupiny, která se stará o validační a schémové jazyky a Topic Maps. Asi před dvěma lety jsem se stal přímo zpracovatelem mezinárodní spolupráce ISO/IEC JTC1/SC34. Což sice znamená, že musím dělat i práci, která není tak zábavná, číst všechny návrhy norem a vypracovávat k nim stanoviska, ale stále můžu dělat, co jsem dělal dřív, a u norem, které mě víc zajímají, se do procesu aktivněji zapojit.

Jirka Kosek a Martin Hassman

Kolik dalších Čechů se pohybuje v těchto organizacích, nebo aspoň o kolika víš?

V OASIS neznám žádného Čecha, ale OASIS se skládá z celé řady technických výborů, tak je možné, že o nich jen nevím.

Ve W3C je Petr Cimprich. Nevím, zda čtenáři Zdrojáku, ale čtenáři Roota ho určitě znají, protože psával pravidelné přehledové články o XML. V pracovních skupinách, které se věnují sémantickému webu, je Jacek Kopecký, kterého někdo může znát ze Systinetu, který dělal do webových služeb.

Kolik může práce pro standardizační organizace zabrat času?

Jedná se naštěstí o práci, které se lze věnovat natolik, kolik času máš. Když někdo nemá moc času, může být pasivním členem pracovní skupiny, který v horším případě nedělá vůbec nic. Maximálně čte zápisy z telekonferencí nebo meetingů. Když čas má, tak připomínkuje návrhy a diskutuje na telekonferencích. A pokud má času dost, může být editorem nebo pomocným editorem specifikace, tj. psát ji celou nebo některé její části.

Specifikace W3C často přichází pozdě a když přijdou, nejsou v souladu s chováním prohlížečů. Kdo za to může? Pracuje  W3C špatně?

To nejde hodnotit globálně. Spousta lidí vnímá W3C jako organizaci, která je jednotná a dělá specifikace pro různé webové technologie. Jenže v praxi ony specifikace vytváří pracovní skupiny a mezi nimi je velký rozdíl. Některé pracovní skupiny jsou více efektivní, jiné méně. Některé skupiny jsou odtržené od reality a dělají věci, o kterých si většina lidí myslí, že jsou k ničemu, resp. nepříliš prakticky využitelné. Vedle nich jsou pracovní skupiny, které se drží víc při zemi a kopírují implementaci firem nebo open source projektů.

Mohl bys uvést nějaké příklady?

Jiří Kosek

Vezměme si třeba takovou často mediálně propíranou a kritizovanou pracovní skupinu pro XHTML. Několik posledních let dělají na XHTML 2.0, které žádný z výrobců prohlížečů nemíní podporovat. Takže je otázka, zda to, co dělají, má smysl a najde někde uplatnění, nebo zda ve W3C tu skupinu jen nechali, aby to celé nevypadalo divně, když už tu bylo nějaké XHTML 1.0, které se již používá. Aby to lidem za XHTML nepřišlo líto a nedělali povyk. To ale nevím, to jsou jen spekulace.

Na druhou stranu členy pracovní skupiny, která vytváří XQuery, jsou zástupci všech velkých databázových firem a různých open source projektů, které dělají XML databáze. A již v době, kdy existuje první verze pracovního návrhu, to mají v produktech implementované. Tam je spíš problém, že některým výrobcům následně dlouho trvá, než změny, které se objeví ve finální verzi specifikace, pak promítnou i do svého produktu.

Takže ani to není ideální. W3C se asi nedá zhodnotit jednou větou, že všechno dělá dobře nebo špatně.

Kdo tedy píše specifikace? Samotná W3C nebo firmy, které se v ní angažují? A jak tvorba probíhá?

Specifikace píší vždy konkrétní lidé. Každá pracovní skupina určí jednoho nebo několik editorů specifikace. Pracovní skupina většinou nevzniká na zelené louce z lidí, kteří se sešli a řekli, že si napíší specifikaci. Většinou je to tak, že v nějakém produktu existuje nějaká technologie a něco velmi podobného má i jiná firma. Následně usoudí buď ony firmy nebo W3C, že by bylo vhodné se dohodnout a místo několika podobných jazyků na stejnou věc mít jeden společný.

Bude to lepší pro vývojáře i pro uživatele. Nebudou svázáni s jedním produktem, bude pro ně snazší přejít k jinému dodavateli. Ve výsledku to může být výhoda i pro ony firmy, protože na vývoji jazyka se bude podílet víc subjektů, a tím spíš vychytají chyby. Pro firmy to má výhodu i z hlediska marketingu, protože dnes je populární tvrdit, že výrobky vyhovují nějakým specifikacím a normám.

Ve W3C do tohoto procesu nevidím, účastní se ho platící členové W3C, což jsou firmy a univerzity. Já jsem ve W3C jako přizvaný expert, a ten nemá práva rozhodovat o tom, zda vznikne nová pracovní skupina.

W3C

Pokud členové, kteří mají rozhodovací práva, potvrdí, že by tuhle pracovní skupinu chtěli založit, skupina je založena a členové, které to zajímá, do ní vstoupí a vyberou si editora. Pokud už nějaká firma podobnou technologii má, vezme se většinou popis jejího jazyka a postupně se začnou spolu domlouvat, co v něm chybí a co udělat jinak. Vybraný editor zapracuje změny a dokument, který byl kdysi např. referenční dokumentací nějakého produktu, stylisticky upraví do podoby specifikace, která je z hlediska produktu neutrální.

Tím vznikne pracovní návrh, který skupina zveřejní. Připomínky k němu může posílat kdokoliv. Ty se řeší během telekonferencí a osobních setkání. Specifikace se postupně vylepšuje, mění, vydávají se další pracovní návrhy.

Jakmile pracovní skupina dojde k přesvědčení, že specifikace spěje k finálnímu tvaru, vznikne Last Call (poslední výzva), po které mají čas všichni, kdo by tu technologii mohli využívat, tj. hlavně implementovat, ale i koncoví vývojáři (uživatelé), si ji přečíst. Pokud jim přijde, že je něco udělaného špatně nebo nešikovně, mohou zaslat komentáře, na které je pracovní skupina povinna odpovědět. Buď zdůvodnit, proč je ignoruje, nebo je zapracovat do specifikace.

K W3C vzhlíží spousta lidí téměř jako k božstvu. Z tvého vyprávění ale vyplývá, že specifikace často vznikají na popud firem a jejich vlastních zájmů. Jak je to ve skutečnosti? Je W3C opravdu ta hodná nezávislá organizace, nebo jen plní to, co si diktují firmy?

Já musím W3C zachovat její andělskou auru, protože jsem jejím členem, tak aby ta moje neklesla. (smích) Ale bylo by naivní myslet si, že W3C je nějaká 100% altruistická organizace, jejímž posláním je nastolit světový mír a plně funkční web. To sice do jisté míry platí, ale prakticky je W3C tvořena členy, kteří mají své zájmy. Většina členů jsou komerční firmy a pro ně jsou určité aktivity, které W3C dělá, prospěšné. Pokud jsou členy nějaké pracovní skupiny, tak většinou chtějí, aby se doporučení W3C se otočilo tím směrem, který je pro ně výhodný.

Kupříkladu pokud do pracovní skupiny vstoupily s tím, že nabídly svou technologii ke standardizaci, nejsou rády, když se v ní dělají nějaké radikální změny. Protože to znamená, že by svou implementaci musely změnit. Proto v pracovních skupinách, kde jsou technologie blízko k uvedení na trh, se firmy změnám často brání.

Takže příprava specifikací je někdy boj?

Určitě. Výrazné to bylo při tvorbě XML schémat. Řada lidí si myslela, že to, co se připravuje, není z technického hlediska úplně správné. Když zjistili, že na půdě pracovní skupiny nejsou schopni prosadit své názory, z W3C odešli. Spousta čtenářů určitě minimálně slyšela o validačním schémovém jazyku RELAX NG, který vydal OASIS a později ho schválilo i ISO. Jedním z jeho autorů je Murata Makoto, který byl původně členem W3C a chtěl, aby schémata byla založena na lepším matematickém formalismu.

Logo OASIS

W3C schéma mají matematický formalismus divoký, resp. žádný. Zájmy tam měly velké softwarové firmy, které schémata potřebovaly rychle dostat na trh a požadovaly některé vlastnosti, které šly proti eleganci jazyka. A tyto zájmy převážily.

Vedle toho existují pracovní skupiny bez zástupců z velkých softwarových firem. Tvoří je lidé, kteří dělají open source nebo je problematika jen zajímá. V nich podobné tlaky nejsou a je v nich spíše kamarádské prostředí.

Nejhorší je, když v nějaké pracovní skupině hašteření mezi rivaly v obchodní sféře přeroste únosnou mez a předseda pracovní skupiny není dostatečně silný v kramflecích, aby členy ukočíroval. Pak na nějaký čas není pracovní skupina zcela efektivní a utápí se ve zbytečných diskusích.

Ideální specifikace by měly být perfektní, ale tvorba takové specifikace by pravděpodobně zabrala nekonečně času. Aby byl standard úspěšný, musí řešit něco, co lidé potřebují, ale také musí světlo světa spatřit v rozumném čase.

Takže specifikace jsou kompromisy?

Celá standardizace je o kompromisu.

W3C hledá osobu na pozici generálního ředitele, nenapadlo tě zúčastnit se konkurzu? (smích)

Ne, to mě opravdu nenapadlo. (smích)

Byl bys šéfem samotného tvůrce webu Tima Bernerse-Lee.

Je otázka, zda by si nechal šéfovat. Lidé ve W3C jsou většinou silné osobnosti a není lehké je nějak kočírovat. Myslím si, že je to velká výzva, ale raději budu dělat něco jiného.

A čistě teoreticky, pokud bys tu funkci přijal, co bys ve W3C změnil?

Nejsem si jist, zda bych něco měnil. On ředitel má dopad na organizační věci, shání peníze, rozhoduje, kolik bude interních zaměstnanců, kteří se starají o infrastrukturu a fungují jako styční důstojníci hlídající, zda pracovní skupiny pracují podle procesů atd. Ovšem to nejzajímavější na W3C jsou specifikace. Ty vytváří pracovní skupiny, na ně nemá provozní management přímý dopad.

Podle pravidel může Tim Berners-Lee (ředitel W3C) cokoliv stornovat (má právo veta) a může vše poměrně do velké míry ovlivňovat, ale to se v praxi téměř nevyužívá. Což je možná škoda, protože některé věci by mohl zaříznout, což by často pomohlo.

Takže ani z pozice generálního ředitele W3C bys nemohl přinutit např. editora HTML5 Iana Hicksona, aby přepsal specifikaci podle tvých představ? Jakmile by Ian Hickson řekl ne, tak bys na něj neměl žádnou páku?

Ne, to bych neměl.

Ostatně pracovní skupina HTML funguje velmi zvláštně. Dlouhou dobu měla předsedy, kteří ji příliš neřídili a skupina se potácela v takovém chaosu a bezvládí. Nedávno byl jako jeden z předsedů jmenovaný Sam Ruby z IBM, který je dobře známý v open source komunitě, protože se podílel na spoustě projektů od Apache. Ten se do toho trochu opřel, takže by to mohlo práci skupiny někam zase posunout.

Podle mé zkušenosti pracovní skupiny, které něco udělají, jsou za prvé ty větší, kde jsou ony zmíněné třenice, ale mají předsedu, který má respekt a umí třenice včas utnout. Sice někdy utne debatu, která by vyústila v lepší řešení, ale tím, že by se hledalo dva roky, by celé věci příliš neprospělo.

Vedle toho dobře fungují malé pracovní skupiny, kde o nic nejde. Tvoří je nějakých 5 kamarádů, kteří si jednou za měsíc zavolají, jednou za půl roku se sejdou a mají vesměs podobný názor na to, co dělají.

Mě zaujal samotný vznik pracovní skupiny pro HTML v roce 2007. Ian Hickson si kladl řadu podmínek, např. aby pracovní skupina byla otevřená pro kohokoliv. W3C na to přistoupilo. Je to běžné?

Logo WHATWG

To rozhodně není běžné. Ostatně W3C trvalo několik let, než tenhle krok udělali. Nemám informace z první ruky, v době největších třenic jsem nebyl invited expertem a nevidím diskusní listy platících členů, kde se řeší podobné záležitosti.

Úspěšnost celé specifikace XHTML je sporná. W3C vývoj HTML ukončilo, proto vzniklo WHATWG, kde se HTML začalo vyvíjet nezávisle dál. W3C se dostalo do rozporuplné situace. Nechtělo, aby budoucí vývoj HTML nemělo pod kontrolou, protože ta specifikace byla původně jejich. Ostatně kdyby WHATWG vydalo HTML5 oficiálně, myslím, že by se do toho vložili právníci kvůli copyrightu W3C a WHATWG by to nemělo jednoduché.

Na název HTML existuje copyright?

Nejenom na název HTML, ale i na text specifikace. Ten je chráněný copyrightem. Vezmi si jakoukoliv specifikaci W3C, najdeš tam copyright. Jsou chráněny autorským zákonem, takže pokud by WHATWG od W3C nezískala souhlas, musela by specifikace HTML5 obsahovat vlastní popis všech značek a atributů, které jsou z 90 % stejné jako v HTML4. Museli by jejich definice napsat znovu, což by nebylo úplně vhodné. Neříkám, že by ten souhlas nutně nedostali, ale kdyby se ve W3C umanuli, tak by pomocí právníků měli celkem dobrý prostor.

Opětovné založení pracovní skupiny HTML byl problém. Jakmile by ve W3C řekli, že HTML se dál vyvíjí na jejich půdě, shodili by tím dřívější rozhodnutí vydat se čistě cestou XHTML. Myšlenka XHTML nebyla špatná, ale realizace se hodně nepovedla. To platí pro XHTML 1.0, o XHTML 2.0 ani nemluvím.

Proto ve W3C dlouho existovalo vnitřní pnutí. Z pohledu WHATWG byl celkem oprávněný požadavek, aby se specifikace vyvíjely hodně otevřeně a členem pracovní skupiny mohl být kdokoliv. Jenže pro W3C to nebylo snadné.

Proč?

Jiří Kosek

K tomu, aby W3C mohlo fungovat a zaplatila se infrastruktura a zaměstnanci, kteří se o ni starají, jsou potřeba finanční příjmy. Specifikace jsou zadarmo, proto jediné příjmy pochází z členských poplatků. A aby členové poplatky platili, požadují nějaká exkluzivní práva, např. když se podílejí na vývoji specifikací, můžou do procesu mluvit, ale nemluví do něj nikdo jiný.

(Pozn. redakce: Komunikace většiny pracovních skupin W3C probíhá ve veřejně nepřístupném diskusním listu, vedle kterého je založen diskuzní list veřejný, kam může přispívat kdokoliv. Číst obsah neveřejného listu ovšem mohou jen členové a pozvaní experti pracovní skupiny. U pracovní skupiny pro HTML je veškerá komunikace veřejná.)

Má to i další důvod. Ve fázi příprav specifikací firmy někdy odkryjí vnitřnosti svých technologií a nechtějí, aby je viděl kdokoliv, pouze další členové. Členem ve W3C se může stát kdokoliv, kdo zaplatí. Členské poplatky jsou řádově tisíce Euro nebo dolarů ročně.

Předseda pracovní skupiny může navíc pozvat jednotlivce jako invited experta. Tímto způsobem se řeší např. open source projekty. Jejich členové nebudou platit několik tisíc Euro ročně, ale pokud daný standard implementují, budou pozváni jako invited experti, aby se na něm mohli podílet.

Ian Hickson kdysi řekl, že jeho moc jako editora specifikace sahá jenom tak daleko, dokud specifikuje to, co by výrobci stejně i bez něj implementovali. Měl tedy pravdu?

Samozřejmě nemá cenu dělat specifikaci, kterou nikdo neimplementuje. V tom se už poučili z minulosti. W3C se vyvíjelo. V 90. letech nebyly před vydáním specifikace u W3C vyžadovány funkční implementace. Dnes je to jinak. Musí existovat dvě nezávislé implementace pro každou funkci popsanou ve specifikaci. Nemusí se jednat o dvě implementace, které implementují celou specifikaci, ale budou třeba čtyři, které implementují různé části, a ve výsledku se to pospojuje. To je samozřejmě krok správným směrem.

Pokračování příště

Tady končí první část rozhovoru s Jirkou Koskem. V další části, kterou zveřejníme příští týden, se budeme věnovat nejen W3C, ale také organizaci ISO a prozradíme některé méně známé informace z procesu schvalování OOXML. Zeptáme se Jirky Koska na budoucnost některých webových technologií a proč na CSS3 čekáme tak dlouho.

Otázky kladl Martin Hassman, fotografie pořídila Ivana Dvorská.

Pracují standardizační organizace dobře?

Vystudoval jsem biochemii. Vymyslel a založil Zdroják. Aktuálně ho vedu. Nejsem váš hodný tatínek, který vás bude brát za ručičku, ale zlý moderátor diskusí. Smiřte se s tím!

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 61

Přehled komentářů

Jan Jelínek Článek
Stanislav.Hoferek jajaj
Hoween Re: jajaj
jAM_jAM Re: jajaj
Hoween Re: jajaj
Martin Hassman Re: jajaj
Hoween Re: jajaj
Martin Hassman Re: jajaj
Marek Lutonský Re: jajaj
Hoween Re: jajaj
jAM_jAM Re: jajaj
prof2 Re: jajaj
Hoween Re: jajaj
jAM_jAM Re: jajaj
Anonym Re: jajaj
Stanislav.Hoferek Re: jajaj
Hoween Re: jajaj
David Grudl Re: jajaj
Hoween Re: jajaj
David Grudl Re: jajaj
Hoween Re: jajaj
David Grudl Re: jajaj
v6ak Vytržení z kontextu
David Grudl Re: jajaj
karel Re: jajaj
Jirka Kosek Soutěž pro čtenáře
pepa Re: Soutěž pro čtenáře
stawanka Re: Soutěž pro čtenáře
Hoween Re: Soutěž pro čtenáře
stawanka Re: Soutěž pro čtenáře
karel Re: Soutěž pro čtenáře
Hoween Re: Soutěž pro čtenáře
karel Re: Soutěž pro čtenáře
Zenek Re: jajaj
David Grudl Re: jajaj
Martin Hassman Re: jajaj
Miloslav Lešetický Re: jajaj
Anonym Re: jajaj
smilelover Co se nepovedlo na XHTML 2?
pan_tau Re: Co se nepovedlo na XHTML 2?
smilelover Re: Co se nepovedlo na XHTML 2?
petr_p Re: Co se nepovedlo na XHTML 2?
Dlouhán Re: Co se nepovedlo na XHTML 2?
petr_p Re: Co se nepovedlo na XHTML 2?
Timy Re: Co se nepovedlo na XHTML 2?
petr_p Re: Co se nepovedlo na XHTML 2?
Timy Re: Co se nepovedlo na XHTML 2?
petr_p Re: Co se nepovedlo na XHTML 2?
Timy Re: Co se nepovedlo na XHTML 2?
Dlouhán Re: Co se nepovedlo na XHTML 2?
smilelover Re: Co se nepovedlo na XHTML 2?
Jirka Kosek Re: Co se nepovedlo na XHTML 2?
alancox Nepov edené XHTML 2
eee Re: Nepov edené XHTML 2
Jirka Kosek Re: Nepov edené XHTML 2
David Grudl Re: Nepov edené XHTML 2
eclipse_guru Copyrigthovat smlouvy a specifikace je nesmysl
Synkretik Copyrigthovat texty standardů je nesmysl
Dlouhán Re: Copyrigthovat texty standardů je nesmysl
Petr Adamek Re: Copyrigthovat texty standardů je nesmysl
AHA Moc pěkné
Zdroj: https://www.zdrojak.cz/?p=2939