Szemantikus web

Amikor először olvastam a schema.org kezdeményezéséről, nagyon megörültem, hisz egy hasonlóra vártam már évek óta. Úgy voltam vele, hogy ha már a W3C egyéb elfoglaltságok miatt nem tud a szemantikus web témakörével a téma fontosságával arányban foglalkozni, akkor maguknak a keresőknek, de leginkább a legnagyobbnak, a Google-nak kéne lépnie. Ez össze is jött, bár csodálkozásomra összefogott a Microsofttal és a Yahooval.

Az első csalódás akkor ért, amikor a kidolgozott objektumok alacsony számával szembesültem, ráadásul azok is leginkább csak a manapság divatos közösségi hálóval kapcsolatos, komolyabb termékekkel foglalkozó weboldalt nem lehet még a segítségükkel készíteni. Ez persze rámutat, hogy maguk a keresők először az internethasználókról szeretnének minél többet megtudni, ami nem meglepő olyan profitorientált cégektől, akik bevételeinek egy része hirdetésekből folyik be.

A második csalódás akkor ért, amikor Jeni Tennison, a szemantikus web egyik szakértője blogjában rávilágított, hogy a sémák specifikációja mellől hiányzik a legfontosabb, mégpedig a sémák értelmezésének módja. A HTML 5 szabvány ebből a szempontból jól ki van dolgozva, ott a készítők a legrészletesebben leírják, hogy az egyes elemeket miként kell kezelni, hogyan működnek. A schema.org esetében ez titok marad, nem tudhatjuk, hogy a keresők ezt önállóan oldják meg, vagy pedig közösen kidolgoztak erre is egy módszert. A weblapkészítőket ez hátrányosan érinti, mert az adatok helyes megadásának módját így csak kísérleti úton határozhatják meg.

Jeni egyébként arra hegyezi ki a bejegyzését, hogy ez az egész a Google keresőmonopóliumát fogja erősíteni, amivel én – egyelőre – nem értek egyet, mert úgy gondolom, hogy mindhárom cég egyenlő eséllyel indul a technológia megvalósításában.

Amiben viszont osztom Jeni nézeteit, az az, hogy a schema.org kezdeményezése további károkat is okozhat. A W3C-nek már van egy keretrendszere a szemantikus tartalom jelölésére, az RDFa, ami kiegészítve a web ontológiával, kiindulási alapnak elfogadható lenne, bár több helyen is olvasni a bonyolultságáról; ahhoz nem is kell különösebb jóstehetség, hogy rájöjjünk, a sémák természetesen nem kompatibilisek ezekkel.

A web egészére hatással lehet, hogy a schema.org kereskedelmi cégek magánkezdeményezése, amire senki nincs hatással, csak ők maguk. Mindent úgy, hogy egyébként egyenként is tagjai a független W3C-nek, és aktívan részt vesznek a szabványok kidolgozásában. Mint már írtam, ezek profitorientált vállalatok, akiknek kizárólagos célja a részvényesek kifizetése (mindent vagy semmi alapon: ha nem produkálnak elegendő nyereséget, a tőkekivonás miatt hamar megroggyanhatnak), és kénytelenek ennek mindent alávetni. Őket nem érdekli az internet nyíltsága (a korlátozott kontrollálhatatlanság), a jelenlegi szabadság, a nyílt szabványok, a verseny, mert ezek mind bevételcsökkentő tényezők.

Ha elfogadjuk azt, amit kínálnak nekünk, akkor önként rakjuk kalodába fejünket, egy lépéssel közelebb leszünk a zárt webhez, ahol a feltételeket ők (és rajtuk keresztül a részvényesek) diktálják.

A szemantikus webre szükség van, de nem közvetlenül tőlük, hanem egy független szervezettől. Ez lehetne akár a W3C is, de a munkatempójukat látva egy ilyen bonyolultságú dolgot hosszú évtizedekig dolgoznának ki a jelenlegi módszereikkel, úgyhogy elképzelhető, hogy célszerűbb lenne egy új internetes szabványokért felelős társaságot létrehozni.

Nagy cég - nagy botrányok. Ebben az írásomban a Google-t veszem górcső alá, mivel rendkívül nagy hatással van életünkre, de ez csak egy kiragadott példa, a többi (Microsoft, Apple és társaik) pontosan ugyanígy működik.
Kezdetben úgy terveztem, hogy az utóbbi öt év zűrös ügyeit mutatom be, de rövid úton kiderült, hogy 2010-ben annyi minden történt ezzel a vállalattal, hogy avval egy könyvet is meg lehetne tölteni.

Számomra 2009-es hír mutatott rá, hogy nincs minden rendben a Google háza táján, amikor kiadták a Chrome nevű böngészőjüket, amiről kiderült, hogy használat közben adatokat küld vissza a cégnek a böngészési szokásainkról. Ezek például: a telepítési és használati információkat, a program felhasználóit egyedi azonosítóval látják el, a beírt webcímeket stb. Ezzel talán nem is az a nagy baj, hogy megtették, hanem hogy "elfelejtettek" szólni róla. Szerencsére a szoftver forráskódja nyílt, így az SRWare nevű német cég azóta minden verzióból kigyomlálja ezeket a felhasználó és szokásainak azonosítására alkalmas kódrészeket, és SRWare Iron néven letölthetővé tették.

2010-ben már hangos volt a média a Google-től, és nem csak a technológiai újításai és szolgáltatásai miatt. A Google Street View-val az céljuk, hogy a városokat 3D-ben bejárhatjuk, amihez szerte a világban speciális panorámakamerával felszerelt autókat indítottak útjukra, hogy lefényképezzék a településeket. Ez több országban és szövetségi államban azonnal tiltakozáshoz vezetett, mert sokan a magánszférájukba való behatolásként értelmezték, ami konkrétan meg is történt. Emellett az is aggasztó a jogvédőknek, hogy a képekre felkerültek értelemszerűen az autók rendszámai és a járókelők arcai.

