Fúúj XML konfig?

Gyakran felmerülő téma errefelé, hogy mekkora idióta formátum az XML és le kéne lőni, aki kitalálta, meg milyen dolog már konfigurációra használni, mennyivel jobb a [insert random formátum, amit egész pontosan egy darab alkalmazás (amit konfigurál) kezel és egyébként lehet nekiesni és stringként kezelni]

Mai feladat: opnsense konfigból kikukázni a static DHCP mappingeket, az alapján eldönteni, hogy melyik MAC címnek melyik VLAN-ban a helye és ebből egy CSV-t generálni. Az opnsense egy központi XML fájlban tárolja minden konfigját, a DHCP static lease-ket speciel így: 


<staticmap>
<mac>00:11:22:33:44:55</mac>
<ipaddr>10.0.23.4</ipaddr>
<hostname>itappmonrobot</hostname>
</staticmap>

Ebből kéne nekem ilyen: 


00:00:22:33:44:55,tesztvlan

XML feldolgozásra természetesen az awk és a sed a legjobb, úgyhogy álljunk neki regexpet í... haha, nem xmlstarlet. Szerencsére minden VLAN-hoz egy /24 tartozik, így az IP -> Subnet -> VLAN név megfeleltetés nem nehéz, elég az elejét nézni az IP-nek.

xmlstarlet sel -t -m '//dhcpd/*/staticmap' -v 'mac' -o ',' \
--if 'ipaddr[starts-with(text(), "10.0.23.")]' -o 'tesztvlan' \
--elif 'ipaddr[starts-with(text(), "10.0.24.")]' -o 'masikvlan' \
-b -n config.xml

( Nyosigomboc v | 2018. 06. 28., cs – 17:37 )

Nekem nincs bajom az xml-lel. Direkt gepi feldolgozasra van.

--
If you get a good wife, you'll become happy; if you get a bad one, you'll become a philosopher. -Socrates

FYI: a Java tanfolyamos topicban irta valaki, hogy mennyire felesleges szerinte a formalis nyelvek.
Ezek szerint megsem, ha valaki egy kornyezetfuggetlen nyelvre (XML, Chomsky 2.) egy regularis nyelvek elemzesere (Chomsky 3.) tervezett eszkozt akar bevetni.

(ettol fuggetlenul csinaltam mar ilyet, egy RSS feedbol kellett kinyernem valamit PHP-ban, es nem akarta feltenni a gep gazdaja a szukseges libet - ugy 2 sor volt kb., igy tobb lett)

--
If you get a good wife, you'll become happy; if you get a bad one, you'll become a philosopher. -Socrates

Nem állítottam egy szóval se, hogy jó ötlet regexszel nekimenni egy xml dokumentumnak. Viszont tudtommal a szubrutinok és a rekurzió lehetőséget ad rá. Nem tudom, hogy ezek a feature-ök beleférnek-e még a formális nyelvek reguláris nyelv definíciójába, én azt gyanítom, hogy nem.

https://en.wikipedia.org/wiki/Regular_expression#Patterns_for_non-regul…

"FYI: a Java tanfolyamos topicban irta valaki, hogy mennyire felesleges szerinte a formalis nyelvek."
Erre csak azt tudom mondani, hogy LOL. Az automataelmélet, legalább azon a szinten, hogy tudja az ember, mi az az állapotgép, mi az a nyelvtan, hogy miként kell leírni egy nyelvet (ami akár lehet egy bináris fileformátum is, vagy egy hálózati protokoll) egy nagyon fontos dolog, sokkal fontosabb egy informatikusnak, mint például a valós analízis.

Szerintem is fontos. A veges allapotu automatak nem veletlenul jottek elo egy csomo teruleten (pl. digit, fony, programozas, pt, meg meg ki tudja).
A regexp megint nagyon hasznos.

--
If you get a good wife, you'll become happy; if you get a bad one, you'll become a philosopher. -Socrates

Ennél jobb a frisseb blogbejegyzés Uncle Bobtól, az Integers and Estimates.
"The founding documents of computer science are documents that prove that there is no finite mechanism for deciding if a program can even be written. The founding of computer science was based on the proof that estimates were not guaranteed."

Nem igazán, mert a regexek által leírt nyelvi osztály még így sem lesz contrext-free language, a bővített regex nem CFG, csak nested-word language lesz, de az baromira nem ugyanaz a nyelvi osztály.
https://en.wikipedia.org/wiki/Regular_grammar
https://en.wikipedia.org/wiki/Nested_word
https://en.wikipedia.org/wiki/Context-free_grammar

Ha kicsi/egyszeru, akkor teljesen mindegy, hogy XML, INI, vagy valami sajat elborult formatumrol van szo.
Ha nagy/bonyolult, akkor kezzel igy is ugy is szivsz, ha meg xml, akkor van ezerfele szabvanyos tool, amivel maceralhatod, B tervkent meg irhatsz egyet. Ha sok eszkozod van, akkor megint jobban jarsz azzal, ha valami automata konfiguralorendszer osszerakja neked, mint ha kezzel csinalnad. Vagy ha minden szukseges program sajat formatumara irnal egyet-egyet. Programozas oldalarol meg ha sajat formatumod van, akkor a parsert is irhatod meg magad, XML/YAML/INI eseten meg behuzol egy libet, es keszen is vagy.

