11.6.2010 13:56 | x | poslední úprava: 25.2.2018 21:38

         

Anketa

Komentáře

[Josef Kufner]

Problém je hlavně v tlačení XML i tam, kde se nehodí. Dalším problémem je jeho ukecanost. Když se to spojí ještě s nevhodným návrhem struktury dat, je na světě další katastrofa.

Jednoduché INI se za náhradu v mnoha případech považovat dá, protože data jsou nebo je možné je uspořádat tak, aby strom nebyl potřeba (například konfigurace většiny programů). Navíc to vede k zjednodušení programu (a pokud ne, tak se INI nehodí).

[AHAHA]

V mnoha pripadech staci mnohem jednodussi, jasnejsi, peknejsi a na datove struktury snaze prevoditelny JSON.

[void]

Kritika XML může být většinou kritikou JSON.

[Radek Miček]

Pro člověka je snáze čitelný například INI nebo YAML. Pro počítač jsou rychleji čitelné s-výrazy nebo JSON nebo nějaký binární blob.

[Václav HFechs Švirga]

jojo, yaml je fajn

[Radek Miček]

s/binární blob/blob/

[Ladicek]

Než se sem nahrnou lispaři se svými S-výrazy, řeknu si to svoje já: JSON je výrazně jednodušší, snazší na čtení i na psaní, a má o dost větší vyjadřovací schopnost (protože má pole). Jako konfigurační formát jsem ho viděl v Chromiu, CouchApp nebo třeba Keyczaru.

Jedna chuťovka od Intelu:

From Intel XML Parsing Accelerator, we found that character checking loop occupies more than 60% CPU cycles of the whole parsing process

[kralyk z abclinuxu]

JSON vypadá opravdu docela pěkně, jak je na tom s UTF-8?
A věděl někdo případně o nějakém lightweight JSON parseru á la TinyXML/ticpp?

[Ladicek]

RFC 4627 praví:

2.5 Strings:

All Unicode characters may be placed within the quotation marks

3 Encoding:

JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.

Přehled různých implementací najdeš na json.org, ale plnohodnotný minimalistický parser kdyžtak sám spácháš za odpoledne

[kralyk z abclinuxu]

Díky, to vypadá opravdu docela hezky. Ještě se tím proberu...

[Ondrej 'SanTiago' Zajicek]

- XML je primarne urcene pro markovani textu a na te syntaxi je to znat

- XML je casto naduzivano - ve vetsine pripadu clovek nepotrebuje strukturovana data a vystaci si s necim dost jednodussim.

- XML je neuveritelne prekomplikovane (staci se podivat na pocet stran specifikace), pro uchovani strukturovanych dat staci neco, co je radove jednodussi (napr. schemove s-expressions), takze clovek bud musi vyuzit nekterou z existujicich implementaci XML parseru (ktere jsou velke, pomale a zabugovane), coz je obzvlast nevhodne u mensich programu (je hloupe mit zavislost na nekolikrat vetsi knohovne jen kvuli naparsovani konfiguraku), nebou napsat parser pro vlastni ad-hoc podmnozinu pseudo-XML pouzivanou interne danym programem (to se take casto dela).

- pouzij s-expressions. :–)

[Let_Me_Be]

Tohle ti prijde dlouhe??? http://www.w3.org/TR/REC-xml/

[pavlix]

Tohle ti prijde dlouhe??? http://www.w3.org/TR/REC-xml/

Na to, jak málo to umí, mi to přijde extrémně dlouhé. Vždyť to co jsi odkázal umí jenom syntaxi pro strom nějakých znakových dat a nic víc.

Dokonce v tý odkazovaný specifikaci nejsou ani namespaces.

[mecheche]

Co to je pesudo podmnozina XML? Da se za to povazovat treba konfigurak Apache?

[Josef Kufner]

Spíš že vemeš jen jednoduché tagy (<x></x>, <x/>), jejich atributy a entity. Ono XML obsahuje ještě kopec blbostí navíc...

[Let_Me_Be]

Pokud vyuzijes vyhody XML, pouzivej XML. Pokud ne a potrebujes ulozit konfiguraci programu, nebo nejaka serializovana data na ktere nikdy nesahnes jinak nez pres svuj program, tak pouzij JSON, nebo YAML.

Pokud jde o ulozeni nejakeho vystupu programu, je XML velmi dobra volba.

[kralyk z abclinuxu]

Jde o výstup/vstup programu, data jsou strukturovaná příliš hluboko, než abych použil INI nebo něco podobně jednoduchého...
YAML mi bez urážky přijde lehce šílený, ale JSON vyzerá fajn...

[pavlix]

JSON je dobrá věc a už párkrát po mně chtěli lidi program s JSON výstupem, takže se ho asi budu držet i dál.

YAML mi přijde podobně šílený jako XML samotné. Takže jako náhrada dost těžko.

[Amarok]

nebo nejaka serializovana data na ktere nikdy nesahnes jinak nez pres svuj program, tak pouzij JSON, nebo YAML.

Proc? Prave k rucni editaci jsou JSON a YAML "relativne" vhodne. Jinak souhlas - XML jen pro automatizovany vystup dat a nasledne nacitani a zpracovani.

Ja jsem par mesicu mel OpenBox a odesel jsem z nej pouze z jednoho duvodu - XML konfigurace. To se proste nedalo... Malo prehledne, silene ukecane, co mam v PekWM na jednom radku, tam zabralo radku klidne 8 nebo 10. Nakonec se z neznameho duvodu cele XML rozsypalo (bylo cele na 1 radku), fungovalo do te doby, nez jsem potreboval neco upravit (zkousel jsem v ruznych editorech), proste jakmile se ulozilo, tak cely OpenBox odmital XML nacist, pry z duvodu chyb. Nekolik hodin jsem se snazil XML procistit ruznymi pomuckami, aby kod byl citelny, pak jsem to musel vzdat.

[xkucf03]

A validátorem jsi ho prohnat zkoušel? Třeba by ti řekl, kde je chyba.

[Amarok]

Urcite jsem to taky zkousel, je to uz pres rok, takze si detaily nepamatuju. Mozna neco validator nasel, jenze ukazal urcite jen chybu na radku c. 1, a editovat to vse na jednom radku proste bylo nad moje nervy (a ten openboxovsky konfigurak je fakt pekne velky). Kdyz jsem to nechal zalomit na konci radku, tak z toho byla proste necitelna slatanina, cili i oprava chyb byla pro cloveka silenost.

[xkucf03]

Pořád nechápu, proč byl ten konfigurák celý na jednom řádku. Vždyť na to stačí příkaz xmlindent konfigurák.xml a je odsazeno, případně použít nějaký inteligentní editor, který odsadit celý dokument taky umí.

[Amarok]

Tak xmlindent vubec neznam a nemam ho ani v systemu, mel jsem se tu radsi asi zeptat. Zkousel jsem to pres ruzne podobne utilitky online a tam to vubec neslo, jelikoz byly v kodu chyby a odmitalo to zformatovat. Jinak proc byl konfigurak na jednom radku? To bych prave taky rad vedel, proste to tak jednoho dne bylo, kdyz jsem ho otevrel.

[Michal Kubeček]

Pokud ho ukládá program a počítá se s tím, že to bude číst opět program, tak se tím ušetří nějaké ty mezery a linefeedy. Že by se ušetřilo mnohem víc, kdyby se to prohnalo gzipem, to je věc jiná…

[Amarok]

Tam prave naopak, konfigurak openboxu je koncipovan pouze pro rucni editaci, zadna utilitka k tomu neni.

[pavlix]

Tam prave naopak, konfigurak openboxu je koncipovan pouze pro rucni editaci, zadna utilitka k tomu neni.

A na to jsi přišel jak?

[Amarok]

Jednoduse v praxi. Aspon teda minuly rok openbox zadny pomocny program nemel (napr. na konfiguraci klavesovych zkratek), vse se resilo jen primo v XML.

[ground]

ja cerveniem iba pri asociacii s OOXML :D

[pozortucnak]

Tohle také vypadá hodně zajímavě - http://sexpr.sourceforge.net/

[Amarok]

To vypada na nejakou sprostarnu, na to nekliknu... :D

[pozortucnak]

s-expression

[Michal Kubeček]

Prohlásit XML za nepřehledné a pak jako řešení navrhnout s-expressions považuji za projev dosti zvráceného smyslu pro humor.

[pozortucnak]

Zas tak hrozné to není... a určitě to není tak náročná na pasování...

(edges
(
(1389.886593 1341.567282)
(1383.122623 1339.369530)
)
(
(1383.122623 1339.369530)
(1387.706464 1325.261939)
)
(
(1387.706464 1325.261939)
(1394.470360 1327.459664)
)
(
(1394.470360 1327.459664)
(1389.886593 1341.567282)
)
); edges end
(edges
( ( 1.1 2.2 ) (2.2 3.3) )
( ( 2.2 3.3 ) (3.3 3.3) )
( ( 3.3 3.3 ) (1.1 2.2) )
) ; end edges of triangle room

======================================================

(setq a (point 1 2))
(setq b (point 5 7))
(setq k1 (circle a b))
(setq k2 (circle b a))
(setq tmp (section k1 k2))
(draw a b (segment (point1 tmp) (point2 tmp)))

[Michal Kubeček]

Řeč byla o přehlednosti a tou ty vaše příklady příliš neoplývají. Parsování mne netrápí, od toho máme libxml2.

[kralyk z abclinuxu]

Parsování tě netrápí na domácích/osobních více-méně (spíš více) našlapaných strojích, tam je to celkem jedno. Ovšem úplně jiná situace nastává na serverech a embeded, kde je efektivita poměrně klíčová...

[xkucf03]

což se s XML nevylučuje

[kralyk z abclinuxu]

Já neříkám, že se to vylučuje, to byla jen obecná poznámka k větě "parsování mě netrápí".
Nadruhou stranu na základě toho jednoho příkladu nemůžeme efektivitu zpracování XML tak úplně potvrdit (i když částečně třeba jo)... konfigurace se načítá jednou při startu, předpokládám, případně se updatuje, což se ale děje málokdy. A ty kousky xml na stdinu nebudou nijak velké, ne?

Aby to bylo jisté, museli bychom mít čísla... porovnání, kolik cpu zabere parsování jakých dat a jak velkých...

[Ondrej 'SanTiago' Zajicek]

A ne? Staci se podivat na priklad seznamu s cislem a retezcem:

JSON: [123, "abc"]

sexp: (123 "abc")

XML:  <list><number>123</number> <string>abc</string></list>

Samozrejme, pro jednu konkretni aplikaci by asi slo udelat rozumne XML-based reseni a uvedeny priklad je jen jedna z moznosti, ale pokud uvazuju opravdu o generickem jazyku pro reprezentaci strukturovanych dat, pak je XML pro tyto ucely znacne neprehledne. Oproti tomu s-expressions a JSON jsou syntakticky velmi podobne.

[Petr Tomášek]

Co takhle:

<l n="123" s="abc"/>

[Michal Kubeček]

A pro úplnost ještě [ "number": 123, "string": "abc" ] :-)

[AHAHA]

Jenže { 123, "abc" } má úplně stejnou vyjadřovací hodnotu - hodnoty v JSON mají typy.

BTW, ten zápis je špatně.

[AHAHA]

V zápisu jsem se spletl i já, správně (jako originál) je [ 123, "abc" ]

[kralyk z abclinuxu]

hodnoty v JSON mají typy

Typy nemají o nic víc než v XML. Leda maximálně o uvozovky, to ale nic nezaručuje.

[AHAHA]

XML samotne nepodporuje zadne datove typy. JSON podporuje string, integer, float, null, boolean, pole a objekt.

Nechapu to "Leda maximálně o uvozovky, to ale nic nezaručuje". Uvozovky zarucuji, ze hodnota obsahuje retezec.

[kralyk z abclinuxu]

Zamysli se nad tím:
JSON: 123, 1.234, "string", ...
XML: 123, 1.234, "string", ...
V čem je přesně ten rozdíl?

[AHAHA]

JSON: [123, 1.234, "string"]

První je určitě integer, druhé je určitě float, třetí je určitě řetězec.

XML:

<values>
  <value>123</value>
  <value>1.234</value>
  <value>"string"</value>
</values>

První může být integer, float s ořezáváním desetinných míst nebo řetězec. Druhé může být řetězec, float, dva integer oddělené tečkou nebo cokoli jiného. Třetí může být řetezec obsahující "string", řetězec obsahující string nebo cokoli jiného.

[xkucf03]

Tady je vidět rozdílný přístup – zatímco JSON je jednoduchý, ale má podstatná omezení (zná jen pár datových typů a těžko tam přidáš něco dalšího), XML má možnosti prakticky neomezené – je rozšiřitelné, přizpůsobitelné (což ale zase vede k tomu, že na těch nejjednodušších příkladech, které se tu pořád omílají vypadá složitě).

Jak zapíšeš v JSONu IP adresu, nebo datum? Jako textový řetězec → tudíž budeš muset provádět kontrolu na úrovni aplikace. Kdežto v XML použiješ některý z hotových datových typů nebo si definuješ vlastní, třeba pomocí regulárního výrazu.

[AHAHA]

Jiste, o tom to je.

Ja problem vidim v tom, ze XML se v mnoha pripadech pouziva jako kanon na vrabce - na veci, kde by vynikaly prednosti JSONu (jednoduchost, vestavene primitivni typy a z toho vyplyvajici velmi snadna a prirozena manipulace) a nevadila jeho omezenost.

[pavlix]

Tady je vidět rozdílný přístup

Ano, přesně ten jsem měl v úmyslu ukázat, protože jsem měl za to, že ho ignoruješ. Rozdílný cíl/účel vyžaduje rozdílný přístup.

A v čem mi pomůže to, že XML schema má nějaké datové typy? A regulární výraz? Jak mi ten pomůže k naparsování prefixu do dvou například 32bitových čísel?

A jak nadefinuješ třeba rodné číslo? Taky pomocí regexpu? V tomhle je schema středně silný nástroj, který se tváří, že umí všechno, ale neumí.

Osobně trvám na tom, že ve výše uvedeném případě je XML méně vhodné než obě ostatní zmíněné možnosti.

Kdežto v XML použiješ...

Existují i jiné knihovny pro práci s datem, časem a IP adresama :).

[kralyk z abclinuxu]

Druhé může být řetězec, float, dva integer oddělené tečkou nebo cokoli jiného.

Ne, dle XML to dva integery být "nemůžou", to by byly každý ve svým tagu (což je ale spíše detail).
No a ten zbytek - to jsou všecko ty uvozovky, o kterých jsem mluvil
(No dobře, tak ještě tečka...)
Nicméně v tomto opravdu není mezi JSON a XML zásadní rozdíl. Vždycky jde především o způsob, jakým ty data interpretuješ. A od toho jsou různá ta schémata a podobná magie.
Slušný XML parser stejně obshuje funkce na typování do integer, float, atd... Takže ono je to šumák.