Ennyi viszont nem volt elég, kiderült, hogy a Google gépkocsijai nem csak fényképeket gyűjtöttek, hanem kódolatlan wifi adatokat is, így jelszavakhoz és banki adatokhoz is juthattak. Rögtön házkutatások és perek áradatát zúdították a cég nyakába, és egymásnak ellentmondásos döntések születtek az ügyekben, valahol meg kellett semmisíteni az összegyűjtött információt, valahol pedig ki kellett adniuk az adatvédelmi biztosoknak.

A Google Buzz nevű szolgáltatása már a tesztidőszakban problémás volt, és elindulása után röviddel le is kellett véglegesen állítani. Kiderült, hogy tudta és beleegyezése nélkül nyilvánossá tették, hogy a felhasználó mivel foglalkozik. Emiatt rögtön felelősségre is vonták a céget, s a perköltségen kívül 8,5 millió dollár további költség megtérítését is vállalták, hogy elkerüljék a csoportos perbe fogást.

Ezek után címszavakban: fotósok perlik a Google-t, mert a könyvdigitalizálásnál nem fizetnek a képek után jogdíjat, valamint ugyanezen projekt miatt a monopolisztikus törekvésekkel is vádolják. A Yahoo szerint a szabadalmait sérti a Google Instant nevű szolgáltatás, bár ők nem mennek perre, viszont az EU igen, mivel a vádak szerint a Google a keresőjében hátrányos helyzetbe hozza a vetélytársait.

Cikkemnek csak egyik mondanivalója az, hogy aki ezek után is a Google-re bízza az adatait, az meglehetősen bátor, de mindenesetre erről mindenkit lebeszélek. A probléma gyökere az, hogy ez egy piaci cég, és az elsődleges feladata az, hogy a befektetőinek hasznot hozzon, mert ha ezt nem teszik meg, lehúzhatják a redőnyt. A verseny erre nincs jó hatással, mert rengeteg pénzbe kerül, ha elsők akarnak maradni, és - úgy látszik - emiatt kénytelenek nem tisztességes eszközökhöz fordulni.

A végső következtetésem az, hogy sem magánadatokat, sem olyan információkat, amelyek a közösség hasznára válnak, nem szabad magáncégek kezébe adni, mert azokkal visszaélhetnek.

Az esetek többségében XML fájlunk két (sokszor el nem különülő) részből áll: a kérésre adott adatokból, valamint kiegészítő információkból. Hogy ezekből melyiket hasznosítjuk, az az igényeinktől függ; lehet, hogy csak a fő adatokra van szükségünk (például össze szeretnénk szedni hasonló technológiával készült termékek paramétereit, és azokat egy gyűjtőoldalon megjeleníteni), de lehet, hogy mindenre (ha egy konkrét weboldalt szeretnénk megnézni, ebben az esetben a kiegészítő információkból épül fel a HTML).

Lássuk akkor egy példán keresztül, hogyan is működik az XML alapú web! Egy nagyon egyszerű blogbejegyzés-gyűjtőoldalt készítettem el, amihez mellékelem a két letölthető példafájlt, és a blog.xml-t megnyitva megtekinthető az eredmény. Ez a leginkább kezdők számára készült a leírás szájbarágós stílusú, ezért akik már ismerik az XML + XSL működését, nyugodtan kihagyhatják.

blog.xml

blog.xsl.xml

(Mivel a blog.hu nem enged meg fájlokat feltölteni .xsl kiterjesztéssel, ezért hozzábiggyesztettem egy .xml-t)

A blog.xml második sorában lévő <?xml-stylesheet type="text/xsl" href="blog.xsl.xml" ?> utasítja a böngészőt, hogy töltse be a megadott stíluslapot, és annak segítségével jelenítse meg. Azért nevezik stíluslapnak, mert elveiben hasonlóan működik a CSS stíluslapokhoz, azaz szabályokat definiálhatunk benne, hogy az adott adatblokkot mivé alakítsa át. A generált adatok formátuma lehet XML, HTML és szöveges tartalom.

Egy XML fájlban egy gyökér elem, azaz root node lehet, minden tartalomnak azon belül kell lennie; esetünkben ezt <blog>-nak neveztem el önkényesen. A kiegészítő információknak létrehoztam egy saját elemet, és a <tartalom> blokkban helyeztem el a képzeletbeli blog bejegyzéseit. Mint látható, minden bejegyzésnek egyszerű szöveges tulajdonságai vannak, valamint a <szoveg> elemben HTML kódot találhatunk, amit értelemszerűen egy az egyben fogunk megjeleníteni.

A blog.xsl.xml-ben találjuk a megjelenítéshez szükséges beállításokat és stílusokat. A kimeneti adatformátunk HTML (mint látható, megadhatjuk a doctype-ot), amihez UTF-8 karakterkódolást használunk.

<xsl:output method="html" version="1.0" encoding="utf-8" doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN" doctype-system="http://www.w3.org/TR/html4/loose.dtd" />

A 7. sorban található <xsl:key ... /> sorral most nem foglalkozom, ami számunkra fontos, az az első stílusdefiníció:

<xsl:template match="blog">
  <html>
    <head>
      <xsl:call-template name="html_fejlec" />
    </head>
    <body>
      <div id="fejlec">
        <h1><xsl:value-of select="//kiegeszito_informaciok/cim" /></h1>
      </div>
 
      <div id="tartalom">
        <xsl:apply-templates select="tartalom" />
      </div>
 
      <div id="lablec">
          copyright (c) Hidvégi Gábor
      </div>
    </body>
  </html>
</xsl:template>

A bemenő XML értelmezése úgy történik, hogy a feldolgozó szoftver végigiterál az összes XML elemen, megnézi, hogy tartozik-e hozzá stílusdefiníció, ha igen, akkor azt alkalmazza. Esetünkben az <xsl:template match="blog"> azt jelenti, hogy minden <blog> elemet lecserél a definícióban található blokkra. Ez a példában egyszer fordul elő, mivel csak a gyökér elemet neveztem el így, de ha a tartalmi szekcióban is így neveznék el egy elemet, akkor elég érdekes lenne a végeredmény.