A YAML meg pont, hogy emberi szemre - es gepre - optimalizalt formatum. Bar toolok szamaban az XML veri.

Egyebkent meg az INI sem volt rossz, de nagyon korlatozott a 2 szint miatt. Ebben a YAML es az XML is jobb.

--
If you get a good wife, you'll become happy; if you get a bad one, you'll become a philosopher. -Socrates

Az xml-hez vannak tool-ok, persze, de attólmég nagy méretben marhára nem lesz egyszerűen átlátható, ha rondán van összelapátolva - és egy mindenütt rendelkezésre álló szimpla vi(m) nem biztos, hogy tökéletes eszköz lesz a matatásához - bár ami igay, az igaz, ha alaposan ismered a szerkezetét, akkor azért kényelmesen nyiszatolható/matatható nagyobb léptékben is. A legdurvább ilyen esetem egyébként egy kb. 800k-s xml-ből való takarítás volt (a hozzá való alkalmazás bizonyos formátumú paramétereket felvenni tudott, de törölni már nem...) - horrorisztikusnak tűnt elsőre, de sikeres volt :-)

A yaml más tészta: amikor éjjel kettőkor jojózik a szemed, hogy honnana rohadt anyjából maradt ki egy space, mikor a kollégád szerkesztette a yaml fájlt, akkor azért nem hinném, hogy "emberi szemre optimalizált"-nak lehet tekinteni.

Ha az ini formátum két szintje nem elég, akkor -bár jóval többet kell gépelni- de simán lehet properties jellegű konfigot használni - az mégiscsak olvashatóbb, egyből látszik, hogy mi hatvan (foo.bar.baz=60), nem kell azzal copni, hogy mi van kintebb meg bentebb...

Jo, a yaml-hoz gondolom esszel kell hozzanyulni pont emiatt. Ahogy mondjuk python kodhoz is. Vagy a 800k-s configodhoz is. Igazabol nem tudom mennyit segitett volna, ha a 800k-s XML helyett egy 800k-s apache2.conf-ot kapsz.

A vi(m) nagyon sok dologra nem tokeletes eszkoz. Tobbszori probalkozas utan rajottem, hogy ez meg a szovegszerkesztesre is igaz, pedig pont arra szantak. Az XML matatasra tervezett toolok listajara sem tennem fel, pedig biztos van ra valami plugin. (A vi-ra mondjuk igaz, hogy mindenhol van.)

Az ini-t meg sokfelekepp meg lehet eroszakolni.
Pl:
[MAIN]
child1=bizbasz
child2=akarmi

[bizbasz]
...

[akarmi]
...

Sot, a Glib-fele implementacio nestinget is tud!

--
If you get a good wife, you'll become happy; if you get a bad one, you'll become a philosopher. -Socrates

( tomsolo | 2018. 06. 28., cs – 19:10 )

A múltkor láttam olyat, hogy xml config amiből a végén lett egy paraméteres config.js :D

No rainbow, no sugar

( lovagX | 2018. 06. 28., cs – 21:45 )

xsltproc rakd fel

itt az xsl hozza, majd valaki javitsa meg, en feladtam. 


<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text" encoding="UTF-8"/>
<xsl:template match="staticmap">
<xsl:value-of select="mac"/>,tesztvlan<xsl:text>&#xa;</xsl:text>
</xsl:template>
</xsl:stylesheet>

masik megoldas. ha van keznel php, akkor irhatsz abban is scriptet es simplexml-el feldolgozhatod.

Azt hiszem, ez valami ilyesmi akarhatott lenni. ;)

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="text" />
  <xsl:strip-space elements="*" />
  <xsl:template match="//dhcpd/*/staticmap">
    <xsl:value-of select="mac" />
    <xsl:text>,</xsl:text>
    <xsl:choose>
      <xsl:when test="starts-with(ipaddr, '10.0.23.')">tesztvlan</xsl:when>
      <xsl:when test="starts-with(ipaddr, '10.0.24.')">masikvlan</xsl:when>
      <xsl:otherwise>ISMERETLEN</xsl:otherwise>
    </xsl:choose>
    <xsl:text>&#xa;</xsl:text>
  </xsl:template>
</xsl:stylesheet>

Az XSLT külön világ megfelelően perverzeknek, de ha kap egy kis "szeretetet", csodákra képes. :) Ez kb. az, mint amit a xmlstarlet kapott argumentumokként, de azért jelentősen könnyebben olvasható és bővíthető (számomra mindenképpen).

Futtatás: xsltproc stylesheet.xslt config.xml

Jaja, AFAIK belül az xmlstarlet is XSLT-vel dolgozik. (az xsltproc-nak utánanézek, a -html kapcsoló biztató...)

megfelelően perverzeknek

