Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
A: <element> <cs>Cesky text</cs> <en>Anglicky text</en> <fr>Francouzsky text</fr> </element>nebo
B: <element lang="cs">Cesky text</element> <element lang="en">Anglicky text</element> <element lang="fr">Francouzsky text</element>
<element> <value lang="cz">Český text.</value> <value lang="en">English text.</value> <value lang="fr">Texte français.</value> </element>
Případně variantu D:
<element id="text1">Defaultní text, pokud není v dospozici překlad</element>
a překlady bych měl v externím xliff souboru (o xliff víc napoví google). U většího projektu by tak mohly překlady dělat pomocí profesionálních nástrojů (třeba Qt Linguist nebo komerční produkty).
Pokud bych použil variantu B nebo C, tak bych místo lang použil standardní xml:lang.
Přiznám se, že někdy váhám, jestli ty elementy ještě takhle obalovat (varianta C) nebo ne. Nějaké argumenty pro a proti?
(samozřejmě jsou případy, kdy je to jasné, např. ten obalující element
se tam může vyskytovat víckrát a má nějaké ID nebo jiné vlastnosti/atributy – pak je jasné, že ty elementy s hodnotou takto seskupíme/obalíme a společné atributy uvedeme jen jednou v tom obalu, než abychom je duplikovali ke každé hodnotě)
<program> <název jazyk="cs">Textový editor</název> <název jazyk="en">Text editor</název> <ikona>/usr/share/…/editor.png</ikona> <cesta>/usr/bin/…</cesta> … </program>Příklad 2:
<program> <název> <hodnota jazyk="cs">Textový editor</hodnota> <hodnota jazyk="en">Text editor</hodnota> </název> <ikona>/usr/share/…/editor.png</ikona> <cesta>/usr/bin/…</cesta> … </program>Jazyk je vlastností elementu
název
(je tam víc instancí názvu – pro každý jazyk jedna) a zároveň přeložený text je alternativní hodnotou vlastnosti název
elementu program
(jedna instance pro všechny jazyky).
XML je v tomhle právě lepší – můžeš v něm mít i vícenásobné atributy (jako třeba v LDAPu). Jak si to přemapuješ do objektového modelu je už na tobě – tam z toho nakonec asi nějaký ten seznam/sadu uděláš, ale taky to nemusíš na objekty mapovat vůbec – může se to mapovat na relační databázi nebo to jít do tisku nebo třeba volat nějaký kód na základě SAX událostí. Mapování XML na objekty je fajn, šetří to spoustu práce, ale ne vždy je nutné nebo žádoucí.
xs:integer
, xs:boolean
a mnoho dalších včetně podtypů (např. text o určité délce, rozsahu nebo vyhovující regulárnímu výrazu). Trojstavový boolean uděláš jako nepovinný atribut nebo element typu xs:boolean
.
Pokud to XML má sloužit ke komunikaci1 s někým dalším, tak ano, schéma2 by tam vždy mělo být. Stejně musíš někde zdokumentovat, jak se ty elementy a atributy jmenují, jaká je kardinalita, jaké hodnoty se do nich mají zapisovat… Tak proč to neudělat rovnou ve strojově čitelné podobě?
Jak to děláš u JSONu, když si chceš dohodnout nějaký formát pro výměnu dat?
[1] nebo třeba konfigurák nějakého programu
[2] pokud je někomu zatěžko psát XSD, tak může napsat třeba Relax NG v kompaktní syntaxi, to počítám taky jako schéma
Stejně
Vím, že to existuje, ale ještě jsem to nikoho neviděl používat v praxi. Zato XSD a Relax NG schémata potkávám běžně. (a ne, nemělo by to být selektivní slepotou, protože JSON API vídám – bohužel – celkem často)
Ale nepotřebuju to k tomu, abych rozeznal true od "true", takže mám lepší šanci správně interpretovat data bez schema.
Když jen tak nakoukneš na nějakou ukázku dat, abys měl hrubou představu, tak je to celkem jedno – stejně u toho musíš přemýšlet a vycházet ze svých zkušeností – když např. někde čteš <price/> tak tě napadne, že to uvnitř asi bude cena, jestli to chápeš jako "490"
nebo 490
je v tuhle chvíli jedno.
Když ten formát chceš seriózně používat a vytvářet v něm i vlastní data nebo spolehlivě pracovat s cizími daty, tak stejně potřebuješ kompletní a závaznou dokumentaci k dané verzi formátu. A tam se dozvíš i o atributech a elementech, které v těch ukázkových datech nebyly, zjistíš z toho kardinalitu („aha, tohle tam může být víckrát“) nebo význam hodnot – např. že u některých se nepoužívá znaménko mínus a píší se tam jen nezáporná čísla, protože ten zápor je implicitní (např. uvnitř <sleva/>) nebo jak se zapisují procenta (může to být 0-1
s desetinnými místy ale taky 0-100
). JSON rozlišuje jen tři primitivní datové typy (string, number, boolean), neříkám, že je to úplně na nic, ale je to takové polovičaté – jen zlomek informací, které k práci s nějakým formátem nebo API potřebuješ. Přijde mi lepší mít ten základní formát/syntaxi jednodušší, tohle tam neřešit (čísla a booleany zapisovat do stejných uvozovek jako texty) a pak mít komplexní typový systém ve schématu.
Tím přidělává práci a zesložiťuje programy, tedy minimálně jejich načítací a ukládací části (nemyslím jen XML parser…
Parsery jsou stejně už napsané a taková zátěž to taky není. Ale kde je potřeba maximální efektivita, tam je stejně blbost používat textový formát a bude to binární.
…ale i to, co interpretuje samotná data).
XInclude a entity ti předžvýká parser. A ty už si pak odchytíš jen to, co tě zajímá – určité elementy, atributy a text.
Nebo použiješ mapování mezi XML a objekty – to už je pro tebe jen pár anotací ve třídách a nic víc neřešíš, funguje to samo
<xkucf03/>
json_encode(json_decode(string)) == string
(až na nevýznamné bílé znaky).
Navíc XML ani JSON schema neobsahují žádné sémantické informace a nezvládají složitější validace dat, takže si s tím člověk beztak nevystačí a tak jako tak to skončí u obyčejné dokumentace. I když z té se automatické doplňování nenakrmí, to jo.
V XML Schematu toho uděláš většinu včetně sémantických informací a dokumentace jednotlivých elementů (to ti pak může zobrazovat editor při napovídání podobně jako třeba u Javy zobrazuje JavaDoc). A složité validace můžeš dělat ve Schematronu – tam už ti editor napovídat nemůže, protože to není deklarace očekávaných struktur, ale soubor pravidel, která mají být splněna – dají se jen validovat – takže je dobré kombinovat oboje: co jde, udělat v XSD a ten zbytek ve Schematronu.
S XInclude a dalším zpracováním v parseru, třeba i jen vynecháním komentářů nebo expanze entit, je problém, když chceš dokument načíst, upravit a zas uložit. Jakmile dokument něco takového obsahuje, je velmi těžké až nemožné to při strojové editaci (např. z GUI) zachovat.
To je pravda, je to minimálně hodně kompilované. Ale je potřeba říct, že JSON je v tomhle „lepší“ jen díky tomu, že tuto funkcionalitu nenabízí. Je to asi jako říct: „naše kuchyň je lepší, protože v ní nejsou žádné nože a nemůžeš se pořezat“ – no jo, jenže nemůžu ani krájet. S XML můžeš dosáhnout téhož výsledku, pokud se sám omezíš a nebudeš ty XIncludy používat (případně se smíříš se změněným výstupem nebo napíšeš poměrně složitý program), ale JSON tě takto omezuje nevyhnutelně, nemůžeš si vybrat, zda ano nebo ne, prostě tam ta funkcionalita chybí.
"include" : "/cesta/k/souboru"
a někdo třeba "require" : "file:///cesta/k/souboru"
xml:lang
Variantu A bych použil asi leda v případě, že by jazyky byly pevně dané – tzn. měl bys tam třeba místní název a pak anglický název podle nějakého ISO standardu (např. názvy zemí).
Ve většině případů bych použil variantu B. Jednak nemusíš měnit schéma, když ti přibude nový jazyk. A jednak jsou to generické struktury a můžeš je zpracovávat jednotným způsobem – např. projdeš v cyklu1 všechny elementy element a jazyk je jen jejich atributem.
V případě A bys musel mít v programu/šabloně vyjmenované všechny jazyky (názvy elementů) a ty zpracovat v cyklu. Nebo bys mohl zpracovat v cyklu všechny (*) elementy uvnitř element
bez ohledu na název těch elementů (název bys interpretoval jako hodnotu – jazyk), což taky jde, akorát to má nevýhodu, kdybys tam chtěl vnořit na stejnou úroveň ještě jiné elementy, které nejsou jazykem, ale obsahují třeba nějaké společné informace – tak je nemáš jak odlišit od elementů obsahujících jazykové verze – leda šoupnout do jiného jmenného prostoru.
Nakonec se dá použít oboje. Akorát v případě B můžeš mít i volnější schéma – povolíš element element
a atribut lang
, ale už nebudeš omezovat jeho hodnoty. V případě A bys to mohl taky udělat takto volné (povolit libovolné elementy uvnitř element
) ale pak už bys ve schématu nemohl definovat vnitřní strukturu těchto libovolných elementů – což v případě B můžeš, např. to bude nějaký značkovací jazyk nebo prostý text vyhovující nějakému regulárnímu výrazu atd. No vlastně ve Schematronu by asi i tohle šlo Ale fakt bych spíš doporučoval to B.
[1] nebo na ně aplikuješ XSLT šablonu
<element cs="Cesky text" en="Anglicky text" fr="Francouzsky text"/>
Zejména když část položek bude překládaných a část společných, že?
Když už to roztahat po víc souborech, tak aspoň použít gettext – k tomu existuje řada nástrojů, které pomohou překladatelům.
To bych ale dělal jen když tam toho překládání bude hodně a bude potřeba ho různě aktualizovat, přidávat překlady atd. – pokud je to pár položek, tak bych to nechal v jednom XML.
Proč ne? Prostě si jen ty části (elementy) označíš příznakem[což nemusí být jen jazyk, můžeš mít i různé další pohledy na ta data – třeba stručnou a plnou verzi] a pak si vyfiltruješ (třeba XSL šablonou to jde hezky) ty společné části + části s daným příznakem a vytáhneš si z toho třeba českou stručnou verzi.
Tady bych doporučil použít ten obalový element kolem těch alternativních verzí/hodnot – pak se dá líp uhlídat, abys měl všude potřebné varianty (všechny jazyky) nebo měl aspoň jednu jako výchozí (např. když chybí český překlad, vypíše se aspoň anglický text + nějaké varování, že tohle ještě není přeloženo).
Ve chvíli, kdy to je v jazykově rozdělené části, tak už tam mám tu vnořenou skoro-společnou fyzicky několikrát
Tak jsi to asi jazykově rozdělil na příliš vysoké úrovni, je to potřeba dělit opravdu až tam, kde se liší ty texty. Ale dovedu si představit i případ, kdy to nepůjde: některé kapitoly budeš mít jen v některých jazykových verzích, pak to musíš jazykově rozdělit výš, ale zase někde uvnitř budou společné části – to bych pak řešil buď tím XIncludem nebo odkazem na ID v jiné části dokumentu (a tam opět můžou být některé části označené příznakem pro určitý jazyk).
Tiskni Sdílej: