Přejít k navigační liště

Zdroják » Rozhovory » Jiří Kosek: příprava specifikací je boj

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

Články Rozhovory, Webdesign

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?

Komentáře

Subscribe
Upozornit na
guest
61 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Jan Jelínek

Díky za rozhovor, byl jsem také jedním z těch, kteří mnoho mnoho let zpět čekali na každý Jirkovo slovo:-)

Stanislav.Hoferek

Jiri Kosek ma naucil HTML, za co som mu veeeeeeeeeelmi vdacny. Teda jeho knizka. dnes uz samozrejme starsia, ale fajn…

Hoween

Kosek akorát naučil všechny bastlit PHP, a to bastlení myslím doslova. Jeho knížka o PHP byl naprosto amatérská, postrádala jakékoli standardy, vybízela k vytváření nebezpečných aplikací (viz config.inc a další ksindly).

Pokud se chcete opravdu něco naučit, zkuste např. Staníčka, Zeldmana, nebo Prokopa ;-)

jAM_jAM

Jsem si nevšiml že by Staníček, Zeldman nebo Prokop učili PHP, nemáte to trochu popletené?

Hoween

Nemám. Narážím tady na edukativní schopnosti pana Koska, ve smyslu napsat knihu, nebo vysokoškolskou přednášku. Jeho znalosti kolem XML nezpochybňuji, ty zcela určitě má. Ale přenést je čtenářům/posluchačům v použitelné formě nedokáže.

Hoween

Viděl jsem dvě Jirkovy přednášky, znám některé jeho knížky a slyšel jsem stejné pozitivní ohlasy od řadu dalších lidí.
Já na pana Koska zase slyšel dost negativních názorů, zejména co do jeho povýšenectví typu „já jsem XML guru, vy jste nuly“.

Když porovnám takový Zvon.org, a potom to, co má Kosek na svém webu, tak Koskova verze může být přínosná tak maximálně pro lidi, co neumí ani slovo anglicky. A není to jen o překladu.

pokud někdo tvrdí, že má vážný problém Jirku pochopit, tak by měl začít hledat problém u sebe
Že i ty začneš kopat do lidí, co mají negativní názor na lidi/články zde na Zdrojáku, to jsem opravdu nečekal. A upřímně, jen proto, že označím Koska za mizerného učitele, mi vpálit do očí něco ve smyslu, že já nic neumím a mám začít u sebe, to je docela ubohé.

Marek Lutonský

Myslel jsem, že Mr. Hoween dělá obecního trolla jen u nás na Živě. Koukám, že se rozšiřuje i dál do světa.

Myslím, že každý čtenář dokáže snadno posoudit úroveň vyjadřování pana Koska v článku a vedle toho příspěvky této identity v diskuzi. Tak podrobné obhajoby proto snad ani není třeba.

Hoween

Pane Lutonský, až přestanete svým čtenářům vyhrožovat, že jim za blokování reklamy budete mazat účty, pak se můžeme bavit o nějaké úrovni vyjadřování ;-)

jAM_jAM

A v USA zase bijete černochy!

prof2

Zvon má leccos i v češtině, ne?

Hoween

Něco ano, ale čtu zásadně tu anglickou verzi :-)

jAM_jAM

V tom případě máte problém se strukturováním textu a a nesmíte se divit že vám lidé nerozumí.

Anonymní