+1. Natívan azóta kerülöm, hogy még egyetemen kipróbáltam, mennyire működőképes, hogy egy tartalomkezelő csak egy XML doksit állít elő, amit még a kliensnek visszaküldés előtt aztán átküld egy xslt sablonon, hogy a böngésző már valami HTML-szerű izét kapjon. Feltehetően nagyon nem értettem az xslt-hez, de mire végeztem azzal a beadandóval, kikapartam a szemem. :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Na igen: nem igazán szokták szeretni a hallgatók (próbáltam már néhány csoportot bevezetni a szépségeibe), de szerintem ez amiatt is van, mert sokszor nincs elég idő a normális elmagyarázására, vagy a magyarázó sem érti igazán annyira, hogy érthető legyen a hallgatóságnak. :) Mondjuk az is érthető, hogy ha valaki csak imperatív / OO nyelveket ismer (meg esetleg markupot), annak elsőre kissé megfekszi a gyomrát a "kitekert" logika.

Egyébként a böngészők (legalábbis egy részük) simán megeszik úgy is az általad említett összeállítást, hogy leküldöd neki az xml-t, illetve egy <?xml-stylesheet?> feldolgozási utasításban behivatkozva az xslt-t, és ő szépen letolja a transzformációkat (tehát nem szükséges a szervert "terhelni" a feldolgozással). Nyilván egy ilyen megoldás hordozhatóságát erősen korlátozza az ilyesmit "értő" böngészők halmaza (illetve a kliens felől rendelkezésre álló teljesítmény), úgyhogy talán inkább tech. demónak jó, mint éles megoldásnak. :)

Nálunk nem volt téma az XSLT (kb. egy-két órán az "egyébként létezik az XML" slide-on az összes többi XML-körüli technológia mellett bullet pointként szerepelt), ezért gondoltam kipróbálni egy beadandó keretében, ahol nem ez volt a lényeg (adatbázisok kurzus).

(azért ez már jó rég volt, az biztos, hogy egy-két dolgot még néztem ki az MSN Messenger (!!!) logjainak az implementációjából - az egy az egyben azt csinálta, amit írsz, szép nagy XML fájl [asszem 20 megát elérve kezdett újat], mellé egy XSLT)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"mennyire működőképes, hogy egy tartalomkezelő csak egy XML doksit állít elő, amit még a kliensnek visszaküldés előtt aztán átküld egy xslt sablonon, hogy a böngésző már valami HTML-szerű izét kapjon."
Ismerek (magyar viszonylatban) nagy cégeket, akiknek így működik a weboldala. Legalábbis a statikus része. Jól auditálható így szerkesztési, tartalomgenerálási és deployment.

Valamint mivel a content meg a content reprezentációja elkülönül, baromi jól lehet betartatni a céges arculatot, nem tudja a jómunkásember egy Wordpressben CKEditorral vagy TinyMCE-vel szétrombolni azt :)

Szóval van ennek előnye, még ha elsőre hülyén is hangzik.

Igazából semmi különbség nincs az XSLT + XML kombóból HTML oldal generálásától, mint az AsciiDoc/Markdown + stylesheet + implicit processing rules kombóból HTML oldal generálásától, csak az előbbinek kb. minden értelmezhető platformra van jó szoftvertámogatása. Régen még a böngészők is támogatták az XSLT-t, így aztán megetethetted olyan XML-lel, ami tartalmazta a hivatkozást az XSLT-re és szép weboldalt kaptál belőle, de sajnos ez kiveszőben van, úgy tudom, nem támogatják.

( enpassant v | 2018. 06. 29., p – 09:37 )

Az XML konfig nagyon jó, ha abból további adatot is ki akarunk nyerni, mint a fenti esetben.
Ilyen esetekre jó az a megoldás is, ha megfordítjuk a folyamatot és a közös adatokat adjuk meg egy helyen és abból generálunk (na oda teljesen jó a regexp a sima keres és cserére) különböző konfigokat.

Emberi fogyasztásra én jobbnak tartom a json alapú formátumokat, még az lehet egy opció.

Ritkán ismert és még ritkábban alkalmazott megoldás konfigra, hogy valamely programozási nyelven írjuk meg a konfigot. A konfig belefordulhat eleve az alkalmazásba (ha mi szállítjuk konkrét helyekre az alkalmazást), vagy lefordítjuk és binárisként, mint egy modul tesszük (vagy teszi a végfelhasználó) az alkalmazás mellé.
Ez utóbbi konfig általános konfigra nem jó, de sok esetben ez a legjobb megoldás.
Bővebben erről itt olvashatsz. Scala a cikkben szereplő nyelv, de természetesen tetszőleges nyelvre alkalmazható.

--
Ickenham template engine

"A konfig belefordulhat eleve az alkalmazásba" - Jürgen Morgen NDK-s vasúti váltókezelő örökbecsű mondata jut eszembe erről, amikor mindkét lábát tőből levágta a berlini gyors... (Igen, "Hát"-tal kezdődik, és "kéne" a vége)
A paraméterezés azért van, hogy lehessen állítgatni. Ami a binárisban benne van, az nem paraméter, az konstans.

