Názory k článku Nové standardy pro JSON
-
- (neregistrovaný)
Díky za info. Jinak pro pohodlnou práci s JSON daty v JS můžu doporučit knihovnu jLinq(podobné knihovny se dají dohledat i pro další jazyky).
-
XMen (neregistrovaný)
Co mi na JSON formate najviac vadi je prave absencia schemy. Podla mna je to najdolezitejsia feature bez ktorej sa XMLka nemozme zbavit a vyuzivat iba ciste JSON. Nechapem ako moze niekomu vadit definovanie takej schemy, ved pomocou nej sa da krasne definovat struktura a tym napr. vyuzivanie JSON aj vo webovych sluzbach namiesto klasickeho XML v SOAP.
-
Já myslím, že i na JSON Schema nakonec dojde, spíš jde o to, v jaké formě. Existuje tenhle aktivní Internet draft: http://tools.ietf.org/html/draft-zyp-json-schema-04. Já sám jsem napsal jiný draft, http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-01, který umožňuje modelovat JSON data pomocí jazyka YANG. Je to sice maličko přes ruku, ale funguje to celkem dobře - implementoval jsem to i do programu pyang.
-
Palo (neregistrovaný)
Len taky simple napad co drzim v hlave nejaku chvilu len nebol cas na realizaciu. Co sa tyka Javy tak Apache umoznuje plugovat parser. Tam by sa dala velmi jednoducho urobit konverzia JSON -> DOM a potom zvysok co sa tyka validacie prenechat uz na standardne postupu ako mas pre XMLko.
-
Palo (neregistrovaný)
Nemyslel som kompletnu implementaciu. Staci pre Apache nasledovny jeden class prepisat pre JSON. Pozri na konci stranky sample pre CSV. To je vsetko. Zvysok bude fungovat ako pre XMLko.
http://xerces.apache.org/xerces2-j/xni-config.html -
XMen (neregistrovaný)
Myslite konverziu JSON do XML a potom naslednu validaciu cez XSD? Ano to sa samozrejme da ale podla mna je to zbytocny medzikrok. Navyse schema nieje urcena len na validaciu ale aj na popis dat.
Ja osobne by som bol rad, keby doslo k vytvoreniu novej verzie SOAP protokolu s vyuzitim JSON namiesto XML. -
Franta (neregistrovaný)
Ad "Myslite konverziu JSON do XML a potom naslednu validaciu cez XSD? Ano to sa samozrejme da ale podla mna je to zbytocny medzikrok."
Tohle je omyl vycházející z toho, že někteří lidé chápou XML pouze jako text s ostrými závorkami. XML je ale v první řadě objektový model - DOM a je z tohoto pohledu jedno, jestli máš data v nějakých hashmapách a polích nebo v DOMu - obojí je tím "mezikrokem" (který ovšem není zbytečný, bez něj to moc nejde - případně se dá použít SAX a za chodu ze vstupního proudu generovat rovnou objekty - tam už validaci nepotřebujeme, protože nevalidní objekty vzniknout nemůžou, resp. je validita je v nich zadrátovaná - na rozdíl od polí a map)
-
Jirka Kosek (neregistrovaný)
Mapování mezi JSON a XML jsou mraky -- doporučuji například pročíst sborníky XML Prague za poslední dva roky. Bohužel to mapování není úplně triviální, protože v něčem se jazyky dost liší -- například povolené znaky v identifikátorech.
Nicméně další verze "XML"-jazyků budou podporovat přímou práci s JSON, např.: http://www.w3.org/TR/xslt-30/#func-parse-json
-
Ahoj Jirko, pro data modelovaná YANGem se nám to mapuje velmi pěkně: http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-01. Na rozdíl od jiných konvertorů se zohledňují i datové typy, takže třeba číselný parametr je v JSON číslo.
-
XMen (neregistrovaný)
No mne skor ide o to, ze pre XML uz existuju jednoduche postupy ako ho validovat a to tym, ze si vytvorim vhodnu schemu, pomocou ktorej mozem validovat. Problem je, ze ako validovat napr. JSON. Ano da sa to prekonvertovat na XML (aj ked uznavam ze niekedy to moze byt problem) a to potom zvalidovat avsak pride mi to ako zbytocny medzikrok. Keby pre JSON existovala nejaka schema, mohol by som ju rovno napisat a pouzit bez konverzie. Samozrejme predpokladam, ze ta JSON schema by bola pouzitelna v hociktorom jazyku ci prostredi.
-
Franta (neregistrovaný)
A není lepší nevymýšlet kolo a použít hotovou technologii? Tzn. mít XSD (případně jiné schéma), které popisuje logickou strukturu dat s tím, že tato data můžu serializovat v různých formátech (ať už klasické XML nebo INI soubory, Java properties, JSON, YAML, Neon a milion dalších podobných formátů)
-
Filip JirsákStříbrný podporovatelNebylo by jednodušší vydat nový standard JML, což by bylo XML, akorát místo špičatých závorek by byly složené? Když jsou tedy ty špičaté závorky takový problém… Ta cesta, kdy se jako alternativa ke XML vymyslí tzv. jednoduchý JSON, a pak se k JSONu postupně přidává vše, co má XML, je podle mne poněkud hloupá.
-
Filip JirsákStříbrný podporovatel
Neexistence JSON Schema je přesně to, na co v poslední době nadávám. Nápověda v editoru, validace dat? Smůla, prostě si musím spustit příslušnou aplikaci a počkat, jestli ten soubor načte.
Mixed content je možnost, ne povinnost – pokud autor formátu nechce, nemusí jej používat.
-
Jasně, ale obecné nástroje - parsery, XSLT procesory - s ním počítat musí, a proto jsou složitější. Obdobným problémem jsou namespaces, které taky leckdo nemusí používat, ale všechno je kvůli nim stejně složitější. Aby ale nevznikl mylný dojem - já používám XML často a rád, ovšem taky chápu, že pro některé aplikace je to příliš velký kanón.
-
Franta (neregistrovaný)
+1
Někteří mají z ostrých závorek psychické trauma. Tohle by jim to možná pomohlo překonat, akorát by se nesměli dozvědět, jak ten nový standard vznikl a že vlastně vychází z jimi nenáviděného XML.
Já už to nějak neřeším, kdo chce znovuvynalézat kolo a zabíjet tím svůj čas, ať si tak klidně činí, jeho problém.
-
Filip JirsákStříbrný podporovatel
Bohužel pokud JSON používá nějaká knihovna nebo aplikace, kterou chci použít, nemám na výběr a musím se vrátit o 15 let zpět – žádné napovídání v editoru, minimální kontrola, žádné komentáře, žádné automatické transformace, žádné kombinování…
-
Franta (neregistrovaný)
Na to jsou vhodnější jiné formáty – klidně i binární, pokud to má být úsporné.
Ale i u propojení dvou systémů mají ta schémata/validace smysl - jednak je to formální specifikace rozhraní, podle které můžeš implementovat ten systém, a jednak si můžeš validovat příchozí zprávy.
JSON je takový nešťastný paskvil - není efektivní jako binární formáty, chybí infrastruktura kolem, jako má XML (validace, transformace, dotazovací jazyk...), blbě se píše ručně (chybí komentáře, schémata, editory, je otrava psát všude uvozovky - na to jsou vhodnější jiné "odlehčené" formáty).
-
Karel (neregistrovaný)
To je trochu posunuté vnímání. Přijde mi to jako kritizovat UDP za to, že nezaručuje dodání rámce, že neumí navázat spojení a že nekontroluje správnost formátu HTTP požadavku. JSON byl na samém počátku chápán jako velmi low level záležitost. JSON je právě ten "odlehčený" formát. Pokud vám přijde příliš odlehčený, tak si vytvořte svůj vlastní formát. Hlavně mu ale dejte jiné jméno, protože jinak se řítíme do situace, kdy "JSON compatible" bude ukrutný bordel. Budete nahrávat JSON soubor do staré aplikace a ona ho nepobere. Nebo vezmete starý JSON soubor a zkusíte ho dát do nové aplikace a ona vás vykope pro "neodpovídající semantiku".
-
Franta (neregistrovaný)
Přečti si prosím komentář, na který reaguji...
- Pokud má sloužit pro přenos dat z jednoho systému do druhého, tak je textový formát nevhodný - data se dají mnohem efektivněji zakódovat binárně.
- Když je to textový formát, tak to vypadá, jako by měl být psaný člověkem - tam ale zase chybí ty komentáře a je zbytečně složitý/neohrabaný. To už jsou vhodnější INI soubory, Java properties, YAML a další (i když taky mají svoje nevýhody oproti XML).
- Vraťme se ještě k propojení dvou systémů - rozhraní systému je potřeba jasně specifikovat, jinak to všechno plave na vodě a spojení nebude fungovat. Rozumné je si vybrat formát, který mi specifikaci rozhraní umožní/usnadní - ať už některý z binárních formátů nebo třeba to XML.Těžko říct, proč se na webu tak rozšířil - asi je to tím, že se do něj snadno serializovaly objekty z JavaScriptu a pro načtení stačilo zavolat eval(), než že by to vycházelo z vlastností toho jazyka. A pak už se šířil jako mor. Rozhodně mi to nepřijde jako racionální promyšlené rozhodnutí - spíš krátkozraké rozhodnutí (počáteční snadnost použití), omyl.
-
lol (neregistrovaný)
nechapem preco by format musel riesit svoju binarnost a uspornost. Od tohu su ine vrstvy, ktore to vedia zarucit. Je celkom bezne, ze na webe sa content type application/json pri prenose autmaticky gzipuje na urovni webserveru. Vysledkom je binarny stream.
Je to format, ktory ma do istej miery sluzit aj ludom - preto sa medzi developermi tesi oblube, pretoze letmy pohlad nanho im da jasnu viziu o strukture dat. Netreba na to ziaden tool.
Je lahko implementovatelny a nie je tak rigidny ako xml. Na to co bezny developer pracujuci s medziaplikacnou komunikaciou potrebuje, je JSON idealny.
Rozhodnutia robi biznis a ak tlaci na IT aby razilo cestu: hlavne rychlo a co najlacnejsie - tak sa nemozes cudovat, ze JSON je v kurze. Je doba prepajania systemov a minimalne na tej low urovni (myslene ako male a nie velmi vyznamne systemy), je JSON presne to co je potrebne.
-
Filip JirsákStříbrný podporovatel
Nesouhlasím s tím, že letmý pohled na JSON soubor dá člověku přehled o struktuře dat. Člověk tam sice uvidí nějaké hodnoty, ale nebude znát jejich význam (který by mohl být napsaný třeba v komentářích) a vůbec nebude tušit, jaké jsou jiné možnosti toho formátu.
Běžný vývojář pracující s komunikací mezi aplikacemi potřebuje vědět například to, zda odesílaný a přijímaný dokument odpovídá dohodnutému rozhraní. To s JSONem nezjistí nijak. Potřebuje si ručně vytvořit příklady dokumentů, které odpovídají rozhraní – k tomu má podporu na úrovni desítky let starých systémů. Měl by mít automatizované testy – s JSONem skončí u toho, že bude nanejvýš porovnávat pár předem daných ručně pracně vytvořených dokumentů.
-
Filip JirsákStříbrný podporovatel
Zapomněl jsem jednu věc k tomu letmému pohledu. Tady máte výchozí konfigurační soubor nejmenovaného internetového prohlížeče:
{ }Co jste z něj letmým pohledem zjistil o struktuře a o možnostech konfigurace?
-
Filip JirsákStříbrný podporovatel
Myslel jsem zjistit to nějakým automatizovaným a objektivním způsobem. Vzít JSON soubor, vedle si otevřít specifikaci popsanou volným textem v PDF samozřejmě může, ale je to zdlouhavé a náchylné k chybám.
-
Franta (neregistrovaný)
Ad "Rozhodnutia robi biznis a ak tlaci na IT aby razilo cestu: hlavne rychlo a co najlacnejsie"
A právě proto se v byznyse používá XML a věci jako WS/SOAP/WSDL/XSD, protože autoři jednotlivých systémů se potřebují nějak domluvit a jasně a formálně si specifikovat rozhraní, aby pak mohl každou část systému dělat jiný dodavatel a přesto to bylo kompatibilní.
-
Ivan (neregistrovaný)
Ono ani to XSD/WSDL neni uplne vsemocny, schvalne si sahnete do svedomi a vzpomente si jakou uroven validace za vas XSD dela.
Tyhle validacni nastroje casto slibuji urcitou miru bezpeci, kterou ale nejsou schopne zajistit.
BTW: traba takovy JaXB umi vygenerovat parser a objektovy model primo z XSD, ale v defaultu to nevaliduje ani pri cteni ani pri zapisu XML.
-
lol (neregistrovaný)
aj-tak to vacsinou v realite funguje tak, ze sa jeden system prisposobuje druhemu takze nie je ziadne autori sa dohodnu.
Navyse implementacia WS/SOAP/WSDL/XSD nie je tak jednoducha ako JSON, cize nie je ani tak lacna a teda pre biznis je to nepohodlne. Inak si neviem predstavit popularitu JSON - jedine ze by sa masovo ludia spravali iracionalne.
Osobne ak si mam vybrat data v xml alebo json, beriem json. Vacsina REST API ponuka jsontext verziu formatovanu pre cloveka. API byvaju zdokumentovane a clovek vie co moze a nemoze od toho ocakavat.
Ale kazdemu podla chuti - nikoho by som nenutil json pouzivat ak by nechcel a bolo by na vyber. -
Franta (neregistrovaný)
Ad „aj-tak to vacsinou v realite funguje tak, ze sa jeden system prisposobuje druhemu takze nie je ziadne autori sa dohodnu.“
Ano, jeden se obvykle přizpůsobuje druhému, protože ten je silnější/první a definuje rozhraní. Ale je rozdíl pokud se máš přizpůsobit něčemu, co je formálně a strojově čitelně specifikované a lze si z toho automaticky vygenerovat klientskou část a pak ji jen používat – a něco jiného je, když se máš přizpůsobovat metodou „pokus omyl“ něčemu, co je zdokumentované stylem: z tohoto URL si stáhněte nějaký JSON a koukněte se, co vám přišlo za data, a podle toho si to nějak naprogramujte. V lepším případě tam je dokumentace ve formě volného textu, která slovně popisuje, jaké struktury se tam dají čekat.
Ad „nie je tak jednoducha ako JSON, cize nie je ani tak lacna a teda pre biznis je to nepohodlne“
Jak se říká: nejsem tak bohatý, abych si mohl dovolit kupovat levné věci. U těch „jednoduchých“ řešení ti obvykle vzniká technologický dluh a nepěkně se ti to vrátí, nebo na to přijdeš brzy, že to jednoduše jen vypadá, ale je to šíleně pracné (zbouchat ručně nějaké klientské rozhraní, otestovat ho na všechno možné, ručně ho aktualizovat při změnách na straně poskytovatele služby…).
-
Franta (neregistrovaný)
P.S. Co se týče rozšířenosti JSONu na webu – vidím tu dva faktory, které mu hrají do karet:
1) Velcí hráči definující API se nemusí s ničím párat, prostě vyblejí nějaké dokumenty, je celkem jedno jak, ostatní budou držet hubu a krok a nějak se podle toho zařídí, protože jim nic jiného nezbývá - jsou rádi, že nemusejí vykrádat data z nějakého nevalidního HTML a mají aspoň ten JSON, i když je nezdokumentovaný.
2) Na webu se dělá spousta krátkozrakých rozhodnutím a obecně se pracuje stylem: rychle to nějak zbastlit, vyfakturovat zákazníkovi a hurá na nový projekt. Weby se málokdy inovují, prostě se starý web zahodí a napíše se to úplně celé znova. U serióznějších podnikových aplikací je ten životní cyklus mnohem dělší, jádro se udržuje klidně deset a více let, pořád se to rozvíjí místo aby se neustále zahazovalo a psalo znova – zahodí se maximálně zastaralé UI nebo se sem tam přepíše nějaká ta komponenta. -
Filip JirsákStříbrný podporovatel
To, že pro JSON neexistují / nepoužívají se standardy pro specifikaci a dokumentaci formátu je pro poskytovatele dat vlastně výhoda. Vezmou interní datové struktury, vysypou je ven ve formátu JSON a mají hotovo. Stejně jako binární formáty MS Office byly vlastně serializované interní datové struktury MS Wordu a spol. Kdyby to bylo XML, hned se někdo ozve, proč je to tak divně strukturované, proč k tomu není schéma, proč k tomu není dokumentace. To v případě použití JSONu nehrozí.
Akorát jsme se od otevřených zdokumentovaných formátů pro výměnu dat dostali zpět k serializaci interních datových struktur do proprietárních formátů, se kterými se pracuje způsobem „tady máte příklady souborů, k odhadu popisu formátu použijte reverzní inženýrství“. Jediný rozdíl je v tom, že už nám tolik nezáleží na velikosti souborů, takže ty proprietární formáty nejsou binární, ale používají JSON.
-
Radek Miček (neregistrovaný)
Hlavní výhodou JSONu, jak už bylo řečeno, je jednoduchost.
chybí infrastruktura kolem, jako má XML (validace, transformace, dotazovací jazyk...)
Vytvářet speciální jazyky jako XSLT nebo XQuery je IMO špatný nápad. Lepší je obohatit stávající programovací jazyky o jejich schopnosti.
-
Franta (neregistrovaný)
Takže DSL jsou nesmysl? To snad ne.
Co se týče obohacování existujících jazyků - tohle ti může velice snadno přerůst přes hlavu - ano, do jazyka se dá přilepit tuhle něco, támhle něco... všechno jsou to samo o sobě fajn věci, ale nakonec je z toho šíleně složité univerzální monstrum, které těžko někdo ovládne celé, lidi se v tom budou ztrácet, bude jim dělat problémy číst cizí kód až nakonec ten jazyk opustí a přejdou na nějaký jednodušší. IMHO je vhodnější mít víc specializovaných jazyků a vždy vědět, v jakém kontextu se pohybuji (např. teď píši deklarativní dotaz vs. teď píši proceduru).
-
Radek Miček (neregistrovaný)
Takže DSL jsou nesmysl?
Když bych mohl totéž napsat v jazyce, v němž programuji celou aplikaci a bylo to kratší, jednodušší a běželo to rychleji, tak je DSL nesmysl.
tohle ti může velice snadno přerůst přes hlavu - ano, do jazyka se dá přilepit tuhle něco, támhle něco... všechno jsou to samo o sobě fajn věci, ale nakonec je z toho šíleně složité univerzální monstrum, které těžko někdo ovládne celé, lidi se v tom budou ztrácet, bude jim dělat problémy číst cizí kód až nakonec ten jazyk opustí a přejdou na nějaký jednodušší.
Musí se to udělat rozumně. Ten jazyk by mohl být jednodušší než Java 8.
-
Ivan (neregistrovaný)
Dalsi moznosti je pouzit jazyk, ktery ma tak volnou syntaxi, ze dokaze JSON primo zchroupat :) (napr. Lisp anebo Perl) - Ok to dost prehnal, ale pravda je, ze jednoduchost JSON ocenite, kdyz pouzijete nejaky funkcionalni programovaci jazyk.
Ve staticky typovane imperativni Jave je vam JSON k nicemu. Javista spis oceni ze mu JAXB vygeneruje objektovy model primo z XSD.
-
Franta (neregistrovaný)
Ano, v dynamických jazycích se dá takhle hezky "prasit", ale to nemá nic společného s použitým formátem dat -- např. v PHP lze díky SimpleXML tímto způsobem pracovat s XML daty. (jestli je tento způsob práce vhodný nebo ne, to je zase na jinou debatu)
-
Ladislav Thon (neregistrovaný)
> Co se týče obohacování existujících jazyků - tohle ti může velice snadno přerůst přes hlavu - ano, do jazyka se dá přilepit tuhle něco, támhle něco... všechno jsou to samo o sobě fajn věci, ale nakonec je z toho šíleně složité univerzální monstrum, které těžko někdo ovládne celé, lidi se v tom budou ztrácet, bude jim dělat problémy číst cizí kód až nakonec ten jazyk opustí a přejdou na nějaký jednodušší.
Skvělý popis, proč lidi tak rychle zavrhli XML a začali používat JSON.
-
Franta (neregistrovaný)
Jeden odmítá speciální jazyky typu XQuery, XPath, XSLT a radši by to nacpal do jednoho obecného jazyka, který bude umět všechno; druhý zase odmítá XML, protože toho umí moc. Je zajímavé, jak si každý najde nějaký důvod, proč nenávidět XML :-) XML sice nabízí hodně možností, ale dává to dohromady smysl a většinu z toho používám a považuji za užitečné. JSON je tak "jednoduchý" že nenabízí vlastně nic, ani komentáře, ale zase tak složitý, že musím psát názvy klíčů do uvozovek a otravovat se s čárkami, středníky, závorkami... JSON mi přijde jako kombinace těch horších vlastností různých formátů. I takové INI soubory (resp. některá jejich specifikace/odrůda) jsou asi lepší. Nebo mnohé jiné formáty (YAML atd.).
-
Radek Miček (neregistrovaný)
Jeden odmítá speciální jazyky typu XQuery, XPath, XSLT a radši by to nacpal do jednoho obecného jazyka, který bude umět všechno
Jednak, jak už jsem naznačil výše, to nutně neznamená, že by ten jazyk musel být složitý.
A navíc není lepší nevymýšlet kolo™ a použít hotovou technologii (rozuměj existující programovací jazyky)?
ale zase tak složitý, že musím psát názvy klíčů do uvozovek a otravovat se s čárkami, středníky, závorkami
Tímto je naopak jednoduchý - specifikace i implementace.
je zajímavé, jak si každý najde nějaký důvod, proč nenávidět XML
Rozlišuji XML a specializovaný programovací jazyk pro práci s XML.
-
Filip JirsákStříbrný podporovatel
Řeší se to tu ze stejného důvodu, jako by se existence kola řešila pod článkem o objevu, že čtverec s kulatými rohy méně drncá.
-
-
Filip JirsákStříbrný podporovatel
Ten váš příměr je ovšem špatně, protože raketoplán a škoda 120 mají zcela jiný účel, jiné technologie, jinou cenu. Tady se ale bavíme o formátu, který je stejně složitý, jako XML, má horší možnosti – a článek je o tom, jak se další kousek technologie známé z XML překlopil, aby ho bylo nějak možné používat i s JSONem. To srovnání s XML si nevymysleli diskutující tady pod článkem, ale vymysleli ho autoři těch dvou v článku zmiňovaných standardů, logicky o tom pak píše i autor článku a následně se o tom (logicky) také diskutuje.
-
jos (neregistrovaný)
JSON hateři se tu snaží vnutit ostatním, že mají k dispozici XML, tak ať ho koukají používat
na to se dá říct jen: NASRAT, je to moje volba, když chce někdo řešit něco kolem JSONu, tak ať to řeší, co je komu kurva do toho?
na další tvoje levný lží nehodlam reagovat, vim co si zač, nazdar