Vážený "experte" Koskova kniha o PHP z roku 1999 byla vůbec první knihou o PHP na celém světě (viz http://www.php.net/manual/en/history.php.books.php).
To, že se v ní píše o věcech, které byly později zavrženy, na tom nevidím nic zvláštního, to je normální vývoj. Chtěl bych vidět, co by jsi v té době napsal ty.

Stanislav.Hoferek

v tom case som cital knizku o HTML. nemam tusenie ci bola prva alebo kolka, ale naucil som sa cez to robit odkazy, tabulky, rozne zvyraznenia textu… a som rad. potom uz len trochu zmaknut CSS a hotovo

Hoween

Vážený pane, to, že byla jeho kniha možná první na světě nemění nic na tom, že i tehdy existovala oficiální dokumentace, která byla na mnohem lepší úrovni. Ostatně, každý by měl primárně používat právě dokumentaci, neboť informace nejsou nijak "filtrované".

Učit uživatele pojmenovávat konfigurační soubor config.inc, to nemá nic společného s nějakým vývojem a nedá se omlouvat "stářím". To je prostě jen naprosto amatérský počin.

David Grudl

Pojmenování konfiguračního config.ini je zcela v pořádku, také to používám a doporučuji http://code.google.com/p/nette/source/browse/#svn/trunk/examples/skeleton/app

Hoween

Pokud pak zabráníte stažení toho souboru, např. pomocí .htaccess, tak není žádný problém. Jenže Kosek nic takového nepopisoval. Není to tak dávno, co jsem se stahováním konfiguračních souborů z různých amatérských webů bavil.

David Grudl

A není snad potřeba tímto způsobem zabezpečit jakýkoliv soubor aplikace? Včetně databází, šablon, skriptů?

Hoween

Pokud mám potlačené chybové hlášky (což by v produkčním prostředí mělo být), tak mi teoreticky stačí mít u všech souborů "spustitelnou" koncovku. Pak už si obsah souborů typu config.inc.php nikdo nestáhne.

David Grudl

Skutečně? Tak si přejmenujte config.inc na config.ini.php a spusťte jej :-) (pro nepéhápkáře: obsah se vypíše na výstup).

Podle toho, co píšete, soudím, že jste opustil v PHP kategorii začátečník ale k expertovi máte ještě daleko. Doporučuji více pokory, aby až po letech narazíte na své vlastní komentáře, tak vás hanba nefackovala.

Zabezpečení aplikace skutečně nespočívá v tom, že vypnu chybové hlášky a budu se modlit. Profík v produkčním prostředí chybové hlášky především loguje. Já nenechá si zaplevelovat error log tím, že mu někdo bude browserem šátrat po aplikaci a "spouštět" config.ini.php.

v6ak

Popravdě řečeno, přijde mi to jako vytržení z kontextu. Je pravda, že ne všechno bylo naprosto precizně a exaktně řečeno. Jasně, že pokud bude mít config.ini.php nějaký ini-like formát, tak se vypíše. Ale pokud tam bude něco jako <?php define(… nebo <?php return (object)array(…); nebo <?php return new Foo_Config(…);, pak jsme někde úplně jinde.

// Nediskutujme teď nad tím, co je lepší.

David Grudl

Ale co to nevídím v dokumentaci Zend_Config – http://framework.zend.com/manual/en/zend.config.adapters.ini.html – pojmenovávají konfigurák config.ini. Hrůůůza!

karel

Vážený "experte", oficiální dokumentace PHP v roce 1999 (kdy jsi zjevně s php neměl nic společného) uživatele učila používat úplně stejné věci jako Koskova kniha – např. automaticky registrované globální proměnné apod. To, že pozdější vývoj vedl ke zjištění, že to nejsou úplně ideální věci, nic nemění na tom, že v roce 1999 šlo o výbornou knihu.

Jirka Kosek

První, kdo najde v http://www.kosek.cz/php/php-tvorba-interaktivnich-internetovych-aplikaci.pdf zmínku o nějakém config.inc vyhrává, co si bude přát.

A speciální soutěž pro Howeena: Ať si udělá checkout CVS dokumentace PHP k podzimu 1998. Za každou funkci, která bude v oficiální dokumentaci popsána podrobněji než ve knize (počítají se jen funkce uvedené v knize), vyhrává pivo. Pokud by piv bylo více než dvacet, dostane jen dvacet piv (nemůžu přece podporovat alkoholismus) a navíc možnost zůčastnit se cyklovyjížďky s autorem knihy z Liberce na Ještěď.

pepa

strana 246

Častým zvykem je ukládání těchto knihoven do souborů s příponou
.inc. Soubory s touto příponou však nejsou WWW-serverem interpretovány
jako skript v PHP a jsou bez jakýchkoliv změn odeslány zpět uživateli.

stawanka

Sakra! Jdu pozde.. (.inc)

Kdybych jeste nekde u rodicu pohrabal, tak tu knizku jeste najdu :) Ne ze bych ji cetl v roce 1999, ale i o par let pozdeji mi dost pomahala. Oni totiz jeste vsichni tenkrat nemeli permanentni pristup k temhletem internetum, takze se knizka narozdil od (celkem chaotickeho) docu hodila.
Nechapu vylevy tady pana Howeena, o jakych standardech tady blaboli? On existuje standard na psani PHP? A ze p.Kosek (ano, mam respekt) neumi ucit? Kdybych secet na kolik prednasek jsem kdy chodil (pravidelne) tak jich napocitam opravdu par a oba kursy na VSE jsou mezi nimi.