Viszont a binárist cserélgetetheted az alkalmazás mellett. Gondolj rá úgy, mintha lenne egy app ELF állományod, meg egy config.so. És az app betölti a config.so-t.Vagy épp van egy app.jar meg egy config.jar. Vagy app.exe és config.dll.
A config.jar/config.so/config.dll cserélhető. Cserébe nem XML-t, init, YAML-t stb. írogatsz, hanem típusos kódot, így nem fordulhat elő, hogy ahol egy URI kell, ott egy lebegőpontos szám van. Vagy ahol egy file elérési útvonal kell, ott egy IP cím van.

Amúgy a típusos konfigot az XML és az XML Schema leírja, de lehet előállítani olyan XML file-t, ami nem felel meg a sémának, így a konfig nem tölti be. Ilyen jellegű hiba code-as-configuration esetén nincs, legfeljebb az lehet, hogy a konfiguráció nem valós (pl. a leírt URI-n nem érhető el szolgáltatás, a Path nem írható file-ra mutat, stb.).

Ami a binárisban benne van, az nem paraméter, az konstans.

Igen, a végfelhasználó szempontjából konstans, de a buildelés során el lehet dönteni, hogy most a fejlesztői beállítások, a production beállítások, az XY felhasználó beállításai, ... buildelődjenek be az alkalmazásba. Ez utóbbi esetben már paraméter.
--
Ickenham template engine

Szerintem amúgy zeller arra is gondol, hogy mi legyen a felhasználói beállításokkal? Azt milyen formában tároljuk el?
Tehát mondjuk egy desktop appnál, amit a felhasználó beállíthat, és nem a környezet (PROD, TEST, DEV) függvénye.
Sok alkalmazás szereti erre használni az SQLLite-ot valami ORM-mel, mert 1 db file, mégis típusos, lekérdezhető, strukturált. De erre meg a nyelvfüggő szerializált file-ok is jók lehetnek (pl. Kryo vagy más szerializáló lib által kiadott formátum, vagy más bináris formátum, amiből egyből objektumgráfot lehet deszerializálniÖ, azt akkor kézzel nem lehet szerkeszteni, cserébe para, ha korrumpálódik,mert akkor nem lehet kézzel helyrerakni sem, nem úgy, mint egy init vagy XML-t vagy JSON-t.

A prod. környezetben lehet egy rakat olyan paraméter, amihez a fejlesztőnek semmi köze sincs, ergo nem tud bináris trutymót generálni a beállításokból - prod. környezetben meg illendően nem buildelünk alkalmazást.
A forráskódot és a konfigurációt illendő külön kezelni/menedzselni, meg akár verziózni is.

Nem, nem dev gép meg prod gép, hanem dobozos szoftver, enduser beállítás. Nem olyanról van szó, ahol te kontrollálod a környezetet, hanem leírást adsz, hogy zet és ezt, így és így lehet konfigurálni a szoftveren.
Mint mondjuk amikor készítesz egy Apache httpd-t, vagy egy nginx-et, vagy egy gitlabot, vagy hasonlókat.

Ilyen szoftverek is vannak ám :)

Ilyen szoftverek is vannak ám :)

Ezt senki sem vitatta ám :-)

Ám a Dev/prod gép és a szoftver típusa ortogonális egymásra.

Egy "dobozos szoftvert" (pl. Apache Httpd) is telepíthetsz éles szerverre (production), és telepítheted olyanra, ahol csak teszteled, próbálgatod, netán beállítást készítesz az éles szerverhez (fejlesztői vagy üzemeltetői típusú gép).

Dobozos szoftvereknél ez a módszer általában nem jó, ezért is írtam:
általános konfigra nem jó, de sok esetben ez a legjobb megoldás

Ami példákat írsz, azok pont olyanok, amelyeknél a célközönsége bőven meg tudná ugrani ezen beállítások használatát. Nem azt mondom, hogy kizárólag úgy lehetne beállítani azokat, de, ha lehetne úgy is, akkor szerintem sok üzemeltető használná azt a módszert (pl. a biztonság miatt).

Inkább PhotoShop, Office és hasonlók jobb példák, amelyeknél semmi esélye ezen konfig módszernek.
--
Ickenham template engine

Másik oldalról meg saxus időnként ideblogol, hogy mekkora trágya már a FOSS világ, hogy a konfig fájl szerkesztése után kell egy reload/restart a serviceknek :) Kíváncsi lennék a sommás véleményére a "írd át a forrásfájlt, forgasd le, deployolt a jar-t és indítsd újra a progit" elvről :)