A következő sor a <xsl:call-template name="html_fejlec" />, ahol egy névvel ellátott definíció eredményét illesztjük bele a generált HTML kódunkba, nevezetesen a <title> és <meta> tag-eket. Az oldal címe a bemenő XML <kiegeszito_informaciok> blokkja cim elemének tartalma, és a későbbiekben ugyanezt az adatot használjuk a <div id="fejlec">-ben lévő <h1> értékének beállításához is.

Hadd hívjam fel a figyelmet a "html_fejlec" nevű stílusdefinícióban található programrészletre, ami a <meta name="keywords"> tartalmának generálásáért felelős!

<xsl:attribute name="content">
  <xsl:for-each select="//cimke[generate-id() = generate-id(key('cimkek', .)[1])]">
    <xsl:value-of select="." />
    <xsl:if test="position() != last()">, </xsl:if>
  </xsl:for-each>
</xsl:attribute>

Működését tekintve ez összegyűjti a bemenő XML-ben található összes egyedi <cimke> elemet, és összefűzi őket egy karakterláncba, vesszővel elválasztva, azaz az eredmény körülbelül így fog kinézni: <meta name="keywords" content="internet, http, szemantikus web">.

Ami ebben különleges, az az elv: nem a szerveroldalon dől el, hogy bizonyos adatokat milyen formában írunk ki, hanem a kliensoldalon, így nem kell a háttérrendszer programozóinak azzal foglalkozniuk, hogy számunkra ugyanazokat az adatokat több módon legenerálják. Már korábban többször említettem, hogy szemléletváltásra van szükség a szemantikus web bevezetéséhez, ez erre egy kiváló példa.

Visszatérve a példára, a következő érdekes sor:

<xsl:apply-templates select="tartalom" />

Ez azt csinálja, hogy a bemenő adatokban megkeresi a <tartalom> elemet, a benne lévő elemeken végigiterál, és ha tartozik hozzájuk stílusdefiníció, azokat feldolgozza és beilleszti erre a helyre. Ha megnézzük a blog.xml-t, a <tartalom>-on belül a <bejegyzesek>-et találjuk, azon belül pedig <bejegyzes> elemeket.

<xsl:template match="bejegyzesek">
  <div id="bejegyzesek">
    <xsl:for-each select="bejegyzes">
      <xsl:call-template name="bejegyzes" />
    </xsl:for-each>
  </div>
</xsl:template>

A fenti definíció segítségével dolgozzuk fel a <bejegyzesek>-et, amiben egy ciklus segítségével végigiterálunk az összes <bejegyzes>-en, és meghívjuk a hozzá tartozó stílust.

A könnyebb érthetőség végett leírom, hogyan működik pontosan a fenti definíció. Az <xsl:template match="bejegyzesek"> hatására a feldolgozó a bemenő XML fájlban megkeresi az összes <bejegyzesek> elemet (esetünkben egyet), és annak tartalmát adja át a stílusnak, ami a következő XML töredék:

<bejegyzes>
  ...
</bejegyzes>
<bejegyzes>
  ...
</bejegyzes>

Első lépésként "kirajzolja" ezt a sort:

<div id="bejegyzesek">

Ez után következik az iteráció:

<xsl:for-each select="bejegyzes">

Ez "fogja" az első <bejegyzes> tartalmát, és átadja a <xsl:call-template name="bejegyzes" /> utasításban megjelölt "bejegyzes" nevű stílusdefiníciónak, amelyik tehát a következő XML töredéket kapja meg:

<cim>A HTTP protokollról</cim>
<url>a_http_protokollrol</url>
<szerzo>Hidvégi Gábor</szerzo>
...

Amikor ebben a stílusban a vezérlés a <h2><xsl:value-of select="cim" /></h2> sorra kerül, akkor ide ennek az adatblokknak a <cim> elemében található tartalmat másolja: <h2>A HTTP protokollról</h2>.

Végül visszakerülünk a <xsl:template match="bejegyzesek"> definícióba, ami az iteráció után lezárja a megnyitott <div> elemünket.

Mindenkit bátorítok, hogy kezdjen el játszani a stíluslapokkal, viszonylag hamar rá lehet jönni a logikájukra, XSL referenciának a ZVON gyűjteményét ajánlom (magyar nyelvű).

Az előző bejegyzésem végén található követelményjegyzék technológiai megvalósításához az egyik legalkalmasabb eszköz az XML + XSLT páros, s én azt javasolnám, hogy térjünk át az XML alapú adattárolásra. Nézzük, hogyan felel meg a fenti követelményeknek:

• legyen szabványos és széleskörűen támogatott:
  az XML 1998-as, míg az XSLT 1999-ben elfogadott szabvány, szinte az összes webes programozási nyelv (mind kliens-, mind szerver oldalon) natívan ismeri
• az adatokat strukturáltan lehessen reprezentálni:
  az XML tipikusan egy fastruktúra létrehozására alkalmas
• az adatok megjelenítési módja legyen teljesen független a tárolásuktól:
  XSLT stíluslapok segítségével a bemenő XML-t bármilyen más formára (XML, HTML, szöveg [pl. javascript]) alakíthatjuk
• legyen gépileg könnyen feldolgozható:
  ez az előbbi három pont következménye
• legyen visszafele kompatibilis, azaz a régi böngészők és a keresők is fel tudják dolgozni:
  mivel HTML-t lehet XML-ből XSLT segítségével generálni, ezért ez minden gond nélkül megoldható

További előnyök, amit az XML + XSLT kombinációjával nyerünk:

• a szerveroldali alkalmazásunk, valamint a kliens minimális kiegészítésével könnyedén megvalósítható, hogy ne egy teljes oldal tartalmát kérjük le, hanem csak a szükséges tartalmi blokk adatait, így gyorsabb lesz a kommunikáció és a feldolgozás sebessége is
• mivel egységes formában, XML-ben küldjük az adatokat, kliensoldalon nem szükséges külön leprogramozni a megjelenítési logikát, mint például a JSON-nál
• egyszerűsödik a munka, mivel a szerveroldalon csak arra kell a programozóknak ügyelniük, hogy megfelelő XML-t generáljanak, míg a kliensoldali fejlesztők felelőssége azok megjelenítése
• az azonos típusú adatok összegyűjtése a különböző oldalakról jóval egyszerűbb lesz, így könnyedén lehet olyan alkalmazásokat írni, amelyek az információt összehasonlítják, például legolcsóbb repülőjegyek keresése stb.

Természetesen vannak hátrányai is a technológiának:

• könnyebbé válik az adatlopás (ilyen félelmek esetén nem kell XML-t használni, hanem vissza lehet térni a HTML-re)
• az átállás XML alapú webre sok munkát, valamint szemléletváltást igényel
• amennyiben egy XML fájl nem érvényes, szintaktikai hibát tartalmaz, nem lehet feldolgozni, ezért különösen körültekintően kell elkészíteni
• bizonyos feladatokat nehézkesebb megoldani XSLT stíluslapokkal, mint magasszintű programozási nyelveken (pl. javascript, PHP) – bár ennek az ellenkezője is igaz

Az XML kicsivel több odafigyelést kíván, mint a HTML, de ezt felfoghatjuk előnyként is: a gyengébbek kiesnek, a szakma tisztul.

A következőkben be fogok mutatni egy példát forrással, hogy miként kell egy XML alapú oldalt elkészíteni.

Az előző bejegyzésem végkövetkeztetése többeket meglephet: miért van szükség a HTML szabványosítási folyamatának leállítására? Hiszen így megrekedhetünk a mostani technológia szintjén, és bizonyos problémákat nem, vagy csak nehézkesen tudunk megoldani.

Amit fontosnak tartok leszögezni, hogy a HTML-re és a HTML 5-re szükség van, mivel egy célra tökéletesen megfelel: adatok megjelenítésére. Rengeteg előnye van, például óriási a támogatottsága, ismertsége, könnyen megtanulható, és viszonylag könnyen lehet a segítségével publikálni. A HTML 5 is hoz pár olyan újdonságot, ami megkönnyítheti a felhasználók és a fejlesztők életét is, bár vannak olyan elemei, amelyek hasznossága mindenesetre kérdéses, pl. a header, article, canvas stb.

Tehát nem az a kérdés, hogy a HTML 5-öt be kell-e vezetni, hanem az, hogy mikor. Már néhányszor kritizáltam a szabványokért felelős W3C sebességét, a HTML 5 bevezetése majdnem másfél évtizedet fog igénybe venni, ráadásul így sem kerül bele sok fontos dolog.

A webes szakma jellemzően fiatal, lelkes fejlesztőkből áll, ami egyrészt nagy húzóerő (végtelen kreativitással dolgozik jó részük, nap mint nap találni fantasztikus megvalósításokat), másrészt pedig – mivel még nem rendelkeznek elegendő tapasztalattal, rálátással a nagy képre – probléma. Például gondolkodás nélkül használják a legújabb szabványokat, tervezeteket, hogy azok még nem hivatalosak, a böngészők egy része nem támogatja őket, így kizárhatják a használatból a látogatók egy csoportját, ezáltal potenciális ügyfeleket és bevételt vesztve. Persze ők azok, akik miatt a régebbi böngészők tulajdonosai (akiknek esetleg nincs is lehetőségük a frissítésre) olyan üzenetekkel találkoznak, hogy "cserélje le szoftverét a legújabbra", pedig az esetek kilencvenkilenc százalékában minimális befektetéssel lehetett volna elkészíteni úgy az oldalt, hogy mindenki használhassa.

Mi következik ebből a kettőből? 2014-ben boldog-boldogtalan át fog térni HTML 5-re, a marketingesek mindenhol azt harsogják, hogy "mi a legújabb szabványok szerint dolgozunk", az ügyfelek HTML 5-öt fognak követelni, anélkül, hogy tudnák, mit is nyernek vele. A W3C szokása a HTML 6-ban bevezeti a <video-3d> elemet, hogy a legújabb divatnak engedjen, a lelkes fejlesztőktől pedig nap mint nap jelennek meg olyan cikkek, hogy ”Trükkök százai a <nav> elemre” és társaik.
A világ pedig továbbra is be lesz zárva a HTML börtönébe, a szemantikus web bevezetése további tizenöt évvel eltolódik (ha nem többel).

Ezek miatt gondolom úgy, hogy a HTML 5 bevezetését el kell halasztani, és mindenkinek a szemantikus web megvalósításán kell dolgoznia. Valóban mindenkinek, mert ez rengeteg munkát kíván, valamint teljes szemléletváltást.

Már a korábbi bejegyzéseimben jeleztem, hogy a jelenlegi eszközökkel és szabványokkal is megoldható az áttérés, de vajon mire is mire is gondoltam? Íme, a követelményjegyzék, hogy milyen problémákat kell megoldani:

• legyen szabványos és széleskörűen támogatott
• az adatokat strukturáltan lehessen reprezentálni
• az adatok megjelenítési módja legyen teljesen független a tárolásuktól
• legyen gépileg könnyen feldolgozható
• legyen visszafele kompatibilis, azaz a régi böngészők és a keresők is fel tudják dolgozni

Hogy mi ez a technológia? A következő bejegyzésben fogom bemutatni.

Szemantika = jelentéstan, nézzük át, hogy a web alapvető adattárolási nyelvében, a HTML-ben milyen módon adhatjuk meg egy szöveg vagy szövegrész jelentését!

A HTML elemeknek van szemantikája, például van fejléc, lábléc, cikk (article) elem – jelezheti mindjárt néhány tájékozott olvasó, viszont ki kell ábrándítsam őket: ezek csak az adott szöveg logikai felépítését írják le, de a szöveg jelentéséről semmilyen információt nem tartalmaznak.