Hoween

Třeba že ačkoli je PHP case-insensitive (bohužel), máme i tak nějaké standardy na zápis funkcí, pojmenovávání proměnných a konstant, závorkovou notaci, formátování bloků…

Dále s oblibou používal funkci _fetch_row, která už tehdy byla naprosto nevhodná, nezmínil se ani slovem o oddělení formy od obsahu, atd., atp. Prostě naučil spoustu lidí strašné prasárny a ještě před dvěma lety jsem na fórech potkával lidi, kteří se podle té knihy zkoušeli učit.

A klidně se přiznám, že jsem si tu knížku v roce 2001 také koupil, v naději, že mě něco naučí. Bohužel už tehdy jsem měl dostatečný teoretický základ a věděl jsem, že existuje nějaká dokumentace, takže se z ní brzy stalo slušné těžítko (tehdy za 400 Kč i poměrně drahé).

stawanka

1) Chapu, co chces rict. Prijde mi ale, ze si to stejne vetsina lidi jede po svem – knizka neknizka. Navrhove vzory od p.Pecinovskeho me napriklad nedonutili delat NašePrvníTřída(JináTřída) ;)
2) A to se tenkrat oddelovalo?
3) Co uz ;)

karel

Pouze potvrzuješ, že v roce 1999 jsi s PHP neměl vůbec nic společného. Nechápu, proč se tedy pouštíš do komentování něčeho o čem víceméně nic nevíš a nerozumíš tomu. Ovšem, pravda, ani mě to nepřekvapuje :-)

Hoween

1999, 2000, 2001? Není to tak nějak jedno? Nebo ty dva roky na PHP3 by někomu daly nějakou výhodu?

karel

Fascinuje mě, jak se ze svých neznalostí snažíš dělat přednosti :-) V roce 2001 tady dávno bylo PHP 4. Koskova kniha je o PHP 3.

Zenek

Pokud mluvíme o knížce PHP – tvorba interaktivních internetových aplikací, Grada 1999, tak ji držím v ruce a na straně 67 je napsáno:

Mnoho tvůrců knihoven (…) pro PHP používá pro tyto knihovny příponu .inc. Pokud však někdo zjistí URL vaší knihovny, a ta má příponu .inc, může si ji stáhnout a prohlížet si zdrojový kód vašeho skriptu. Pokud však knihovnu uložíte do souboru s příponou .php, bude vždy interpretována systémem PHP a neoprávněnému uživateli dorazí zcela prázdná stránka.

Nemohu tím sice vyvrátit vaše tvrzení, neboť celou ji číst nebudu, ale toto upozornění jsem si z toho pamatoval a myslím, že by bylo v rozporu s případným použitím config.inc.

David Grudl

Helemese, Exkrement zase perlí.

Koskova kniha o PHP byla jednou z nejlepších učebnic, na které jsem kdy narazil, a nemám tím na mysli jen jazyk PHP. Je velká škoda, že je dnes již zastaralá, jinak bych ji doporučoval všem začátečníkům i nadále.

Miloslav Lešetický

Ano, mě určitě potěšíte. Dík i za tenhle rozhovor.