BTW a legbarátságosabb konfig megoldás, amivel eddig találkoztam a SoftEther-é: van egy még véletlen sem standard, típusos szöveges konfig fájlja (példa lenn), egyben mentheted, átviheted másik szerverre, berakod a helyére, start és jó nap (ez az, amit egy nagyon-enterprise-MS-termék-amit-mmc-ből-konfigolsz-oszt-előbb-utóbb-majd-újra-olvassa-a-konfigját-de-nem-kellett-neki-reload vagy tud, vagy nem ;) ), tudod szerkeszteni (sima szöveg fájl), de egy GUI-n keresztül kell "hivatalból" menedzselni. Ha futás közben szerkeszted, előre kikötötten nem definiált működést kapsz [többnyire simán felülcsapja a változtatásaid :)], ha kézzel akarod mókolni, akkor vagy a GUI-n (úgy rémlik be tudsz adni teljes konfig fájlt a futó szervernek) vagy leállítod-szerkeszted-újraindítod. 


        declare IPsec
        {
                bool EtherIP_IPsec false
                string IPsec_Secret vpn
                string L2TP_DefaultHub VPN
                bool L2TP_IPsec false
                bool L2TP_Raw false

                declare EtherIP_IDSettingsList
                {
                }
        }

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Én két fajta beállítást különböztetnék meg:
1. konfiguráció,
2. más fajta beállítás.

A konfiguráció alatt azt értem, hogy jó esetben egyszer beállítjuk és hónapokig, évekig nem nyúlunk hozzájuk, emiatt ezeket elég a programinduláskor felolvasni, és ezek miatt nem is igényelnek kényelmes megadási módot (pl. az adatbázis elérési adatai).

A másik fajta beállítást pedig gyakrabban változtatjuk, emiatt jobb, ha a beállításuk után nem kell újraindítani a programot, illetve jobb, ha a felhasználó kényelmesen megadhatja.

A konfigurációs adatnál nem lényeges a kényelmes megadási lehetőség, sokkal fontosabb a biztonság és a konfigurációs adat helyessége, hogy az ne a program futása közben okozzon váratlan helyeken hibákat. Emiatt is célszerűbb azt egyszer, a program indulásakor ellenőrizni és, ha bármilyen hiba van bennük, akkor jobb, ha a program el sem indul.

A másik fajta beállítást jellemzően a programon belül adjuk meg, így a program azonnal tudja ellenőrizni a helyességét, és ha bármi gond van vele, akkor figyelmezteti a felhasználót, de a program futását nem érinti, mert a régi beállításokkal szépen futhat tovább.

Ha futás közben szerkeszted, előre kikötötten nem definiált működést kapsz

Ennél rosszabb működést nagyon nehezen tudok elképzelni :-)
--
Ickenham template engine

( khiraly | 2018. 06. 29., p – 15:44 )

Mi a kovetkezo lepes? vi regedit.dump.xml ?:)

Get-ChildItem HKCU:\SOFTWARE\$app -recurse | Export-CliXML "\\server\Users\$Profile\out.reg"

Ez a baj, ha elindul valaki a lejton.... Messze meg az alja.. :-\

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( gee v | 2018. 06. 29., p – 17:15 )

Szerintem jó az XML. Nem arra van, hogy ember olvassa, de mivel könnyen értelmezhető, követhető, így az ember számára se lehetetlen.
Sokkal jobban olvasható, mint mondjuk egy ASN.1/BER. Már úgy értem, átlagos humánnak. Számítógépnek mindegy, aki meg ASN.1-el fekszik és kel, az azt is el tudja olvasni.

Ezt az xmlstarlet toolt nem ismertem.

Én biztos xslt irányból közelítettem volna meg a problémát, mert amikor egyszer kb. 15 éve hasonló feladat volt, akkor azt használtam és logikusnak tűnt.
xalan volt a tool, xpath-szal lehetett kiválasztani, hogy melyik node kell, és a style sheet leírta, hogy mit mivé konvertáljon.

Nem tudom, hogy manapság mi a szokás.

( uid_4263 v | 2018. 06. 30., szo – 23:21 )

Szerintem semmi baj nincs az xml-lel. Számomra a fő vonzereje a standard ipari toolok tömkelege (xsd, xpath, xslt), processzorok-feldolgozók mindenfajta környezetben. Ha nem túl nagy, akkor érdemes pretty printelni, kiemelni, szagosítani és még jól is olvasható. Van hozzá egy csomó tool, az IDEA remekül támogatja, stb.

A JSON-t időnként kerülgetem jobbról meg balról, de még mindig úgy érzem hogy míg az xml "typesafe", addig a JSON, legalábbis önmagában nem az, és csak a közösen elmondott ima és egymás biztatgatása a garancia arra, hogy két alkalmazás, ami JSON-ben kommunikál egymással ugyanarról beszélget.*

*erről a témáról várom a lemaradtál, nézd, itt tart a világ típusú felvilágosításokat

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Szerintem semmi baj nincs az xml-lel.

Szerintem sincs, csak eljárt felette az idő. Van amire még mindig használható.

még mindig úgy érzem hogy míg az xml "typesafe", addig a JSON, legalábbis önmagában nem az

Pont fordítva, az xml önmagában semennyire sem "typesafe", csak egy DTD-vel vagy xsd-vel lesz "typesafe", addig egy json önmagában is tud boolean, number, string, object, array típusokat. Json schema-val ez tovább fokozható, de nem tudom, hogy bárki is használja-e komolyabban.

Json-os világban kicsit máshogy megy a kommunikáció, nem az üzenet írja le önmagát, hanem az üzenetnek van egy típusa (mime type) és az írja le, ez így sokkal szabadabb is, mert nem csak json-t küldhetsz, hanem tetszőleges típust. Persze ez alkalmazható xml-nél is, de akkor meg ott is valamelyest feleslegessé válik a schema leírás.

