Archívum - Szep 20, 2016 - Fórum téma
Weboldal XML-ben
Egy másik fórum témában felmerült, hogy a HTML + meta markup helyett XML-t és XSL-t kellene használni arra, hogy a weboldalainkat kiszolgáljuk. Erre példa Hídvégi Gábor kolléga saját oldala.
Az alapján, ami abból a threadből kiderült, ennek a megközelítésnek a következő előnyei vannak:
1. Minden adatot csak egyszer tárolunk el, nem duplikáljuk.
2. Nem alkalmazunk szerver oldali feldolgozást ahhoz, hogy a megfelelő kimeneti formátumra konvertáljuk az adatokat (HTML, RSS, stb). Ezzel CPU-t spórolunk meg.
3. Egységes, követhető adatformátumot kapunk, nincs szükségünk külön metaadatokra.
4. Mindig nyers adatokat küldünk, a klienstől dönti el, hogy mihez kezd vele.
Problémák, amiket én látok ezzel a megoldással:
1. Egyedi XML formátum oldalanként. Teljességgel kizárt, hogy mindenki hajlandó legyen ugyanazt az XML formátumot használni a hasonló adatai tárolására. Vagyis a közvetlen adat-integráció kizárt.
Ahhoz, hogy ez működjön, az XML formátumnak valamiféle közös jellemzőkkel kellene rendelkeznie, ami viszont azt is jelenti, hogy szükség lenne valamilyen schema.org-hoz hasonló markupra.
Ezzel viszont felmerül a probléma, hogy a piaci szereplők már most sem tudnak megegyezni róla, mert a Facebook az OpenGraph-ot nyomja, a Twitter a Twitter-flavor OpenGraph-ot, a Google pedig a schema.org-ot. Lásd még: XKCD.
Végeredményben tök mindegy, hogy HTML vagy XML, az adatainkat továbbra is markupolni fogjuk a mindenféle szolgáltató által támogatott sémák szerint, vagy az XML-ben közvetlenül, vagy az XSL átalakítás során.
2. Kliens oldali támogatás. Noha a böngészők XSL támogatása ma már egész tűrhető, sok adatfeldolgozó kliens nem rendelkezik ilyen képességekkel, és különböző okokból kifolyólag nem is fog. (pl.
Az alapján, ami abból a threadből kiderült, ennek a megközelítésnek a következő előnyei vannak:
1. Minden adatot csak egyszer tárolunk el, nem duplikáljuk.
2. Nem alkalmazunk szerver oldali feldolgozást ahhoz, hogy a megfelelő kimeneti formátumra konvertáljuk az adatokat (HTML, RSS, stb). Ezzel CPU-t spórolunk meg.
3. Egységes, követhető adatformátumot kapunk, nincs szükségünk külön metaadatokra.
4. Mindig nyers adatokat küldünk, a klienstől dönti el, hogy mihez kezd vele.
Problémák, amiket én látok ezzel a megoldással:
1. Egyedi XML formátum oldalanként. Teljességgel kizárt, hogy mindenki hajlandó legyen ugyanazt az XML formátumot használni a hasonló adatai tárolására. Vagyis a közvetlen adat-integráció kizárt.
Ahhoz, hogy ez működjön, az XML formátumnak valamiféle közös jellemzőkkel kellene rendelkeznie, ami viszont azt is jelenti, hogy szükség lenne valamilyen schema.org-hoz hasonló markupra.
Ezzel viszont felmerül a probléma, hogy a piaci szereplők már most sem tudnak megegyezni róla, mert a Facebook az OpenGraph-ot nyomja, a Twitter a Twitter-flavor OpenGraph-ot, a Google pedig a schema.org-ot. Lásd még: XKCD.
Végeredményben tök mindegy, hogy HTML vagy XML, az adatainkat továbbra is markupolni fogjuk a mindenféle szolgáltató által támogatott sémák szerint, vagy az XML-ben közvetlenül, vagy az XSL átalakítás során.
2. Kliens oldali támogatás. Noha a böngészők XSL támogatása ma már egész tűrhető, sok adatfeldolgozó kliens nem rendelkezik ilyen képességekkel, és különböző okokból kifolyólag nem is fog. (pl.