Anonymní

Ano ano, na této knize sem se ponořil do svět programování.

smilelover

Hezky rozhovor, uz se tesim na dalsi cast.

Akorat bych rad, kdyby pan Kosek vic rozbral tu nepovedenost XHTML 2. Nemam ted na mysli tu slavnou kontroverzi tvrdeho/mekeho pristupu k chybam v markupu. Zajimaly by me dalsi konkretni veci, ktere p. Kosek vidi spatne… (cimz nerikam, ze tam zadne takove nejsou)

pan_tau

Taky se primlouvam. Me prijde postavit HTML na XML docela dobry napad. Treba nutnost well-formed xml urcite neni ten pravy duvod, proc je XHTML odmitano tvurci prohlizecu.

smilelover

Ja se obavam, ze to prave jeden z hlavnich duvodu je… stranek, ktere krome ignorace standardu nemaji ani validni samotny markup je bohuzel stale obrovske mnozstvi.

petr_p

Což vůbec nevadí, protože na XHTML je zavedený zvláštní MIME typ, takže, že by přestaly stránky fungovat samy od sebe, nehrozí.

Já bych viděl problém ve dvou věcech: MSIE neumí XML a mnoho webů z nejrůznějších důvodů vkládají javascript třetích stran, který v XML nefugnuje.

Dlouhán

na XHTML je zavedený zvláštní MIME typ
Jistě, text/html, to je mime typ, kterému rozumí prohlížeče a vyhledávače, i když jsou v kódu různé chyby.

Já bych viděl problém ve dvou věcech: MSIE neumí XML
Jůů, vy nevíte, co umí
Internet Explorer

mnoho webů z nejrůznějších důvodů vkládají javascript třetích stran,
který v XML nefugnuje

Cituji z Webylonu:
Jen tak mimochodem: všechny tři
nejrozšířenější prohlížeče podporují vlastnost innerHTML,
takže nejste-li

mimořádní amatéři
, můžete si document.write() hravě
doskriptovat.
Ale bacha — asi tím trošku nakrknete prohlížeče, které jsou drakonismu
věrné a nekonají, dokud nemají jistotu.

petr_p

na XHTML je zavedený zvláštní MIME typ
Jistě, text/html, to je mime typ, kterému rozumí prohlížeče a vyhledávače, i když jsou v kódu různé chyby.

Na to jsem se neptal. Ostatně jak typu text/html rozumí prohlížeče a vyhledávače a jak mu nerozumí jiné programy, je také zajímavá otázka.

Já bych viděl problém ve dvou věcech: MSIE neumí XML
Jůů, vy nevíte, co umí
Internet Explorer

Nic nového jsem se z té stránky nedozvěděl. Ona totiž vůbec nepopírá, že IE XML neumí. Ona spíše předkládá tvrzení, že IE XHTML neumí (a nepotřebuje umět), protože existují prohlížeče, které jej neumí. Nevím, co chcete touto tautologií dokázat.

mnoho webů z nejrůznějších důvodů vkládají javascript třetích stran,
který v XML nefugnuje

Cituji z Webylonu:

Jen tak mimochodem: všechny tři
nejrozšířenější prohlížeče podporují vlastnost innerHTML,
takže […] můžete si document.write() hravě
doskriptovat.

Ono to asi nebude tak zcela pravda. Kdyby byla, tak by tuhle emulaci dělaly prohlížeče samy od sebe. Ono totiž stačí, aby poslední document.write() nevytvářel správně uzávorkovaný kód, a přestanou fungovat i předchozí bezchybná volání.

Mimochodem XHTML kód, který jste v tomto příspěvku použil, je velmi zábavný. em a cite znamenají něco jiného, než jak jste je použil.

Timy

„Ona totiž vůbec nepopírá, že IE XML neumí.“

Ajajaj, to snad ta stránka neříká. Jestli ano, tak jste něco hodně špatně pochopil, protože MSIE samozřejmě XML zvládá. Otevřete si v MSIE libovolný RSS feed, například ten Zdrojáku. Otevře? Otevře. Umí? Umí :-).