Ha meg megbízható, gyors (kicsi), "typesafe" kommunikációt akarsz, arra meg vannak még jobb formátumok, pl. a protobuff (kryo, avro, thrift) ...

Amire az xml, arra a json is használható, hiszen egy json nagyon egyszerűen xml-lé konvertálható.
--
Ickenham template engine

Na jó, de van szabvány JSON doksik aláírására (XML-Sig), titkosítására (XML-Enc)? Van szabványos query language JSON dokumentumokban keresésre (XPath)? Van szabványos transzformációs nyelv JSON doksikra (XSLT)? Van elfogadott kanonikus forma egy JSON doksira (ami ugye az aláírás/titkosítás szükséges feltétele)? Van...?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Azért ez nem ugyanaz, mint egy XML-Sig... még a linkelt oldalon ki is emelik, hogy igazából bármi lehet a payload-ban ("So actually we might be using any type of data!"), a linkelt RFC-ben a "canoni" string háromszor fordul elő, egyszer "canonical case"-ként (és kis- és nagybetűkről beszél és azt írja, hogy azt csinálsz, amit akarsz :) ), egyszer a StringOrURI kapcsán, hogy nincs kanonikalizálás, egyszer pedig az ASN.1 leírásának a linkjénél a címben... Ráadásul a JWS compact serialization már nem is JSON, hanem néhány JSON (header + signature) meg egy "valami izé" (payload) base64-e összekatolva pontokkal.

A JSONPath van bárhol specifikálva, vagy van egy implementáció, aztán aki JSONPath-ot akar, csinálja meg ugyanazt?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Senki sem mondta, hogy ugyanaz.
Igen, bármi lehet benne, nem csak json. Ettől rosszabb?

Ezt hol olvastad, hogy a "kanonikus forma az aláírás/titkosítás szükséges feltétele"?
Ezek szerint azt állítod, hogy a "JSON Web Signature (RFC7515) szabvány" az nem is igazi aláírás és a "JSON Web Encryption (RFC7516) szabvány" az nem is igazi titkosítás?

A JSONPath az valóban nem szabvány, de specifikálva van, hiszen annak a linkjét adtam meg.
--
Ickenham template engine

"Ezt hol olvastad, hogy a "kanonikus forma az aláírás/titkosítás szükséges feltétele"?"
Amikor digitálisan írok alá, akkor azt akarom mondani, hogy egy adott tartalmat (absztrakt adatstruktúrát) ellátok a digitális kézjegyemmel, hogy ezzel én egyetértek.
De matematikailag egy bitsorozatot írok alá. Rögzített bitsorozatú formátumoknál (pl. ASN.1 CER) egy adatstruktúra szerializálása mindig ugyanazt a bitsorozatot eredményezi.

Viszont ha van nekem egy JSON dokumentumom, ami ugye freeform (mármint bárhol lehet benne plus whitespace, stb.).
Namármost, attól, hogy két JSON dokumentum strukturálisan/tartalmilag ugyanaz, még nem lesz igaz, hogy az egyiknek a digitális aláírása megegyezik a másikéval. És ez gond lehet akkor, amikor ellenőrzöl.

Ugyanez a gond ugye az XML-lel is, de ott létezik kanonikus szerializáció, amely két, strukturálisan megegyező XML-ből ugyanazt a bitsorozatot állítja elő, így a digitális aláírásuk is ugyanaz lesz.

Ha már tényleg adatstruktrát (azaz JSON-t) akarunk aláírni, akkor ne mondjuk azt, hogy "hát ez másik bitsorozat, más az aláírás". Leaky abstraction. Elabsztrahálod az adatreprezentációt egy free-form struktúrába, aztán rámondod, hogy oppábocsi, mégse free-form. Na, ez gáz.

Viszont ha van nekem egy JSON dokumentumom, ami ugye freeform (mármint bárhol lehet benne plus whitespace, stb.).

"There's no such thing as "free-form"/"non-free-form" JSON as every valid JSON-string must be formatted according to the specific rules mentioned on JSON.org."

https://stackoverflow.com/questions/32673997/whats-the-difference-betwe…

Magyarul ami nem úgy van indentálva ahogy a szabvány leírja akkor az nem valid JSON, ugye? Mert a való életben van aki indentál van aki nem, és mindenki validnak tekinti. Ez az elmélet és gyakorlat közti nem elhanyagolható különbség.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Látod, amit mondasz, az egy olyan szabály, amit nem specifikál senki hivatalosan, míg hasonló szabályrendszer létezik az XML-Signature előtt, és ezt hívják kanonikus formának.
És pont azér szabvány, hogy mindenki, mindig ha érvényes XML digiális aláírást akar, ugyanúgy járjon el.
Ez a lényege a szabványoknak, hogy mindenki mindig tudja, hogy mit kell csinálni, és mi mit jelent.
A te általad adott szabály nem szabvány, nem feltétlenül jár úgy el mindenki, amikor JSON aláírást csinál, hogy minifyol, hiszen semmi nem kötelezi rá.
Lehet sok mindent csinálni, a szabványoknak az a lényege, hogy sok-sok ember, egymástól függetlenül is ugyanazt értse. Na, JSON-nál ilyen nincs.

