Weblabor

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. RSS feldolgozásnál a szükséges CPU kapacitás, de akár a programozói lustaság is.) Az XSL feldolgozás sok feladatra megsokszorozná a szükséges erőforrásokat, holott sok adatátviteli formátumot pont azért találtak ki, hogy ezeket megkönnyítse. Ez sok piaci szereplőnek (RSS aggregátorok) azt jelenti, hogy a költségek a többszörösére nőnek.


3. Lapozás. Ha sok adat van, akkor kénytelen az ember lapozást vinni a rendszerbe. Ezzel viszont felmerül egy probléma, hiszen sokszor több szempont szerint szeretnénk rendezni a weboldalunk elemeit (pl. blogpost), és ezzel kénytelenek vagyunk valamiféle AJAX vagy más egyéb megoldással behúzni az egyes alkotóelemeket. Amellett, hogy ez SEO szempontból öngyilkosság, további probléma, hogy például egy blognál az eredeti threadben írtak szerint a teljes blogpostot letöltené még egy listanézethez is.

Ugyanez igaz a keresésre is, tekintettel arra, hogy keresni nagy adatmennyiségben csak szerver oldalon tudunk, ami viszont szükségessé teszi a dinamikusan generált XML adathalmazt.


4. Statikus tartalmak. Ha minden tartalmat csak egyszer akarunk a szerveren letárolni és mindent adat alapon átvinni, elvesszük a lehetőségét annak, hogy a képeinkből különböző méreteket tartsunk, vagyis a szerveren a legnagyobb szükséges képet kell letárolnunk. Ez azt is jelenti, hogy ez az adatforgalomban is számottevő növekedést fog jelenteni, hiszen a kliens oldalon méretezünk.


5. Üzleti igények. Repülőtársaságok, szállodák, stb. külön szerződéseket kötnek a különböző aggregátor oldalakkal, sokszor nem kevés pénzért. Lehet nem szeretni ezt az üzleti modellt, de tény, hogy az ebből nyereségre szert tevő piaci szereplők nem fogják szivesen látni, ha könnyebb lesz az adatok kinyerése.


6. Adat overhead. Nem minden nézetben van szükségünk minden adatra. Egy webes listanézetben nincs szükség a teljes adatszerkezetre, egy adatfeedben viszont igen. Ez megint csak szükségessé teszi a szerver oldali feldolgozást.


Összességében én úgy látom, hogy az XML / XSL megoldás több, részben architekturális, problémát hordoz. Noha a 2000-es években az volt a jövőkép, hogy ilyen lesz a web, mára már (szerintem) világossá vált, hogy ez, részben emberi, részben műszaki tényezők miatt, nem lesz így.

Egy biztos: ez a megoldás jópár problémát felvet. Cserébe számomra kérdéses, hogy pontosan mi az a probléma amit megold, hiszen adattranszformációkra szerver oldalon így is szükség van.

Ti mit gondoltok?