„Ona spíše předkládá tvrzení, že IE XHTML neumí“

Ona především dokazuje tvrzení, že i MSIE umí XHTML. Zobrazte si v MSIE informace o stránce (pravý klik → vlastnosti) a uvidíte tam typ XML. Pak se podívejte do zdrojového kódu stránky a uvidíte XHTML.

petr_p

Jeden/dva/několik fungující(ch) příklad(ů) není důkaz funkčnosti. Naopak stačí jediný platný XHML soubor, na kterým selže, a je to důkaz, že neumí.

Já takový protipříklad mám. Jedná se o XHTML poslané jako application/xhtml+xml s XML prologem.

(Tohle jsem testoval kdysi ve verzi 7. Pokud je to už opravené tak třikrát sláva a až najdu nějaký stroj s Windows, tak zkusím najít další nefungující případ :(

Timy

„Jeden/dva/několik fungující(ch) příklad(ů) není důkaz funkčnosti. Naopak stačí jediný platný XHML soubor, na kterým selže, a je to důkaz, že neumí.“

Ale jo, taky jsem se učil důkazy v matematice. V tom případě žádný prohlížeč XHTML „neumí“, protože každý má nějaké mouchy a něco interpretuje jinak než praví standard. Hezký soupis je na webylonu (část Důkazní materiál).

Pokud tedy definujeme „umí X(HT)ML“ tak, že musí do puntíku splňovat nároky na standard, pak to patrně žádný prohlížeč neumí. Pokud to definujeme tak, že existuje nějaký X(HT)ML dokument, který daný prohlížeč zobrazí, pak to splní všechny prohlížeče. Přičemž stále platí, že není problém napsat stránku v XHTML tak, aby ji všechny běžné prohlížeče včetně MSIE rozparsovaly a zobrazily.

petr_p

Nevím, proč si zavádět vlastní uhnutou definici „umí XML“, když už ji máme zahrnout ve specifikaci XML (ve dvou úrovních pro nevalidující a validující parser).

Takže souhlasím, že v tuto dobu neexistuje/neznám žádný prohlížeč splňující specifikaci.

Důkazním materiálu je chybný bod České znaky při MIME typu „text/xml“ bez udání charsetu. Bez udání kódování se za implicitní považuje UTF-8 nebo UTF-16.

Timy

Protože v praxi nám i to málo co umí může stačit.

Dlouhán

A co třeba tenhle důvod, který se týká obecně XHTML (a XML), to je pro vás novinka?
http://blog.ataxo.cz/article:xhtml-mime-typ

smilelover

Nejde mi o XHTML vs. HTML, ja budu stejne psat HTML5 jako validni XML, kdyz na to prijde (a budu to posilat klidne se "spatnym" mime typem, jde mi o to, abych mel kdykoliv moznost na svuj markup pouzit kterykoliv z XML nastroju).

Jde mi o konkretni rozdily mezi HTML5 a XHTML2, o to, jak pristupuji k veci. Me konkretne se treba na XHTML2 libi, ze jde na vec obecne. HTML5 je prilis kratkozraka… elementy jako progress, header, footer, navigation IMHO vubec nemaji v takove specifikaci co delat. Oznacuji veci, u kterych neni vubec duvod, aby mely zvlastni tagy a ktere se daji vzdy vyresit kompozici zakladnich tagu a potrebnou semantiku jim lze dodat nejakym atributem pro to urcenym — treba "role", tak jak to navrhuje XHTML2. Tak mate volne ruce do budoucna. Osklivost jmenem predefined class names (hmus ala mikroformaty) uz je jen tresnickou na dortu… spolu se zombii "font" apod.

Samozrejme i moc dobre veci tam jsou (dialog, figure, vylepseni inputu), ale obecne z toho dobry pocit nemam.

Jirka Kosek

Nezapomínejte na to, že HTML5 otevřeně přiznává, že HTML od formátu pro dokumenty posouvá k prostředku pro psaní webových aplikací. Takže pokud přijmete tuto premisu, tak prezentační elementy či užší integrace s DOM dávají smysl. Jen se tím přiznává to, jak se dnes většina aplikací píše.

alancox

Problém XHTML je, že kromě toho, že je to XML dokument nic fakticky nepřináší. Naprosto, ale vůbec nic.

To, že je HTML posunuto směrem do XML je fakticky na 99,99999% pro web k ničemu. Každý browser tak jako tak musí obsahovat parser HTML, neboť HTML stránek je obrovské množství a browser je musí zobrazit. Takže na straně implementace je XHTML jen zesložitění, nikoli zjednodušení – nutnost implementace dalšího standardu.

Další problém XHTML je jeho nekompatibilita mezi verzemi.

Já bych řekl, že u XHTML zvítěžila akademičnost nad praktičností – a to, že browsery odmítají implementovat XHTML 2 beru s úlevou. Konečně někdo ten ošklivý způsob, kterým W3C neustále zesložiťuje standard HTML–>XHTML aniž by to cokoli _praktického_ přineslo zarazil.

Primárním důvodem, proč W3C chtělo zaříznout HTML byla neschopnost W3C jakkoli reflektovat praktické potřeby a nedokázala vůbec rozumně řídit vývoj HTML, protože vydávalo nedomyšlené a špatně navržené verze HTML. W3C nebyla s to ani dobře popsat gramatiku HTML, čím se ve všech normách jakéhokoli jazyka vždy začíná – tady to musel udělat až WHATWG skupina. Už to je důkazem neschopnosti W3C řídit vývoj.

XHTML zase W3C dovedlo do stavu, kdy to nejde tam ani zpátky.

Pokud chcete někdo argumentovat výhodami XHTML, pak prosím odečtěte marketinkové a fanatické hype, které se kolem XHTML udělalo. Pak zjistíte, že král je nahý – XHTML je nanic – bylo zbytečné a nic užitečného nepřineslo.

Osobně myslím, že daleko logičtější a přínosnější krok je web stránky v XML + styly, což má možnosti, které se od HTML někam posunují. Mimochodem, ani CSS není vynález W3C.

eee

Ach je, zase rozumbrada Ponkrac.

XHTML prineslo nove veci a to napriklad jmenne prostory a moznost skladani ruznych specifikaci v jednom dokumentu. A to je vyrazne vylepseni.

Jirka Kosek

W3C nebyla s to ani dobře popsat gramatiku HTML

Myslíte, že kombinace jazyka SGML + SGML deklarace pro HTML + DTD pro HTML je nejednoznačná? Gramatika HTML byla popsána dobře, ale žádný prohlížeč ji neimplementoval. Místo použití skutečného parseru SGML používaly prohlížeče vlastní parsery, které různě reagovaly na různé mezní situace ve zdrojovém kódu. To vedlo k drobně odlišnému pochopení stránek s chybným kódem a ve výsledku to způsobilo odchylky v zotavování z chyb mezi prohlížeči, které dnes řeší HTML5.

Takže celou situaci lze chápat i obráceně — výrobci prohlížečů museli založit WHATWG a začít pracovat na HTML5, aby napravili hnůj, který si způsobili o pár let dříve tím, že ignorovali specifikace HTML a SGML.

Jojo, nic není tak jednoduché, jak to vypadá.

David Grudl

To víte, SGML specifikace není zdarma ke stažení, takže spoustě HTML „odborníků“ připadá, že vůbec neexistuje :-)

Ale výrobce prohlížečů docela chápu. Když budu mít chuť na třešničku, taky kvůli tomu neupeču třípatrový dort s třešničkou, ale pokusím se sehnat jen tu třešničku (byť je třešnička specifikována jako to, co je na vrcholku dortu s třešničkou).

—-

(původně jsem jako příměr napsal, že kvůli kousku slonoviny přece nezabiju stádo slonů, ale pak mi došlo, že vlastně…)

eclipse_guru

U smluv to myslím u nás ze zákona nelze, u těch specifikací je to řekl bych "podvrh".

Synkretik

Vynucování copyrightu u schválených veřejných standardů mi přijde jako nesmysl. To je jako chránit copyrightem texty zákonů a ústavy. A ani OSA u nás nevybírá poplatky za zpěv Národní hymny :)