[AHAHA]

Ne, dle XML to dva integery být "nemůžou", to by byly každý ve svým tagu (což je ale spíše detail).

Ne, muzou. Muze to byt cokoliv, je na aplikace nebo schematu (coz neni "samotne XML"), aby definovala o co se jedna.

V samotnem XML neni zpusob, jak definovat typ hodnoty. To muzes ve schematu, coz neni "samotne XML". Pokud mas tedy jen XML, musis zarucit, ze vsechny zucastnene strany jsou dohodnute na tom, co co znamena.

V JSONu to neni potreba, 1.0 je vzdycky float, true je vzdycky boolean. Programatori se na tom nemusi domlouvat, protoze je to pevne.

Mozna ti to pripada jako detail, ale je v tom velky rozdil.

Slušný XML parser stejně obshuje funkce na typování do integer, float, atd... Takže ono je to šumák.

Pokud nema schema, tak nic takoveho udelat nemuze.

[kralyk z abclinuxu]

Ne, muzou. Muze to byt cokoliv, je na aplikace nebo schematu (coz neni "samotne XML"), aby definovala o co se jedna.

V tom případě můžu mít klidně v JSONu "12.33" apod. Taky tam můžeš mít cokoliv. Ano, nebude to JSON-košér, ale <item>123.456<item> jakožto dva integery taky není XML-košér.

Mozna ti to pripada jako detail, ale je v tom velky rozdil.

Tak mi ten velký rozdíl ukaž, opravdu mi není jasný, kde je.

Dejme tomu, že v aplikaci čtu z JSONu a z XML string a integer, integer se jmenuje "idnumber" a string se jmenuje "name".
Aplikace volá parser:
V případě JSON: Zkus vytáhnout integer označený jako "idnumber" a string označený jako "name".
V případě XML: Zkus vytahnout string označený jako "idnumber" a převést ho na integer, a vytáhnout string označený jako "name".
Čili JSON buď integer vytáhne, nebo řekne že tam není. XML vytáhne string, nebo řekne že tam není, zkusí ho převést na integer, a když to nejde, jako by tam nebyl. Určitý rozdíl v tom samozřejmě je, ale nehraje to nijak velkou roli.
Stejně si musí ta aplikace podle nějakého návodu říct o konkrétní věci.

[AHAHA]

Zkusim to jeste jinak: zamysli se nad tim, na co je schema. Pak ti snad dojde, na co je dobre vedet, jakeho typu jsou data.

[kralyk z abclinuxu]

Pak ti snad dojde, na co je dobre vedet, jakeho typu jsou data.

Schema nespecifikuje pouze jakého typu jsou data, ale především kde má jaký typ dat být, to je to podstatné, a v tom taky je rozlišení typů u JSONu prakticky nahouby.
Na co ti je dobrý, když víš s určitostí, že nějaký element je typu integer, ale nevíš jaký typ tam má správně být?
A naopak, když už víš (díky schématu) jaký datový typ má v určitém elementu být, tak už je ti jedno, jestli je z formátu je nebo není jasné, jaký typ to je, protože parser ti tak jako tak řekne, jestli je v té položce správný typ dat.

[pavlix]

Fajn, tak si můžete udělat JSON schema :). Je to asi tak stejně náročné jako udělat XML schema, které navíc očividně neuspokojilo všechy, takže k němu existuje několik alternativ.

S tím JSON schema to není zase tak špatný nápad. Možná už někdo něco i zkusil :).

[pavlix]

Viz http://tools.ietf.org/html/draft-zyp-json-schema-02

[kralyk z abclinuxu]

Jj však jo, imho JSON schémata jsou, co jsem koukal na wiki.
Já jsem rozhodně nechtěl nějak kritizovat JSON nebo vyzdvihovat XML. Z těch dvou se mi víc líbí JSON, jen jsem chtěl říct, že to typování je pouze minimální výhoda...

[AHAHA]

Schema nespecifikuje pouze jakého typu jsou data, ale především kde má jaký typ dat být, to je to podstatné, a v tom taky je rozlišení typů u JSONu prakticky nahouby.

Jiste, je to slabe, ale furt lepsi nez XML, ktere neumoznuje ani to rozliseni typu.

Na co ti je dobrý, když víš s určitostí, že nějaký element je typu integer, ale nevíš jaký typ tam má správně být?

Opet, jo, neni to idealni, ale stale lepsi nez neznat ani ten typ dat.

A naopak, když už víš (díky schématu) jaký datový typ má v určitém elementu být, tak už je ti jedno, jestli je z formátu je nebo není jasné, jaký typ to je, protože parser ti tak jako tak řekne, jestli je v té položce správný typ dat.

To jo, ale bavime se tu o cistem XML, ne o DTD nebo XML schema. Pokud mas schema, tak nemam nic proti. Problem spis vidim s hura programatory, kteri "jo, budem cool, budem pouzivat XML", ale na schema se vyprdnou.

[xkucf03]

Opet, jo, neni to idealni, ale stale lepsi nez neznat ani ten typ dat.

A co ti brání si do toho XML dát něco jako tohle?

<položka typ="int">123</položka>

Vždyť je to jako když v JSONu někde máš uvozovky a někde ne – vždycky stejně musíš v aplikaci řešit, jestli tam náhodou bez uvozovek není napsané třeba abcd místo čísla. V JSONu můžeš mít jen dva typy dat (no dobře, různé druhy čísel) a v XML jich můžeš mít neomezeně mnoho, to je to eXtensible ve zkratce XML.

Problem spis vidim s hura programatory, kteri "jo, budem cool, budem pouzivat XML", ale na schema se vyprdnou.

Něco podobného se mi nedávno stalo – asi trochu pod vlivem toho, jak se dneska všude vnucují noSQL resp. bezschémové databáze a je to děsná „móda“, tak jsem si řekl, že to taky zkusím bez schématu – akorát jsem používal XML a soubory, ale to je jedno. Je to velice jednoduchá aplikace, tak jsem si říkal, že to zvládnu – ale ne – hodně rychle jsem si to schéma dodělal. A to to byla opravdu jednoduchá aplikace s pár dokumenty o pár elementech – ale jak jsem ji vyvíjel, přidával nové funkce nebo měnil, tak se měnily i dokumenty – a nebavilo mne ručně kontrolovat, jestli je každý dokument je v souladu s aktuálním kódem programu (nebo to naopak nekontrolovat a nechat kód bobtnat různými alternativními větvemi jako, co když tenhle element chybí, nebo co když se jmenuje ještě postaru atd. tak udělej tohle…)

[Michal Kubeček]

A co ti brání si do toho XML dát něco jako tohle?

To, že potřebuje ukázat, jak je XML špatné. :-)

[AHAHA]

Snazim se ukazat, ze pro nektere pouziti jsou i lepsi formaty.

[xkucf03]

Ale jistě. Mým oblíbeným příkladem je kurzovní lístek ČNB, který je v prostém textovém formátu, hodnoty oddělené pomocí | a na každém řádku jedna měna. Je to tak jednoduchý typ dat, že XML snad ani není nutné, dá se to snadno parsovat bez jakýchkoli knihoven v libovolném jazyce.

I když i tady je to na hraně, některé věci si člověk musí domýšlet – např. že první dva řádky nejsou měny, ale hlavičky, datum a názvy sloupečků. Kódování se pošle v HTTP hlavičce, takže tady snad není problém (problém nastane, až když si někdo ten soubor uloží na disk).

Jenže těch jednoduchých úloh (jako kurzovní lístek) je relativně málo – a anti-XML fanatici pak často zbytečně vymýšlejí vlastní složité formáty a přidělávají práci sobě i ostatním, jen aby nemuseli použít to zlé, neefektivní, složité, nečitelné XML

[pavlix]

a anti-XML fanatici

Zatím jsem tu žádného neviděl, akorát pro-XML fanatiky. Teda na jednoho anti-XML jsem podezření měl, ale nepotvrzené.

Jakou máš motivaci prosadit XML jako jediné správné řešení a pošpinit všechny ostatní? Vždyť je to jen syntaxe.

[xkucf03]

Tak si to přečti znova – vždyť třeba u toho lístku ČNB mi to přijde celkem fajn – kdysi jsem ho parsoval a funguje to pořád stejně – zahodíš první dva řádky a ty další rozsekáš podle | a vybereš si z nich sloupečky, které tě zajímají. Bez jakýchkoli knihoven a je to kód na pár řádků. Tzn. i jednoduchý ne-XML formát se může dobře používat a může být fajn – za předpokladu, že i ty data jsou odpovídajícím způsobem jednoduchá. V tomhle případě je to vlastně tabulka a staré dobré CSV, akorát místo čárek jsou svislítka, ale to je jedno (+ je tam jedna hlavička navíc, ale tu přeskočíme). CSV je celkem dobrý formát, na tabulková data (akorát to chce pořešit kódování, escapování a dohodnout dělící znak, protože ten může být čárka, středník, svislítko jako zde, tabulátor, nebo cokoli jiného). Může to být i lepší než XML – na první pohled přehlednější.

Přestřelit se dá na obě strany – použít XML na příliš jednoduchá data nebo použít ne-XML na moc složitá data. Ale podle mých zkušeností se napáchalo daleko víc škody používáním ne-XML formátů na data, která se nakonec ukázala složitější, než si jejich autoři původně představovali. Viz třeba konfiguráky Apache*, /etc/sudoers a podobná zvěrstva.** Na druhé straně, když někdo použije XML i tam, kde není nutné, a já s tím musím pracovat, tak mě to tolik netankuje – může to být víc psaní (to stejně člověk zkopíruje, vyřeší programově, skriptováním, nebo to za něj udělá editor), ale zase nemusím dumat nad tím, v jakém kódování je dokument, jak se escapují znaky, jestli se používají uvozovky nebo apostrofy, jestli se hodnota přiřazuje pomocí rovnítka, dvojtečky, mezery nebo nějak úplně jinak, jestli řádky končí středníkem nebo ne atd. atd. Já opravdu nemám čas na to, abych se kvůli každému programu učil jeho vlastní syntaxi – stačí, že se musím učit, jak se jednotlivé konfigurační volby jmenují.

Závěrem bych řekl, že i ten JSON je většinou lepší než nějaké specializované formáty, které si vymyslel autor programu XYZ a nikde jinde se nepoužívají – je aspoň jakžtakž standardizovaný, i když neumí to, co umí XML, člověk se ho naučí jen jednou a pak tyto znalosti aplikuje na více místech (v tomhle jsou specializované „jednoduché“ formáty strašně neekonomické).

*) ty sice obsahují ostré závorky, ale XML to rozhodně není – horší formát jsem snad neviděl, a to jak sémantikou, tak syntaxí, opravdu zrůdnost.

**) a to nepočítám formáty, které jsou podělané už jen tím, že kódování není stanoveno ani v dokumentu, ani ve standardu, a tak je vždy jen předmětem domýšlení a věštění – např. tohle XML řeší – má se používat UTF-8 a pokud chceš něco jiného, tak si to deklaruješ uvnitř dokumentu (což má taky svoje mouchy, ale pořád lepší než nic).

[pavlix]

Tvůj příspěvek je neúměrně dlouhý tomu, na co reaguješ. Zřejmě máš spoustu času, tak ti doporučuju ho využít na psaní blogpostu, nebo ještě lépe kvalitních článků.

Tak si to přečti znova

Tak jsem si to přečetl znova a zareagoval bych znova stejně. Můžeš mě prosím upozornit, co jsem pochopil špatně a proč jsem si měl tvůj příspěvek číst znova?

Přestřelit se dá na obě strany

Mám to chápat, jakože uznáváš, že XML není na místě za všech okolností?

použít ne-XML na moc složitá data

Byly dokonce doby, kdy XML neexistovalo a pravděpodobně přijdou doby, kdy XML existovat nebude. Můžeš mi říct objektivní důvod, proč je XML jediným rozumným formátem pro "složitá data"? Samozřejmě kromě toho, že je v módě.

Závěrem bych řekl, že i ten JSON je většinou lepší než nějaké specializované formáty, které si vymyslel autor programu XYZ a nikde jinde se nepoužívají

Většinou.

má se používat UTF-8 a pokud chceš něco jiného, tak si to deklaruješ uvnitř dokumentu

Souhlasím že v tuhle chvíli nenajdeš vhodnější znakovou sadu než Unicode a vhodnější kódování než UTF-8 a taky doufám, že se bude čím dál tím víc ustalovat na úkor iso*, windows* i UTF-16.

[AHAHA]

A co ti brání si do toho XML dát něco jako tohle?

Nic. Jenze pak musis programatorovi (ktery ten XML bude generovat) na druhem konci datoveho toku vysvetlovat, ze prvky pole se ukladaji do tagu se jmenem polozka, typ dat se uklada v atributu prvku tohoto pole se jmenem "typ" a celociselny typ se znaci "int" a ne "integer". Vtipne bude, az se o mesic pozdeji zjisti, ze se v poli muze vyskytnout i null, pak se budete muset znovu dohodnout (novy atribut, typ="null" nebo jak?).

Vsechno tohle u JSONu odpada. Jinak JSON nema 2 typy, ale jak jsem psal kdesi nize: integer, float, null, boolean, pole a objekt.

Samozrejme, ze je XML mocnejsi a obecnejsi, nehodi se ale na jednoduche ulohy.

[xkucf03]

„Položka“ je generický název, který jsem použil jen v příkladu – ve skutečném XML takové elementy nemají co dělat*. Správně by název elementu odpovídal názvu té reálné věci, kterou XML modeluje – např. osoba má jméno a příjmení a věk – takhle se budou jmenovat i ty elementy, ne že to bude nějaký generický <objekt/> a bude obsahovat „pole“ podřízených elementů <položka/>, to je špatně a nepochopení/nevyužití možností XML.

Dávat typ do atributu nemá moc opodstatnění – jen jsem na tom chtěl ukázat, že XML umí to samé, co JSON (a mnoho dalšího), a že tenhle styl (deklarovat typ uvnitř dokumentu) je možný i v XML. Normální je používat datové typy, které jsou už definované.

*) tedy pokud se nejedná třeba o fakturu, která skutečně má položky.

[AHAHA]

Dávat typ do atributu nemá moc opodstatnění – jen jsem na tom chtěl ukázat, že XML umí to samé, co JSON (a mnoho dalšího), a že tenhle styl (deklarovat typ uvnitř dokumentu) je možný i v XML. Normální je používat datové typy, které jsou už definované.

Samozrejme, ze to v XML jde - problem je, ze docela slozite.

[pavlix]

jen jsem na tom chtěl ukázat, že XML umí to samé, co JSON