Itt van például ez a blogbejegyzés: a cím alatt található egy dátum, de igazából ránézésre nem lehet megmondani, hogy minek az időpontját mutatja. A cikk létrehozásának dátumát? Az utolsó mentés dátumát? A cikk élesítésének dátumát? Ha megnézzük a forráskódot, ott is csupán a class attribútum utalhat erre, de annak értéke "date", tehát nem vagyunk előrébb. Ez csak egy kiragadott példa, de körbennézve bármelyik weboldalon, ezer hasonló adatot találhatunk, amik „csak úgy vannak”, s bár mi, emberek ránézésre el tudjuk dönteni, mit jelentenek, gépileg ez a mai eszközökkel szinte lehetetlen, de mindenesetre rendkívül bonyolult mesterséges intelligencia szükséges.

A HTML klasszikusan a szöveg jelentésére csak két eszközt biztosít: a description és keywords meta tag-eket. Ezek használata rendkívül korlátozott, mivel a description az egész oldal leírására szolgál, míg a keywords-ben található kulcsszavak nem párosíthatóak az oldal tartalmában található tartalmi blokkokkal.

Az úgynevezett "web2" egyik legnagyobb újítása az volt, hogy magukat a tartalmi blokkokat jelölhetjük meg címkékkel, magyarul tag-ekkel. Ezáltal elvileg összeköthetővé válhatnának az azonos témájú tartalmak, nem csak egy oldalon belül, hanem akármilyen mennyiségű weboldalon.

Tehát csak ez a találmány forradalmasíthatta volna az internetet – legalábbis technológiailag, majd később egészében –, de ez elmaradt, köszönhetően az internetes szabványokat készítő W3C testület teljes nemtörődömségének. A címkézés olyan mérföldkő, amit azonnal be kellett volna emelni a HTML szabványba, persze a megfelelő kidolgozás után.

Gondoljunk csak bele! Először is meg kéne jelölni, hogy az adott címke melyik HTML tartalmi blokkra vonatkozik (például egy id-vel), hogy az könnyen azonosítható legyen. Második körben létre kéne hozni egy központi adatbázist, amiben a címkék feliratait tároljuk különböző nyelveken, hogy nyelvfüggetlenül összeköthessük az azonos témájú tartalmakat. Ha például arra keresek rá, hogy Fidzsi-szigetek, akkor valószínűleg a legtöbb és legrelevánsabb információt hindi nyelven találom meg (és az már legyen a fordítóprogram feladata, hogy a saját nyelvemen jelenítse meg a szöveget). Az internetes oldalak hirtelen egy nagy, összefüggő masszává válnának, jóval relevánsabb találatokkal.

E fejlesztés nélkül korlátozzuk magunkat az anyanyelvünkre, valamint az általunk beszélt egy-két idegen nyelvre, de a világ internetes tartalmának jórészét gyakorlatilag nem tudjuk így elérni.

A 2014-ben megjelenő HTML 5-ben erre a problémára a W3C egy megoldást ad: a linkeknek megadhatunk egy olyan attribútumot, hogy "tag", azaz kb. így néznek majd ki:

<a rel="tag" href="http://domain/link">Fidzsi-szigetek</a>

Én ezt a következőképp tudnám elképzelni, feltételezve, hogy a korábbi bekezdésben említett központi adatbázis nyelve angol:

<div id="fiji_szigetek">A Fidzsi-szigetek leírása ...</div>
<a tag="fiji" tag-content-id="fiji_szigetek" href="http://domain/link">Címke</a>

A HTML5 ajánláson dolgozó csoport tagjai olyan nagy cégek, böngészőgyártók, akik nagy befolyással vannak mindennapjainkra, mind például a Mozilla, az Apple, Microsoft, Google stb. Nem elég, hogy lassan dolgoznak (a HTML verzióváltására tizennégy évet kell összességében várni), még a valós problémákat is képtelenek felismerni és azokra választ adni. Ehelyett az aktuális divatirányzatoknak szeretnének megfelelni, nem törődve azzal, hogy mekkora kárt okozhatnak ezzel hosszú távon.

A probléma igazából a HTML-lel van, pontosabban azzal, hogy nem a helyén kezeljük. Tisztázni kell: a HTML se több, se kevesebb, mint adatok megjelenítésének leírónyelve. A kulcsszó a „megjelenítés”, tehát leegyszerűsítve azt a feladatot kell ellátnia, hogy az adatok milyen színnel és milyen méretben jelenjelenek meg. Magukat az adatokat teljesen külön kell választani a megjelenésüktől, ellenkező esetben a szemantikus keresés bevezetését nehezítjük meg, és - minden ellenkező híreszteléssel ellentétben - technológiailag továbbra is maradunk a web 1.0 szintjén.

Erre a szétválasztásra a mai technológiai eszközökkel már megvan a lehetőség, a következő lépés az internetes fejlesztők szemléletváltása. A HTML5 bevezetésével csak a jelenlegi állapotokat konzerváljuk – az eddigiekből kiindulva újabb másfél évtizedre –, és mivel ezzel a nyelvvel amúgy sem nyerünk sokat – tehát a legtöbb „újítása” helyettesíthető már létező eszközökkel –, a szabványosítás folyamatát véleményem szerint azonnal le kell állítani, és ki kell dolgozni egy olyan életképes módszert, amivel minél hamarabb szemantikus alapra helyezhetjük az internetet.

A Kitenkintőben a blog témájához nem feltétlenül szorosan kapcsolódó írásokat fogok megjelentetni, és a hangnem is valószínűleg kevésbé lesz kötött, mint a szakmai cikkeké.

Ma reggel fedeztem fel az index.hu egyik újonnan indult mellékletét, a Városfigyelőt, és megnyitás után rögtön láttam, hogy a programozók szinte minden tipikus hibát elkövettek, amit lehetett, s ezért az oldalt most konstruktív kritikával ki fogom elemezni.