Žil jsem v domnění, že zákony, vyhlášky a standardy přijaté státními institucemi jsou z hlediska copyrigtu "public domain", tj. každý je může volně citovat či na ně navázat. Viz citace z Autorského zákona na konci mého příspěvku.

Pokud tedy W3C aspiruje na to, že jeho standardy jsou přejímány Úřadem pro technickou normalizaci, může IMO na copyrightovou ochranu zapomenout. Předpokládal bych, že podobný princip platí i v ostatních civilizovaných zemích.

Samozřejmně že soukromé standardizační instituty je jiná věc, ty ať si texty texty svých norem prodávají za takové peníze, jaké uznají za vhodné, ale pokud mají být webové standardy součástí státem přejatých norem (vzpomeňme na argumentaci kolem ODF / OpenXml), na copyrightovou ochranu můžou zapomenout. Což je IMO správně.

———
Citace z Autorského zákona:
§ 3 Výjimky z ochrany podle práva autorského ve veřejném zájmu

Ochrana podle práva autorského se nevztahuje na
a) úřední dílo, jímž je právní předpis, rozhodnutí, veřejná listina, veřejně přístupný rejstřík a sbírka jeho listin, jakož i úřední návrh úředního díla a jiná přípravná úřední dokumentace, včetně úředního překladu takového díla, sněmovní a senátní publikace, pamětní knihy obecní (obecní kroniky), státní symbol a symbol jednotky územní samosprávy a jiná taková díla, u nichž je veřejný zájem na vyloučení z ochrany,
b) …