Tak to jsme se nepochopili. Považoval jsem za samozřejmost, že v XML půjde uložit to co v JSONu. I to, že pro něj taky jde nějakým způsobem definovat schéma.

a mnoho dalšího

Ono to XML v oblasti strukturovaných dat zase nic moc navíc oproti JSONu neumí, nebo jsem si aspoň ničeho nevšiml.

[pavlix]

V JSONu můžeš mít jen dva typy dat (no dobře, různé druhy čísel) a v XML jich můžeš mít neomezeně mnoho

Počkej, tohle nemůžeš myslet vážně. V čem je XML bohatší na typy než JSON?

Umí oba zapsat string? Ano.

Umí oba zapsat číslo? Ano, oba v textové podobě, JSON ho navíc narozdíl od XML odlišuje od stringu.

Umí oba zapsat strukturovaná data (seznamy a objekty)? Ano.

Tak mi prosimtě vysvětli, kde vidíš ten rozdíl, případně co tě vedlo k tomuto omylu.

[xkucf03]

Viz ty datové typy, které jsem tu už několikrát odkazoval – je to daleko bohatší než string a číslo. V XML je možné hodně věcí vyřešit už na úrovni formátu/parseru, kdežto JSONem projdou až do aplikace a musíš je ošetřovat tam – to je jedna z výhod XML. Opět je tu ta přenositelnost a znovupoužitelnost – pro někoho je možná tvorba XML Schématu nepřekonatelně těžká a napsat pár řádků v jeho oblíbeném jazyce mu přijde jednodušší, ale zase XML Schéma napíšeš jednou a použiješ v libovolném jazyce – tady zase záleží, jestli je to nějaká jednoúčelová interní záležitost, nebo věc, na které má spolupracovat víc lidí/firem/systémů/jazyků…

[pavlix]

Viz ty datové typy, které jsem tu už několikrát odkazoval – je to daleko bohatší než string a číslo.

XML specifikaci jsem četl a nic takového tam není.

V XML je možné hodně věcí vyřešit už na úrovni formátu/parseru, kdežto JSONem projdou až do aplikace a musíš je ošetřovat tam – to je jedna z výhod XML.

V tomhle se XML a JSON neliší.

pět je tu ta přenositelnost a znovupoužitelnost – pro někoho je možná tvorba XML Schématu nepřekonatelně těžká a napsat pár řádků v jeho oblíbeném jazyce mu přijde jednodušší, ale zase XML Schéma napíšeš jednou a použiješ v libovolném jazyce – tady zase záleží, jestli je to nějaká jednoúčelová interní záležitost, nebo věc, na které má spolupracovat víc lidí/firem/systémů/jazyků…

Co konkrétně se ti na JSON schéma nelíbí?

[kralyk z abclinuxu]

Jiste, je to slabe, ale furt lepsi nez XML, ktere neumoznuje ani to rozliseni typu. ...
Opet, jo, neni to idealni, ale stale lepsi nez neznat ani ten typ dat.

Jo, o pidikousíček lepší to je

To jo, ale bavime se tu o cistem XML, ne o DTD nebo XML schema. Pokud mas schema, tak nemam nic proti. Problem spis vidim s hura programatory, kteri "jo, budem cool, budem pouzivat XML", ale na schema se vyprdnou.

No tak s tím samozřejmě souhlasím, o tom žádná...

[AHAHA]

To je taky blbe. Ondrej Zajicek chtel jasne demonstrovat jednoduchost zapisu seznamu hodnot s informaci o jejich typu (= pole).

Problemy:

- do jednoho elementu asi nebudete dava obecne N atributu

- napr. stringu tam budete davat obecne vice nez jeden, jeden atribut musi mit jen jeden vyskyt

- "s" a "n" jaksi nabouravaji srozumitelnost

[xkucf03]

A je vůbec potřeba, aby definice typů byla součástí dokumentu? Nebylo by lepší, kdyby byla součástí nějaké definice schématu/typu a dokument obsahoval jen čistá data?

Tzn. místo:

<object>
  <string>Josef</string>
  <string>Novák</string>
  <integer>25</integer>
</object>

psát raději:

<osoba>
  <jméno>Josef</jméno>
  <příjmení>Novák</příjmení>
  <věk>25</věk>
</osoba>

V prvním případě dokument obsahuje informaci o datových typech, ale význam hodnot na jednotlivých pozicích musí být definovaný někde mimo dokument. Naopak druhý příklad obsahuje význam hodnot, ale neobsahuje informaci o datových typech – ta musí být definovaná mimo dokument.

Případně jde oba přístupy zkombinovat a uvnitř dokumentu definovat všechno:

<osoba type="object">
  <jméno type="string">Josef</jméno>
  <příjmení type="string">Novák</příjmení>
  <věk type="integer">25</věk>
</osoba>

Osobně mi přijde nejvhodnější druhá možnost, byť samozřejmě záleží na konkrétních podmínkách a ty druhé dvě taky mohou najít svoje využití.

P.S. píšu to v XML protože je mi nejbližší, ale mělo by to jít i v jiných jazycích – pro zajímavost můžete tyhle tři příklady přepsat do toho svého oblíbeného

[AHAHA]

A je vůbec potřeba, aby definice typů byla součástí dokumentu? Nebylo by lepší, kdyby byla součástí nějaké definice schématu/typu a dokument obsahoval jen čistá data?

Jak kdy. Nekdy se schemata hodi, nekdy ne. A o tom to je: "pick the right tool for the job".

Ta typovost mi prijde mnohem prijemnejsi a jasnejsi (kdyz to XML pisu, ma tam byt "integer" nebo "int"?). Samozrejme to funguje jen u primitivnich typu, ale to v mnoha pripadech v pohode staci.

Na JSONu se mi strasne libi, ze umoznuje 1:1 konverzi z klasickych datovych struktur. Naproti tomu XML je treba generovat a cist specialne ...

[pavlix]

Tobě přijde XML nějak výrazně přehlednější?

[Michal Kubeček]

Nemusí být, ale pokud se budu aspoň trochu snažit, bude (pro mne) přehledné do té míry, jakou u s-expressions nikdy nedosáhnu. Samozřejmě kromě triviálních příkladů na pět řádků.

[pavlix]

Troufám si tvrdit, že při troše snahy na tom JSON (a syntaxe slovníku) nebude hůře. S-expr nechme stranou.

[Michal Kubeček]

Přijde mi trochu zvláštní je nechávat stranou, když právě o nich byla v této větvi řeč. :-)

[User682]

zdravim,

co se tyce naduzivani xml, tak to uz tady nekdo dobre popsal a je zbytecne to opakovat.

Ono bude asi tezci prijit s nejakym lepsim formatem, kdyz uz tu xml je a aby ten format nemel chyby xml.

Podle me muzete hodne veci nahradit efektivneji pomoci objektovych databasi. Ale i ty nejsou prilis velkou spasou.

Udam tu hezky priklad:

Jeden clovek mi kdysi tvrdil, ze xml je na nic a ze by bylo lepsi si prenaset csv soubory pres web. A idealne si vytvaret svoje formaty ruznych druhu. Mozna na prvni pohled genialni myslenka.

Osobne jsem z toho ale mel pocit, ze ten clovek nedelal na necem vetsim, s hotovymi knihovnami. Ze nezna neco jako odolnost vuci chybe. Ze nezna neco jako spoluprace s ruznymi systemy, castmi aplikaci. Muzeme pokracovat vecmi jako narocnost na implementaci (vlastni parser textovych souboru muze byt rychlejsi, ale ne kazdy dela gramatiky).

Asi zasadni otazka, co by si mel polozit clovek pote, co mu nekdo rekne, ze technologie XXX je srot, tak kdo to rika a jak dlouho s tim delal. Pak se take muzete hodne nasmat.

gf

[Amarok]

Tady je ale rec pouze o rucni editaci (pokud tuhle diskuzi chapu spravne). Proti automatizovanemu zpracovani XML pomoci ruznych knihoven snad nikdo nic nemuze mit, k tomu byl ten format snad vytvoren.

[pavlix]

A já měl naopak pocit, že se W3C holedbá hlavně tou čitelností z pohledu člověka, což by naznačovalo přesný opak.

[Miloslav Ponkrác]

Ono je to jinak.

Kdysi existoval SGML standard (který nevytvořilo W3C). Jednou z aplikací SGML je HTML.

W3C se holedbá tím, že XML je implementačně jednodušší, než SGML. A to opravdu je. Od toho odvozuje W3C svá tvrzení o jednoduchosti a to byl jeden ze dvou účelů proč vzniklo XML.

Druhý účel, který je u W3C společný pro mnoho standardů je ten, že cokoli co nevzniklo u W3C tato organizace nesnáší, a musí to přeplácnout nějakým vlastním standardem a následně ten jiný standard poplivat na každém rohu.

Oba účely XML dokonale naplnilo.

Vidíte tam snad nějaké tvrzení o lidské čitelnosti, jednoduchosti XML, praktičnosti XML, výkonnosti XML, nebo něco takového?

Stejným způsobem postupovali v náhradě nenáviděného standardu HTML, který vedlo W3C tak špatně, že často jeho vývoj byl obohacován subjekty mimo W3C. Svou nenávist k HTML i SGML pak vyjádřili vznikem XHTML, který ovšem vedli stejně mizerně jako je běžné ve W3C organizaci. A dovedli ho do stavu, kdy všichni implementátoři browserů ho svorně odmítli v poslední verzi implementovat. Muselo nutně být ukončeno XHTML pro nezájem autorů browserů a WHATWG pokračovalo v HTML.

[pozortucnak]

HTML je značkovací jazyk, tedy dalo by se říci , že je XML také značkovací jazyk? V tom případě je skutečně nesmysl používat XML pro konfigurační soubory...

[Miloslav Ponkrác]

SGML i HTML je určeny primárně pro texty.

Protože XML bylo vytvořeno zjednodušením SGML, má v zásadě vlastnosti především pro ukládání formátovaných textů.

Také XML je lidsky nejčitelnější, pokud v tom začnete psát formátované dokumenty – na to je to geniální. I když SGML bylo na ruční psaní dokumentů mnohem lepší.

Pro XML připouští upouštění elementů přímo doprostřed textu, což je většinou pro konfiguráky k ničemu.

XML se používá pro konfiguráky proto, že

a) je to hrozně in a kdo nepoužívá XML tak je outsider

b) XML dokáže uložit stromovou strukturu

c) všichni se hádají a nedokázali navrhnout jednodušší rozumný formát na uložení stromové struktury, který by se jednotně převzal

[AHAHA]

XHTML zaniklo jen ve sve (nedokoncene) verzi 2.

XHTML5 (aplikace XML) bude to same jako HTML5 (aplikace SGML).

[Ladicek]

HTML5 není aplikace SGML, je to úplně samostatný formát.

[Miloslav Ponkrác]

Není. HTML5 se odpojilo od SGML, ale vzhledem k tomu co kolega nad Vámi napsal, bylo stejně jasné, že o tom moc neví.

[Miloslav Ponkrác]

XHTML se stalo mrtvé. Nebude se už dále vyvíjet a jeho vývoj i budoucnost byla odpískána.

Byla odpískána proto, že W3C v podstatě s každou verzí XHTML chtělo vytvořit zcela nový, s předchozími verzemi nekompatibilní jazyk. Kdybychom nechali řádit W3C ještě pár let, máme klidně 10 různých značkovacích jazyků, kdy by W3C považovalo za naprosto samozřejmé, že by browsery měly těmto deseti jazykům rozumnět. Přičemž všechny by vyjadřovaly naprosto to stejné.

XHTML5 je jenom pofoukání bolístky W3C, aby nebrečeli. Když k tomu dostanout ještě lízátko a nanuka, tak se dostanou z depresí.

Celé HTML5 je koncipováno jako sjednotitel a nástupce HTML. A tím také bude. Vše v HTML5 se řídí tím co je v existujících verzích a dialektech HTML.

Mimochodem, tento bordel také způsobilo W3C svou neschopností. Vydat normu 4 verzí HTML a v žádné z nich nepopsat syntaxi a závazný způsob parsování, takovou hoschštapleřinu umí jen W3C.

Ještě by měli W3C sebrat CSS, aby se to rozjeli a bylo by fajn.

Případně W3C zcela zrušit.

[pavlix]

Tak zaniklo (verze 2 je poslední verzí) nebo nezaniklo (pracuje se na verzi 5).

Já osobně vím, jak to mám chápat, ale na první pohled si tvé dvě věty přímo protiřečí... i když... "král je mrtev, ať žije král".

Osobně vnímám sjednocení HTML a XHTML velmi pozitivně. Celý ten hype okolo nového skvělého XHTML se spoustou skvělých vlastností a zahození starého HTML se nějak nepovedl. Plynulá návaznost mi přijde jako dobrá cesta.

Btw, jsi si jistý, že HTML5 je aplikace SGML?

[AHAHA]

No z XHTML zustal zachovan jen nazev a to, ze je to aplikace XML. Je fakt, ze jsem to v puvodnim prispevku moc dobre nenapsal.

S tim HTML5 a SGML jsem se spletl, resp. jsem mylne predpokladal, ze tak jako predchozi verze bude aplikaci SGML.

[Amarok]

Ja se spis divim, ze nutnost uzavirat vsechny TAGy se neprotlacilo aspon do HTML5. Ukonceni obou vetvi (html vs. xhtml) vidim taky jako vyhodu, ale nechapu jednoduse logiku v psani otevrenych TAGu (jako <br> <img> apod.), to je z programatorskeho hlediska pekny humus, proto taky zasadne pouzivam zapis xhtml. Je v tom asi videt ten zmatek a moc rozdilnych nazoru uvnitr W3C, jak tu psal i pan Ponkrac.

[Michal Kubeček]

U elementů typu br nebo img, které mají z definice empty content, to až tak nevadí. Za daleko horší považuji fakt, že HTML nikdy nezavedlo povinnost ukončovat elementy typu li, td, tr nebo p.

[default]

Mě spíš nebetyčně štve interpretace tagu script. Tohle funguje:

<script type="text/javascript" src="můj/geniální/script.js"></script>

a tohle nefunguje:

<script type="text/javascript" src="můj/geniální/script.js" />

[Michal Kubeček]

Správně by samozřejmě mělo fungovat oboje a pokud ne, je to chyba. Na druhou stranu, specifikace XHTML doporučuje (v HTML compatibility guidelines) používat staženou formu pouze pro elementy, které mají z definice empty content (img, br), a ne pro elementy, které mohou obsah mít, ale náhodou zrovna žádný nemají. On totiž třeba ještě MSIE verze 6 XHTML vůbec neumí a zobrazí ho pouze v případě, že mu o něm řeknete, že je to HTML, a také ho pak jako HTML interpretuje.

[xkucf03]