Két okból böngészek kikapcsolt javascripttel: az egyik, hogy a biztonsági hibák nagy részét jól megírt javascript kóddal lehet kiaknázni, másrészt pedig az oldalak nagyságrendekkel gyorsabban töltődnek be így, és az esetek kilencvenkilenc százalékában semmilyen pluszt nem nyújtanak a csilivili animációk. A Városfigyelő megnyitásakor rögtön a következő üzenet fogadott: "Ahhoz hogy teljes minőségében élvezhesd a Városfigyelő-t, kérünk, hogy kapcsold be a javascript támogatást.", így rögtön tudtam, hogy igazi csemegére akadtam.

Miután a scripteket bekapcsolom, az első tipikus hiba, ami zavarja az szemem, a bevillanó betöltés-jelző, aztán megjelenik a tartalom a képernyő teljes szélességében, majd az egész összébb ugrik kb. tíz pixellel, megint megjelenik a betöltésjelző, majd újra előtűnik a tartalom. Én ezt a következőképp oldanám meg: mielőtt bármit kirajzolnék, kiszámolnám a képernyő szélességét, majd elindítanék egy számlálót, és a betöltésjelzőt csak abban az esetben jeleníteném meg, ha az oldal tartalma kb. 1-1,5 másodperc alatt nem jelenik meg, ilyen módon el lehetne kerülni a villódzást.

A következő, ami feltűnt, hogy az oldalon belül az url-ek # jellel kezdődnek, amivel kapcsolatban két probléma is felmerül. Az első, hogy Internet Explorerben (7 és 8-as verzió) nem működnek a böngésző oda-vissza gombjai (más programokban is csak korlátozottan), így navigáció nehézkessé válik, pedig már vannak elérhető nyílt forráskódú megoldások, amit fel lehetne használni. A második hiba - bár ez eléggé elhanyagolható -, hogy amikor egy kérést indítunk a webszerver felé, a # utáni karaktersort a böngészők nem küldik el a kiszolgálónak, így kikapcsolt javascripttel egy ilyen oldal teljességgel használhatatlan (és most tekintsünk el attól, hogy ezen a konkrét példán ebben az esetben még tartalom sem jelenik meg). Erre megoldás, hogy hagyományos url-eket használunk, és a cím AJAX-os megnyitását egy jól megírt javascript függvénnyel kezeljük le, és a tartalom a hagyományos módon is elérhető marad.

A lelkes fejlesztők az oldal kódját HTML 5-ben készítették el, amivel két gond van: az első, hogy - mint a blog bevezetőjében említettem - előre láthatólag csak 2014-re lesz csak szabvány, a második pedig az, hogy jelen pillanatban legjobban csak az Opera támogatja, a többi böngésző pedig hiányosan. Mivel a HTML 5 új tag-jei semmilyen plusz jelentést nem hordoznak (például semmilyen különbség nincs a <div class="article"> és az <article> elem között), ezért semmiképp sem ajánlanám 2014 előtt, hogy bárki is használja, a HTML 4-es tökéletesen kielégít minden igényt (ez nem csak az én véleményem).

A forráskódot elemezve feltűnt, hogy rengeteg javascript fájlt kell betölteni az elején, én, ha lehet, ezeket összevonnám egy állományba a gyorsabb letöltés végett, valamint komolyabban elgondolkoznék, hogy muszáj-e külső fejlesztő által készített keretrendszereket használni. Sajnos ezekkel eléggé negatív tapasztalataim vannak, mivel amikor az átlagnál egy picivel bonyolultabb feladatokat kell megoldani (és ez egy átlagos munka esetén már a második napon meg szokott történni), és előjönnek a keretrendszer hibái, azok javítása sokszor több időbe telik, mintha magam írtam volna meg az adott funkciót a nulláról indulva.

Végkövetkeztetésnek azt vonnám le, hogy egy technikai fejlesztés akkor hasznos, ha abból a lehető legtöbben profitálnak, de senki sem veszít. Esetünkben ez sajnos nem így van, és bizonyos régebbi böngészők használóit (akik nem feltétlenül amiatt nem használnak újabbat, mert nem akarnak, hanem mert nem lehetséges) kizárták abból, hogy gond nélkül megtekinthessék az őket érdeklő információkat, ráadásul őket úgy áldozták föl, hogy az oldal rendkívül primitív szöveges animációkat használ, amelyek semmit nem tesznek hozzá az oldal használati értékéhez. Ezeket az effektusokat minden különösebb erőfeszítés nélkül el lehetett volna készíteni úgy, hogy a tartalom elérhető lehetne mindenki számára.

Könnyű helyzetben vagyunk, amikor konkrétumot gépelünk be a keresőbe, például egy bizonyos típusú gépkocsit vagy szolgáltatást szeretnénk igénybe venni, biztosak lehetünk benne, hogy az első találatok között meg fogjuk találni. Ez a magabiztosság viszont elszáll, amint nehezebben megfogalmazható, mire is van szükségünk. Például „abercrombi ruhát hol lehet kapni fehérváron” vagy egy olyan játékot, „amiben a fekete szörny a hegyen szaladgál”, vagy „bányászattal kapcsolatos szólások, közmondások”-at. Ezeket nem én találtam ki, hanem az egyik régi játékokkal foglalkozó blog összegyűjtött legviccesebb keresőkifejezései.

Valóban viccesek? A kontextust nézve igen, viszont rávilágít egy tényre: sokan úgy keresnek, ahogy gondolkoznak. Sajnos a keresők itt megbuknak a vizsgán, hiszen a fent említett három kifejezésből kettőre teljesen rossz helyre irányította az illetőt. Miért van ez, miért kell nekünk alkalmazkodni a technológiához, amikor olyan találmányok vesznek körül minket, mint a három dimenziós televízió, az átlátszó álcázás, vagy az IBM szuperszámítógépe, ami legyőzte az egyik műveltségi vetélkedő két legsikeresebb játékosát?

A választ az internetes adattárolás nyelvében, a HTML-ben kell keresnünk: csak minimális többletinformációt hordoz a segítségével megjelenített szövegekről és adatokról, így, ha jelenlegi állapotában fel szeretnénk azokat dolgozni, szükség is lenne az előző bekezdésben említett szuperszámítógépre.

