Názory k článku
Jiří Kosek: příprava specifikací je boj

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

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

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

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í.

O Jirkových pedagogických schopnostech nepochybuji a jsem upřímně přesvědčen, pokud někdo tvrdí, že má vážný problém Jirku pochopit, tak by měl začít hledat problém u sebe. Tedy pokud k tomu najde dostatek odvahy.

Když porovnám takový Zvon.org

Zvon je skvělý, mám ho rád. A je to práce celého týmu lidí (Zdravím Mílu, Béďu, Jirku a další...!)

Že i ty začneš kopat do lidí

Nejednalo se o urážku, nýbrž od odborný názor člověka, který několik let zcela vážně uvažoval o tom, že bude na vysoké škole přednášet, pedagogikou a hodnocením přednášejících se vážně zabýval i nadále zabývá. Připomínka nebyla adresována nikomu osobně, ale namířena do všeobecně pléna. Moc mne totiž zajímá, zda se objeví i další podobné názory.

Zcela vážně si totiž myslím, že už jen dokázat začít hledat problémy u sebe (tedy připustit si vůbec jejich možnou existenci), to není nikdy ostuda, ale odvážný a chválihodný krok pro kohokoliv. Vím, že to v dnešním světě řada lidí tak nevnímá, a proto může na původní větu reagovat citlivě. Z mé strany se má jedná o dobrou radu, nikoliv urážku, vlastně to slovo kopání je na místě, protože takový kopanec to vlastně byl. Ale správné nakopnutí, to je bude vždy potřeba. Jen víc takových!

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.

A v USA zase bijete černochy!

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

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

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

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

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.

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!

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.

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ěď.

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.

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.

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 ;)

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 :-)

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.

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.

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.

Téma Jirka Kosek a knížky ještě lehce otevřeme v druhé části rozhovoru. Pevně věřím, že tím některé čtenáře určitě potěšíme.

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)

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.

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.

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.

„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.

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 :(

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.

V 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.

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

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.

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.

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.

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á.

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ě...)

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

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) ...

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.

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).

Moc pěkný rozhovor, děkuji!