To se bohužel týká i pozdějších verzí IE :-/

[Michal Kubeček]

Hm. :-( Verzi 6.0 jsem zmiňoval proto, že je to poslední, u které jsem si tímto chováním jistý. Právě podobné věci vedly k tomu, že už oblast webdesignu (a zejména (ne)kompatibility prohlížečů) nesleduji tak jako dřív.

[pavlix]

No z XHTML zustal zachovan jen nazev a to, ze je to aplikace XML. Je fakt, ze jsem to v puvodnim prispevku moc dobre nenapsal.

Tak... zůstalo to, že je to apliakce XML a taky zůstalo to, že je to předpokládaný nástupce/alternativa HTML. Což si myslím přesně zkratka XHTML vystihuje.

To že si pánové teoretici vymysleli nějakou slepou větev, kterou jim nikdo nechce používat, to je jenom ukázka toho, že ignorování praxe je přinejmenším stejná chyba jako ignorování teorie.

S tim HTML5 a SGML jsem se spletl, resp. jsem mylne predpokladal, ze tak jako predchozi verze bude aplikaci SGML.

Myslím, že jednou z výhod novějších HTML je právě to, že se už oficiálně odklánějí od SGML, které už dávno browsery parsovat neumí.

[xkucf03]

To že si pánové teoretici vymysleli nějakou slepou větev, kterou jim nikdo nechce používat

To vycházíš z čeho? Že se lidi nevrhli na přepisování starých zprasených stránek do XHTML je celkem pochopitelné (to snad nikdo nečekal, ne?). Ale podívej se, v čem vznikají nové weby – tady se XHTML stalo normou, pokud někdo dělá seriózně* webdesign, tak používá právě XHTML, lidi si oddechli, že snad končí ten chaos a bude trochu pořádek, souvisí to i dost s koncem optimalizace pro jednotlivé prohlížeče a respektováním standardů, což je správná cesta. Slepá cesta je HTML 4, to je mrtvé, není důvod ho používat a (X)HTML5 pořád není hotové, a tak v podstatě jediným rozumným formátem je dneska XHTML 1.0/1.1. Časem asi (X)HTML5, ale zatím to není tak horké (zatím se o něm víc mluví a píší články, než že by se něco dělalo).

Házet špínu na XHTML prostě není na místě. Je to zralá osvědčená technologie, která se běžně používá. Rozhodně bych ji neoznačoval jako mrtvou nebo neúspěšnou. Mrtvé je HTML 4 a ve vývoji je (X)HTML5, což je zatím spíš experiment (a hlavně buzzword) a jak to všechno dopadne a kam se vyvine se teprve uvidí.

*) projdi si prezentace známých lidí a studií, co nabízejí webdesign – všichni dělají XHTML, zatímco HTML 4 nenabízí nikdo, za to by se musel stydět, HTML 4 prostě spadá do té smutné etapy webu, kdy byl všude neskutečný bordel a na stránky se dávali nápisy typu „optimalizováno pro MSIE verze X a rozlišení 800x600“. Ti pokrokovější se možná pochlubí znalostí (X)HTML5, ale v současné době jde hlavně o to říct: „my jsme nezaspali, víme, že to existuje a učíme se nové věci“ než že by se v tom seriózně pracovalo. Maximálně ti někdo udělá web s <video/>, ale stejně to bude ohackované javascriptem a pojištěné Flashem, aby se to lidem zobrazilo.

[Miloslav Ponkrác]

Kde se stalo XHTML normou a co vlastně vyřešilo?

XHTML se stalo stejný náboženstvím, mnohem větším, než XHTML. Neumí vůbec nic navíc oproti HTML kromě faktu, že je to XML, který je zcela k ničemu na web stránkách.

Webdesigneři si prostě vytvořili boha XHTML, ale nejsou s to to obhájit. Lidé, kteří něco umějí klidně používají HTML. Třeba i pan Kosek se diví, proč by HTML nemělo být používáno.

Nicméně i já mám web v HTML a budu mít web v HTML. A to jsem člověk, který kdysi před lety přinášel do Česka jako první informace o novém XHTML.

V zásadě když zhodnotím Váš příspěvek, tak kromě plácání se po zádech, že XHTML je nutnost a politickými nekorektními kecy jste tak asi skončil.

Možná jste to nepochopil, tak pro jistotu – XHTML je mrtvé. Možná to dnes není tak vidět, možná si to odmítáte přiznat, ale XHTML je mrtvé. Apple mluví o použití HTML, Google mluví o použití HTML, vyvíjí se oficiálně HTML5. XHTML je mrtvola, která za krátký čas zajde na nedostatek potravy a zájmu. Ať už si přejete co si přejete. Příčina smrti XHTML: W3C.

[AHAHA]

Pokud bude XHTML5 pouhym obrazem HTML5 v XML, tak v cem je problem? Parsovat webove stranky pomoci libovolneho XML parseru je dost prakticke, ne?

[Miloslav Ponkrác]

Parsovat webove stranky pomoci libovolneho XML parseru je dost prakticke, ne?

Naopak vrcholně nepraktické. Web browser tak jako tak musí umět HTML parsing, takže jediné čeho dosáhnete je nutnost přidání dalšího parseru.

Praktické by to možná bylo, kdyby browsery nemusely umět HTML, což se nikdy nestane.

A zasr...í browseru několika v zásadě identitickými standardy a dalšími parsery – aniž by to zvedlo užitečnost, to je asi vrchol toho co W3C dokázala.

[xkucf03]

Viz moje komentáře o filtrech a o tom, že by bylo dobré oddělit dvě věci:

1. věštění a domýšlení toho, jak to autor webu myslel, napravování zprasených webů jejich převod do nějakého normálního tvaru, který se dá zobrazit
2. vlastní vykreslování dokumentu

[pavlix]

Viz moje komentáře o filtrech a o tom, že by bylo dobré oddělit dvě věci:

Z pohledu idealisty tomu rozumím a chápu tě. Ale k tomuhle nemůžeš lidi donutit. Kde se nějaké to XSLT usadí a bude se pracovat tímto stylem, tak to bude třeba fungovat. Ale je to relativně drahé třeba pro jednotlivce, kteří by museli platit někoho, kdo dobře ovládá XML a XSLT.

[xkucf03]

Tím filtrem jsem nemyslel XSLT – ale kód prohlížeče, který se zabývá věštěním a domýšlením toho, co autor webu zanedbal. Tenhle kód by stálo za to vyčlenit do nějaké společné knihovny – pak by ideálně mohly mít všechny prohlížeče stejné věštecké schopnosti. A v nějaké daleké budoucnosti by se používaly prohlížeče bez této knihovny. Případně by sis mohl přeložit vlastní zjednodušený prohlížeč bez věšteckých schopností (např. pokud má zobrazovat jen tvoje aplikace, které máš pod kontrolou).

[pavlix]

Pokud ti jde o jednoznačnost jazyka, tak tu podporuju. Dokonce podporuju i spoustu myšlenek, které k vývoji XHTML vedly.

Jediné, co na snahách W3C nepodporuju je (1) slevování z požadavků během tvorby standardu a (2) ignorování reálných potřeb.

Tím slevováním z požadavků myslím například to, že původně mělo být XHTML parsováno striktně (z hlediska XML), pak se do specifikace dostalo, že bude dokonce volitelně parsováno jako text/html.

[AHAHA]

No, webove prohlizece jsou mi docela ukradene. Me zajima, jestli a jak si dokazu tu stranku zparsovat ve svem vlastnim programu.

[xkucf03]

Neumí vůbec nic navíc oproti HTML kromě faktu, že je to XML, který je zcela k ničemu na web stránkách.

Přínos XHTML byl obrovský, webdesign se konečně vyhrabal z toho hnoje, už se nedělali stránky psané na míru proprietárním prohlížečům, ale lidi si začali uvědomovat, že existují nějaké standardy, které slouží jako společná dohoda – řídí se jím webař, řídí se jím prohlížeč a výsledkem je fungující komunikace – to bylo v dobách HTML zcela nevídané. Lidi na tu dobu pomalu zapomínají, ale myslím, že je dobré o tom mluvit a občas to připomenout – dneska už se považuje za normální, že když si otevřu stránku ve Firefoxu, že vypadá stejně jako v IE nebo v Opeře, ale ne vždy tomu tak bylo.

Třeba i pan Kosek se diví, proč by HTML nemělo být používáno.

Pokud vím, tak pan Kosek k tomu řekl, že jeho stránky jsou moc rozsáhlé a on má spoustu jiné práce než aby je předělával do XHTML.

která za krátký čas zajde na nedostatek potravy a zájmu

Jak zajde? Přestanou ho podporovat prohlížeče? Začnou lidi hromadně přepisovat stránky z XHTML do HTML5? Obávám se že ne, stejně jako je všechny nepřepsali z HTML 4 do XHTML.

Ještě odkážu na diskusi na Zdrojáku – HTML 5 sice přináší některé zajímavé funkce (které možná budou zabity neschopností prohlížečů se na něčem shodnout), ale jinak je to strašný bastl, splácaný a nedokonalý, zbytečně zatížený údajnou „zpětnou kompatibilitou“. Viz moje komentáře k h1 a další.

[xkucf03]

P.S. ukazuje se to třeba i na značce <video/>, která byla velkolepě oznámena jako konečné řešení videa na webu a odstranění problémů Flashe, ale nakonec se ukázalo, že problém je někde jinde. Že stěžejní je společná dohoda na kontejneru a formátu – nikoli na tom, pomocí jaké značky to budeme zapisovat. Značka by klidně stačila ta již existující – standardní a starý dobrý <object/>.

[pavlix]

Značka <object> je skvělá a zbytečně duplikovaná všema těma iframes, video, atd... V tom s tebou plně souhlasím.

Ale vůbec zavedení toho, že video bude normálně přes HTTP a bez proprietárního software (a pokud ne, tak se takovému stavu aspoň co nejvíc přiblíží a časem se to třeba dožene), to byl účel zavedení této značky.

[xkucf03]

Jako jo, chápu, že věci je potřeba nějak pojmenovat, udělat tomu marketing a celá ta hysterie kolem HTML5 a <video/> vypadá líp než nějaká bezejmenná iniciativa za to, aby se prohlížeče shodli na nějakém jednom formátu a kontejneru, nebo aspoň se to dá líp prodat.

[pavlix]

Ono rozlišení tagů podle obsahu má svůj smysl, lidi (vývojáři) to snáz pochopí.

Mezi náma webařina je dneska tak přeceňovaná (a ta kvalitní podceňovaná), že se na tom uživí kdejakej blbeček, co vůbec neví, co dělá (tím myslím trochu i sebe před lety, ale já se aspoň snažil se zlepšovat).

[Miloslav Ponkrác]

Přínos XHTML byl obrovský, webdesign se konečně vyhrabal z toho hnoje, už se nedělali stránky psané na míru proprietárním prohlížečům, ale lidi si začali uvědomovat, že existují nějaké standardy, které slouží jako společná dohoda – řídí se jím webař, řídí se jím prohlížeč a výsledkem je fungující komunikace – to bylo v dobách HTML zcela nevídané. Lidi na tu dobu pomalu zapomínají, ale myslím, že je dobré o tom mluvit a občas to připomenout – dneska už se považuje za normální, že když si otevřu stránku ve Firefoxu, že vypadá stejně jako v IE nebo v Opeře, ale ne vždy tomu tak bylo.

Vážený pane, mám pocit, že dikutuji s fanatikem hrubého zrna.

Znovu: Pokud W3C NEDEFINUJE způsob parsingu HTML, ani další naprosto základní věci, pak vznikne hnůj, který ovšem způsobilo W3C. Takový hnůj vznikne kdekoli, kde standardtizační komisi dělají mentálně retardovaní jako třeba ve W3C. Pak nutně, chca nechca, musí výrobci prohlížečů domýšlet jak to mají dělat – a že to každý prohlížeč vymyslí jinak je logický důsledek.

W3C pomocí XHTML začala dělat stejný hnůj. Co XHTML, to zpětně nekompatibilní standard. Zmnožovala standardy, aniž by to bylo k něčemu.

Teprve až se do toho vložila realita, dostalo konečně zaslouženě W3C nakopáno do zadku. Na webdesignery vrhá velmi špatné světlo to, že hochštapleřinu W3C nepoznali, repsektive jen ti nejlepší, jako třeba Kosek. Jiní viděli růžovými brýlemi W3C tak růžově, jako to snad nebylo ani v Romeovi a Julii, když byli nejvíce zamilovaní.

Tedy blbost webdesignérů přizvukujících neschopné W3C pak museli napravit lidé z praxe.

1) Autoři browserů, kteří odmítli bordel W3C generující nedomyšlené XHTML verze – nedomyšlené z hlediska praktičnost – prostě zastavili svou nepodporou a veřejným vyjádřením, že XHTML dále podporovat nebudou.

2) WHATWG skupina mimo W3C, která se rozhodla dotáhnout HTML a dodat ty podstatné věci, které W3C ve své neschopnosti měla dodat už v HTML1, ale prostě jejich neschopnost jim to nedovoluje.

Teprve později prosila W3C na kolenou doslova WHATWG, aby se stala součástí W3C, jinak by W3C měla ostudu jako vrata, a nejspíše by ztratila prakticky veškerou autoritu. WHATWG souhlasila, ale za naprosto nadstandardních podmínek, který jiný projekt ve W3C nemá.

Bordel způsobený W3C neodhalili webdesigneři (ti byli zamilovaní do W3C způsobem, který se dá nazvat jen blbostí), ale uklidili ho praktičtí lidé mimo W3C – a také lidé mimo W3C způsobili, že se něco standardizuje.

Protože prkatičtí lidé uklízející bordel se vbrátili k HTML, je tohle budoucnost webu. XHTML je formálně mrtvé, žije jen z minulosti, ale dále už je impotentní. Plodný samec, ze kterého dále budou vyvěrovat webové standaryd už bude jen HTML.

Kdyby webdesigneři projevili soudnost vůči W3C, je tu pořádek už dávno. Nicméně sněte si dál svůj sen – za pár let se podívejte kde bude XHTML.

Napsal jsem to drsně, ale podle skutečnosti. Nejsem webdesignér, a nemusím se bát psát pravdu, nejde mi o kšeft. Když webdesigneři zákazníkům nakukali, že XHTML je to pravé, nemohou jim teď říct, že se spletli, ale musí těžit prachy od zákazníků dokud to jde.

Přínos XHTML není žádný, s okolnostmi přímo záporný. HTML umí vše co XHTML, to samé, navíc je v něm skutečná budoucnost. Tečka. Dál nebudu na toto téma reagovat. Vy chcete snít svůj sen o XHTML, sněte, Váš problém.

[pavlix]

A ještě si Franta neuvědomuje jednu věc...