Értem a felvetésed, még esetleg azt is elfogadom, lehet olyan helyzet, ahol erre szükség lehet, de nem igazán tudok elképzelni ilyet, pláne nem találkoztam még ilyennel.
Nekem ez kb. olyan, mintha egy szövegszerkesztővel készült formázott szöveget úgy akarnánk aláírni, hogy akkor is ugyanaz legyen az aláírás, ha MS Office-szal készül és akkor is, ha LibreOffice-szal.
A digitális aláírás azt mondja meg, hogy azt a valamit az tényleg az adott személy (dolog) írta alá. Nem arról szól, hogy ha készítek egy ugyanolyat és az adott személy azt is aláírja, akkor annak az aláírása is ugyanaz lesz-e.

Van egy db adatom és egy darab aláírásom. Ha ellenőrizni akarom, akkor azt az egy adatot ellenőrzöm az adott illető (dolog) publikus kulcsával, nem egy másik, vele tartalmilag egyező valamit.

Azért rákerestem és bár nem szabvány, de erre is van specifikáció json esetében is.
--
Ickenham template engine

Nekem ez kb. olyan, mintha egy szövegszerkesztővel készült formázott szöveget úgy akarnánk aláírni, hogy akkor is ugyanaz legyen az aláírás, ha MS Office-szal készül és akkor is, ha LibreOffice-szal.

AFAIK (lusta vagyok megnézni :) ) egyik xml alapú doksi formátum sem használ embedded aláírást (amikor a doksi tartalmazza az aláírást/aláírás tartalmazza a doksit), hanem detached aláírást használ (a document.xml aláírva egy passz.. signatures.xml fájlban). De technikai akadálya nem lenne egy olyan formátumnak, ahol a zipes marhaságot elfelejtjük és csak egy xml doksi mozog, benne a tartalommal és az aláírással. Sőt, akár csak a doksi egy részét is aláírhatod, teszem azt egy szerződésben a szerződés szövegét/tartalmát, a formátumát (pl. milyen fejléc legyen a papír tetején...) már mindenki úgy alakítja, ahogy akarja - a te aláírásod továbbra is érvényes lesz és csak arra fog vonatkozni, amit aláírtál.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Elvileg megtehető, hogy egy <foo>valami=60</foo> mező mellé odabiggyeszted, hogy <foo_sign>a foo mező elektronikusan aláírva</foo_sign> Abban az esetben, ha egy (nem illedelmes) alkalmazás áttördeli a doksit úgy, hogy sortöréseket, soreleji whitespace-eket rak be/szed ki, akkor a foo_sign mező invalid lesz, hiszen a foo tagek közötti bájtsorozat megváltozott. Ez első blikkre kivédhető lenne azzal, hogy az aláírásnál bizonyos karaktereket nem veszel figyelembe a hash generálásakor (és az ellenőrzéskor is ugyanígy teszel), ezzel viszont kockáztatod a tartalom értelmének az észrevétlen megváltoztatását: nem mindegy, hogy egy szavakból álló listában az szerepel, hogy "Hat ló patak dűlő", vagy "Hatlópatak dűlő".
Illedelmes szoftver természetesen az aláírt részeket nem piszkálja/tördeli át, de nem csak illedelmes programok léteznek :-)

Itt nem illem, hanem szabvány kérdése :) https://www.w3.org/TR/xml-c14n/#Example-WhitespaceInContent

Szerk.: mármint szabvány kérdése, ha a szabvány XML-Sig-et használsz, ahol nem foo_sign lesz, hanem <Signature> és benne a fél világ specifikálva (kanonikalizálás módszere, transzformációk, akár enveloping aláírásnál maga a tartalom is)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"Nekem ez kb. olyan, mintha egy szövegszerkesztővel készült formázott szöveget úgy akarnánk aláírni, hogy akkor is ugyanaz legyen az aláírás, ha MS Office-szal készül és akkor is, ha LibreOffice-szal."

Pedig pont ez a lényeg. Érted, egy szerződést a valóságban sem a formája, hanem a tartalma alapján kell megítélni (lásd: jogrendszer).
Épp ezért fontos, hogy egy adatot, ha digitális aláírás van rajta, valójában nem a formája (szerializációja), hanem a tartalma (struktúrája) alapján kellene megítélni, hogy valid-e.

Tehát ha ugyanazt a szerződést MS Office-ban írom meg, vagy épp Notepad-ben, szimpla txt-ben, majd ezt a két dokumentumot elektronikusan aláírom, akkor ugyanannak kéne lennie az aláírásnak?! Az elektronikus aláírás _nem_ az _értelmezést_ hanem a _tartalmat_ validálja.