Ha a szövegeket már megértenék a gépek, jobban állnánk, de felvetődik a következő probléma: a megjelenő szövegek és adatok közti összefüggések. Az egyik legegyszerűbb példa erre egy blogbejegyzés, aminek van címe, bevezetője, szövegtörzse, szerzője. Ha egy ember ránéz, ezeket elsőre felismeri, de arra újabb mesterséges intelligenciát kell kifejleszteni, hogy gépileg is fel lehessen ezeket térképezni.

Történtek már kezdeményezések az internetes oldalakon található tartalmak jelentésének megjelölésére, lásd például a mikroformátumokat. Viszont azt kéne felismernie minden webes fejlesztőnek, hogy a HTML alapvetően csak adatmegjelenítésre alkalmas, főleg a legújabb változata, az 5.0, mivel 1, rengeteg (fölösleges) információt tartalmaz az adatok megjelenítésének kinézetével kapcsolatban, 2, az összetartozó adatok közötti összefüggéseket nem tárolja.

Tehát két választási lehetőségünk van, ha pontosabb találatokat szeretnénk kapni. Az első az, hogy óriási összegeket költünk olyan mesterséges intelligencia kifejlesztésére, ami a meglévő internetes tartalomban felismeri a szövegek és adatok jelentését, valamint a köztük lévő összefüggéseket. Ezt nyilvánvalóan csak olyan tőkeerős cégek tudják megengedni maguknak, mint például a Google vagy a Microsoft, viszont annak beláthatatlan következményei lehetnek, ha így magánkézbe kerül az internet jövője.

Erre egy alternatíva lehet az, hogy első körben megváltoztatjuk az internetes adattárolás nyelvét egy olyanra, ahol a megjelenítendő információkat elválasztjuk a megjelenítési formájuktól, azaz a fenti példával élve külön tároljuk egy blogbejegyzés címét, szerzőjét, tartalmát a grafikai reprezentációjától. Ezáltal létrejönnek olyan objektumok, amelyeket egységesen lehet kezelni, mert ugyanolyan tulajdonságaik vannak.

Második körben létre kell hoznunk egy olyan központi adatbázist, amiben a világot leíró objektumok közti kapcsolatokat tároljuk, például egy objektum a blogbejegyzés, és annak gyermek objektumai a hozzá kapcsolódó hozzászólások és így tovább. Ilyen módon legalább egy mesterséges intelligencia kifejlesztését megspórolhatjuk, valamint a nyílt technológiával biztosítjuk az internetes társadalmat a magáncégek visszaéléseitől.

A jó hír az, hogy a vázolt alternatíva megvalósítható már létező technológiákkal, a rossz hír viszont az, hogy rengeteg munkát igényel. Előbb-utóbb viszont meg kell lépni, és ha azt szeretnénk, hogy az internetet hatékonyan használhassuk arra, amire kitalálták, azaz információátadásra, célszerű minél előbb belevágni.

Amikor megnyitunk egy weboldalt, az általában több részből áll: fejlécből, tartalmi blokkból és láblécből, és sokszor ezeket is fel lehet bontani. Ha az oldalon belül elkezdünk új lapokat megnyitni, megfigyelhetjük, hogy igazából nem sok minden változik, általában csak a tartalmi szekcióba kerül új szöveg, valamint a hirdetések cserélődnek le.

Jogosan vetődhet fel ilyenkor, hogy miért kell akkor a teljes oldalt újratölteni? Sokkal kisebb terhelés lenne mind kliens-, mind pedig szerveroldalon, ha a korábbi állapothoz képest csak a változásokat kéne kiküldeni. Ennek az oka pedig az, hogy az HTML-ben az oldalak egy nagy egységként vannak kezelve, amit csak programozással lehet szétbontani.

Milyen következményekkel járna, ha egy-egy weboldal ilyen darabokból állna? Mivel egy kis blokkban jóval kevesebb adat van, mint a teljes lapon, ezért a szerveren az adatbáziskérések száma jelentősen csökkenhet. A kis kódrészeket gyorsabb kiszolgálni, így a sávszélességen és a processzoridőn is rengeteget spórolhatunk, és nem csak a kiszolgálón, hanem a kliensen is. A böngészőben a kevesebb adatot gyorsabban lehet feldolgozni és kirajzolni a képernyőre, azaz végeredményben többszörösére növekedhet a megjelenítési sebesség. A különböző blokkoknak egyedi gyorstárazást állíthatunk be, hisz nagy valószínűséggel egy portálon például a gyorshírek hamarabb frissülnek, mint az időjárási információk.

A weboldalaknak a fentiekben leírt szétszabása a jelenleg használatos technológiákkal lehetséges. Ez természetesen új problémákat is felvet, amiket meg kell oldani. Ahhoz, hogy a keresők továbbra is indexelni tudják az oldalt, meg kell hagyni a korábbi HTML generáló algoritmusokat, és külön el kell készíteni azokat az atomi blokkok adatait kiszolgáló kódot (bár az előbbiek az utóbbiakból épülnek fel). Mivel a weboldalak látogatói hozzászoktak, hogy az egyes oldalak között a böngészők előre és vissza gombjaival tudnak navigálni, meg kell oldani, hogy azok továbbra is működjenek.

Amennyiben a technológia működőképes, célszerű elgondolkodni új szabványok létrehozásán vagy a meglévők átdolgozásán.

A HTTP protokoll működése röviden a következő: miután lekértük a megtekinteni óhajtott weboldal HTML kódját, a böngésző összegyűjti belőle a megjelenítéshez szükséges fájlokat (képeket, stíluslapokat stb.), és, amennyiben szükséges, letölti azokat a szerver(ek)ről. Ha az adott fájlt korábban már lekértük, akkor először azt ellenőrzi le, hogy változott-e a tartalma, ha igen, akkor a szerver újraküldi, ha nem, akkor pedig csak annyit válaszol, hogy nincs változás, használhatjuk a gyorstárban lévő állományt (ilyenkor csak az úgynevezett válasz fejléceket küldi vissza, ami pár sornyi szöveg).