V době, kdy přicházelo XHTML tak webdesigneři tvrdě stáli za HTML, protože to fungovalo a bylo to zavedené.

Když se najednou zjistí, že vývoj XHTML nejde úplně dobrým směrem, pozdější designeři pevně stojí za XHTML1 a HTML/XHTML5 je pro ně moc velká novinka.

Já bral šikovné novinky vždycky plnýma hrstma, takže po přechodu

HTML4 text/html -> XHTML1 text/html

klidně přejdu na korektnější

HTML5 text/html

a až bude XML na webu přinášet nějaké výhody, tak přejdu na

XHTML? application/xml, případně application/xhtml+xml nebo jiné

[pavlix]

Přínos XHTML byl obrovský, webdesign se konečně vyhrabal z toho hnoje, už se nedělali stránky psané na míru proprietárním prohlížečům

Pokud vím, tak tohle přineslo právě HTML 4.0.

XHTML 1.0 nepřineslo pokud vím žádné změny značek nebo vůbec cokoliv co by sjednocovalo prohlížeče více než předtím... a navíc přineslo nový velmi špatný zvyk a to vydávat XHTML za HTML.

[kralyk z abclinuxu]

+1

[pavlix]

Nicméně i já mám web v HTML a budu mít web v HTML. A to jsem člověk, který kdysi před lety přinášel do Česka jako první informace o novém XHTML.

Tak v tom tě můžu jenom podpořit.

On je velký rozdíl mezi lidmi, co vědí a lidmi, co se potřebují svést na vlně nadšení. A když někdo zapadá do obou kategorií, tak je to docela schíza, na jedné straně se chovat k zákazníkům tak, abys splnil očekávání a na druhé straně jiným říkat jak věci jsou.

[pavlix]

Ale podívej se, v čem vznikají nové weby – tady se XHTML stalo normou

Bavíme se oba dva ještě pořád o XHTML 2.0 nebo vznikl nějaký informační šum?

Zatím jsem slovo XHTML viděl používat hlavně s nesmysly typu content type text/html s hlavičkou XHTML 1.0, případně 1.1 a jestli toto někdo označuje za pokrok, tak má trošku jinou definici pokroku než já.

projdi si prezentace známých lidí a studií

Kdybych se živil webem na této úrovni, tak bych asi musel tohle divadlo hrát taky. Ale ruku na srdce, kde jsou výhody XHTML 1.0 proti HTML 4.0 pro koncového uživatele?

[void]

JSON vs XML - příklad na Wikipedii. Je to skoro stejné.

[Amarok]

Az na to, ze se JSON rozhodne lip cte.

[void]

Subjektivní - viz můj komentář o závorkách.

[void]

Dokonce z toho JSON může být při větším dokumentu závorkové peklo. V XML jsou pojmenované otevírací i ukončovací elementy, takže se člověk vyzná; v JSON jsou jen závorky.

[Josef Kufner]

To sice může, ale pokud se to prožene nějakým formátovacím udělátkem, tak v tom nebude sebemenší problém. Ono ani to XML není kdovíjak čitelné při větších objemech dat. Výhoda pojmenování uzavírací závorky je jen při delší vzdálenosti od té otvírací, ale u krátkých úseků, kterých je výrazně více je spíš na obtíž.

Btw, k tomu příkladu na wikipedii... Po odříznutí odsazovacích mezer má XML 328 znaků a JSON jen 273. To je o 55 znaků méně na triviálním 15řádkovém kousku dat.

[Ladicek]

Ono to fakt je skoro stejné. Akorát že JSON nemá entity, mixed content a podobné šílenosti

[void]

V JSON zase dochází k mixování "schématu" a vlastních dat:

"firstName": "John"

[Ladicek]

Metadata jsou taky data

[void]

Ale jsou meta. ;)

[pavlix]

JSON zase dochází k mixování "schématu" a vlastních dat:

K tomu v XML dochází úplně prakticky stejně.

<firstName>John</firstName>

To schéma je tam akorát zduplikované a best practice říká, že se nebudou používat libovolně nazvané tagy, ale dodržuje se nějaké schéma (i kdyby nepsané). Stejná konvence jde aplikovat i na JSON.

[podlesh]

Jen počkejme, vsadím se že někde existuje nějaká komise IBM+Microsoft+Oracle a něco takového kutí (Enterprise JSON?).

[Ladicek]

Hope not! Všechno, co jsem nad JSONem zatím viděl (JSON Schema, JSONPath), vypadá docela rozumně.

[xkucf03]

V JSONu zase nenapíšeš knihu

[Ladicek]

A bohudíky za to! Ostatně knihy se nepíšou ani v XML, to jen banda pošuků od počítačů občas používá DocBook k psaní dokumentace.

[xkucf03]

A v čem? V LaTeXu/TeXu? Psal jsem v obojím a to XML mi přijde příjemnější – nejen syntaxí, ale i tím, že v DocBooku píšu, co se bude sázet, ne jak se to bude sázet – nakonec se teprve uvidí, jestli z toho bude PDF, HTML nebo něco úplně jiného.

[Radek Miček]

Psal jsem v obojím a to XML mi přijde příjemnější – nejen syntaxí

Obvzláště pro zápis matematiky. Syntakticky je TeX flexibilnější než XML a podle mne zápis v TeXu je i přehlednější.

v DocBooku píšu, co se bude sázet, ne jak se to bude sázet

Pokud chcete udělat typograficky kvalitní dokument, tak je to nevýhoda.

[Miloslav Ponkrác]

DocBook nikdy na typografii nebyl. Nicméně to neznamená, že v něm nejde udělat typograficky kalitní dokument. Jen je třeba si uvědomit účel DocBooku, opravdu to není nástroj na výrobu reklamních plakátů.

[pavlix]

Mno zápis v TeXu je možná přehlednější na čtení... ale rozhodně je daleko složitější na tvorbu a neviděl jsem žádnou kvalitní ucelenou dokumentaci, která by mi umožnila psát v TeXu tak, aby se to přeložilo a vypadalo tak jak chci.

[Ladicek]

V čem? No, knihy se obvykle píšou v textovém editoru Autor se sazbou většinou vůbec nepřijde do styku.

Jinak volba mezi DocBookem a (La)TeXem je volbou ze dvou zel, obojí je do určité míry zvrhlé a záleží na tom, k jaké úchylce inklinuje uživatel. O žádné třetí volbě nevím, osobně bych vybral ten LaTeX.

[Miloslav Ponkrác]

Jakto?

Já knihu napsal a celou jsem jí napsal ve vimu v plain textu. Následně posadil do libovolného textového editoru (Word, OpenOffice) – cokoli co umělo styly.

Vytvořil jsem si asi 20 stylů způsobem „nadpis 1", „normání text“, „popis k obrázku“, „zdrojový kód“, „URL odkaz“ a tak dále.

A to jsme poslal sazeči. Jakýkoli dnešní sázecí program umí leccos importovat a styly vypreparovat.

Totéž můžete dělat i ve Scribusu. Importnout si OpenOffice text, upravit si styly a udělat sazbu. Naprosto minimální práce.

DocBook a Latex je obojí svinstvo na nic. Není důvod v tom primárně psát knihu. V DocBooku by se dalo, kdyby k tomu existoval nějaký editor, nástroj, či cosi. DocBook dneska schopně umí používat jen Kosek, který tomu věnoval celý život. Pro normálního člověka je penzum času, který DocBooku musí věnovat dost neúnosné pokud chce napsat něco většího – pro absenci slušných nástrojů kolem DocBooku.

Latex zase není editor na psaní knihy, je to sázecí program vzniklý už hodně dávno.

Člověk si hlavně nesmí věci komplikovat – tedy není-li masochista, který z toho má exaktické pocity.

[Ladicek]

No, takže v textovém editoru. Jasně, autor musí nějak vyznačit nadpisy, zvýrazněný text, popisy k obrázkům atd., a některá nakladatelství jsou zařízená na Word. Ale neříkal bych tomu, že jste udělal sazbu

Jinak mám pocit, že si neodporujeme. Psát knihu v TeXu nebo DocBooku je práce pro vraha (DocBook – Kosek, TeX – Olšák ), ale pro takové ty technické dokumentace, které má ve firmě na starosti s bídou jeden člověk, se to asi dá.

[Miloslav Ponkrác]

Ale od vyznačení stylů pak sazba nemá skoro co dělat. Vezme nějakou šablonu stránky/stránek, naimportuje text, nadefinuje každý styl, chvíli šoupá myší aby to ručně upravil a je vysázeno. Pokud si s tím nechcete hrát.

Referenční dokumentace generuji Doxygenem, jako asi ve většině firem. Dá se v tom rozumně napsat i něco vlastního. Vygeneruje to HTML, PDF, TeX, Word, man stránky, info nápovědu, a x dalších formátů.

DocBook by byl silný nástroj, kdyby pro něho existovalo nějaké IDE. Nicméně DocBook pro sazbu není, protože informačně do něho spoustu věcí nazanesete.

Samozřejmě pokud si s tím člověk může hrát dá se leccos.

[xkucf03]

Já knihu napsal a celou jsem jí napsal ve vimu v plain textu.

A nebylo by lepší do toho textu ve vimu občas vrznout něco jako:

<section>
<title>Tohle je nadpis</title>
… a tady zase pokračuji v psaní prostého textu
</section>

nebo aspoň

\section{Tohle je nadpis}

než to pak procházet znova označovat kusy textu a dávat jim styly dodatečně?

[Miloslav Ponkrác]

Bylo.

Ale použitý sázecí program by to nenaimportoval.

[kralyk z abclinuxu]

JSON vs XML - příklad na Wikipedii. Je to skoro stejné.

Ok, jesliže jsou oba tyto formáty nevyhovující, jakou alternativu navrhuješ?

[void]

Ta podmínka je false, takže ti nic nenavrhnu.

[Václav HFechs Švirga]

yaml? :P Čitelný asi nejvíc, ale opruz je to odsazování no... nic není ideální.

[kralyk z abclinuxu]

Sry, ale ten se mi moc nezamlouvá...

[Robo]

XML sa da najebat vsade; neni treba viac riesit

[Messa]

S ostatními odpověďmi souhlasím, jen bych přidal ještě další poznámku - kolem XML je docela velký ekosystém. Zatímco JSON, YAML a podobně jsou "jen" formáty pro ukládání relativně jednoduše strukurovaných dat (a proto tento jediný úkol mohou zvládat lépe), XML poskytuje možnost jmenných prostorů, validace, XPath, XSLT... Samozřejmě, to všechno lze udělat i pro ty ostatní, ale toto je standardizované a víceméně zavedené. Zkuste si představit složitější webovou stránku v JSONu místo v XHTML... bordel by to nebyl o nic menší

[Radek Miček]

Na webové stránky lze použít Haml.

[Messa]

Pokud myslíš stránku s pár elementy, z toho většina <div> s nějakou třídou nebo id, pak ano.

[JS]

Velky ekosystem je i PHP.

[pavlix]

Já bych to viděl jinak...

Webové stránky jsou typický use case pro "mixed content"... a to ať se nám to líbí nebo ne.

Různým datovým formátům a konfiguračním souborům typicky mixed content škodí.

Z tohoto pohledu lze XML a JSON jen těžko srovnat, když přesně každý vyhovuje jiné aplikaci (samozřejmě pokud na tento názor přistoupíš).

[xkucf03]

Různým datovým formátům a konfiguračním souborům typicky mixed content škodí.

Jak může škodit? Prostě ho nevyužiji (nepovolím ve schématu) a je to. Že má XML hodně funkcí a mně jich stačí málo přece není takový problém. Počítač taky umí (může umět) spoustu věcí a přesto ho hodně lidí používá jen k brouzdání po webu – a nevypadá to, že by jim to nějak vadilo.

[pavlix]

Já stejně trvám na tom, že škodí.

Za prvé je tomu na míru postavená syntaxe, takže musíš pečlivě značkovat úplně všechno. Viz:

acl {
    10.0.0.0/8;
    192.168.0.0/16;
    172.16.0.0/12;
}

případně

[
    "10.0.0.0/8",
    "192.168.0.0/16",
    "172.16.0.0/12"
]

versus

<acl>
    <item>10.0.0.0/8</item>
    <item>192.168.0.0/16</item>
    <item>172.16.0.0/12</item>
</acl>

Dál ještě XML knihovny dost překáží programátorovi, co potřebuje právě jenom takové jednoduché konfigurační direktivy. Parsing je ok (když vynechám efektivitu), ale třeba generování "pěkných" XML konfiguráků řeší velká část běžných XML knihovem špatně (teď ani nevím, která to řeší dobře).

[pozortucnak]

http://en.wikipedia.org/wiki/SXML

[kralyk z abclinuxu]

V tomhle byly skripty k jedný hře. Už nikdy více

[JS]

Ja XML nenavidim, i kdyz s nim (nastesti) moc pracovat nemusim. Je to jazyk, ktery se pouziva zcela nesmyslne. Jak uz poznamenal Ondrej Zajicek, na markup dokumentu je to fajn. Na ostatni veci (zejmena konfigurace a komunikace pocitac-pocitac) jsou to prekomplikovane S-expressions (zejmena je v navrhu schematu problematicka dichotomie element/atribut, ktera ma prave vyznam je pro dokument markup).

Sice to nesouvisi tolik s XML, ale doporucoval bych vam tento clanek.

Ja za tim vidim marketing. Stejne jako za Javou. Sun se snazil Javu prosazovat kde to slo (a skoro vsude, kde se to delalo, to nedavalo smysl), a podobne je to i s XML. Muzete to pouzit, ale je to pres ruku.

[kralyk z abclinuxu]

Hm, ten nápad s nahrazením jazyka C/C++ preprocesoru samotným C/C++ je sice lehce naivní, ale jinak velmi zajímavý...

[Ladicek]

Makrojazykem pořádného programovacího jazyka je ten jazyk sám, to se učí děti snad už v mateřské školce

[Josef Kufner]

Teoreticky možná, prakticky určitě ne.

[JS]

V (Common) Lispu to tak je. A to je velmi prakticky jazyk. Ale mozna se ta vase veta vztahovala na deti v materskych skolkach, nejsem si jisty.

[Michal Kubeček]

To, že pár lidem LISP vyhovuje, ani zdaleka neznamená, že je to praktický jazyk.

[JS]

Naopak, je to jeden z nejpraktictejsich jazyku. Nevnucuje vam zadne paradigma, jak mate programovat. To je velmi prakticke. A takove prakticke veci, jako treba makra nebo signaly, zatim do jinych mainstream jazyku nedorazily.

Samozrejme, spousta lidi vidi jen zavorky a maji pocit, ze diky tomu je to neprakticke. Ale to je jen o zvyku.

[pozortucnak]

