Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.8.
Herní studio Hangar 13 vydalo novou Mafii. Mafia: Domovina je zasazena do krutého sicilského podsvětí na začátku 20. století. Na ProtonDB je zatím bez záznamu.
Operátor O2 má opět problémy. Jako omluvu za pondělní zhoršenou dostupnost služeb dal všem zákazníkům poukaz v hodnotě 300 Kč na nákup telefonu nebo příslušenství.
Společnost OpenAI představila GPT-5 (YouTube).
Byla vydána (𝕏) červencová aktualizace aneb nová verze 1.103 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.103 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Americký prezident Donald Trump vyzval nového generálního ředitele firmy na výrobu čipů Intel, aby odstoupil. Prezident to zdůvodnil vazbami nového šéfa Lip-Bu Tana na čínské firmy.
Bylo vydáno Ubuntu 24.04.3 LTS, tj. třetí opravné vydání Ubuntu 24.04 LTS s kódovým názvem Noble Numbat. Přehled novinek a oprav na Discourse.
Byla vydána verze 1.89.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Americká technologická společnost Apple uskuteční v USA další investice ve výši sta miliard dolarů (2,1 bilionu korun). Oznámil to ve středu šéf firmy Tim Cook při setkání v Bílém domě s americkým prezidentem Donaldem Trumpem. Trump zároveň oznámil záměr zavést stoprocentní clo na polovodiče z dovozu.
Zálohovací server Proxmox Backup Server byl vydán v nové stabilní verzi 4.0. Založen je na Debianu 13 Trixie.
Společnost Google uvolnila zajímavou technologii Protocol Buffers. Ta v Googlu údajně původně sloužila jako komunikační formát pro vzdálená volání procedur, nyní je používána jako univerzální datový a komunikační formát. K dispozici je i zápisek na blogu společnosti Google vysvětlující motivaci k zavedení tohoto formátu.
Tiskni
Sdílej:
9.7.2008 05:18
thingie | skóre: 8
9.7.2008 08:34
zoul | skóre: 43
| blog: ☂
| Boskovice
However, protocol buffers are not always a better solution than XML – for instance, protocol buffers would not be a good way to model a text-based document with markup (e.g. HTML), since you cannot easily interleave structure with text. In addition, XML is human-readable and human-editable; protocol buffers, at least in their native format, are not. XML is also – to some extent – self-describing. A protocol buffer is only meaningful if you have the message definition (the .proto file).Pojďme se bavit trochu na úrovni, nadávání na XML už je z módy.
9.7.2008 09:04
finc | skóre: 8
| blog: Finc
| Kolín
9.7.2008 09:27
zoul | skóre: 43
| blog: ☂
| Boskovice
Jen mě připadá úchylné, když se dne musí autoři binárního protokolu hájit oproti tomu, proč nepoužili XML.Oni se nehájí. XML je dnes tak rozšířené, že slouží nejenom jako samotná technologie, ale i jako koncept – způsob řešení, vůči kterému se jiné technologie dají vymezovat. Binární protokoly jsou sice služebně starší, ale pro dnešní mladou generaci programátorů se dají paradoxně definovat jako „rychlejší XML“. Což je přesně to, co dělají v dokumentaci Protocol Buffers: „think XML, but smaller, faster, and simpler“.
Obecně binární formáty nemají omezení na stromovou strukturu jako má XML, jsou tedy daleko univerzálnější.Univerzálnější v čem? S-výrazy mají stromovou strukturu, TLV koncept ve výsledku vede nanejvýš taky na stromovou strukturu, stromovou strukturu má i syntaxe programovacích jazyků. Ve stromové struktuře lze triviálním způsobem popsat obecný graf (naivně např. uvedením samostatné tabulky vrcholů a samostatné tabulky hran) i N-rozměrné pole a zřejmě tedy všechny datové struktury, na které si v tuhle chvíli vzpomínám. Mohl byste seslat trochu světla na neznalého bloudícího v temnotách? Předesílám, že nevěřím na XML a že je mi zcela jasné, že reprezentovat např. to N-rozměrné pole v XML přináší ohavně vysokou režii při serializaci a deserializaci, ale to je rozdíl pouze výkonnostní. Jaké jsou ty rozdíly konceptuální?
gosh> (use srfi-1) #<undef>> gosh> (circular-list 1 2 3) ; Cyklicky graf #0=(1 2 3 . #0#) gosh> (let ((a '(1 2 3 4))) (list a a a)) ; DAG (#0=(1 2 3 4) #0# #0#) gosh>Samozřejmě se to dá zase načíst zpátky (asi desekrát rychleji, než nejrychlejším XML parserem
).
Mnooo, S-výrazy alespoň v podání Lispu/Scheme umějí nejen stromy, v XML jsem něco takového hledal marně.Ty neznáš XML Graph Working Group, která standardizuje nový XGraph?
Každopádně ten zápis je pořád strom a přiřazení úhlových závorek kulatým je vzájemně jednoznačné, ne?
To, že to po průchodu lexerem a parserem je strom a po průchodu evaluátorem obecný graf je jiná písnička.Struktura stromu vygenerovaného parserem je jasně viditelná už ze zápisu (vy fakt čtete bajty? To klobouk dolů, já písmena a věty v daném jazyce), proto jsem si dovolil tuhle zkratku. Inu, není na světě člověk ten, aby se zavděčil lidem všem.
XML je zbytečný, pomalý, nešikovný, překomplikovaný balast, znovu vynalézané kolo a ještě ke všemu šišaté, těžké a vyosené.To je super, akorát to v téhle diskusi zaznělo už několikrát. A že by to přispělo k objasnění konceptuálního rozdílu mezi XML a binárními komunikačními protokoly, to ani při nejlepší vůli říct nemůžu. Ale napadá mě jiná otázka: jak funguje serializace toho
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
circular-listu?
(circular-list 1 2 3) vyrobí stream, který při iteraci vypadá takhle nějak: (1 2 3 1 2 3 1 2 3 [a tak dále pořád do nekonečna]). Tohle se ovšem přímo serializovat nedá, hádám, že se bude serializovat spíš definice. Tedy v podstatě se při serializaci zapíše výraz (circular-list 1 2 3), který se při deserializaci znovu vyhodnotí.
Pokud je tomu skutečně tak, přesně tohle lze přece serializovat i XML stromem. Jasně, naprosto k tomu není důvod, ale nenapadá mne, při použití pro přenos dat, rozdíl. Výhoda S-výrazů je tady v tom, že je lze použít i pro uložení datových struktur při běhu programu, kde líné vyhodnocování umožňuje takové "triky". Psát program nad DOM strukturou je těžká pakárna, ale pořád žiju v představě, že XML je prostředek pro komunikaci, a proto se bavím o komunikaci (tedy, řekněmě, serializaci a deserializaci zpráv).
(circular-list 1 2 3) vyrobí stream, který při iteraci vypadá takhle nějak: (1 2 3 1 2 3 1 2 3 [a tak dále pořád do nekonečna]). Tohle se ovšem přímo serializovat nedá, hádám, že se bude serializovat spíš definice. Tedy v podstatě se při serializaci zapíše výraz (circular-list 1 2 3), který se při deserializaci znovu vyhodnotí.Nic takového, ten serializovaný zápis prostě obsahuje v jednom místě referenci na jiné místo sebe sama. Tomu bych ale neříkal definice.
A jaké líné vyhodnocování? To se tam vůbec neobjevilo.
<list>
<item id="1">1</item>
<item id="2">2</item>
<item id="3">3</item>
<item ref="1"/>
</list>
A pak někde sebrat logiku, která mi z toho ten seznam vytvoří. V tom Lispu to hádám bude o poznání univerzálnější a vůbec milejší. Nedá se k tomu najít někde něco víc? Ve zmíněném SRFI-1 na tohle téma nic nevidím (což mi sice celkem dává smysl, ale to je tak všechno ).
No já jsem jenom hádal, jakpak se to asi dělá. Referenci, referenci, to je hrozně nicneříkající. Jak se serializuje reference?To je právě ten rozdíl, pro Lisp je to jasně definováno, pro "XML" jako formát nikoliv. Jen v některých shema je to jako extrabuřt a ještě ke všemu je to potenciálně konfliktní s přirozenými prvky viz tvůj vlastní příklad níže. To jako nemůžu mít attribut který se jmenuje 'ref'? LOL a to si říká jako univerzální formát, tenhle paskvil.
V XML taky můžu napsat
<list>
<item id="1">1</item>
<item id="2">2</item>
<item id="3">3</item>
<item ref="1"/>
</list>
A pak někde sebrat logiku, která mi z toho ten seznam vytvoří.Bingo! Kde tu logiku sebereš, to je ten rozdíl.V tom Lispu to hádám bude o poznání univerzálnější a vůbec milejší. Nedá se k tomu najít někde něco víc? Ve zmíněném SRFI-1 na tohle téma nic nevidím (což mi sice celkem dává smysl, ale to je tak všechno
Syntaxe všech protokolů vede na strom, jak je tak u syntaxe zvykem, ale deserializované datové struktury mají v případě Lispu (a dalších) obecně význam grafu, kdežto u XML pořád stromu (DOM). Bingo, konceptuální rozdíl objeven, díky všem zúčastněným za trpělivost
Nicméně je zřejmě možné napsat nad běžnými prostředky pro práci s XML knihovnu, která by byla schopná serializovat a deserializovat i obecné grafy objektů, dost možná už taková existuje. Konfliktní názvy atributů lze bez problémů vyřešit zvláštním jmenným prostorem, tady jsem to LOL teda nepochopil.
Nicméně je zřejmě možné napsat nad běžnými prostředky pro práci s XML knihovnu, která by byla schopná serializovat a deserializovat i obecné grafy objektů, dost možná už taková existuje.Pomýšlel jsem v tomhle ohledu na XStream, a už úvodní stránka mi dává za pravdu:
Full object graph support. Duplicate references encountered in the object-model will be maintained. Supports circular references.Pár detailů je ještě na stránce o grafech objektů.
15.7.2008 13:54
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Souhlasím. Jen mě připadá úchylné, když se dne musí autoři binárního protokolu hájit oproti tomu, proč nepoužili XML. Za chvíli budou padat dotazy, proč IP protokol není definován jako XML instance.Kdyby použili binární XML, nemuseli by se vymezovat
9.7.2008 15:12
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
9.7.2008 15:18
zoul | skóre: 43
| blog: ☂
| Boskovice
9.7.2008 15:49
otula | skóre: 45
| blog: otakar
| Adamov
Džone, padla, jdeme domů.No a když někoho "chytrého" napadlo vzít poměrně nešikovný jazyk pro popis strukturovaného textu (tj mnoho textu a málo značek) a udělat z toho XML a používat to pro popis obecných dat (tj hromada značek, málo textu), tak se není čemu divit. * A autoři SGML se prostě nikdy nestarali o to, aby byl popis SGML rozumně zapsatelný v SGML samotném a důsledky si vyžíráme dodnes.
Nemůžu Stýve, musím do toho SGML vymyslet komentáře
Kašli na to, v televizi jsou Vyvolení
(mezitím večer se kočka prošla po klávesnici a na monitoru blikaly znaky <!--<-->*)
Na komunikaci asi ne.
Na LWN jsem našel pěknou poznámku "It's a useable 80% solution, whereas ASN.1
approaches 100% unuseable."
9.7.2008 14:49
zoul | skóre: 43
| blog: ☂
| Boskovice
Umite nekdo kratce popsat, proc bych mel chtit protocol buffers a ne BER/DER?Složitost? Když zkusím vygůglovat BER/DER, najdu například A Layman’s Guide to a Subset of ASN.1, BER, and DER, který mě upřímně děsí. (Přestože je podle názvu určený laikům a popisuje podmnožinu zmíněných standardů.) Když se mrknu na dokumentaci PB, na první pohled v podstatě rozumím všemu. Jednodušší specifikace = větší počet implementací = větší popularita ≈ méně problémů v praxi.
Proto jsem taky mluvil o té komunikaci. Interně uvnitř firmy se asi člověku dýše volněji, než když musí komunikovat se světem, který se masochisticky rozhodl používat na textová data XML a na binární ASN.1.
aniž by vzali v úvahu kontextV komentáři, na kterým jsem odpovídal, není o Google ani slovo. Takže ten, kdo je mimo kontext, nejsem já. Pokud by Google chtěl minimalizovat datové přenosy nebo potřebný výkon serverů, nebude na to používat ani žádný jiný univerzální binární formát, ale vytvoří si vlastní binární formáty pro každou jednotlivou aplikaci, přesně šité na míru. Cokoliv jiného (i univerzální binární formát) je stále kompromis mezi potřebným výkonem a složitostí vývoje.
Jste si jist? Pokud rozdíl mezi potřebným výkonem serveru třeba pro zpracování univerzálního binárního formátu a binárního formátu přesně šitého na míru je 0,00001% ve prospěch vlastního formátu (což může být tak reálné číslo v praxi), pak nemusí být moc důvodu nepoužít i obecnější binární věc.Pokud chcete porovnávat skutečně rozdíly mezi vlastním binárním formátem, univerzálním binárním formátem ASN.1 nebo dalšími univerzálními binárními formáty a univerzálním formátem XML, asi nezbyde, než potřebné výkony serveru pro jednotlivé případy nějak spočítat nebo změřit. Protože jinak tady můžeme věštit z křišťálové koule, že rozdíl mezi formátem na míru a ASN.1 bude 0,0001 % a rozdíl mezi ASN.1 a XML bude 0,0003 %, ale žádný přesnější údaj nezískáme.
I bez měření je jasné…To je skutečně pádný argument. Jasné je to možná někomu, komu se o špičatých závorkách zdají v noci zlé sny. My ostatní bychom potřebovali alespoň nějaký argument, proč by tomu tak mělo být. Povídání o metajazyku tím argumentem není, protože není principiální rozdíl v tom, jestli mám v souboru jeden bajt, podle jehož hodnoty poznám „následuje serializovaná hodnota objektu toho a toho typu“, nebo jestli to samé zjistím přečtením názvu tagu.
To transmit a "person" we might send:Ve skutečnosti je ten rozdíl řádový, protože UBF je přímo bytecode velmi jednoduchého zásobníkového VM a jeho parser napíše malé dítě s prstem v zad... na několika málo řádcích kódu, kdežto parser XML je něco tak neskutečně obludného. Sám Google tvrdí, že ten rozdíl je{'person'"Jane"18}$The equivalent XML might be:<p><person/><name>Jane</name><age>18</age></p>Which would take roughly twice as long to parse - since we must at a very minimum inspect each individual character on the input stream.
... it would probably be 28 bytes long and take around 100-200 nanoseconds to parse. The XML version is at least 69 bytes if you remove whitespace, and would take around 5,000-10,000 nanoseconds to parse.Což je podle mého laického závěru rozdíl 50x, tedy o jeden řád bezmála dva řády. Stačí? P.S.: Mimochodem, binární kódování PB je pěkněj maglajs. Po technické stránce nic moc. Spíš dobré jako odstrašující příklad. Nejvíc bych se obával, že se to vážně rozšíří.
Which would take roughly twice as long to parse - since we must at a very minimum inspect each individual character on the input stream.Zatímco UBF tam má asi spoustu znaků zbytečně, které je možné klidně ignorovat. Nebo jsou tam potřebné všechny, pak se ale také musí všechny přečíst – a věta platí pro oba formáty stejně. Což nám při hledání rozdílu moc nepomůže.
Ve skutečnosti je ten rozdíl řádový, protože UBF je přímo bytecode velmi jednoduchého zásobníkového VM a jeho parser napíše malé dítě s prstem v zad... na několika málo řádcích kódu, kdežto parser XML je něco tak neskutečně obludného.Aha, takže porovnání specializovaného parseru binárního formátu a obecného XML parseru bychom už měli. Teď ještě můžeme porovnat obecný parser binárního formátu s XML parserem nějakého konkrétního XML formátu. A tomu XML můžeme říkat třeba bytecode jednoduchého zásobníkového VM. Jediný rozdíl je, že jeho instrukce jsou poněkud ukecanější – no ale jestli aplikaci nejvíce brzdí porovnání pár bajtů na shodu, pak musí být vše kolem ní tak vypiplané, že nevím, kde se tam to XML vzalo.
A co je na tom parseru UBF tak specializovaného, že je to v opozici k obecnému XML. Ten parser UBF je stejně obecný jako XML.Which would take roughly twice as long to parse - since we must at a very minimum inspect each individual character on the input stream.Zatímco UBF tam má asi spoustu znaků zbytečně, které je možné klidně ignorovat. Nebo jsou tam potřebné všechny, pak se ale také musí všechny přečíst – a věta platí pro oba formáty stejně. Což nám při hledání rozdílu moc nepomůže.Ve skutečnosti je ten rozdíl řádový, protože UBF je přímo bytecode velmi jednoduchého zásobníkového VM a jeho parser napíše malé dítě s prstem v zad... na několika málo řádcích kódu, kdežto parser XML je něco tak neskutečně obludného.Aha, takže porovnání specializovaného parseru binárního formátu a obecného XML parseru bychom už měli.
Teď ještě můžeme porovnat obecný parser binárního formátu s XML parserem nějakého konkrétního XML formátu.Dtto, UBF je stejně obecný jako XML, není žádný specializovaný UBF. Ad hoc si ho někdo může napsat, ale proč by to dělal, když mu obecný přinese o několik řádů vyšší výkon, než obecný XML a nejméně několikanásobně vyšší výkon, než specializovaný XML parser (který by uměl jen speciální zprávy).
A tomu XML můžeme říkat třeba bytecode jednoduchého zásobníkového VM. Jediný rozdíl je, že jeho instrukce jsou poněkud ukecanější – no ale jestli aplikaci nejvíce brzdí porovnání pár bajtů na shodu, pak musí být vše kolem ní tak vypiplané, že nevím, kde se tam to XML vzalo.
A co je na tom parseru UBF tak specializovaného, že je to v opozici k obecnému XML. Ten parser UBF je stejně obecný jako XML.Není, UBF rozeznává datové typy, obecné XML ne. Když budete parsovat XML podle určitého schématu parserem, který bude brát v úvahu datové typy určené tím schématem, dostanete podle mne parser ekvivalentní s parserem UBF. Nebo jaký mezi nimi bude rozdíl?
když mu obecný přinese o několik řádů vyšší výkon, než obecný XML a nejméně několikanásobně vyšší výkon, než specializovaný XML parser (který by uměl jen speciální zprávy).A kde se ten výkon vezme? To když procesor uvidí „XML“ lekne se a schová se do kouta? Rád bych se dozvěděl o tom, rozdílu, který ten několikanásobně vyšší výkon způsobí – zatím stále vidím jen použití jiné zkratky pro název technologie, ale princip technologie je stále stejný.
Ne, pletete kule s baňama. Obecný UBF parser sice rozeznává datové typy, ale nikoliv proti konkrétnímu schématu. To, že XML nerozeznává datové typy a dovede to jedině se schematem je jeho mínus. UBF rozeznává datové typy a kromě toho ještě dokáže použít schema a vůči němu validovat. UBF je rychlejší i pro běh bez schematu, váš hypotetický XML parser se schematem ad hoc kompilovaný pro jeden konkrétní úkol možná může být stejně rychlý, ale to jsme poněkud někde jinde. Obecný UBF parser bez schematu je rychlejší než obecný XML parser. Ad-hoc na míru kompilovaný XML na jedno konkrétní schema bude snad srovnatelně rychlý jako obecný UBF parser, ale stejně pomalejší už jen proto, že pořád musí zpracovat větší datový tok. Z toho se prostě nevykecáte. Už to sice nebude několik řádů jako u obecného XML parseru, ale stále to bude u specializovaného XML několikrát pomalejší než obecný UBF.A co je na tom parseru UBF tak specializovaného, že je to v opozici k obecnému XML. Ten parser UBF je stejně obecný jako XML.Není, UBF rozeznává datové typy, obecné XML ne. Když budete parsovat XML podle určitého schématu parserem, který bude brát v úvahu datové typy určené tím schématem, dostanete podle mne parser ekvivalentní s parserem UBF. Nebo jaký mezi nimi bude rozdíl?když mu obecný přinese o několik řádů vyšší výkon, než obecný XML a nejméně několikanásobně vyšší výkon, než specializovaný XML parser (který by uměl jen speciální zprávy).A kde se ten výkon vezme? To když procesor uvidí „XML“ lekne se a schová se do kouta? Rád bych se dozvěděl o tom, rozdílu, který ten několikanásobně vyšší výkon způsobí – zatím stále vidím jen použití jiné zkratky pro název technologie, ale princip technologie je stále stejný.
Už to sice nebude několik řádů jako u obecného XML parseru, ale stále to bude u specializovaného XML několikrát pomalejší než obecný UBF.A kde se vezme to „několikrát“? Jinak ono by bylo možné parsovat i to XML s ohledem na typy a bez schématu, jenom by proto bylo nutné si stanovit nějakou konvenci. Jenže jsem se ještě jednou podíval na ten UBF formát, a on i čísla ukládá jako text, takže ani parsování podle datových typů nebude rychlejší. U čísla stejně musí hledat ne-číslici, u stringu stejně musí hledat „"“ a „\“ atd., takže jediný rozdíl oproti XML je, že XML ještě navíc udělá test na shodu
x znaků. Myslím, že test na shodu není v celém parsování ta nejpomalejší operace, aby to vedlo k několikanásobnému zpomalení.
A kde se vezme to „několikrát“?Dvakrát víc znaků, dvakrát pomalejší parsování i kdyby to ostatní bylo stejné, ale ono není.
Jinak ono by bylo možné parsovat i to XML s ohledem na typy a bez schématu, jenom by proto bylo nutné si stanovit nějakou konvenci. Jenže jsem se ještě jednou podíval na ten UBF formát, a on i čísla ukládá jako text, takže ani parsování podle datových typů nebude rychlejší. U čísla stejně musí hledat ne-číslici, u stringu stejně musí hledat „"“ a „\“ atd., takže jediný rozdíl oproti XML je, že XML ještě navíc udělá test na shodu x znaků.A v tom samozřejmě není rozdíl. Hmm, tak si to zkuste naprogramovat a pak se můžeme bavit dál.Myslím, že test na shodu není v celém parsování ta nejpomalejší operace, aby to vedlo k několikanásobnému zpomalení.OK, tak já zkusím napsat obecný parser UBF v C a vy napíšete specializovaný parser XML na nějaký dataset z praxe. O co se vsadíte, že ten můj výsledek bude rychlejší?
Rád bych se dozvěděl o tom, rozdílu, který ten několikanásobně vyšší výkon způsobí
Nejsem expert, ale vždycky mi přišlo, že i když jednu a tutéž strukturu zapíšu pomocí XML a pak třeba ještě pomocí něčeho jiného, ale ekvivalentního, třeba pomocí S-vyrazů nebo pomocí vlastní jednoduché syntaxe, tak docela dost výkonu obětuju na samotný XML "lexer" - najit levý zobáček, název, pravý zobáček, na konci totéž s lomítkem a hezky párovat a kontrolovat značky tam, kde S-výrazům stačí "(" .. ")" a spoustě jiných formátů stačí "{".."}". Tyhle stavové přechody a testy navíc se na výkonu neprojevují? Navíc i XML experti (třeba Uche Ogbuji) tvrdí, že napsat korektní XML parser a ošetřit všechny případy je pekelně těžké. Jestli to není jednoduché, asi nebude jednoduchý ani ten kód a pokud není jednoduchý, nevidím příliš mnoho důvodů, proč by měl být rychlý, a skutečně jsem v životě rychlý XML parser neviděl. (No, možná ten od Martina Mareše mě přesvědčí, až ho uvidím. )
Samozřejmě si dokážu představit parser "něčeho jako XML", který bude mnohem rychlejší, protože většinu problematických věcí vynechá, ale "něco jako XML" nebude XML a já to stejně nebudu moci používat jako XML parser, protože mi pak někdo pošle soubor v "úplném XML" a ono se mi to na něm zakucká, protože tam budou třeba CDATA a já budu mít smůlu.
docela dost výkonu obětuju na samotný XML "lexer" - najit levý zobáček, název, pravý zobáček, na konci totéž s lomítkem a hezky párovat a kontrolovat značky tam, kde S-výrazům stačí "(" .. ")" a spoustě jiných formátů stačí "{".."}". Tyhle stavové přechody a testy navíc se na výkonu neprojevují?S-výraz bude hledat „)“ nebo „}“, XML parser bude hledat „<“ a pak udělá test „je následujících 7 znaků rovno '/osoba>'?“ To způsobí řádový rozdíl v rychlosti?
Samozřejmě si dokážu představit parser "něčeho jako XML", který bude mnohem rychlejší, protože většinu problematických věcí vynechá, ale "něco jako XML" nebude XML a já to stejně nebudu moci používat jako XML parser, protože mi pak někdo pošle soubor v "úplném XML" a ono se mi to na něm zakucká, protože tam budou třeba CDATA a já budu mít smůlu.Jediné, co je na XML složité, jsou entity, které jsou v XML bůhvíproč, nikdo je nepoužívá a nejlepší by bylo je vyhodit. Když budu dělat specifikaci nějakého XML formátu, klidně tam přidám i podmínku, že na entity se nehraje. Nevím z hlavy, jak je to se sekcí CDATA – možná ji dokážu vyloučit vhodným schématem, a pokud ne, ten parser o moc složitější nebude.
), zeptejte se expertů.
Ó nikoliv vážený, je zjevné, že jste lexerů a parserů moc nenapsal, protože si pletete lexer a parser. Už jen to, že lexikální jednotky 'docela dost výkonu obětuju na samotný XML "lexer" - najit levý zobáček, název, pravý zobáček, na konci totéž s lomítkem a hezky párovat a kontrolovat značky tam, kde S-výrazům stačí "(" .. ")" a spoustě jiných formátů stačí "{".."}". Tyhle stavové přechody a testy navíc se na výkonu neprojevují?S-výraz bude hledat „)“ nebo „}“, XML parser bude hledat „<“ a pak udělá test „je následujících 7 znaků rovno '/osoba>'?“ To způsobí řádový rozdíl v rychlosti?
(' a ')' mají konstantní délku vám udělá v praxi nezanedbatelný rozdíl výkonu. Naproti tomu v XML by ekvivalentní lexikální jednotky byly začátek a konec tagu, jenže nemůžou protože attributy, takže i ta otevírací závorka se v XML musí rozbít na menší lexikální jednotky a už i tu otevírací závorku předhodit parseru a parser je zpravidla výrazně pomalejší než lexer. A tady jsme zase u toho vašeho hypotetického specializovaného XML parseru, který by třeba neměl ve schema atribut a pak by jsme se dostaly na jednodušší parser, která bude mít otevírací a zavírací tag lexikální jednotkou, ale pak nám do toho zase vstoupí proměnlivá délka lexikální jednotky, dynamická alokace, delší datový tok a už se vezeme. Opravdu zvláštní, že těch rychlých XML parserů jsou všude mraky, že.Jinými slovy sám vidíte, že XML je překomplikovaný a aby to bylo rychlé, tak musíte definovat schema a zakázat některé vlastnosti, ale pak už to jaksi není obecné XML. Pěkně se v tom plácáte vážený.Samozřejmě si dokážu představit parser "něčeho jako XML", který bude mnohem rychlejší, protože většinu problematických věcí vynechá, ale "něco jako XML" nebude XML a já to stejně nebudu moci používat jako XML parser, protože mi pak někdo pošle soubor v "úplném XML" a ono se mi to na něm zakucká, protože tam budou třeba CDATA a já budu mít smůlu.Jediné, co je na XML složité, jsou entity, které jsou v XML bůhvíproč, nikdo je nepoužívá a nejlepší by bylo je vyhodit. Když budu dělat specifikaci nějakého XML formátu, klidně tam přidám i podmínku, že na entity se nehraje. Nevím z hlavy, jak je to se sekcí CDATA – možná ji dokážu vyloučit vhodným schématem, a pokud ne, ten parser o moc složitější nebude.
Ó nikoliv vážený, je zjevné, že jste lexerů a parserů moc nenapsal, protože si pletete lexer a parser. Už jen to, že lexikální jednotky '(' a ')' mají konstantní délku vám udělá v praxi nezanedbatelný rozdíl výkonu. Naproti tomu v XML by ekvivalentní lexikální jednotky byly začátek a konec tagu, jenže nemůžou protože attributy, takže i ta otevírací závorka se v XML musí rozbít na menší lexikální jednotky a už i tu otevírací závorku předhodit parseru a parser je zpravidla výrazně pomalejší než lexer. A tady jsme zase u toho vašeho hypotetického specializovaného XML parseru, který by třeba neměl ve schema atribut a pak by jsme se dostaly na jednodušší parser, která bude mít otevírací a zavírací tag lexikální jednotkou, ale pak nám do toho zase vstoupí proměnlivá délka lexikální jednotky, dynamická alokace, delší datový tok a už se vezeme. Opravdu zvláštní, že těch rychlých XML parserů jsou všude mraky, že.To, že chcete mít lexer a parser oddělený a lexer nemůže využívat informací parseru o tom, jaké hodnoty může očekávat, je váš problém, nikoli problém XML formátu. Já s vámi souhlasím, že lze napsat XML parser tak, že bude řádově pomalejší, než cokoli jiného. Ale abychom mohli porovnat formáty samotné, je potřeba je porovnávat asi na nejlepší možné implementaci.
Jinými slovy sám vidíte, že XML je překomplikovaný a aby to bylo rychlé, tak musíte definovat schema a zakázat některé vlastnosti, ale pak už to jaksi není obecné XML. Pěkně se v tom plácáte vážený.Já jsem nikde neobhajoval obecné XML s entitami, DTD apod. Ale i XML-jak-se-dnes-používá je pro člověka čitelnější, než různé binární formáty – obecné XML není vůbec podmínkou (spíš naopak). Nevím, co vám tolik vadí na XML – zda jenom ty samotné špičaté závorky, nebo to, že součástí dokumentu jsou i informace o jeho struktuře. Pokud to druhé, pak se asi neshodneme – protože já osobně vidím výhodu popisu struktury přímo v dokumentu jako výhodu, a taky vidím použití všude kolem. Třeba takové protokoly HTTP, SMTP e-mailová zpráva – to vše by se samozřejmě dalo přepsat do formátu, který bude mít strukturu určeno někde mimo vlastní dokument. Ale třeba s takovým e-mailem se člověku mnohem lépe pracuje, když tam vidí napsáno
Subject:, než kdyby musel někde hledat, že Subject je třeba 5. hlavička. Příklad, kdy je struktura dané mimo, jsou třeba IP a TCP/IP hlavičky, protože ty je potřeba zpracovávat velmi rychle i na jednoduchých zařízeních a neočekává se, že by se do těchto hlaviček přidávaly nové a nové informace.
Jakmile má nějaký formát popis své struktury jako součást dokumentu, bude vždy platit, že buď jsou spolu lexer a parser provázané a lexer ví, co může v daném okamžiku očekávat za klíčová slova, a nebo může lexer pracovat jen nad nízkoúrovňovými lexikálními jednotkami, a pak bude pomalejší.
Ono se to XML používá hlavně v heterogenních prostředích, kde se třeba komunikační formáty postupně vyvíjejí, ne každá aplikace potřebuje všechny údaje nebo některá potřebuje skrz cizí aplikace poslat ještě navíc svoje údaje – a tam všude se bude dost těžko používat formát, který má strukturu mimo dokument samotný a s každou změnou formátu je nutné upravit všechny aplikace.
Nevím, co vám tolik vadí na XML – zda jenom ty samotné špičaté závorky, nebo to, že součástí dokumentu jsou i informace o jeho struktuře. Pokud to druhé, pak se asi neshodneme – protože já osobně vidím výhodu popisu struktury přímo v dokumentu jako výhodu, a taky vidím použití všude kolem.Ale ne, informace o struktuře mi nevadí. I v UBF může být taková informace součástí. Na XML mi nevadí ani ty špičaté závorky, ale sémantika a způsob serializace, hlavně escape schema. Prostě je to překomplikované. Semanticky XML struktura je něco takového:
XMLNode = ( tag : STRING, attrs: {(STRING:STRING)*}, content: [STRING|XMLNode] )
Kde () je tuple - má fixní počet hodnot, konkrétně tři, tag, atributy a obsah. I když druhé dva mohou být prázdné. Atributy představují něco jako hash/dictionary {} - každý klíč se může nacházet pouze jednou a z hlediska sémantiky XML by nemělo záležet na pořadí. A nakonec tu máme obsah, který je sémanticky pole/list [] (záleží na pořadí) a prvky toho pole mohou být jak kusy textu (obecně jakýkoli binární ... - CDATA) tak i další XML uzly. Proč nemůže být XML uzel hodnotou atributu? Proč nemůže být hodnota tagu jakýkoli string? Proč nemůže být klíč atributu jakýkoli string? Proč musí být XML uzly - děti uspořádané? Proč musí být escape sekvence tak hrozně komplikované? Proč CDATA nesmí obsahovat ]]>? Proč je to XML tak neskutečně blbě navržené? Protože XML! Přitom na zakódování libovolné struktury stačí Lispu jediná konstrukce - cons! Libovolný XML dokument jde zakódovat do S-expr, jenže to má háčky. Dokud nepřidám naprosto nesmyslná omezení na jméno tagu a atributu, tak nemůžu všechno, co strukturálně vypadá jako S-expr XML dokumentu - bude kopírovat sémantiku XML popsanou výše, serializovat do XML. Prostě protože XML obsahuje naprosto nesmyslná omezení. A na CDATA rezignuje člověk rovnou, protože by musel každý binární string testovat na existenci sekvence ]]>. Prostě XML je paskvil, že se z toho člověku zvedá žaludek. Doufám, že naše děti se na XML budou učit, jak nemá vypadat univerzální datový formát.
Když chci v UBF uložit dictionary, tak jednoduše napíšu
#{"key3""val3"}&{"key2""val2"}&{"key1""val1"}&$A v XML?
<neco_si_musim_vymyslet_sem key1="val1" key2="val2" key3="val3"/>Jenže to nemůžu použít, když bych chtěl do value uložit něco jiného než string, to hned musím použít:
<neco_si_musim_vymyslet_sem> <key1>some more complicated <val1>heh?</val1></key1> <key2>val2</key2> <key3>val3</key3> </neco_si_musim_vymyslet_sem>A sranda nekončí, co když klíče nejsou textové s povolenou množinou znaků? Třeba jen, když to začíná číslicí, ROFL!
<neco_si_musim_vymyslet_sem> <pair key="1">some more complicated <val1>heh?</val1></pair> <pair key="2">val2</pair> <pair key="3">val3</pair> </neco_si_musim_vymyslet_sem>A proč by klíč měl být string a nemohla to být struktura?
<neco_si_musim_vymyslet_sem>
<pair>
<key>some complicated <key1/></key>
<val>some more complicated <val1>heh?</val1></val>
</pair>
<pair>
<key>key2</key>
<val>val2</val>
</pair>
<pair>
<key>key2</key>
<val>val3</val>
</pair>
</neco_si_musim_vymyslet_sem>
Co že to chci uložit? Jen takový jednoduchý slovník a pokaždé musím použít naprosto navzájem nekompatibilní XML schema! ROFL. Tohle má být jako univerzální datový formát, to si ze mě někdo dělá srandu, ne?
Když chci v UBF uložit dictionary, tak jednoduše napíšu
#{"key3""val3"}&{"key2""val2"}&{"key1""val1"}&$… a dostanete slovník, který vám jen tak lítá ve vzduchu. Já tedy nevím jak vy, ale já většinou potřebuju vědět, co ten slovník znamená. A k tomu právě slouží to vaše neco_si_musim_vymyslet_sem. Navíc že je ten váš zápis zrovna slovník, kde key1 je klíč, je vaše interpretace, ničím nepodložená. Co když je to slovník, ale klíč je val1? Co když je to jen seznam uspořádaných dvojic bez bližšího rozlišení? Co když je to seznam uspořádaných n-tic, kde se zrovna v tomto případě shodou okolností vyskytují jen dvojice?
XML uzel nemůže být hodnotou atributu proto, že atribut je dodatečná informace, základním strukturním prvkem XML je element. Omezení názvu tagu mi nepřipadá jako velký problém, zvlášť když vezmu v úvahu původní účel, proč XML vzniklo. CDATA a nemožnost dovnitř vložit ]]> je dost hloupá věc. Že má podle vás XML málo zpětných lomítek, s tím vám nijak nepomohu.
Takže abych to shrnul, na nevhodně navržené sekci CDATA se shodneme, vám vadí málo zpětných lomítek a to, že klíčová slova nemohou být libovolný string, a umíte si vymyslet spoustu způsobů, jak něco, co máte špatně zapsané v UBF přepsat ještě hůř do XML.
kulcs nebo korallsziget a místo value eretek? Z toho zjistím co? Asi tak stejný prd jako z UBF. Kde tam vidíte rozdíl? Vy prostě nábožně uctíváte XML a XML je samospasitelné. Že obsahuje prakticky stejnou out of band informaci jako jakákoli jiná serializace, to už ve své zaslepenosti nevidíte. To co jsem zapsal v UBF je ve skutečnosti stejně špatné jako <neco_si_musim_vymyslet_sem>
<pair>
<key>key1</key>
<val>val1></val>
</pair>
<pair>
<key>key2</key>
<val>val2</val>
</pair>
<pair>
<key>key2</key>
<val>val3</val>
</pair>
</neco_si_musim_vymyslet_sem>
Stejně informace o tom, že pair jsou páry s klíčem key a hodnotou val nějakého slovníku neco_si_musim_vymyslet_sem tam nikde uložená není. Ten formát tu sémantickou informaci nenese. Takovou informaci nese například JSON, nebo YAML, ale XML rozhodně ne.
Jak to prostě vím, že tagem key označuji klíč?Někteří to pochopíme hned, někteří si budou muset přečíst v dokumentaci, že „
key is key“.
Když už tady píšete ty ekvivalentní příklady v UBF a XML, nějak vám v tom UBF chybí možnost pro libovolná volitelná rozšíření nebo dopřednou kompatibilitu formátu. Třeba když se do toho slovníku někdo rozhodne přidat datum poslední modifikace – ale tak, aby to nerozbilo stávající aplikace. Možná při tom přeci zjistíte, že XML přeci jen nějakou sémantickou informaci nese…
{'dictionary'#{"key1""val"}&{"key2""val2"}&{"key3""val3"}&}$nebo{'dictionary'#{'pair'"key1""val1"}&{'pair'"key2""val2"}&{'pair'"key3""val3"}&}$nebo dokonce{'dictionary'
#{'pair'#{'key'"key1"}&{'val'"val1"}&}&
{'pair'#{'key'"key2"}&{'val'"val2"}&}&
{'pair'#{'key'"key3"}&{'val'"val3"}&}&
}$Jenže na rozdíl od XML nemusím takhle plýtvat s přenosovými linkami, pamětí a CPU a můžu to hezky poslat taky takhle'pair'>p'key'>k'val'>v
{'dictionary'
#{p#{k"key1"}&{v"val1"}&}&
{p#{k"key2"}&{v"val2"}&}&
{p#{k"key3"}&{v"val3"}&}&
}$A samozřejmě to nemusím dělat ručně, ale tuhle kompresi za mě udělá stroj. To co v XML musím v UBF můžu. Takže to máme rychlejší parser, úspornější datový tok a větší volnost a flexibilita a specifikace na dvě stránky. Proti tomu XML může tak maximálně postavit spornou čitelnost (asi jak pro koho), specifikaci na desítky stránek, escape sekvence, kdy jeden znak nahradí 4 a více znaků, prakticky nepoužitelné CDATA a pomalý parser. Doufám, že jsem na nic nezapomněl. Ale jo, zapomněl, bambilión pochybných rozšíření, které se předhánějí v tom, které bude mít složitější, delší a hůře čitelnou specifikaci, které se pokoušejí o nemožné, odstranit na co se při specifikaci XML zapomnělo nebo znovu vynalézt kolo.
{'dictionary'
#{'pair'#{'key'"key1"}&{'val'"val1"}&}&
{'pair'#{'key'"key2"}&{'val'"val2"}&}&
{'pair'#{'key'"key3"}&{'val'"val3"}&}&
}$To už by na XML snad šlo převést nahrazováním podle regulárního výrazu, ne? A ještě tam chybí jmenné prostory – rozšiřitelnost s jediným globálním názvovým prostorem nejde moc dohromady.
Jenže na rozdíl od XML nemusím takhle plýtvat s přenosovými linkami, pamětí a CPU a můžu to hezky poslat taky takhle…No, a co teprve to zkomprimovat třeba zipem. To by byla panečku úspora! Akorát ta zkrácená UBF notace má jednu obrovskou nevýhodu – používají se tam lomené závorky. Tak nic, to bude taky formát k ničemu…
Nejde, vy jste odborník na slovo vzatý. To ví i malé dítě z mateřské školky obor formální jazyky, že tohle je mimo definiční obor regulárního výrazu. To by zvládly tak maximálně regulární výrazy v perlu, ale to jsou spíš "regulární" výrazy.To už by na XML snad šlo převést nahrazováním podle regulárního výrazu, ne?{'dictionary' #{'pair'#{'key'"key1"}&{'val'"val1"}&}& {'pair'#{'key'"key2"}&{'val'"val2"}&}& {'pair'#{'key'"key3"}&{'val'"val3"}&}& }$
A ještě tam chybí jmenné prostory – rozšiřitelnost s jediným globálním názvovým prostorem nejde moc dohromady.A co jsou vlastně ty jmenné prostory v XML? Není to náhodou taková ta věc, že když se v názvu tagu nebo atributu vyskytuje speciální znak ':', tak má speciální význam oddělovače jmenného prostoru od jména. Hmm, a to v UBF nejde? Prostě 'a:b' se nerovná 'b'. Jak se to prakticky liší od jmenných prostorů? Jak se to, ne formální definicí, ale skutečnými praktickými dopady, liší? LOL, jmenné prostory, to je fakt hyper feature na kterou jen tak někdo nemá. Co mi ubozí si bez jmenných prostorů počneme. Nemáme formálně definované jmenné prostory, tagovat můžeme libovolným atomem. Atom může obsahovat libovolné znaky. Ó my nebozí chudáci, bez jmenných prostorů jsme ztraceni. Ehm.
Chabý pokus o vtip. Pokud vím, tak proti lomeným závorkám jsem nenapsal ani jediné slovo. Můžete mě prosím citovat, aby jste mi oživil paměť.Jenže na rozdíl od XML nemusím takhle plýtvat s přenosovými linkami, pamětí a CPU a můžu to hezky poslat taky takhle…No, a co teprve to zkomprimovat třeba zipem. To by byla panečku úspora! Akorát ta zkrácená UBF notace má jednu obrovskou nevýhodu – používají se tam lomené závorky. Tak nic, to bude taky formát k ničemu…
A co jsou vlastně ty jmenné prostory v XML? Není to náhodou taková ta věc, že když se v názvu tagu nebo atributu vyskytuje speciální znak ':', tak má speciální význam oddělovače jmenného prostoru od jména.Ne, není. Pletete si zkratku jmenného prostoru a jmenný prostor.
Hmm, a to v UBF nejde? Prostě 'a:b' se nerovná 'b'.Ale jde to, ale pak už neříkejte nic o tom, jak je XML ukecané:
{'com.example.service.document:dictionary'
#{'com.example.service.document:pair'#{'com.example.service.document:key'"key1"}&{'com.example.service.document:val'"val1"}&}&
{'com.example.service.document:pair'#{'com.example.service.document:key'"key2"}&{'com.example.service.document:val'"val2"}&}&
{'com.example.service.document:pair'#{'com.example.service.document:key'"key3"}&{'com.example.service.document:val'"val3"}&}&
}$
Chabý pokus o vtip. Pokud vím, tak proti lomeným závorkám jsem nenapsal ani jediné slovo. Můžete mě prosím citovat, aby jste mi oživil paměť.Proti lomeným závorkám přímo jste nic nenapsal. Ale napsal jste dva ekvivalentní zápisy, jediný rozdíl je v tom, že jeden používá lomené závorky a druhý ne. Ale ten první je podle vás beznadějně špatný.
'com.example.service.document'>c'pair'>p'key'>k'val'>v
{c'dictionary'
#{cp#{ck"key1"}&{cv"val1"}&}&
{cp#{ck"key2"}&{cv"val2"}&}&
{cp#{ck"key3"}&{cv"val3"}&}&
}$
... Ale napsal jste dva ekvivalentní zápisy, jediný rozdíl je v tom, že jeden používá lomené závorky a druhý ne. Ale ten první je podle vás beznadějně špatný.Ekvivalentní? Máte velmi svérázný výklad slova ekvivalentní. Už jen propastný rozdíl výkonu parseru ukazuje, že to co je sémanticky ekvivalentní není až tak úplně ekvivalentní. Už jen to, že každý uzel může mít atributy i obsah a tyto dvě věci jsou sémanticky neslučitelné a nezaměnitelné, parser XML komplikuje do té míry, že obecný parser XML je řádově pomalejší než obecný UBF parser.
15.7.2008 14:11
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
To transmit a "person" we might send: {'person'"Jane"18}$Opravdu? Ja vidim konstrukt, kde je slovo person a pak jeden retezcovy a jeden ciselny udaj. Co to je 18? To je vek nebo vyska nebo IQ? A Jane? To je prijmeni?... Tohle ani nahodou neni To transmit a "person". Ale mozna uz jste tohle rozebirali nize, priznam se, ze se mi nechce celou tu diskusi louskat do posledniho slova. A opravdu mi chcete po tech vsech vasich ukazkach tady tvrdit, ze UBF je pro rucni praci pro bezneho smrtelnika citelnejsi a prijemnejsi na praci?
Nevim jak vy, ale ja masochista nejsem.
15.7.2008 14:46
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
{'person'#
{'name', "Jane"}&
{'age', 18}&
}$Jenže na rozdíl od XML můžete, ale nemusíte. A k tomu se vám přidá tzv. caching, který se na větších datových objemech sakrametsky projeví. Proč uzly stromové struktury pro uložení v univerzálním datovém formátu musejí mít takovou podivnou sémantiku jak jsem popsal v jiném příspěvku. To je oč tu běží. XML je univerzální, ale za jakou cenu? Za cenu jen základní specifikace na 50+ stran. I ve vyšších jazycích je parser plně odpovídající specifikaci na několik tisíc řádek kódu. Výsledek je zbytečně pomalý, plýtvá přenosovým pásmem, pamětí i výkonem CPU a o lidské čitelnosti se dá s úspěchem pochybovat. Escape schema, které vypadá jako by ho navrhovalo malé dítě a binární podpora, která neumožňuje uložit libovolnou binárku. To je výsměch a ne univerzální formát. UBF zdaleka není žádný vybroušený diamant, ale i tak je kvalitativně tak daleko vepředu, že mu XML už ani nevidí záda.
15.7.2008 16:24
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
person.
o lidské čitelnosti se dá s úspěchem pochybovatTo je subjektivni. XML se mi libi mnohem vic, nez ta vase zmet znaku
UBF zdaleka není žádný vybroušený diamant, ale i tak je kvalitativně tak daleko vepředu, že mu XML už ani nevidí záda.Az na tu podporu v jazycich a nastrojich, ze...
Ta vase ukazka trpi stejnou nemoci jako JSON -- pri velke datove strukture kdyz v editoru sjedu dolu, tak nevim, ze to, co nahore zacinalo, je person...Hmm, já mám ve vimu %. Zasvinit si kvůli tomu datový formát, no já nevím. Při nejhorším si tam udělám komentář, ne?
{'person'#
{'name', "Jane"}&
{'age', 18}&
}%person%$
15.7.2008 18:47
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Při nejhorším si tam udělám komentář, ne?A je z toho jeste vetsi bordel nez predtim
Predstavte si timhle zapisem (+ namespaces) nejaky slozitejsi ODF dokument. Nechal bych vas ho editovat za trest. Zlata rucni editace XML!
Protože jsem to na závěr taky zhodnotil tak, že původně očekávané pohodlí a rychlost práce s kancelářským balíkem se nějak nekonaly, a sice jsem se vyhnul patlání se stylama pro LaTeX, ale vysvětlovat kancelářskému balíku, že číslovat nadpisy nebo odkazy na literaturu bude dělat jak chci já chci je čas stejně neproduktivní – jediný rozdíl je v tom, že u (La)TeXu se dá odhadnout horní hranice času, jak dlouho mi to bude trvat, u kancelářských balíků je možné podobné problémy řešit třeba donekonečna. Jenže tohle byla zrovna moje práce, ale třeba kamarádku bych asi těžko přesvědčoval, že se má vykašlat na Word a radši to napsat v TeXu Bohužel první jsem upravoval tu práci ve Wordu (který dělal vylomeniny podobného rázu), a bláhově jsem doufal, že OOo už takovéhle hlouposti s textem dělat nebude – a v koutku mi probliklo i to, že přinejhorším to v XML půjde opravit .
Ale jsem v tom nepoučitelnej – a to jsem dva roky dělal ve Wordu školní časopis. Když mne vždycky jednou za čas popadne takovej nápad, že za ty desítky let, co už se dělají (WYSIWYG) textové procesory, snad už musel někdo napsat takový procesor, který nebude na hranicích mezi dvěma písmeny nebo slovy občas zapomínat formátovací značky. Nejdál v tom byl asi windowsovský WordPerfect, který aspoň uměl ty značky zobrazit a šly pak vymazat ručně. Jinak je zdá se WYSIWYG editace formátovaných dokumentů stále ještě nevyřešený problém
15.7.2008 21:00
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Michat synatxi UBF jeste se syntaxi sablonovaciho jazyka, ktery by se o generovani staral, to by byla opravdu chutovka
22.7.2008 00:04
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Vzhledem ke zprávičce pod kterou tu diskutujeme, si zjevně myslí i v Google, že XML není zrovna moc praktický datový formát, že?Demagogie. Po zverejneni te zpravy lide z Googlu nekolikrat zopakovali, ze proti XML jako takovemu obecne nic nemaji. Slo o konkretni aplikaci.
15min a 0.5s? To bych skoro rekl, ze v prvnim pripade slo o PEBKACSamozřejmě, ten blbec mezi klávesnicí a ždlí si myslel, že na to jde použít XSLT. Naštěstí jsem prosadil, aby se na to XSLT nepoužívalo a bylo po problému. Pěkná ukázka praktické použitelnosti XML.
Já jsem jasně napsal slovo praktický. Co je to za praktický datový formát, když se pro konkrétní aplikaci z praxe nedá použít. To je spíš nepraktický formát. Vzhledem, k tomu, že pro Google není XML praktický pro datové přenosy, tak je naprosto korektní napast, že XML není zrovna moc praktický. To je samozřejmě demagogické, upozornit na to, že datový formát pro datové přenosy, není příliš prakticky použitelný pro datové přenosy. Děkuji za nálepku damagoga. V tomto případě hodlám býti demagogem.Vzhledem ke zprávičce pod kterou tu diskutujeme, si zjevně myslí i v Google, že XML není zrovna moc praktický datový formát, že?Demagogie. Po zverejneni te zpravy lide z Googlu nekolikrat zopakovali, ze proti XML jako takovemu obecne nic nemaji. Slo o konkretni aplikaci.
22.7.2008 14:51
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Vzhledem, k tomu, že pro Google není XML praktický pro datové přenosy, tak je naprosto korektní napast, že XML není zrovna moc praktický.
Vy teda valite... takze cokoliv neni prakticke pro datove prenosy, tak vlastne neni moc prakticke? Rekneme, ze na datove prenosy u AJAXu treba pouzivam JSON a na serveru na par veci mi velice vyhovuje XML & XSLT. A z toho tedy vyplyva, ze XML není zrovna moc praktický...?
Extensible Markup Language (XML) Introduction Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. ...Hmm. Simple? Specifikace v1.0 - 199kB, v1.1 - 220kB a to jsou jen úplně základní specifikace formátu, žádné romány. Very flexible? Někde až moc a někde žalostně málo. Například uložení binárky je dobrej vtip, pak fixní podoba nodu s podivnou sémantikou, omezená množina znaků tagu, atributu ... Fakt flexibilita jak noha. Brainfuck je taky flexibilní programovací jazyk, je turingovsky úplný. Asi jako je XML flexibilní datový formát
Ale prakticky?
"designed to meet the challenges of large-scale electronic publishing"? tak nějak v tom cítím, že se má nějaká informace I dostat od subjektu A k subjektům B, C, ... To mi zní jako datový přenos.
"increasingly important role in the exchange of a wide variety of data on the Web and elsewhere" Ha! Vida ho! Zase už přenášejí data. Takže autorita nejpovolanější tvrdí, že XML je určen k přenášení dat. Jenže právě při praktickém přenosu dat s ním mají lidé a firmy (např. Google) největší problémy, takže co s tím uděláme? Zavřeme oči a budeme se modlit
To není špatná aplikace XML, dokonce bych řekl, že svůj účel plní výborně. A skutečně, kladivem se hřebíky zatloukají dobře. Ale ty přenosy dat v normálním slova smyslu (SMTP, NFS, RPC...) tam už nikde nevidím.
Já si pod pojmem "electronic publishing" představuju něco jako DocBook.SOAP? XMLRPC?
22.7.2008 19:05
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
9.7.2008 15:16
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Protobufs do show one lesson learned from experience: they mirror XML's must-ignore semantics. It is possible to put extra fields in a protobuf and not break every downstream consumer that doesn't know about those fields. That's a rare quality in a binary format.
10.7.2008 08:35
Quimby | skóre: 6
| blog: Quimby
| Havířov / Praha
10.7.2008 09:03
zoul | skóre: 43
| blog: ☂
| Boskovice
<osoba>
<jméno>…</jméno>
…
</osoba>
A může použít Protocol Buffers. Ty fungujou tak, že v nějakém samostatném souboru
popíšeš datové typy, které chceš posílat, třeba takhle:
message Osoba {
required string jméno = …
…
}
Pak spustíš program z balíku Protocol Buffers, který pro danou definici vytvoří kód
v Tvém programovacím jazyce (momentálně alespoň Java/Python/C++). A jako programátor
už pak můžeš říct jen něco jako:
chci nový objekt typu Osoba nastavit jméno nastavit věk serializovat…a dostaneš serializovanou podobu toho objektu, čili nějakou posloupnost bajtů, která se dá poslat po drátu a na druhé straně z ní můžeš analogickým postupem (opět s pomocí Protocol Buffers) rekonstruovat původní objekt.
10.7.2008 15:26
Quimby | skóre: 6
| blog: Quimby
| Havířov / Praha