Dlouhán

No jo, ale tady by nebylo až tak důležité kontinentální právo, a české už vůbec ne. Zákony amerických soudruhů jsou trochu jiné, než je v Eurosajůzu zvykem.

Petr Adamek

Na normy vydávané Úřadem pro technickou normalizaci, metrologii a státní zkušebnictví se výjimka dle § 3 nevztahuje, nejedná se o úřední dílo (viz explicitní výčet toho, co je úřední dílo).

Nejedná se ani o "jiná taková díla, u nichž je veřejný zájem na vyloučení z ochrany", protože ten veřejný zájem by musel být nějakým zákonem explicitně deklarován. Naopak zákon č. 22/1997 Sb. říká, že

"České technické normy nebo jejich části vydané na jakémkoliv nosiči smějí být, pokud zvláštní zákon (odkaz na zákon č. 183/2006 Sb., o územním plánování a stavebním řádu) nestanoví jinak, rozmnožovány a rozšiřovány jen se souhlasem pověřené právnické osoby nebo za podmínek stanovených v odstavci 6 se souhlasem Úřadu." (§ 5 odst. 8)

a že

"Úřad na základě podnětu, který obdrží, nebo na základě vlastního zjištění, uloží pokutu do výše 1 milionu Kč tomu, kdo

b) neoprávněně rozmnožil nebo rozšířil českou technickou normu, nebo její část (odkaz na autorský zákon)," (§ 19, odst. 3)

Takže když to shrnu:

1) normy jsou v ČR chráněné autorským zákonem jako jakékoliv jiné autorské dílo;
2) normy jsou v ČR chráněné i zákonem č. 22/1997 Sb., o technických požadavcích na výrobky;
3) autorská práva k převzatým normám navíc nedrží ani nevykonává Úřad pro technickou normalizaci, ale skutečný autor normy (v tomto případě W3C);
4) případný spor W3C s autory specifikace HTML 5 by stejně neprobíhal podle evropského autorského práva (které platí i v ČR), ale nejspíše podle amerického práva (které funguje na odlišném principu).

AHA

Moc pěkný rozhovor, děkuji!

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.