Psát za každým příkazem středník, nebo každý příkaz o závorkovat, to vyjde  téměř nastejno...

[Miloslav Ponkrác]

Zvláštní, když je jazyk volný a nevnucuje paradigma, dává velkou svobodu, pak je to špatný jazyk (častý argument, kterým se tu řada lidí pokouší střílet do C++)

Nicméně LISP je IMHO až moc syrový jazyk. Tedy v zásadě je to tak blbý, až v něm jde všechno.

LISP z původní velké obliby ustoupil do pozadí, a s ním plus mínus všechny klasické funkcionální jazyky. Protože nejsou praktické pro běžné programování.

LISP-like jazyk je velmi jednoduché implementovat. Ano vyjadřovací schopnosti a možnosti toho jazyka jsou obrovské, volnost neskutečná. Dokonce má řadu atributů, které běžným jazykům chybější – například snadno se paralelizuje.

Jenže pro praxi LISP není příliš praktický jazyk, je to ideální jazyk pro akademickou sféru, nebo pro krátké skripty.

[pozortucnak]

A já myslel, že ta dnešní módní věc - closures pochází z funkcionálních jazyků... a lambda ve 2.x pythonu...

[Miloslav Ponkrác]

Z functionálních jazyků pochází leccos. Dokonce jedna panípovídala, že objekty vznikly původně hraním si na LISPu. Co je na tom pravdy nevím.

Funkcionální jazyky jsou obrovské semeniště nápadů. Nicméně stále si všimněte, že praxe dává přednost tomu adoptovat nějakou featuru / nápad z funkcionálního jazyka do nějakého mainstreamového, než aby používala čisté funkcionální jazyky přímo. Proč asi? Co to o těch funkcionálních jazycích říká?

Přihodím ještě jeden fakt. Když jsem začínal se sw, funkcionální jazyky byly velmi rozšířené. Nedalo se s nimi nesetkat, ani je v praxi vynechat. Ale jejich rozšíření v zásadě jen klesá. Co to o těch funkcionálních jazycích říká?

Abych neryl jen do funkcionálních jazyků. Existoval taky logický jazyk Prolog, kterému se předvídala obrovská budoucnost. Nové programátorské paradigma – logické programování. Dneska po něm pes neštěkne.

[pozortucnak]

Jelikož nejsem programátor, tak nemohu soudit.
Ale celkem by mě k tomuto tématu zajímali názory ostatních...

[pavlix]

Možná proto, že není tak úplně jednoduché najít slušný interpret prologu se slušným debuggerem.

Ten jazyk se mi v některých ohledech i líbí a klidně bych ho použil na části programu a volal třeba z C nebo čehokoli jiného. Ale zkoušel jsem odladit něco v SWI prologu a ten program mi přijde z hlediska ladění naprosto nepoužitelný. A kvalitní náhradu jsem nenašel.

[Radek Miček]

Prolog ještě úplně nevymizel.

Ale jejich rozšíření v zásadě jen klesá.

To si nemyslím. Už jen proto, že poslední dobou vychází docela velké množství knih o funkcionálních programovacích jazycích jako F#, Scala nebo Clojure.

[Miloslav Ponkrác]

V (Common) Lispu to tak je.

Common Lisp v zásadě neumí nic jiného, než makrovat. Je na makrování do značné míry založen.

Takže preprocesor máme, a ještě k LISPu přidat nějaký programovací jazyk.

[JS]

To je omyl. Common Lisp podle standardu obsahuje temer vsechny konstrukce ostatnich jazyku a nektere dalsi (treba signaly). A standardni knihovnu ma srovnatelnou se standardni knihovnou starsiho C++ (ale uz ne srovnatelnou s Javou nebo Pythonem). Naimplementovat cely Common Lisp da opravdu dost prace.

A nektere komercni Lispy maji skutecne knihovny, ktere jsou srovnatelne se standardnimi knihovnami Javy. Nicmene, co polozilo Common Lisp bylo prave IMHO to, ze nebyla zdarma verze s velkym mnozstvim dalsich knihoven (a urcita roztristenost komercnich implementaci, to spolu souvisi).

Stejne tak je mylne vase dalsi tvrzeni, ze Common Lisp je funkcionalni. Ja v nem treba programuji drsne imperativne.

[Miloslav Ponkrác]

No a C++ zase (což tu nebylo zmíněno) obsahuje věc, která do značné míry je stupněm mezi preprocesorem a programovacím jazykem a je to plnohodnotný Turingovsky kompletní systém zvaný šablony.

Common Lisp může obsahovat co chce, ale celý LISP je především stavěn na obdobě makrování. Tudíž se vůbec nedivím, když se tu mluví o preprocessoru, že LISP je ideální kandidát, protože to co umí je v zásadě přerostlý preprocesor.

Prostě Lisp je jazyk, který vznikl od makrování (trochu zjednodušuji), C/C++ je jazyk, který původně vznikl z opačného konce.

O tom jak kde programujete není důkaz ničeho, protože „každý fortranista programuje v každém jazyce jako ve fortranu".

[JS]

To co tvrdite je nesmysl. Prectete si neco o Common Lispu (treba knizku Practical Common Lisp nebo referenci Common Lisp the Language). Semantika Common Lispu stoji na 29 specialnich formach, a jen 2 z nich se tykaji maker (konkretne macrolet a symbol-macrolet).

Abyste mohl programovat v Common Lispu, vubec nemusite umet makra psat (a jejich pouzivani je stejne jako pouzivani specialnich forem). Stejne tak, kdyz mrknete do Common Lisp the Language, z asi 30 kapitol je tam o makrech jedna kapitola.

[Miloslav Ponkrác]

Celý LISP je zabstraktněné makrování a nějakou omáčkou kolem. Tak to prostě je.

Třeba když to vezmete kolem a kolem, tak v klasických jazycích je třeba if, else, while, for, volání funkce, return, volání metody, výjimky – to vše a leccos dalšího je jen zobecněný koncept skoku (případně s nějakou podmínkou), nic jiného. Každý zobecněný koncept se rozmnoží do x tvarů / forem. Stejně tak tvrdím, že LISP je de facto hodně zobecněný koncept.

A píšu to proto, že jsem reagovat na to, že v původním vlákně bylo cosi o tom, že preprocesor by měl být totéž co jazyk, a že LISP je v tomto lepší.

Nabídl jsme úvahu, že LISP je zbytnělý a zabstraktněný princip maker dotáhnutý do, neboli doplněný o součásti programovacího jazyka.

C/C++ je programovací jazyk doplněný o preprocesor.

Tudíž proto se většině lidem lépe programuje v klasických jazycích, a proto je LISP mainstreamem odmítán. A tak kde je potřeba hodně volně makrovat (tedy dělat akce blízké preprocesoru), či skriptovat je zase LISP lepší.

[JS]

Zase, to co rikate je nesmysl. Protoze to same muzete tvrdit o libovolnem programovacim jazyce, ze se akorat jedna o urcitou "omacku" okolo assembleru nebo neceho takoveho. Ale tak to neni. Ta omacka je totiz to podstatne (a v pripade Common Lispu tvori, jak uz jsem rikal, nejakych 98%).

Ta omacka je to podstatne proto, protoze to jsou prave nove abstrakce, ktere vam umoznuji uvazovat na programovanim jinak. Je sice pravda, ze podminky a smycky jsou implementovany jako goto, ale vy nad tim pri tom programovani tak neuvazujete. Stejne tak, jak uz jsem rekl, nemusite znat makra, abyste mohl pouzit Common Lisp. Na druhou stranu, jejich znalost vam muze usetrit hodne prace tam, kde vam to normalni jazyky nedovoli (stejne jako vam goto muze usetrit praci v jazyce, ktery ho umoznuje).

Programovaci jazyky jsou v podstate uzivatelske rozhrani pro programatory. Proto je tezke, podobne jako u GUI, navrhnout je dobre a kazdy ma jiny nazor na to, co je spravne. A proto ta "omacka" hraje roli. Stejne ve vyberu jazyka hraje roli existence knihoven, ktere muzete take jen nazvat jakousi "omackou".

[default]

No, je to trochu off-topic, ale má to něco společnýho s Javou a XML.

Dělal jsem na dvou komponentách. Obě jsou dost svázaný s databází, takže součástí jejich konfigurace jsou i netriviální SQL dotazy. Konfiguraci jsem chtěl mít v Javím stylu. To aby se supporťáci nemuseli učit nic novýho, specifickýho pro mé komponenty.

Při vývoji té první jsem podlehnul No-XML náboženství a neskutečně si zandal. Ano, nezvolil jsem XML, ale Properties. Posuďte sami:

