Vlákno názorů k článku RDAP: nástupce protokolu WHOIS od lol - JSON? Z toho sa tu niektori jedinci osypu...
-
Filip JirsákStříbrný podporovatelPokud se na ta data chcete dívat očima, ideální formát to možná je. Ale pokud to chcete zpracovávat strojově, pro JSON chybí spousta věcí, které jiné formáty mají. Například nemá jmenné prostory, takže ten „ideální“ formát bude ideální do okamžiku, kdy bude potřeba něco přidat. Pak se vám najednou formát rozpadne a budete z toho mít hromadu hodnot, kam si každý může přidat nebo ubrat, co ho napadne. Popis definice a dokumentace konkrétního formátu (něco jako XML schema) také není u JSON obvyklý, pokud už vůbec existuje finální verze standardu. Jazyky pro transformace nebo dotazování také chybí nebo se teprve tvoří…
-
ebik (neregistrovaný)
Zrovna pro strojové zpracování mi přijde JSON dobrý dost. Pravda chybí mu _nadstavba_, která by popisovala validní strukturu dat, ale podle mne by to měla být nadstavba a nemělo by to být zažráno přímo do toho formátu. Kdo nechce používat dalekonosnou raketu na sesetřelení komára, tak ji použít nemusí.
-
Filip JirsákStříbrný podporovatel
Všechno, co jsem popisoval, jsou nadstavby. Akorát že ty nadstavby musí někdo vymyslet a musí se rozšířit jejich používání. A až se tak stane, budeme mít z JSONu konečně druhé XML, akorát místo špičatých závorek budou kudrnaté.
Problém strojového zpracování JSONu je, že ten formát není robustní. Vzniklo to „tak to uděláme úplně jednoduše a pošleme si javascriptový objekt zapsaný ve zdrojáku“, což je pro nějaký prototyp nebo ad-hoc řešení výborné. Jenže pak bylo potřeba z toho udělat standard, tak se k tomu začala přilepovat další omezení. Takže to není nějaký ucelený standard, který by měl svou vnitřní logiku, ale je to takový slepenec různých omezení, u kterých není vůbec jasné, proč zrovna takhle. Po světě pak běhá spousta dat, která vypadají jako JSON, ale JSON nejsou, tomu se přizpůsobují parsery, které se snaží vypořádat i s nevalidními formáty,jenže každý parser to řeší jinak, takže jeden ten nevalidní vstup vám někde projde a jinde ne, nebo dokonce může projít na více místech, ale pokaždé dostanete něco jiného. Jediná reálná „výhoda“ oproti XML pak je, že se ušetří opakování názvu tagu v uzavíracím elementu. To mi připadá oproti všem těm nevýhodám zoufale málo, a když už je těch pár znaků tak důležitých, stačilo se inspirovat u SGML a do další verze XML povolit i prázdné uzavírací tagy
</>. -
Filip JirsákStříbrný podporovatel
JSON je na rozdíl od XML typovaný
JSON má tři základní typy, a tím to končí, žádný další typ z toho neodvodíte. Samotné XML nemá žádné typy, ale nadstavby jako XML schema umožňují definovat vlastní typy.parser lze v Boost Spirit napsat na asi padesát řádků
Parser čeho? JSON podle standardu? Reálného JSON?Zpracování XML je oproti tomu velmi složité
Není. Složité na něm rozhodně není to, co popisujete, složité by bylo jedině implementovat plnou podporu pro DTD, která se v praxi stejně nepoužívá.