Ha a kettőtök közti protokoll szerint a formátum aláírt XML egy megadott séma szerint, akkor igen (az meg már az aláíró szoftver feladata, hogy az aláírásban megadott kanonikalizálási algoritmust végigfuttassa, hogy pl. ne legyen különbség az <Payment sum=1000000 currency="huf" /> és <Payment currency="huf" sum="1000000"></Payment> között).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem ertek egyet.

A legtobb ilyen multiline sztringben benne van a sortores (\n) karakter is, a
kodszerkeszto pedig nem oda teszi a soft wrapjat.
Van ahol szamit.

A workaround ra az ilyen:

{'a': ['ez egy tobb soros1,
'string',
'',
'A help menu pedig:']
}

Vagy json5. De megint ott vagyunk, hogy valaminek az elso verzioja elterjedt,
es nem allnak at a nepek:-\

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

config fajl .json-ban. Es annak szerkesztese random szovegszerkesztovel ssh-n keresztul.

Vagy komolyabb dolgok .json -ban. Pl. egy html snippet.
Valami iszonyat szivas debuggolni, amikor egy sorban van.

Szerintem PITA, de van rengeteg dolog az eletben ami az.

En remenykedem hatha a `` atszivarog a .jsonba, most hogy mar a js megkapta.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem, nem feltétlenül ekvivalens vele valójában, ez az a tag definícójától függ. Lehet, hogy az a tag meg sem engedi a mixed-contented. Hasonlóképpen, vedd figyelembe, hogy az XML-ben lévő mixed-contentre érvényesek az entity resolution és egyéb szabályok (na meg attribute value normalization és társai). Ezért például: 


{
   "a": "&"
}

és 


<a>&</a>

nem ekvivalens.

Jo az a JSON, de a JS-es kapcsolata (JavaScript Object Notation ugye..) es a JS-ben az eros tipusossag hianya miatt nem tudod a serializalt infot kozvetlenul visszaalakitani csak ganyolassal.
Ha van egy ilyenem: <Complex Re="2.71" Im="3.14" />, akkor be tudom tolteni a Complex tipusomba. Ha JSONben van egy ilyenem: {"Re":2.71,"Im":3.14}, akkor nem tudom, hogy ez Complexbe kerul, (lehetne mondjuk kvaternio is). Persze meghackelhetem mondjuk igy: {"type":"Complex","Re":2.71,"Im":3.14}, de azert nem ugyanaz, a formatumban nincs benne. Kotott struktura eseten persze mukodik, de pont a confignal nem artana tudni, hogy mi micsoda. Meg XML-hez tobb tool van.

Osszessegeben a JSON is kap egy like-ot (foleg, ha az ellenoldal mondjuk egy registry bejegyzes lenne).

--
If you get a good wife, you'll become happy; if you get a bad one, you'll become a philosopher. -Socrates

De itt a "Complex" az az elem neve, míg az XML-es példában az elem típusa.
Például: 


<Complex id="a" re="1" im="2"/>
<Complex id="b" re="3" im="4"/>

Ennek a JSON megfelelője: 


{
  "a": {
      "re": 1,
      "im": 2},
  "b": {
      "re": 3,
      "im": 4},
}

Az XML leírja, hogy az a és b idjű elem egy Complex, míg a JSON-nél ez az információ hiányzik.

Az XML-es példában is a Complex az elem neve, nem a típusa, így is hívják: (xml) element name. A típust esetlegesen egy külön fájl mondja meg, amit a json esetén is megmondhatja.
Pl. 


<xs:element name="Complex" type="complexType">

Inkább ilyesmi a json megfelelője: 


{
  "Complex": {
      "_id": "a",
      "_re": 1,
      "_im": 2
  },
  "Complex": {
      "_id": "b",
      "_re": 3,
      "_im": 4
  }
}

--
Ickenham template engine

Az a baj, hogy nincs benne a tipus.
Ahol szamit, az pl. mongodb-ben az objectid. Mindenhol hexaban kapod meg, de amikor jsont importalsz, akkor azert kell egy BSON.ObjectID.createFromHexString.

Vagy a datumok. A datumok jsonban sztringek, pl:
2018-04-23T18:25:43.611Z

Ezt neked kell "tudni", hogy datum, es ugy importalni be.

A szamoknal se egyertelmu:
a) 100
b) 100.0
c) 1.0E+2
d) 1E+2

Az elso integer, a masodik float, akkor mi a negyedik?
innen: https://stackoverflow.com/a/41083343

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem teljesen ugyanarról beszélünk typesafe címén, de én is rosszul fogalmaztam. Igen, kell XSD, ami leírja az elemek sorrendjét, beágyazottságát, nevét, típusát, kötelezőségét, számosságát, esetleg plusz constraint-eket (pl. regex).
Amikor két alkalmazás JSON-ben beszélget, nekem innen a felsorolt megszorítások automatikus ellenőrzése hiányzik, értsd, elírok egy mezőnevet oszt a másik oldalon lesz belőle egy null. Vagy?

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

( bennyh | 2018. 07. 01., v – 07:09 )

Én a Pistike Bt szintű Java asztali programocskáimhoz is XML konfigot használok. Tisztább, szárazabb, biztonságosabb érzés.