Hiába gyorsul a legtöbb helyen az internetelérés sebessége, a "legdrágább", azaz leglassabb művelet a fent leírt ellenőrzés, mivel minden egyes fájl esetében egyesével kell elküldeni a kérést, és megvárni a választ. Egy átlagos lekérés 50-100 milliszekundumot vesz igénybe (feltételezve, hogy az adott tartalom már a számítógépünkön van), ezt szorozzuk meg a lekérendő állományának számával, és máris több másodperces válaszoknál is tarthatunk. Ahogy a böngészők és a személyi számítógépek fejlődnek, egy átlagos weboldalon is akár ötven-hatvan lekérés is történhet oldalmegnyitáskor, gondoljunk csak a sok képre, reklámokra, programozási keretrendszerekre, statisztikai számlálókra stb.

A modern böngészők ezen a problémán úgy segítenek, hogy egyszerre több adatkapcsolatot indítanak a webszerver(ek) felé, de ennek is vannak korlátai, és egyáltalán nem biztos, hogy a kiszolgáló két kérést kétszer olyan gyorsan tud feldolgozni, mint egyet. Különböző trükkökkel lehet még a sebességet növelni, de igencsak hamar elérhetjük a protokoll korlátait.

A megoldás egészen nyilvánvaló, ha a fentebb leírtakat továbbgondoljuk. Egy kérés minimális ideje - induljunk ki a magasabb számból - 100 milliszekundum, azaz ennyi idő alatt kapcsolódunk a szerverhez, az feldolgozza a kérést, és visszaadja a megfelelő válaszfejléceket. Ha egy megabites kapcsolattal számolunk (egy másodperc alatt kb. 125 kilobájt adat), akkor ennyi idő alatt 12,5 kilobájtot küldhetett volna. Ahánnyal a kérések számát csökkentjük, annyiszor 12,5 kilobájtnyi adatforgalmat és annyiszor 100 milliszekundumot spórolhatunk meg. Ezt a legkönnyebben úgy tehetjük meg, hogy az oldal megjelenítéséhez szükséges fájlokat egy nagy fájlba csomagoljuk, így egyszerre küldünk el annyit, amennyit lehetséges.

Mit nyerünk így? A kevesebb kérés gyorsabb feldolgozást eredményez mind a kliens böngészőjében, mind pedig a szerveren, és tovább javíthatunk a sebességen, ha ezeket a csomagokat tömörítjük. A fenti példánál maradva az ötven fájlt ha öt csomagra tudjuk bontani, fél másodpercet nyerhetünk csak a letöltési időben.

Mivel minden éremnek két oldala van, ez a megoldás új problémákat is felvet: jól át kell gondolnunk, hogy az egyes csomagokba mit pakolunk (érdemes például a képeket külön tenni a szöveges információkat tartalmazó állományoktól), bár erre viszonylag könnyen lehet a webszerverekhez olyan kiegészítést írni, ami automatikusan elkészíti a forgalmi adatok alapján a megfelelő csomagokat.

Steve Souders, az ismert szakértő, aki a weboldalak megjelenítésének gyorsaságával foglalkozik, is ajánlja ezt a megoldást, már létezik is erre kidolgozott technológia, bár még nem igazán támogatott.

Amit jelenleg tehetünk, az az, hogy a fentiekben vázolt megoldást propagáljuk, átgondoljuk, kidolgozzuk. Emellett foglalkozni kell a jelenleg is működő gyorstárazási technológiák bemutatásával, hogy a webmesterek és programozók teljeskörűen megismerhessék a lehetőségeket, és gyakorlati tanácsokat kéne összegyűjteni a témakörben, hogy ne több helyről kelljen ezeket az információkat összegyűjteni.

Az internet 2011-ben húsz éves, ez kiváló alkalom arra, hogy értékeljük tapasztalatainkat.

Bár a kinézetek terén a weboldalak fényéveket fejlődtek, nem mondható el mindez a hagyományos értelemben vett internet háttértechnológiájáról, s emiatt egyre többet ütközünk a korlátaiba.

A HTTP protokoll messze nem ilyen forgalomra lett kitalálva, az oldalkéréseket nagyban lassítja, hogy rengeteg képet, stíluslapot és scriptet kell betölteni. Hiába nőtt a számítógépek és az internetkapcsolatok sebessége többszörösére, még mindig rengeteget kell várnunk, hogy egy átlagos oldal betöltődjön, ahhoz képest, hogy egy jól megírt specifikációval - hasonló műszaki háttérrel - ez mennyi lehetne.
Mivel ez egy olyan probléma, amit erőből meg lehet oldani (még gyorsabb szerverek, még gyorsabb számítógépek és még gyorsabb internetkapcsolat), valószínűleg sok fejlődést nem várhatunk ezen a téren a közeljövőben.

Az igazi problémát az jelenti, hogy az internet adattárolási nyelve, a HTML egy alapvetően szöveges tartalmak megjelenítésére lett kitalálva, és minimális lehetőség van arra, hogy a benne tárolt adatok jelentését, azaz szemantikáját jelöljük. Csupán az oldalon látható szavak alapján nem biztos, hogy a minket érdeklő információt találjuk meg, márpedig a mai keresők összefüggések keresésére nem képesek.

Bár voltak az utóbbi években kezdeményezések a tartalmak jelentésének megadására, a ma már legtöbb oldalon használt címkék vagy tag-ek segítségével, de ezek kezelésére nincs egységes technológia. A HTML jelenleg aktuális, 4.0-ás verziója 1998-as keltezésű, és egy friss hír szerint 2014-re várható a következő változat, azaz a szabványkészítő szervezet rendkívül lassan dolgozik, és várhatóan rengeteg igényt így sem lesz képes kielégíteni.

A problémákról röviden ennyit, részletesebben a következő bejegyzésekben írok. Hogyan lehet ezeket megoldani? Ezekre keresem a választ.