myWonderfulQuery=SELECT \
        something, \
        something_else \
    FROM \
        (SELECT \
            …

Při vývoji té druhé jsem se poučil a použil XML:

…
<entry key="myWonderfulQuery">
    SELECT
        something,
        something_else,
    FROM
        (SELECT
            …
</entry>
…

Ano. Rozdíl je v těch backslashích. Asi každému je jasné, jaké peklo se musí podstoupit při úpravě dotazu, který je uložen v Properties. Načítání těch konfiguráků je v obou případech na dva řádky.

Takže tak. Existují případy, kdy je XML opravdu o malinko lepší.

[Miloslav Ponkrác]

Buď jak buď jste podlehnul náboženství a spravedlivě jste byl potrestán.

Správně se má každý nástroj používat tam, kde se využijí jeho výhody a nebudou vadit jeho nevýhody.

Jakékoli náboženství, ať už XML, nebo NO-XML je jen a pouze náboženství, a ať už podlehnete jednomu, nebo druhému, neříká to nic o XML, pouze o extrémním fanatismu zleva, nebo extrémním fanatismu zprava.

Jinak se omlouvám, nepíši to ani tak o Vás, jste velmi rozumný člověk, spíše generalizuji na téma tohoto článku.

Je to stejné, jako mnoho desítek procent tohoto národa si myslí, že v politice levému fanatismu se ubrání pravým fanatismem, ale v extrém číhá peklo na obou koncích. Je vůbec úžasné sledovat, jak média si s lidmi pohrávají jak se psy a ženou je jednou na jeden konec extrému a když to špatně dopadne nabídnou jim druhý konec extrému. To lze určitě dělat dosti dlouho.

[kralyk z abclinuxu]

Asi by to chtělo v této diskusi zmínit Comparison of data serialization formats.
Updatuju to do blogu...

[xkucf03]

Když člověk chce schéma a standardní API, tak nemá moc na výběr. Zrovna ta možnost definice schématu mi přijde jako jedna z nejdůležitějších vlastností.

[kralyk z abclinuxu]

Nač?

[xkucf03]

Např. teď píšu v DocBooku, validace se hodí, abych se pak nemusel divit, proč to padá nebo z toho lezou divné výsledky – validace je jedno kliknutí a ani ne půl vteřiny času, to za to stojí. Taky když píšu, tak mi editor napovídá použitelné značky podle schématu – nemusím si všechno pamatovat.

[kralyk z abclinuxu]

Aha. Tak to jo. Já myslel, že mi to pomůže nějak při implementaci programu, který s daným XML fajlem pracuje. Když jsem nabouchával do C++ hardcoded xml značky, na které program reaguje, svrběly mě ruce. Ale ono by to tak jako tak nakonec bylo hardcoded, přinejlepším oklikou, takže co...

[xkucf03]

Kontrolu proti schématu by za tebe udělala knihovna a pak by ses mohl spolehnout, že jsou data OK. Smysl to má hlavně tehdy, když má spolupracovat víc lidí – typicky když jde o nějaký formát nebo protokol, pak funguje schéma jako část dokumentace, nebo se někdy do něj podaří nacpat všechno – ostatní si pak snadno zkontrolují, jestli to implementovali dobře – nemusí číst desítky stránek a kontrolovat to ručně a při každé změně znova.

[kralyk z abclinuxu]

Jj s tím souhlasím, pro dokumentaci a přehlednost to smysl jistě má. Nicméně ve chvíli, kdy chci načíst ty informace do paměti a pracovat s nimi, stejně musím mít nějaký harcoded hodnoty, identifikátory. Leda bych celý xml nějak transformoval na již vytvořené objeky (structy, c++ třídy apod.) a ty nahrál do paměti - ale to mi přijde jako šílenost...

[pavlix]

Asi připomenu tobě zřejmé, ale snad to někomu pomůže.

Na tohle je přesně stavěný JSON, aby z něj člověk vyrobil přímo objekty programu, ale půjde to asi jen v dynamických jazycích.

[Josef Kufner]

Jen malé doplnění: Načtení dat uložených v JSON se v Javascriptu dělá takto:

obj = eval(json_string);

Tolik k "šílenému".

[default]

A jak zajistíš, že ten json_string obsahuje opravdu jen data a nikoli kód?

[pozortucnak]

http://zdrojak.root.cz/clanky/nacitame-a-zpracovavame-json/

[default]

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
     text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text + ')');

Muhehe.

[Ladicek]

V moderním javascriptovém prostředí lze použít JSON.parse(text) pro deserializaci a JSON.stringify(obj) pro serializaci. Viz též http://www.json.org/js.html.

[xkucf03]

jj, něco jako:

XMLDecoder.readObject();
XMLEncoder.writeObject();

akorát ten XMLDecoder a XMLEncoder máme už od dob Javy 1.4

[Ladicek]

Tak jo. Podívej se, jak vypadá to XML, co tyhle metody vygenerují, pak si po sobě přečti svoje výroky v téhle diskusi o tom, jak by se XML mělo a nemělo používat, a pak přijď. Třeba s XStreamem, ten se dá považovat za aspoň trochu rozumné řešení.

[xkucf03]

Já vím, jak ty soubory vypadají Optimální to není, ale pokud ten postup vypadá takhle:

objekt → serializovat → odeslat → přijmout → deserializovat → objekt

tak je celkem jedno, co je uvnitř. V obou případech je to formát odvozený od nějaké konkrétní platformy (v jednom případě Java, v druhém JavaScript), udělat k tomu načítací a ukládací knihovny pro jiné jazyky jde v obou případech. JSON je méně „ukecaný“ a přehlednější, lepší pro ruční psaní – ale pokud ho ručně nepíšeš (místo toho serializuješ objekty), tak je to celkem jedno. Když chceš lepší (přizpůsobitelný) výstup, tak stejně nepoužiješ obyčejnou serializaci, ale mapování třeba pomocí JAXB.

[Ladicek]

pokud ten postup vypadá takhle: objekt → serializovat → odeslat → přijmout → deserializovat → objekt

tak použiju Protocol Buffers nebo spíš Thrift

[kralyk z abclinuxu]

Jen malé doplnění: Načtení dat uložených v JSON se v Javascriptu dělá takto:

obj = eval(json_string);

Tolik k "šílenému".

No to je možné, že v javascrpitu se to tak dělá. Já to psal z pohledu člověka, co píše C++, a tam by to imho šílené bylo dost...

[default]

Ono je to šílené i v tom JavaScriptu.

[Josef Kufner]

Vtip je v tom, že při použití AJAXu prostě víš, že těm datům můžeš věřit, protože jsou z tvého serveru. Takže s tím není sebemenší problém.

V C++ nic takového nevíš, takže tam by to příliš rozumné nebylo.

[default]

Vtip je v tom, že při použití AJAXu prostě víš, že těm datům můžeš věřit, protože jsou z tvého serveru.

Opravdu?

[pavlix]

Jen malé doplnění: Načtení dat uložených v JSON se v Javascriptu dělá takto:

obj = eval(json_string);

Tolik k "šílenému".

Nejsem Javascriptových programátor, ale podle toho, co jsem četl o JSONu, tak to není pravda. Podle mých informací v Javascriptu existuje podpora pro JSON (nevím které verze kterých implementací to podporují).

[Ladicek]

Je to pravda a musí to jít už proto, že JSON je podmnožina JavaScriptu. Kvůli syntaktické nejednoznačnosti se sice používá eval('(' + json + ')'), ale to je detail. Nativní serializace a deserializace existuje, ale ještě zdaleka ne všude.

[pavlix]

Je to pravda

I podle ostatních příspěvků není.

a musí to jít už proto

Samozřejmě, že to musí jít, ale to ještě neznamená, že je to správný nebo dokonce rozumný způsob. JSON je samostatný datový formát, byť je z hlediska syntaxe podmnožinou programovacího jazyka.

Způsob, který uvádíš je nebezpečný a špatný. Pokud je jenom trochu zbytí, nebo není zvláštní důvod, proč ho použít, tak bych se mu vyhnul.

Nativní serializace a deserializace existuje, ale ještě zdaleka ne všude.

V případě absence čtecí rutiny to do jisté míry chápu, ale ani tak to nepovažuju za ideální.

[Ladicek]

Zkus se podívat na implementaci JSON.parse v JavaScriptu, odkazoval ji tu tuším default – hádej, co tam najdeš

[pavlix]

Zkus se podívat na implementaci JSON.parse v JavaScriptu

Vidíš, já si dodnes myslel, že Javascript je programovací jazyk. Takže... na kterou z mnoha implementací se mám podívat? Nebo nechceš mi rovnou udělat statistiku kolik jich to řeší jakým způsobem?

[Ladicek]

Mám samozřejmě na mysli json2.js, což je de facto standard ve všech JavaScriptových prostředích, kde není JSON.parse/stringify k disposici nativně a kde tyhle funkce chtějí. Po kontrole, zda je text skutečně platný JSON, což se dělá těmi pár regexpy, které tady kdosi označil za šílené, se volá… chvilka napětí… j = eval('(' + text + ')'); Nedává smysl implementovat v JavaScriptu parser JSONu, i když by to samozřejmě šlo.

[pavlix]

kde není JSON.parse/stringify k disposici nativně

Tohle je přesně ta varianta, o které jsem psal jako o výjimce, když není nativní implementace.

Po kontrole

Ale ta kontrola je tam velmi důležitá. Kdyby se dělal jenom eval, je to dost průser.

[Ladicek]

Ten průser je poměrně běžně k vidění Ostatně na tomtéž principu funguje JSONP.

[pavlix]

Netvrdil jsem, že není. Spousta průserů je běžně k vidění a používání některých se i uzákoňuje.

[Ladicek]

Tak potom asi nevím, co jsi tvrdil, když jsi na JSON se v JavaScriptu parsuje evalem reagoval, že to není pravda Ale dobře, řekněme, že mezi dělá se a správně by se mělo dělat je drobný rozdíl, který může v komunikačním šumu zaniknout

K JSONP: nejsem si jistý, jestli tě chápu, ale celý ten chytrý hack spočívá v tom, že klient dynamicky vytvoří element script, čímž zajistí vykonání načteného kódu v JavaScriptu, a server pošle JSONová data, která by normálně poslal, akorát obalená závorkami a na začátku ještě s textem, který klient zadá. Akorát že ošklivý server může poslat jakýkoli kód v JavaScriptu…

[pavlix]

Ale dobře, řekněme, že mezi dělá se a správně by se mělo dělat je drobný rozdíl

Když napíšeš, že v Javascriptu se to dělá pomocí eval, nevyzní to jako "jednou z obvyklých chyb programátora je parsovat JSON funkcí eval". Ten drobný rozdíl tu tedy je, ale to, co jsi napsal v podstatě může znamenat obojí a vybral jsem si interpretaci, kterou jsi asi namysli neměl.

K JSONP

Ten jsem neznal. Moje chyba, je to přesně jak píšeš.

[pavlix]

Hodil jsem do googlu JSONP a nikde se nepíše nic o tom, že by se to mělo interpretovat nekriticky jako Javascript.

[JS]

Aaa, typova bezpecnost, oblibene tema. Me to prijde jako trochu plavani proti proudu, protoze to co je opravdu zajimave se typove zabezpecit neda (mozna to dokonce souvisi s nerozhodnutelnosti, co ja vim). Ale proti gustu...

[Radek Miček]

to co je opravdu zajimave se typove zabezpecit neda.

Pokud máte důkaz, že program má určité vlastnosti, není důvod, proč by ten důkaz neměl jít zapsat v typovém systému (vhodného jazyka).

[JS]

No takhle, ja treba nemam nic proti tomu, jak je to udelano v Haskellu (i kdyz ho vlastne moc neznam). Tam totiz to odvozovani z vetsi casti dela ten jazyk za vas. Ale vynucovat to od programatora, a jenom pro specialni pripady, jako to delaji typove systemy treba v Jave? Navic mi prijde, ze misto toho, mit staticky typovy system je lepsi proste pouzit assert. Tim rikate, jaka presne ma byt ta podminka, a muzete na to vyuzit ten stejny jazyk jako v kterem to pisete.

Nejvic by se mi asi libilo, kdyby ty asserty doplnoval pocitac na zaklade pozorovani behu programu. A programator by je pak jen schvalil. Chci vytvorit takovy jazyk, ale zatim jsem se k tomu nedostal.

Taky mi pripada, ze slovo "typ" ma dva vyznamy. V jednom vyznamu to oznacuje operace, ktere lze s danym objektem delat. V druhem vyznamu to je konkretni vnitrni usporadani nebo jina podminka na ten objekt.

[Radek Miček]

No takhle, ja treba nemam nic proti tomu, jak je to udelano v Haskellu (i kdyz ho vlastne moc neznam). Tam totiz to odvozovani z vetsi casti dela ten jazyk za vas.

Problém je v tom, že typová inference je pro složitější typové systémy nerozhodnutelná (čímž samozřejmě nechci ospravedlňovat jazyky, které ji nepoužívají tam, kde by to šlo -- třeba Vámi zmíněná Java).

Nejvic by se mi asi libilo, kdyby ty asserty doplnoval pocitac na zaklade pozorovani behu programu. A programator by je pak jen schvalil. Chci vytvorit takovy jazyk, ale zatim jsem se k tomu nedostal.

To je zajímavá myšlenka, ale problém bude asi s tím, jak zařídit, aby počítač zobecnil konkrétní pozorování a vytvořil z nich "rozumné" asserty.

[Miloslav Ponkrác]

„Navic mi prijde, ze misto toho, mit staticky typovy system je lepsi proste pouzit assert.“

Statický typový systém řeší trochu více, než assert. Třeba optimalizuje uložení dat, není nutné k hodnotě přidávat ještě typ jako u dynamických typových systémů.

“Tim rikate, jaka presne ma byt ta podminka, a muzete na to vyuzit ten stejny jazyk jako v kterem to pisete.“

Mně by zajímalo, jak byste se chtěl bez typů obejít? Vždyť už tím, že napíšete literál jste automaticky dal typ.

„Taky mi pripada, ze slovo "typ" ma dva vyznamy. V jednom vyznamu to oznacuje operace, ktere lze s danym objektem delat. V druhem vyznamu to je konkretni vnitrni usporadani nebo jina podminka na ten objekt.“

Přijdete si další význam: typ jako způsob uložení dat a vnitřní reprezentace dat. Typ jako způsob implementace operací.

Protože je Vám houby platné, že typ určuje operace, které jde s objektem dělat, když s tisícem různých typů uděláte určitou stejnou operaci, ale u každého typu může proběhnout tato operace jinak (mít jinou implementaci).

S podmínkami, či assertu se bez typového systému nehnete, typ je daleko více, než popíšete podmínkami. A to nemluvím, že Vámi navržený systém bude pomalý jako prase, a to natolik, že to bude vadit i na dnešním rychlém hw.

[JS]

Ano, samozrejme musite urcit, jakym zpusobem budou data ulozena; ja ted mluvim o typech v kontextu jakehosi overeni zameru programatora (protoze tak jsme se k tomu dostali od XML). Nicmene v praxi se ukazuje, ze to bez statickych typu neni az takovy problem, a lze se bez toho vetsinou obejit pomoci typove inference nebo JIT kompilatoru (a nebo toho, co jsem navrhoval ja).

Vase dalsi definice toho, co je typ je totez jako druhy vyznam, ktery myslim ja. V tom prvnim vyznamu je to uzitecne pro typovou bezpecnost, v tom druhem to musite nejak definovat (at uz implicitne a za behu) tak jako tak.

A nechapu, jak muzete o necem, co jeste neexistuje, seriozne tvrdit, ze to bude pomale.

[Miloslav Ponkrác]

A nechapu, jak muzete o necem, co jeste neexistuje, seriozne tvrdit, ze to bude pomale.

Po 25 letech zkušenosti s programováním si občas odvážím i něco tvrdit.

Celých 25 let pořád něco tvrdím o něčem co ještě neexistuje. Ono je jaksi praktičtější nejdříve program navrhnout předtím, než ho skutečně udělám. Pro elektronika je zase praktičtější navrhnout obvod předtm, než skutečně bude fyzicky existovat.

Dokonce i Ti z NASA (samozřejmě sebevědomí blbci) navrhnou a něco tvrdí o dráze rakety ještě v době kdy tam raketa nedoletěla.

---

Bez statických typů to samozřejmě jde a já Vám přeji hodně bádání a přemýšlení – je to dobrodružná práce. Sám jsem v myšlenkách vymýšlel leccos.

Nicméně hlavní účel, který typy mají (kromě vyšší efektivity staticky typovaných jazyků) plní statické typování další účel – a to další kontrolu programu.

Je obecně snahou vymýšlet programovací jazyky, ve kterých programátor upustí co nejvíce informací o svých záměrech a pokud možno způsobem, který ho neobtěžuje. Nějak tak je ze zkušeností známo, že při vývoji sw vzniká obrovské množství chyb a činnosti, jejichž účelem je předejít chybám, nebo je detekovat či odstranit tvoří podstatnou část vývoje.

Statické typy byly zavedeny ze dvou důvodů: a) efektivita běhu, b) zlepšit detekci chyb a donutit nevědomky programátora, aby se typovými deklaracemi a typovou štábní kulturou odstranila značná část chyb, která by v programech jinak byla.

Pokud nahradíte typy nějakou automatickou detekcí, pak samozřejmě zvýšíte dosti silně pravděpodobnost chyb v programu – což kromě neblahých důsledků na spolehlivost programu bude mít (v případě, že se bude takový program užívat někde, kde na tom záleží) za důsledek zdražení vývoje na dalších činnostech souvisejícíc s testy na chyby a odstranění chyb.

Typová inference zcela jistě leccos za programátora najde a leckdy je i užitečná. Ostatně neexistuje jazyk, kde by se nějak nepoužívala – C, C++, Pascal, Java, kam si dosadíte. Napíšete někam "ahoj" a kompilátor si jakousi typovou inferencí řekne: aháááá string. Když napíšete složitý výraz, kompilátor automaticky typovou inferencí zjišťuje typy ve výrazu a nenutí vás jej většinou uvádět.

Nicméně typy se uvádí dnes hlavně proto, že velmi pomáhají v detekci chyb a přitom programátora až tak nezatěžují. Tím velmi zlevňují vývoj sw a na takový program se dá pak i relativně více spolehnout. Proto se i do dynamických jazyků zavádějí typové kontroly a je silná tendence naopak typy do jazyků přidávat, než je ubírat.

[JS]

Trosku se mylite. Ja chci nahradit staticke typovani automatickou detekci, kterou pozdeji, bude-li na to takovy pozadavek, programator potvrdi nebo vyvrati.

[JS]

Ale abych se jeste vratil ke XML a schematum. Ja narazel napr. na to, ze (z moji slabe zkusenosti) jakekoli slozitejsi XML vyzaduje definovat cosi jako promenne. Tj. potrebujete aby byly konzistentne stejne hodnoty na ruznych mistech XML stromu. To pomoci schemat, pokud vim, neosefujete. Proto mi ta schemata pripadaji jako plavani proti proudu. Mnohem lepsi by proste bylo, kdyby byla knihovna podminek, ktere ma ta datova struktura splnovat (a kod te knihovny by mohl byt Turingovsky uplny, a zahrnout tak rovnou vsechna mozna pravidla konzistence tech dat).

[Radek Miček]

To je naprostá pravda. Většina jazyků pro schémata má sílu rozpoznávat pouze regulární jazyky, takže si často tu validaci musíte udělat stejně v aplikaci.

[xkucf03]

Mnohem lepsi by proste bylo, kdyby byla knihovna podminek, ktere ma ta datova struktura splnovat

Tímhle stylem je postavený Schematron – XML Schema není jediný způsob jak definovat „schéma“ v XML.

[JS]

No ale zase je to pres ruku. Muzete se v tom Schematronu odvolavat na jine casti stromu? Muzete si vytvorit docasnou datovou strukturu, kam si neco v prubehu testovani ulozit? Nakonec vytvorite novy Turingovsky uplny jazyk se silenou notaci, a dojdete presne tam, kde vas jiz ocekavam. Aneb, jak pravi klasik, kazdy jazyk, pokud to jiz neni Lisp, ma tendenci Lisp znovu objevit.

[xkucf03]

Vzhledem k tomu, že i pro Lisp existují XML knihovny, tak by bylo klidně možné vedle DTD, XML Schema, RelaxNG a Schematronu vytvořit ještě jeden jazyk k popisu typu XML dokumentu resp. schématu, tentokrát ale postavený nad Lispem Ono takové DTD nebo kompaktní Relax NG taky nejsou samy o sobě XML, přestože se k validaci XML používají (a k definici schématu). Pak by se snad dosáhlo dokonalosti a nebylo by už potřeba vymýšlet další jazyk pro popis schématu

[JS]

Jo, a nebo by take bylo mozne pouzit sexpy rovnou a na XML se vykaslat. Coz byla jaksi moje pointa.

[Miloslav Ponkrác]

Asi takto:

XML je prostě in, takže se používá asi 100× častěji, než je to užitečné.

Používání XML je ve větším měřítky značně unfriendly, pokud to nedělá program někde jako vnitřní práci.

Například jsem léta psal dokumentaci v DocBooku. Nakonec jsem po několika letech toho zanechal, ačkoli výsledky byly moc pěkné. Připadal jsem si jak při návratu k děrným štítkům. Už jen samotný překlad DocBook zdroje do výsledku znamenalo instalaci, kterou nabylo snadné rozchodit.

Neexistuje nic moc free dobrého na editaci obecného XML. Ani na DocBook (pokud něco znáte, sem s tím).

Kolem XML je naprskáno x standardů, začíná to XPath, XSLT, DOM, a nabaluje se to s mnoha dalšími do obrovské sněhové koule.

Nemá to pořádnou snahu o validaci, to co je v XML 1.0 donutilo nacházet náhrady.

Parsování je pomalé – je krásné srovnat kolik requestů za sekundu dokáže CORBA a kolik SOAP.

XML jsou velmi dobrou věcí pro některé případy, špičkovou.

Ale základní problém je: XML je náboženství a bují kolem toho náboženský fanatismus s tvrzením toto je jediný pravý Bůh. To je celou příčinou, proč XML nemá mnoho lidí rádo.

Díky tomuto XML fanatismu se XML začalo šířit na míst,ě kde je vrcholně nevhodné ho používat.

[xkucf03]

Co takhle Serna XML Editor? (není to nic sprostého , open source verze je pod GPL.

[kralyk z abclinuxu]

To napsal amigapower, ne?

[Miloslav Ponkrác]

Už ho mám stažený díky! I když XML editor s názvem "ser na XML" – není to rasismus?

[kralyk z abclinuxu]

Určitě to je rasismus. Dneska je rasismus úplně všecho. A taky to je ještě terorismus, kinderporno a poškozování životního prostředí.

[Michal Kubeček]

A zaručeně za to může Paroubek. :-)

[Miloslav Ponkrác]

Pokud tohle naprogramoval Paroubek, tak je to machr.

[Miloslav Ponkrác]

Já bych ještě dodal, že jste zapomněl na neonacisty, na oběti domácího násilí (používání obhroublých slov v názvu programu je vyjádřením skryté agrese, která by se měla řešit a s dotyčným pojmenovatelem zatočit, pokud to dokonce nemá ještě jiný úchylný podtext).

Dále určitě program porušuje nějaké patenty, či jinak vyjadřuje neúctu k duševnímu vlastnictví.

Ještě je třeba prošetřit, zda název je genderově neutrální.

[xkucf03]

K tomu náboženství: mně spíš jako náboženství přijde odmítání XML u některých lidí, případně odmítání Javy. Ostatní tyhle technologie prostě spokojeně používají nebo je považují za nezajímavé a je jim to jedno. Ale část lidí kolem toho musí pořád nadávat. Proč?

[JS]

Protoze se to naduziva i na veci, kde se to nehodi (XML). Java se mi nelibi proto, ze jsou jeji tvurci sebestredni idioti, kteri az po letech dochazeji k zaveru, ze tam ve skutecnosti potrebuji nektere veci, ktere ze zacatku povazovali z ideologickych duvodu za nesmysl (drive enum, pozdeji autoboxing a JNI, nejnoveji uzavery..).

[Miloslav Ponkrác]

Průkopníkem k nadužíváním XML je Java.

Nicméně XML je nadužíváno.

A odmítání Javy? To můžete říci o každém jazyce! Mně jako náboženství přijde fanatické odmítání C++ a ono se skutečně děje. Pár lidí tu bolí fanatické odmítání funkcionálních jazyků a ono se skutečně děje.

U Javy se situace komplikuje nosánkem nahoru u značné části Javistů často kombinovaná s velmi malými znalostmi. Ostatně sám Sun často Javu šířil dosti nenávistně – otevřeně se vysmíval a pomlouval C++, které mělo být Javou zničeno. Následně se posmíval Microsoftu, kdy Windows mělo být zničeno JavaOS. Také se vysmíval celému PC segmentu, který měl být zničen konceptem NetPC. Což vyvolalo značnou nelibost na mnoha stranách.

Mimochodem, když to řeknu upřímně, Java se dodnes nenávistně naváží do všeho. Koukněte se třeba na wikipedii. Třeba Javisté dosti nevybíravě kritizují hesla u řady programovacích jazyků tím, jak je ten jazyk blbej, přičemž podstatou kritiky je „je to jiné, než Java“. Například u článku C++ najdete poměrně rozsáhlou část „Criticism C++“ a „Comparing C++ a Java“ – není těžké uhodnout, kteří zastánci kterého jazyka to mají na svědomí a nemohou snést, že kromě Javy existuje také jiný jazyk.

Nenávistnost Javistů potvrzuje tkaé to, že nic takového v článku o Javě nenajdete.

Na české wikipedie jsem poměrně razantně v hesle o PHP smazal mnoho žvástů jednoho zastánce Javy s mnoha poznámkami, že spadl z višně a ať to přestane pít a uvědomí si, k čřemu je Java a k čemu PHP.

Za nenávist vůči Javě si mohou Javisté velmi sami. Chovají se jak debilové – omlouvám se, ale slušněji to říci nelze.

[kralyk z abclinuxu]

No já nevim, příde mi, že nadávání na XML je podobně módní jako XML samotné...

[Leoš Literák]

První věta není pravdivá, já mám XML obecně rád.

[kralyk z abclinuxu]

To "všichni" je tzv. slangový kvantifikátor, jehož přesný význam je poněkud mlhavý

[Miloslav Ponkrác]

Jakmile někdo použije kvantifikátor „všichni“ pro skupinu lidí, kde ani zdale nemusí být většina, pak se nepochybně jedná o výrok ženy.

Je to typické ženské vyjadřování.

[kralyk z abclinuxu]

Ale houby. Je to typické lidské vyjadřování...

[pavlix]

Myslíš slang, kde "všichni" znamená to samé, co "skoro nikdo"? To je mi pěkné lidské vyjadřování.

[kralyk z abclinuxu]

Co znamená to "všichni" je otázkou - nikdo z nás afaik průzkum obliby XML neprovedl. (Nejen) o tom je tento blogpost. No a krom toho já se nebudu furt vyjadřovat se strojovou přesností (pokud to zrovna není opravdu potřeba)

[pavlix]

Autor blogpostu se dopustil bulvárního nadpisu, o nějaké minoritě, co cítí nenávist vůči nějakému formátu zápisu dat.

Nedovedu si představit, že by "všichni" si vytvořili ke XML tak silný vztah, aby se dal označovat nenávistí.

[AHAHA]

OMG, to je zas diskuse :D

[Rastafan]

Ja vidim rude pri zaslechnuti XLM z duvodu Ant, Tomcatu, Struts a javovych udelatek pro perzistenci a milionu dalsich javovych veci. Nebyt nocni mury XML tak by se treba i ta java dala k napsni nejakeho webu pouzit, kdo vi.

[minix]

jako aktualne XML postizeny nekolik poznamek. V projektu dodava budouci uzivatel data ve formatu .doc. Data jsou strukturovana (tak to nazyvaji bezni uzivatele), coz znamena, ze atrubuty v textu (nadpisy, linky, bold ..) jsou vyznaceny stejnym zpusobem a kupodivu se toho vsuchni autori textu drzeli.

Tyto texty musi byt nyni prevedeny do html a zobrazeny na webu. Rozhodli jsme se jit cestou automatickeho prevodu .doc-dokumentu (zhruba 20 tisic) do ms-xml formatu. To ma tu vyhodu, ze od ms-office 2003 mohou uzivatele i nadale editovat sve textty v ms-office , jen musi pouzivat tem m$ XML format.

Vysledkem automatickeho prevodu (na to existuji pod windows programy - dost drahe) jsou _silene_ xml dokumenty s rozsekanymi texty. (napr. je rozdil, jak mel autor .doc-puvodniho-textu nastavenou spravu gramatiky). Pro jejich parsovani jsme pouzili vlastni parser (perl - co jineho , ze), ktery ty zvracenosti zanalyzuje a vytvori odpovidajici html-dokumenty.

Nyni by se mely jeste automaticky vytvorit z tech xml dokumentu pdf soubory. Blahove jsme se domnival, ze se na linuxu spusti nejaky program, ktery to provede automaticky. Nic se nanaslo. Za jakykoli tip budu jen rad.

[Darken]

Co tahle potvora ?

http://code.google.com/p/wkhtmltopdf/

[pozortucnak]

http://aur.archlinux.org/packages.php?ID=14176
htmldoc
wkhtmltopdf

[Michal Kubeček]

Sázení z XML obvykle řeším tak, že si napíšu XSL transformaci, která mi XML převede na TeX, a dál podle potřeby TeX+dvips (dvilj*) nebo pdfTeX.

[minix]

nejdrive kolegum Darken a pozortucnak ( ) dekuji za tipy, jiz jsem si nakouknul stranky a budu to zkouset.

k Vasemu prispevku bych rad neco vic:

- napisu si XSL transformaci

ano, to je patrne ta spravna cesta, jak jsem vycetl z te volne pristupne knizky o XML od pana Koska (kterou jsem take ze zoufalstvi nahledl pri hledani moznych cest). Ona je to takova kratka veta a kdybychom to umeli, tak to asi ve firme i udelame. Ale my nechceme delat vsechno, my si u nas myslime, ze delba prace je ta spravna odpoved pri tvorbe software a proto jsme se poohledli, jestli by to pro nas nekdo nenapsal. Prekvapeni bylo, ze odpovidajici odbornici minili, ze zadny problem, udela se sezeni, nastartuje se projekt, zanalyzuji se pozadavky, .. blabla ... Cena odpovidajici.

Muzete to potvrdit a nebo se nekdo snazil vyuzit nasi neznalost.?

- Tex a ostatni

take jsme na to mysleli a pri otukavani te varianty jsem narazili na problematiku unicodu v Texu. Existuji dodatkove pakety a trochu jine pakety a k nim rada dokumentu, jak to naraficit, aby ten unicode (je potreba windows arial-sada) fungoval. To nas take znepokojilo.

Pod carou bych rekl, my jsme si mysleli, ze s XML prijde nejaky takovy format, kde bude mozno bez nejakych kurzu a skoleni ztreba i za pomoci _dostupnych_ nastroju provadet transformace do jinych formatu. To ale ne ten pripad.

[Miloslav Ponkrác]

Ano, to je právě to co jsem psal, že když jsem dělal s XML, připadám si jako v době děrných štítků.

Samotný XML je jednoduchý, celý ekosystém kolem něj je pak obludný.

Ale celé XML je strašně neforemné, drahé, nepřátelské, problematické a nedomyšlené. Nic tam nejde pořádně, snad jen to psaní XML jako konfiguráků (v plain text editoru), nebo práce s XML přes nějakou DOM/SAX/cokoli knihovnu.

Kdyby to XML bylo nějak dotaženo do konce, ale ono je to opravdu jak z doby děrných štítků.

Jenže takové jsou skoro všechny standardy W3C, které nikdy neumělo nic udělat pořádně a nic dotáhnout do konce, ani napsat pořádný standard.

Navíc mám pocit, že W3C zbytečně dubluje pomocí XSLT již existující prostředky, navíc ani to XSLT není až tak všemocné, nebo přímočaré.

To XML se neumí ani samo pořádně zkontrolovat na správnost, ty prostředky, které dává norma jsou ubohé a nedostatečné. Navíc nechápu, proč třeba DTD není standardní XML, proč tahle nezkonzistence.

S XML se velmi špatně pracuje, mám pocit, že je to takový nový COBOL.

[Michal Kubeček]

Příloha:

• xml-tex.tar.gz (12569 bytů)

Zkuste se podívat na příklad v příloze. Podotýkám, že když jsem to dělal, jednoznačnou prioritou bylo co nejrychleji a s co nejmenší námahou vyrobit HTML a TeX z těch dvou XML dokumentů, takže elegance a univerzalita řešení byly zcela podružné. Ale jako příklad, co jsem měl na mysli, by to posloužit mohlo.

[pozortucnak]

add docbook...

toto vypadá prinejmenším zajímavě:

http://tbookdtd.sourceforge.net/

http://tbookdtd.sourceforge.net/db-diss.html

[Miloslav Ponkrác]

DocBook je zajímavý. Nicméně na hovno.

Rozchodit a nainstalovat vše kolem docbooku je poměrně složité.

Editovat XML pomocí plain text editoru je nic moc, práce pro vraha.

Nějaký editor, který by přímo podporoval DocBook? Zapomeňte!

Když už DocBook máte, tak potřebujete styly, kterým byste to převedl do čeho chcete. Chcete v nich něco změnit, vystudujte atomovou fyziku, potřebujete minimálně doktorát.

Je to user unfriendly jako svině. Já jsme v tom psal několik let, a pak jsem toho nechal. To co to ušetřilo si to nabralo ve své nedodělanosti a práce jak na mainframu. Už mi k tomu chyběla jen feritová paměť a děrnopásková jednotka.

[Petr Tomášek]

add docbook...

Co chceš kam přidávat?

[Michal Kubeček]

Očividně ten DocBook, jen nevíme kam. :-)

[pozortucnak]

Jen mi to přijde jako zajímavá alternativa...

Máte nekdo zkušenosti s Heirloom troff?

[Michal Kubeček]

Kolega narážel na "ad" vs. "add". První znamená latinsky "k", druhé anglicky "přidat".

[kralyk z abclinuxu]

Přidána anketa.

[Miloslav Ponkrác]

V anketě mi chybí, že když mi někdo zaplatí pivo a guláš, tak budu hlasovat pro XML, jinak proti.

[pavlix]

To už by od nás měl minimálně dva hlasy :).

[pavlix]

Anketa se bohužel ptá na oblibu technologie XML obecně... přitom diskuze byla převážně o použití XML pro záznam strukturovaných dat (rozdíl oproti značkování dokumentů).

Nakonec ale píšu, že XML spíš nemusím, protože si myslím, že šlo udělat kousek líp a kousek jednodušeji, pokud by se tolik nestavělo na SGML základu.

Na druhou stranu v mnoha případech doporučím XML použít, protože je to jediný značkovací jazyk i jediný (byť ne moc dobrý) jazyk pro strukturovaná data, na němž se dokážou firmy do jisté míry shodnout. Prostě praktické důvody, rozhodování podle světa jaký je, ne podle světa, jaký by měl být.

[pozortucnak]

  A tohle jste už viděly? http://ogdl.sourceforge.net/

[pavlix]

To neni úplně špatný.

[Amarok]

Ty jsi ženská, že mu na to odpovídáš? :D