(Java applet) se nadomešča z , (directory list) in (menu list) postaneta , (element, ki je dovoljeval dodajanje parametrov v poizvedovalni niz) pa se nadomešča z uporabo . 16 npr. akustične naprave ne potrebujejo prikazovalnega modula, ki vsebuje definicijo relativne velikosti pisave, niti ne potrebujejo Style‐Sheet modula. Z izključitvijo določenih opcij se razvijalcu aplikacije omeji spekter znotraj katerega lahko razvija in s tem optimizira rezultat za v naprej določeno platformo.
str. 17/84 2.3 Problemi Quirksmode
Šele ob upadu popularnosti MSIE in povečani uporabi alternativnih brskalnikov (Firefox, Opera, Safari , Konqueror), ki so uporabniku nudili boljšo uporabniško izkušnjo, se je pojavila potreba po upoštevanju neodvisnih standardov – do takrat je bilo »jasno«, kako je treba pisati kodo za željen učinek.
Prvi »napredni« brskalnik v smislu upoštevanja standardov je bil MSIE5 za Mac‐a, iz leta 2000. Baziral je na lastnem prikazovalnem pogonu, Tasman (Windows verzije so uporabljale Trident) in napredno upošteval standarde HTML 4, CSS 1 in Ecma/JavaScript17. Implementiral je tudi »doctype‐switching18« ter XML & DOM. Slednja dva naj bi bila sicer na razpolago, a ne v zadovoljivi meri. (9)
Kljub dobronamernim teoretskim pristopom so se (in se še) standardi uporabljajo »od oka«. Primarna naloga oblikovalca je, da ustvari uporabniku užitno stran in tudi tu velja, da cilj upravičuje sredstva. Tudi je proizvajalcem brskalnikov pomembnejši faktor, kolikšen tržni delež imajo, kot pa, ali do potankosti sledijo zahtevam konzorcijev. Takšen pristop pa pomeni, da se brskalniki trudijo prikazati strani čim lepše, ne glede na standarde, se pravi v »Quirks‐mode«, ki tolerira stare grehe.
Nobena skrivnost ni, da se strani pišejo tako, da odgovarjajo določenemu brskalniku in ne glede na standard. »Standard« nikoli ni bil garant za enak prikaz strani na različnih platformah, kljub temu, da je bil kot tak zamišljen.
MSIE, kot nesporni vodja na trgu, je šele z verzijo 7.0, leta 2006, pričel resno razmišljati o dostojni podpori za CSS 2.1, PNG in druge standarde, kar je trend, ki ga z verzijo 8.019 nadaljuje. Uvedba MSIE 7.0 je dovedla do tega, da so se nekatere strani, ki so bile pred tem prilagojene na IE 6, »zrušile«. Razlog za to je bilo odpravljanje hroščev, ki so pred tem obvladovali IE 6.
Zavedajoč se problematike nekompatibilnosti lastnih brskalnikov s standardi, oz. drugimi brskalniki, se je Microsoft odločil, da z verzijo IE 5 vpelje univerzalni opisni jezik za prilagoditev strani posameznemu brskalniku: Conditional comments. Cc. je specifično strukturiran HTML/XML komentar,
17 JavaScript je iznajdba Netscape. Microsoft je to funkcionalnost kloniral pod imenom ECMAScript.
18 Različno prikazovanje glede na nastavljen DTD (Strict, Transitional, Frameset). Pred switching‐om se je DTD‐je enostavno ignoriralo.
19 MSIE8.0 je trenutno (apr2008) še v beta fazi. Striktnost standardov je bistveno naprednejša od MSIE7, govora je tudi, da bo prestal Acid‐2 test (interne bete ga že prestajajo) – test, s katerim se preveri, ali brskalnik sledi spletnim standardom, kot je CSS 2.1 (v grafičnem smislu). Aprila 2008 so Acid‐2 prestali Opera, Safari, Konqueror in iCab in napovedani Firefox 3. Medtem je v pripravi že Acid‐3 test, katerega je prestala napovedana verzija Opere 9.5.
str. 18/84 ki ga prepozna samo MSIE, ostali brskalniki pa ga ignorirajo. Znotraj komentarja ima uporabnik možnost, da preveri verzijo MSIE in ustrezno aktivira določen segment kode:
Koda, ki jo vidi samo IE v.6 ali višji
Cc. so uporabljivi zgolj znotraj (X)HTML/XML kode in ne direktno v CSS‐ih, ki so večinoma srž problema. Razvijalci se prilagodijo tej situaciji tako, da odvisno od verzije MSIE prikažejo različen CSS, ter v njem redefinirajo nastavitve, ki jih CSS postavlja za ostale brskalnike.
A medtem ko so Conditional comments možnost, ki jo je Microsoft zavedno dal na razpolago za rešitve obstoječih problemov, so nekateri brskalniki nenačrtovano nudili hrošče, proti katerim so se (in se še) ustvarjalci spletnih strani branijo na takšen ali drugačen način.
Netscape 4 ni poznal @import ukaza v CSS, kar je pomenilo, da so se ukazi, namenjeni zgolj za IE, zapisali v eksterni CSS. MSIE 5/Mac pa je nudil »commented backslash hack« za CSS, saj njegov razčlenjevalnik (parser) ni zaznal konca komentarja, v kolikor je bila pred zvezdico leva poševnica (escape‐znak):
/* navaden komentar \*/ .winOnlyStyle {...} /* IE5/Mac šele ob koncu tega komentarja zaključi prejšnjega */
Ta hek za Mac je obstajal v dveh variantah. Z opisano varianto je bilo mogoče skriti celoten blok, torej več vrstic kode, medtem ko je brskalnik v primeru, da ni sledil »zaključni« komentar, ignoriral zgolj eno vrstico. (10)
Pomemben hek za MSIE, preden je uvedel podporo za PNG, je bila uporaba AlphaImageLoader, sicer DirectX‐metode, ki se jo je vsililo v CSS preko filter atributa (ki sicer ni del standarda).
CSS‐hekanje je postala pravcata znanost, posamezni heki pa so dobivali imena kar po njihovih iznajditeljih. Hekanje se prakticira ne le preko napak v razčlenjevalnikih, temveč tudi preko podpore za prihodnje tehnologije/standarde. Prilagoditev izgleda za avantgardne brskalnike (recimo Opera) in s tem prelisičenje drugih (recimo IE) se prakticira tudi preko CSS‐3, ki še zdavnaj ni veljaven standard.
Pomembna referenca za to področje je online na
http://css‐discuss.incutio.com/?page=CssHack, primerna vstopna točka pa
http://www.quirksmode.com
str. 19/84 Preden je Microsoft objavil IE7, je večkrat pozival javnost, naj se nanj pripravi. Obširno je tudi obveščal o standardu CSS 2.1. Prizadevanja za standardizacijo so sicer hvalevredna, povsem zmotno pa je razmišljanje, da je možno prisiliti ljudi v pravilno uporabo standardov, zlasti če jih brskalniki sami ne podpirajo dosledno.
V pravu velja osnovno načelo, da nihče ne sme utrpeti škode, ki se zanaša na veljavno pravo. S tem načelom je povezana tudi prepoved retroaktivnega učinka, torej da bi neko pravno pravilo učinkovalo za nazaj. Takšno razmišljanje je povsem logično in utemeljivo.
Enako je logično, da so vse spletne aplikacije, ki so bile zgrajene v času, ko je imel IE6 popolno prevlado, povsem legitimne in torej ustrezajoče »standardom«, ki so takrat veljali. (Politično gledano je bil Microsoft v tistem času suveren, ki je postavljal pravila igre, medtem ko so bili razni konzorciji zgolj nasprotujoče skupine, ki so skušale uvesti novi pravni red.) Oblikovalci in spletni arhitekti so torej pridobili pravico do pravilnega prikazanja njihove strani s tem, da so se zanašali na hrošče in napake Internet Explorerja ter obstoječe hek‐e, s katerimi so te napake prikrivali.
»Doctype‐switch« je metoda, ki jo je predlagal leta 1998 Todd Fahrner, da bi razdelil spletne strani na takšne, ki sledijo standardom in takšne, ki jih še vedno zanemarjajo – to pa naj bi bilo odvisno od korektne navedbe DTD‐deklaracije. Pri takšnem dokumentu bi brskalnik lahko pričakoval, da je avtor kode dodobra seznanjen s standardi in bi stran prikazal dosledno glede na specifikacije.
Popularno je postajalo, da se je DTD navajalo v spletnih straneh, tudi orodja so temu trendu sledila. Realnega pomena te vrstice kode se marsikdo ni zavedal v polnem pomenu20, bistveno je še vedno ostalo, da je stran izgledala v brskalniku kot načrtovano, kar tudi je – saj se do IE7 ni spremenilo praktično nič.
IE je, da bi zagotavljal kompatibilnost do predhodnih verzij, preklopil v Quirks‐mode, kadar je zapazil, da (X)HTML ne odgovarja nujno standardom, kar je imelo za posledico, da se je stran še vedno lepo prikazala uporabniku.
20 Testno smo validirali nekaj spletnih strani preko http://validator.w3.org, ki so navajale uporabo DTD. www.direkt.si (XHTML 1.0 Strict: 11 napak), www.feri.uni‐mb.si (XHTML 1.0 Transitional: 8 napak), www.rtvslo.si (XHTML 1.0 Strict: 184 napak), www.spiegel.de (HTML 4.01 Strict: 155 napak), www.nzz.ch (XHTML 1.0 Transitional: 119 napak), www.microsoft.com (HTML 4.01 Transitional: 28 napak), www.cnn.com (HTML 4.01 Transitional: 44 napak). Testirali smo tudi www.firefox.com, www.opera.com in www.altova.de, ki pa so vsi /XHTML 1.0 Strict oz. Transitional pri Altovi/ test prestali. (Ironično bi bilo, če ga ne bi.)
str. 20/84 Praksa je dovedla do tega, da je DTD‐switching danes nezadostna metoda za korektno (torej takšno, kakršno je v danem trenutku želel avtor) prikazovanje spletnih strani glede na standarde, saj ta metoda ne zagotavlja konsistence skozi čas.
Aaron Gustafson, sicer član WaSP21, predlaga, da se nadaljnja definicija uporabljenih »standardov« pri zasnovi spletnih strani uredi s pomočjo navedbe brskalnika, za katerega je stran prilagojena. V svojem članku na ALA22 tako predlaga uporabo elementa za označitev verzije in imena brskalnika. Na tak način bi bilo mogoče emulirati okolje, za katero je bila zgrajena dotična stran in tako v vsakem primeru prikazati stran takšno, kakršna je bila od avtorja zamišljena. (11)
Gustafsonov predlog je naletel na burne odzive in nasprotovanja stroke, saj obstaja bojazen, da bi kaj takega zopet odprlo vrata za lastniško razhajanje pri implementaciji standardov in ne bi spodbujalo doslednega sledenja »uradnim« standardov.
V kolikor se bi takšna rešitev uporabljala že od samega začetka, bi to pomenilo pomemben doprinos h konsistenci spleta, upravičen pa je dvom, ali je takšna zaščita danes sploh še smiselna (razhajanj med posameznimi brskalniki je čedalje manj).
3. CSS
CSS je jezik/sintaksa, ki je nastala kot reakcija na evolucijo HTML iz semantične podatkovne strukture v sintakso za opis izgleda in postavitve elementov na spletni strani.
Ne le HTML je postajal vedno kompleksnejši in anarhičen, tudi obvladovanje mase kode in ažuriranje strani je postalo vedno bolj zahtevno, saj se je grafična postavitev, barva ozadja, velikost in tip tipografije, za vsak pojav posameznega elementa moral eksplicitno določiti. Že manjše spremembe izgleda so za sabo prinesle mučno iskanje in zamenjavo nepregledne množice atributov.
S CSS‐om se je to rutinsko delo močno olajšalo, tudi koda se je na ta način »očistila« in optimizirala, kar je imelo pozitivne učinke tudi glede same preglednosti dokumentov in njihove »teže« pri prenosu preko mreže.
21 WaSP – The Web Standards Project je neformalni konzorcij, ki se zavzema za promocijo in učinkovito uporabo spletnih standardov. www.webstandards.org
22 ALA – A List Apart, www.alistapart.com
str. 21/84 3.1 Zgodovina
»Oče« CSS je Norvežan Håkon Wium Lie23, ki je leta 1994, ko je še delal na CERN‐u pri Tim Berners‐ Lee (»izumitelju« WWW, gl. zgoraj), predlagal »Cascading HTML Style Sheets« ‐ CHSS. V predlogu CHSS (12) Lie izhaja predvsem iz problematike odločanja o izgledu posamezne strani, ki da je prepuščen nastavitvam izgleda, kot jih uporabnik definira v svojem brskalniku.
(Paradigma slogovnih datotek takrat ni bila nič novega – separacija strukture in oblike je dejansko obstajala, le da je bila slogovna datoteka v domeni posameznega brskalnika. Lie je čutil potrebo po redefiniciji obstoječih razmer, ker je želel, da bi avtor strani imel več moči pri odločanju o prikazu strani. Brskalniki so takrat večinoma dopuščali zgolj prilagoditev barve, velikosti in tipa pisave. (13))
Lie je tako predlagal, da bi posamezne CHSS‐določbe vsebovale določilo, kako močno vplivajo (v odstotkih) na predhodne določbe izgleda. Na tej podlagi se bi potem brskalnik npr. odločil, kako velik, ali katerega tipa bi bila določena pisava. Avtor HTML‐dokumenta bi bil tisti, ki ne bi diktiral (kot je to danes slučaj) oblike, temveč bi zgolj »predlagal«, kako si predstavlja izgled strani na način, da bi navedel različne CHSS reference/ukaze in jim dodal vrednost uteži. Skupek večih CHSS pravil (od tega paradigma »cascading«) bi potemtakem vplival na uporabniško izkušnjo.
Iz današnjega vidika je to sicer banalna problematika, saj sodobno spletno oblikovanje bazira na tezi, da je uporabniška izkušnja predvsem pasivna in da si uporabnik primarno ne želi prilagoditi izgleda24, upoštevajoč časovni faktor tega predloga pa je takšno razmišljanje dokaj razumljivo –WWW je bil še v plenicah, Mosaic je dominiral, lastniški HTML še ni bil v igri.
Pozneje se je Lie‐ju pridružil Bert Bos, ki je takrat delal na lastnem brskalniku, Argo, ki je uporabljal svoj pristop k paradigmi slogovnih datotek, Stream‐based Style Sheet Proposal (SSP). Argo/SSP je imel posebnost, da se ni vezal zgolj na HTML, temveč je bil odprt tudi za druge jezike – ta lastnost je vplivala, da se je besedo »HTML« črtalo iz CHSS in je tako postal CSS.
23 Lie je danes CTO (Chief Technology Officer – tehnični direktor) norveške Opera Software. Njegova najodmevnejša dosežka sta CSS in predlog Acid2‐testa (29), ki se danes uporablja za testiranje vizualno korektnega prikazovanja spletnih strani odgovarjajoč spletnim standardom.
24 To tezo potrjuje tudi usoda tkzv. »webparts«, ki so kljub tehnični inovativnosti uporabniku nudili preveč možnosti za prilagoditev izgleda, kar je posledično to tehnologijo zaznamovalo kot praktično neuporabno.
str. 22/84 Argo je že leta 1994 poznal napredne koncepte, kot so attribute selectors25 in generated text26, ki pa so bili vneseni v CSS šele v verziji CSS 2.0, leta 1998.
Implementacija v brskalnike je bila do nedavnega zanemarljiva. Prvi »komercialni« brskalnik, ki je podprl CSS je bil MSIE 4 (avg. 1996), nekaj mesecev pred priporočilom W3C za CSS (dec.). Takrat se je MS še s ponosom hvalil, da njegov brskalnik podpira spletne standarde. No, upoštevati je treba, da je bil MSIE takrat še inferiorni brskalnik, a tudi implementacija CSS ni bila pretirano natančna – na razpolago so bila določila glede barv, pisav in ozadja, medtem ko box model27ni bil podprt.
Netscape je v tem času močno gradil na »centralni« spletni tehnologiji – JavaScript. Tako je tudi paradigmo slogovnih datotek prenesel v to okolje in avg. 1996 W3C‐ju predlagal JavaScript Style Sheets (JSSS). Istočasno je gradil na verziji 4 Navigatorja, ki bi bil predan popolnoma JSSS – NN4 je bil napovedan za začetek leta 1997. Ker je W3C zavrnil JSSS in priporočil CSS, Netscape pa na to ni bil pripravljen, so ta problem reševali z JavaScriptom, kar je resultiralo v mačehovski implementaciji. (14)
Netscape je pozneje, z Geckom, postal dostojen upoštevalec standardov – popularnost pa mu je dotedaj že močno upadla. Microsoft je standarde zanemarjal in se šele ob MSIE 7 »pokoril«. Nišno področje brskalnikov, ki se opirajo na standarde, ki sta ga NN in MSIE zanemarjala, so v vmesnem času zapolnili drugi – Opera, Firefox, Safari,… Danes NN ne obstaja več, nasledil ga je Firefox, ki, tako kot tudi ostali moderni brskalniki, dokaj natančno sledi standardom.
3.2 Paradigma/sintaksa
CSS pozna selektorje (ang. selectors), lastnosti (ang. properties, nem. Eigenschaften) in vrednosti.
Selektor [, Selektor2, …]{ Lastnost: Vrednost; }
Selektorji lahko predstavljajo elemente, razrede, psevdo‐elemente in ‐razrede; preko njih nato dostopamo do HTML‐elementov oz. trenutnega stanja28.
25 element[attName]{ … } – attribute selectors so močna, a dokaj neznana funkcionalnost CSS. Krivda za to je brez dvoma v tem, da jih MSIE do pred v. 7 ni podpiral.
26 element { content: “text”; } – generated text je možnost, da oblikovalec posameznim elementom doda še vsebino.
27 Box model je osnova paradigma CSS, ki ureja pozicioniranje in dimenzije posameznih elementov. Podpora za b.m. takrat še ni bila krucialna, saj se je postavitev urejala s pomočjo tabel. Tabele so bile sicer zamišljene za »spreadsheet« prikaz podatkov, a so se začele uporabljati za postavitev elementov, saj drugega ni bilo za to na razpolago. Danes se za postavitev (pretirano) uporablja pretežno
elemente. 28 Podrobnejši opis selektorjev je v pregledu CSS 3, na strani 55.
str. 23/84 Manipulacija pozicije in dimenzij vsebine se vrši preko Box‐model, ki je opis pravokotnega prostora, znotraj katerega se odvija vse pri CSS (gl. Slika 1). »Škatle« se generirajo za dokument in vsak element posebej, arhitekt pa ima kontrolo nad njegovimi dimenzijami, ozadjem, vsebino, robom, padding‐om (prostor med vsebino in robom), ter margin‐om (prostor izven robu, ki še spada k škatli).
Slika 1: Box‐model podaja standardno terminologijo in parametre za vizualno prezentacijo elementov v prostoru, katerih naj se bi brskalniki in druga prikazovalna okolja, držali. To pa ne prepreči, da ne bi Internet Explorer zopet delal po svoje…
Kar zveni sila preprosto in nadvse logično, je postala pravcata znanost, saj zopet igra predvidljivi faktor nekompatibilnosti brskalnikov pomembno vlogo. Specifikacija veleva, da je škatla z 200px širine vsebine in 50px padding‐a široka 300px, se torej padding prišteje k dimenzijam vsebine. IE v verziji 5.x pa je uvedel svojo logiko, pri kateri sta širina in višina škatle dimenziji, ki sta merodajni in uporaba padding‐a jemlje prostor vsebini. V praksi so se razvili številni »heki« za obid tega problema, kot je Tantek Çelik‐ov hek, ki uporabi hrošča pri prebiranju‐u (Tabela 1).
div { padding: 50px; width: 300px; /* za IE 5.x */ voice‐family: "\"}\""; width: 200px; /* ostali brskalniki */ voice‐family: "\"}\""; }
Tabela 1: Tantek Çelik‐ov CSS ‐ hek
Enostavnejši hek, ki se je razvil pozneje, se prav tako poslužuje napačne interpretacije te serije IE. Tu se postavi dva prazna komentarja pred in za dvopičjem, ki zmedeta IE 5.x, kot to prikazuje Tabela 2.
str. 24/84 div { padding: 50px; width: 300px; /* za IE 5.x */ width/**/:/**/ 200px; /* ostali brskalniki */ }
Tabela 2: Dva prazna komentarja pred in za dvopičjem zmedeta IE 5.x
3.3 »hasLayout?«
Vir vseh težav s CSS pri Internet Explorerju (Trident) je vprašanje “hasLayout?”. Trident je najstarejši še obstoječ prikazovalnik, ki se uporablja v brskalnikih in njegovo znanje bazira na Spyglass Mosaic (Zgodovina , str. 12), ni pa dolgo časa sledil evoluciji tehnologije. Trident je posledično ostal na razvojni stopnji, ko je bila postavitev elementov v HTML sestavljena iz tabel in vsebine, kar pa je bil tehnično razmeroma enostavno področje – tabelo sestavljajo celice, ki so vsaka zase “škatla” s fiksnimi dimenzijami in pozicijo.
Zmedo v to hierarhijo je vnesel CSS, ki je predvideval pozicioniranje elementov, ki ne ustreza več paradigmi škatle in vsebine, temveč dovoljuje tudi vsebino izven škatle, relativno (torej odvisno od očetovskega elementa) in absolutno pozicioniranje, “lebdeče” (floating) elemente itd.
Za nadgradnjo obstoječega Trident pogona (engine) (standardsko ozaveščeni uporabniki spleta si bi bolj pozdravili preskok na Tasman pogon, ki se je uporabljal v IE na Mac‐u) je Microsoft uvedel svoj lasten atribut “hasLayout” (tipa boolean) za HTML elemente, s katerim definira, ali je dotični element sam zadolžen za prikazovanje (hasLayout='true'), ali pa le‐tega prepusti naslednjemu elementu v hierarhiji, katerega hasLayout je “true” (uporablja se tudi izraz, da “imajo layout”).
Elementi, kot so html , body, table, input, … imajo privzeto layout, medtem ko ga je za druge (span, div, p, …) potrebno eksplicitno definirati, saj v nasprotnem primeru za njihovo postavitev poskrbi nadrejeni kontejner. Dodatno elementu dajo layout tudi določeni CSS‐atributi, kot so width:(!auto), height:(!auto), position:absolute, display:inline‐block, float:left|right, … hasLayout je atribut, ki ga je izrecno možno le brati, implicitno pa se ga postavlja s pomočjo prej omenjenih CSS‐atributov (in določenih lastniških atributov, kot je atribut “contentEditable”, katerega uporaba pa v te namene ni priporočljiva). Njegova pravilna uporaba odpravi večino anomalij, ki jih pozna Trident pri uporabi CSS.
str. 25/84 4. XML
SGML, katerega dialekt je XML, je glede na merila, ki veljajo pri IT‐tehnologijah, prastara tehnologija, saj njegovi začetki segajo v leto 196929. Namen SGML je bil ustvariti opisni (meta) jezik, s katerim bi bilo mogoče opisati nadaljnje opisne jezike. Ta tehnologija je bila ustrezno bolj kompleksna in manj pregledna, kot so to njeni dialekti, ki jih uporabljamo za potrebe spleta.
Ravno nepreglednost in kompleksnost SGML je zavirala njegovo popularno uporabo. Odgovor na ta problem je W3C skušal najti (in ga tudi našel) leta 1996 v razvoju XML. Tako kot pri SGML gre tu za opisni/meta jezik, katerega namen je opisati podatke različnih oblik. Osnovna struktura je izredno preprosta, saj jo sestavlja nabor ad‐hoc definiranih označb (delimiterjev), ki vsebujejo kompleksno vsebino. Preprosta struktura XML in prilagodljivost omogočata poljubo definicijo strukture, kar je pri spletnih tehnologijah pomembno zlasti pri komunikaciji med aplikacijami in hrambi podatkov.
Kot dialekt je XML podvržen pravilom SGML, katere specificira bolj podrobno in strogo. Tako je sintaksa XML »case‐sensitive«, torej se loči med malimi in velikimi črkami, zahtevano je zapiranje označb (tudi tega SGML ne postavlja kot pogoj), atributi morajo biti vsebovani v narekovajih in se lahko pojavijo le enkrat v elementu, označevanje začetka in konca označb pa je omejeno na špičaste oklepaje – SGML namreč dopušča sintakso, kot izvira iz GML30.
Pozneje (1998) se je pojavil še predlog za imenska področja (namespaces) v XML, ki bi služila strukturiranju področij v sami sintaksi. Imenska področja vežejo del kode na prej definirano identiteto (načeloma poljuben niz znakov, a se v praksi uporablja URI spletni naslov), s čimer se prepreči prepletanje kode in konflikte glede imen elementov. Uporaba imenskih področij ni zavezujoča, a se v praksi pogosto uporablja, saj se na ta način posamezne sklope elementov v dokumentih označi kot elemente tujega izvora in kot taki ne vplivajo na validnost glavne sintakse – v XHTML dokumentu »vgrajen« SVG kodni blok se pri validiranju XHTML sintakse ne upošteva kot moteč element, temveč se ga validira v sklopu s pravili SVG sintakse.
XML dokumenti poznajo dva nivoja pravilne uporabe sintakse – well formed in valid. Prvo pomeni, da dokument ustreza osnovnim strukturnim pravilom – pravilno zaprti elementi, zapiranje tudi praznih elementov, atributi v oklepajih, pravilno gnezdenje, medtem ko je dokument valid, če izpolnjuje dodatne gramatične pogoje, ki jih navedemo v za to narejenem opisnem jeziku, kot so DTD, XML Shema,... V obči uporabi je validacija zanemarjena in se razčlenjevalniki kode ter aplikacije
29 Takrat se je razvil predhodnik SMGL – GML.
30 Začetna označba GML se je začela z dvopičjem, zaključila pa s piko, končna označba pa je imela še črko “e” pred imenom, s čimer se je označilo, da gre za zapiranje obstoječe označbe.
str. 26/84 osredotočajo zgolj na pravilno sestavo dokumentov. Preverjanje validnosti dokumentov pa postane pomembno pri izmenjavi podatkov na nivoju poslovne logike in v situacijah, ko je struktura krucialnega pomena.
4.1.1 Sintaksa
Ker je XML tehnologija, ki se je razvila po HTML in si le‐tega vzela za vzor, je logično, da sama sintaktična sestava močno spominja na slednjega ‐ enako kot pri HTML se pri XML elementi označujejo s špičastimi oklepaji ( ).
Dokument je sestavljen iz treh “regij” – neobveznega prologa, ki vsebuje gramatikalna pravila (npr. DTD oz. povezavo do njega), ter ev. ukazov za procesiranje31; telesa dokumenta, ki ga tvori en korenski element in njegovi otroci; ter epiloga32, v katerem so lahko nadaljnji ukazi za procesiranje, “beli prostor”33, komentarji.
Osnovo sintakse tvorijo elementi. Vsebino elementov tvorijo znaki (character data), drugi elementi, ukazi za procesiranje, reference do entitet in znakov34, komentarji35, atributi36.
31 Processing instructions so deli sintakse, ki ne posegajo v strukturo in vsebino podatkov, temveč so namenjeni aplikaciji, ki uporablja XML. PI se označujejo kot sledi: , pri čemer je “naslov” ciljni element, na katerega se PI nanaša. PI, ki je najbolj uporabljen, je značilen – sicer neobvezen, a priporočan – prvi stavek , ki aplikacijo seznani o tem, kakšno verzijo XML uporabljamo, v kakšni kodni tabeli je zapisan dokument itd.
32 Ker XML ne pozna metode, kako označiti konec dokumenta, večina aplikacij konča procesiranje pri zaključni označbi korenskega elementa. Posledično se prolog smatra za napako pri načrtovanju specifikacije.
33 White Space so znaki, ki jih človek kot take ne razloči. Sem spadajo presledki, prelom vrstice, tabulatorji.
34 Reference so sinonimi za poljubne nize znakov, definirane v opisnem jeziku (npr. DTD), ki se začnejo z & in končajo z ;. Referencirati je možno tudi znake v decimalni in heksadecimalni obliki – reference nanje pa se začnejo z . Reference ©, © in © so ekvivalentne in pomenijo znak ©. Referenca, na katero so uporabniki HTML že dodobra navajeni ‐ ki se uporabi za presledek, v XML žal manjka, namesto tega se uporablja , ki je heksadecimalna oblika presledka.
35 Komentarji se označujejo z
36 Atributi sicer ne spadajo direktno med vsebino elementa v sintaktičnem smislu, saj za vsebino smatramo podatke med začetno in končno označbo, atributi pa so sintaktično sestavni del začetne označbe. Kljub temu so semantično gledano atributi pomemben del vsebine, kot taki pa se tudi uporabljajo v praksi. Atributi se zapisujejo kot ime=”vrednost”.
str. 27/84 Nabor znakov znotraj elementa je praktično neomejen (dovoljeni so vsi znaki kodne tabele Unicode 2.1, ki je 16‐bitna), le znaka & in < sta prepovedana – ampersand je namreč rezerviran za označevanje referenc do entitet, znak za manjše pa je začetek nove označbe ali njenega zaključka. Ta dva znaka, kot tudi druge specifične, je možno opisati s pomočjo referenc, ki jih nudi XML.
Ko pridemo v situacijo, ko želimo izpisati znake, ki jih XML ne dopušča – zlasti ko izpisujemo kar kodo samo, so nam na voljo »CDATA sekcije«. Sintaksa zanje je , pri čemer vsebina lahko vsebuje poljubne znake, razen sekvence »]]>« (ne glede v kakšni kodni obliki).
Imenovanje elementov je – enako kot pri njihovi vsebini – praktično poljubno. Unicode kodna tabela nam omogoča, da se imena elementov zapisujejo v večini svetovnih pisav. Edini pogoji za imenovanje so, da se ime začne s črko, podčrtajem ali dvopičjem, v nadaljevanju pa se smejo poleg navedenih uporabiti še številke, pomišljaji in pike. Nadalje se ime ne sme začeti s črkami XML (neodvisno ali so pisane malo ali veliko), saj je to začetek, ki je rezerviran za elemente, ki jih uvede W3C.
XML ima veliko prednosti proti drugim tehnologijam za shranjevanje podatkov – je odprt, brez pripomočkov čitljiv (saj bazira na tekstovnem zapisu) in danes široko podprt. Kot tak se ponuja za komunikacijo med aplikacijami, shranjevanje informacij, opisovanje struktur. Ravno pri shranjevanju in obdelavi podatkov pa ležijo tudi njegove slabosti, saj gola sintaksa zahteva dosti pomnilniškega prostora, procesiranje podatkov pa je ustrezno zahtevnejše.
4.1.2 Gramatika (shemata)
Za opis pravil/gramatike XML in njegovih dialektov je na razpolago več metajezikov (shem): stari DTD (Document Type Definition), moderen W3C XML Schema ter avantgardni RelaxNG (Regular Language for XML Next Generation), Shematron (na XPath – jeziku za navigacijo po strukturi XML, gl. str. 33 – basirajoč sistem) in DSD (Document Structure Description).
Standardi, v katerih so definirani XML in dialekti (XHTML, RSS, ...), so opisani v DTD, ki je do prihoda XML Scheme veljal za najpomembnejši opisni jezik. DTD ima proti ostalim opisnim jezikom prednost, da se ga lahko definira “inline”, torej znotraj dokumenta, poleg tega nudi uporabniku možnost, da definira lastne reference (entitete), s katerimi si lahko olajša delo37. Poleg elementa ENTITY, DTD pozna samo še ELEMENT (definicija elementa, ki lahko vsebuje nadaljnje elemente in atribute), ATTLIST (elementu podrejen seznam atributov) in NOTATION. DTD nam dopušča, da definiramo, ali
37 ‐ ta vzorčna entiteta se v XML dokumentu referencira nato z &imeEntitete; Reference so možne tudi za samo konstrukcijo DTD‐ja. V takem primeru govorimo o parametriziranih entitetah, ki se od vsebinskih sintaktično ločijo z dodatnim %‐znakom: .
str. 28/84 vsebujejo elementi še otroke, kakšne atribute imajo, ali so atributi oz. elementi obvezni, opcionalni, jih je več kot nič oz. ena, opcijske vrednosti atributov itd.
Največji problem DTD je njegova zakrnelost – v njem ni mogoče definirati kompleksnejših informacij, kot so podatkovni tipi, omejitev obsega podatkov in uporabe imenskih prostorov.
(Imenski prostori (namespaces) so virtualni dodatki k imenu elementa. Imenski prostor se definira z uporabo rezerviranega atributa xmlns, kateremu se priredi unikatno vrednost, ki jo uporablja samo ta imenski prostor (ta vrednost je načeloma lahko poljuben niz znakov, priporoča se takšen, ki tvori URI). Ta metoda omogoča, da se v enem XML dokumentu lahko kombinira več naborov XML struktur, brez da se bi zašlo v nevarnost, da bi se pojavila dva elementa z enakim imenovanjem, a različno semantično strukturo.)
Ravno te probleme rešuje W3C XML Schema (WXS), ki pozna kompleksno definicijo tako podatkovnih tipov, kot tudi pravil njihovega obsega, ter dopušča dedovanje. Podatke je možno omejiti celo z regularnimi izrazi. WXS je zapisana v obliki XML, na podlagi pravil, ki jih definira njej lastna WXS38.
Pedantna struktura in definicija podatkov WXS omogoča enostaven prenos strukture v programersko okolje in posledično enostavnejšo manipulacijo s podatki – ob validaciji s pomočjo sheme se generira tkzv. PSVI (Post Schema‐Validation Infoset), katerega aplikacije po validaciji lahko prevzamejo za manipulacijo nad podatki.
PSVI je nekaj, česar DTD ne nudi, a tudi RelaxNG – tretja pomembnejša opcija opisnih jezikov – ga ne. Slednji tudi ne pozna definicije konkretnega števila oz. razpona repeticij posameznega elementa (npr. razred šteje najmanj 15 in največ 32 dijakov). Tudi število razpoložljivih podatkovnih tipov je pri RelaxNG omejeno na string in token (v praksi se izkoristi možnost kombinacije z WXS podatkovnimi tipi). Tako kot WXS se tudi RelaxNG sestavlja v obliki XML dokumenta, oz. opcionalno s svojo – manj prostorsko požrešno in z XML neskladno – sintakso v sklopu “compact syntax”, pri čemer je sintaksa RNG bolj intuitivna in enostavnejša kot sintaksa WXS.
4.1.3 Programatski dostop
Pomembna prednost XML je ta, da je vsebina berljiva tudi z prostim očesom – binarni, lastniški, zapisi podatkov, ki so nastali v bližnji preteklosti, danes deloma sploh niso več berljivi, saj zanje ne obstaja več strojna in programska oprema, ki bi te podatke lahko pretvorila v človeku razumljivo obliko.
38 XML zapis olajša tudi programatsko obdelavo sheme – tako je možna tudi manipulacija s pomočjo DOM, XSL, ter navigiranje preko Xpath. (Definicija DTD bazira na Extended Backus Naur Form, ki pa ni direktno dostopljiva in manipulabilna preko orodij za obdelavo XML).
str. 29/84 Prominentni primeri izgubljenih informacij so razni arhivi preteklih avtoritarnih režimov, ki so svoje “poslovanje” v svojem času prenesli na moderno tehnologijo.
Človeška berljivost in njena široka zasnova, ki jo ponuja XML (večina pisav in svetovnih jezikov), pa za sabo nujno prinašajo obilico dela za računalniške procesorje, saj je tekstovno obliko sprva nujno pretvoriti v računalniško berljiv zapis. Šele, ko računalnik tekst zazna kot drevo elementov, lahko z njim ustrezno manipuliramo.
Najbolj ustaljen model za programatski dostop do XML je Document Object Model – DOM. DOM ni API, ki bi omogočal manipulacijo z XML, temveč definicija vmesnika, kot jo podaja W3C. Posledično je platformsko in sistemsko neodvisen.
Najbolj znana uporaba DOM na spletu so operacije nad strukturo/vsebino dokumenta na strani odjemalca (client‐side) ob uporabi JavaScript. Pri tem velja opozoriti, da brskalnik ne uporablja nujno strukture DOM za lastno sestavo strani, standard od njega zgolj zahteva, da nudi določene objekte, kot so okno, zgodovina, dokument...
Razvoj te tehnologije se je začel v sredi 90ih, bila pa je sprva vsebovana v specifikaciji HTML 4. Samostojna specifikacija – DOM 1 – se je objavila šele leta 1998, dve leti kasneje ji je pa sledil DOM 2, ki je vseboval podporo za imenska področja in slogovne datoteke. DOM 2 je uvedel tudi lastne “dogodke” – DOM events39. Pozneje je sledila še specifikacija DOM 3, ki podpira tudi XPath za standardizirana povpraševanja (querrying), katera pa ne uživa široke podpore.
Glavna prednost DOM je, da celoten dokument pretvori v strukturo objektov. Ker to zahteva vnaprejšnjo predelavo dokumenta, lahko v avtomatiziranem procesu večje količine podatkov pride do nepotrebno dolgega procesiranja podatkov, oz. procesiranje sploh ne bi bilo mogoče, zaradi pomanjkanja spominskih kapacitet. Na tem mestu vskoči SAX40, ki do podatkov dostopa serialno.
SAX besedilo bere od začetka do konca, pri tem pa sproža dogodke, ko pride do novega elementa (enostaven/kompleksen element, ukaz za procesiranje (PI), komentar), oz. se le‐ta zaključi. Tak pristop je bistveno hitrejši, ni pa možna poljubna navigacija, zlasti ne do preteklih objektov.
39 Tako kot sam DOM, predstavljajo tudi DOM‐dogodki zgolj unificirano specifikacijo, ki služi kot mandatorna referenca pri implementaciji tega standarda. Sem spadajo dogodki, kot so onclick, onmouseover, dragenter, close, …
40 Simple API for XML je neformalni protokol – za referenco se uporablja Javina implementacija.
str. 30/84 4.2 XSL, XQuery
Manipulacija XML dokumentov je programatsko intenzivna dejavnost – dokument (niz znakov) je potrebno prvo razčleniti, interpretirati in sestaviti DOM‐drevo, sam način zapisa pa predvideva sorazmerno dosti (računalniku) nepotrebno obilnih informacij (overhead). A tudi iz razvijalskega vidika bi bilo direktno analiziranje teksta in interpretiranje v hierarhično strukturo mučno in takšnega truda nevredno.
Uspešnost tehnologije, kot je XML sigurno ne bi bilo, če ne bi bilo ustreznih podpornih tehnologij, ki na zedinjen način nudijo (načeloma) enako logiko za upravljanje s podatki in drevesno strukturo. Taka podporna tehnologije je DOM, na podlagi katerega gradijo tudi vse ostale tehnologije, kot jih nudi W3C “out‐of‐the‐box” in razvijalcem olajšajo njihovo delo. Sem spadajo predvsem priporočila W3C, zbrana pod pojmom XML Stylesheet Language (XSL): XSLT (XSL Transformations), XPath in XSL‐FO (XSL Formatting Objects).
(Posamezne XSL tehnologije so med seboj tesno povezane, kar onemogoča jasno razdelitev področij. Tako je XPath, kot jezik za navigiranje po hierarhiji elementov, obvezni sestavni del XSLT transformacij, XSLT pa predstavlja del XSL specifikacije, ki se je med samim razvojem “osamosvojil” – XSL‐FO je torej tisto, kar je ostalo od XSL, po tem ko se je odcepil XSLT.)
4.2.1 XSLT
Manipulacijo obstoječe strukture lahko sicer alternativno (oz. odvisno od konteksta) izvedemo s pomočjo rešitev, ki nam jih ponujajo razvijalska okolja za obdelavo DOM, tako da se poslužujemo internih funkcij. Takšen pristop za sabo potegne ne le obvladovanje dotičnega okolja, temveč postane rešitev tako tudi platformsko odvisna. XSLT je standardiziran pristop (torej nabor vhodnih in izhodnih točk), ki se uporablja za enostavne in kompleksne pretvorbe strukture XML v širok spekter izhodnih formatov. Sama sintaksa je dialekt XML, kar dopušča tudi scenarij transformacije že obstoječe transformacije in validacijo.
XSLT je deklarativni programski jezik ‐ tako so na razpolago enostavne funkcionalnosti in tipi, kot so spremenljivka (variable), zanka (for‐each, gl. Slika 2), pogojni operaterji (if, choose) in kompleksni podatkovni tipi, ki dopuščajo dedovanje. A kljub tem lastnostim je XSLT samosvoj jezik, ki zahteva osvojitev nove logike, ki ni enaka tisti, kot so jo razvijalci navajeni pri uveljavljenih programskih jezikih.
str. 31/84
Slika 2: XSLT transformacija, ki napolni JavaScript array (niz) s podatki.
Pomemben aspekt XSLT je njegova moč, da se transformacije lahko izvajajo preko meja dokumentov – možne so spojitve z eksternimi podatkovnimi viri (tudi s spletnimi storitvami). Pomembno je tudi, da se same transformacije lahko izvedejo na strani odjemalca, kar bistveno pripomore k zmanjševanju procesorske zasedenosti na strežniku.
Transformacije pa ni možno le izvajati znotraj brskalnikov, temveč obstajajo tudi implementacije v programerskih ogrodjih, ki omogočajo XSLT manipulacijo znotraj proceduralne kode (Slika 3).
Slika 3: proženje XSLT transformacije znotraj spletne storitve v ogrodju .net 3.5
str. 32/84 Michael Kay v svoji knjigi »XSLT – Programmers reference« opisuje analogijo med XSLT in SQL, saj sta to tehnologiji katerima je skupno, da podpirata pridobivanje in manipulacijo s strukturami, ki hranijo podatke, torej podatkovnimi bazami. Ko SQL pridobiva podatke iz relacijske podatkovne baze, kjer operira s tabelami, slednje združuje, filtrira in na koncu vrne novo tabelo, takrat XSLT pridobiva podatke iz XML DOM dreves, katere združuje, filtrira in kot rezultat vrne novo DOM drevo za nadaljnjo uporabo.
4.2.2 XLink, XPointer, XPath
XLink, XPointer in XPath so tehnologije, ki znotraj potreb XML urejajo navigacijo, povezovanje in naslavljanje. Vse tri so med seboj tesno povezane in se deloma močno prekrivajo.
XLink je tehnologija, ki ne uživa zadostne implementacijske podpore, kar ima za posledico, da je v praksi neuporabljiva – edino Mozilla od popularnih brskalnikov nudi eksperimentalno in močno pomanjkljivo podporo... Sam koncept je v teoriji sicer zanimiv – XLink naj bi urejal hiperpovezave pri XML elementih in s tem odgovoril na vprašanje označevanja hiperpovezav, ki se je pojavilo pri tranziciji iz HTML na XHTML/XML.
(X)HTML pozna element , za katerega velja, da predstavlja hiperpovezavo, a razumljivo je, da XML analognega primera ne pozna in poznati ga tudi ne more. Rešitev prinaša XLink, ki predstavlja nabor atributov, zbranih pod svojim imenskim prostorom, za katere pa velja ravno to, kar velja za , namreč da opredeljujejo način, kako se označi element, ki deluje kot hiperpovezava (Tabela 3).
Tabela 3: z XLink bi bilo mogoče spremeniti vsak element v hiperpovezavo
V kolikor se bi ta koncept oprijel, bi (X)HTML močno izgubil na svoji pomembnosti, saj bi za izdelavo spletnih predstavitev zadoščalo preoblikovati XML dokument s pomočjo XSLT transformacije, mu dodati hiperpovezave in ga oblikovati s pomočjo CSS.
Funkcionalnost XLink je v teoriji bistveno mogočnejša, kot so to v praksi HTML hiperpovezave. Tako XLink določa, ob kakšnem dogodku se proži povezava (xlink:actuate='onRequest | onLoad | ...') ali pa kam se proži povezava (xlink:show:'replace|new|embed' – embed omogoča, da se vsebina povezave vnese v obstoječ element in s tem dinamično gradi hierarhija). Vse to pa so funkcionalnosti, ki se danes izvajajo s pomočjo JavaScript, DOM in dogodkovnega modela, ki ga le‐ta ponuja za HTML elemente (.onclick, .appendChild()/document.write(),...).
str. 33/84 V XLink href atribut je možno vnesti tudi več povezav – za primer, da recimo ena ne bi bila dosegljiva. Povezave, katere bi v takem primeru vnašali, bi bili lahko tudi tipa XPointer. XPointer dopušča, da naslavljamo tudi fiksne ali dinamično preračunane fragmente naslovne strani, do katerih dostopamo preko sintakse iz XPath. HTML href atribut sicer že pozna dostopanje do fragmenta na podlagi ID:
./xp.xhtml #xp2, kar pa XPointer mogočno razširi:
./xp.xhtml#xpointer(//točka[@naslov='xpoint']) in tako uvede vso moč, ki jo nudi XPath.
Če bi kombinirali XLink‐ov show:'embed' z močjo XPointer, da dostopamo do oddaljenih elementov, bi lahko brez nepotrebnih spletnih storitev, razčlenjevanja strani in uporabe skriptnih jezikov vključevali vsebino na drugi lokaciji v naše strani. A to je scenarij, ki je dato (2008) kljub teoriji nemogoč.
Edina navigacijska tehnologija v XML paketu, ki se je obče uveljavila, je XPath. XPath sicer ni nič kaj dosti mogočnejši od obeh prej omenjenih, a ker je njegova uveljavitev pogojena ob uporabi XSLT, katerega je stroka spoznala za koristno dopolnitev k XML, se je imel sploh priliko uveljaviti.
XPath omogoča sistematsko navigacijo po DOM drevesu, s katero hierarhično in pogojno dostopamo do elementov, njihovih vrednosti in vrednosti njihovih atributov. XPath dopušča tudi osnovne aritmetične operacije, ter klicanje funkcij, ki so bodisi del XPath, bodisi del XSLT.
4.2.3 XQuery
Novejša, na prej omenjenih konceptih basirajoča tehnologija, je XQuery (primer uporabe prikazuje Tabela 4). XQuery je dobil status W3C priporočila (recommendation) šele leta 2007 (XSLT in XPath sta to postala 1999), v praksi pa se vede podobno kot XSLT. Osnovan na XPath, katerega uporabi za navigacijo po elementih, se XQuery poslužuje koncepta FLWOR41, da dostopa do podatkov, shranjenih v podatkovni zbirki na način, kot to prikazuje Tabela 4.
for $x in doc("xml_osebe.xml")/oseba where $x/ime = 'janez' return $x/starost
Tabela 4: XQuery dostop do podatkov
41 “For, Let, Where, Order by, Return”
str. 34/84 Tako z XSLT, kot tudi z XQuery je možno filtrirati podatke, jih sortirati, združevati, nad njimi izvajati funkcije in jih sestaviti v poljubno obliko. A kljub temu sta ti dve tehnologiji konceptualno različni – XSLT je namenjen transformacijam manjših zalogajev XML podatkov iz uporabniškega vidika, XQuery pa je koncipiran za rudarjenje po večjih zalogah podatkov. Temu ustrezne so tudi razlike, ki jih je sicer (razen sintakse) zelo malo. XQuery tako ne pozna koncepta templates (predlog), s katerimi se v XSLT definira transformacijo določenega elementa, ne glede kje v hierarhiji se nahaja, saj je to lastnost, ki bi zgolj negativno vplivala pri večjih količinah podatkov, saj je praktično ni mogoče kontrolirati. Nadalje XSLT prednjači pri kozmetičnih aspektih, saj nudi funkcionalnost za formatiranje in lokaliziranje podatkovnih tipov (npr. številke, datum).
4.3 RSS
Razvoj RSS dialekta se je začel s predlogom Applovega (pozneje Netscapeovega) raziskovalca Ramanathana Guhe leta 1996 o odprtem formatu za predstavitev vsebine MCF (Meta Content Framework) v sklopu projekta »Project Sauce/X«, ki je bil pozneje preimenovan v »HotSauce« (15). HotSauce je bil poskus prikaza spletne strani v 3d prostoru, pri čemer naj se bi stran vizualizirala s pomočjo vsebovane strukture MCF. HotSauce se nikoli ni obnesel, že sama logika navigacije je bila preveč nenavadna, da je bi bilo moč uveljaviti. Dejansko je HotSauce predstavil splet kot preprosto računalniško igrico.
Guha je leta 1997 zapustil Apple in prešel k Netscape, kjer je začel razvijati RDF (Resource Description Framework), v katerega je inkorporiral ključne principe MCF.
Začetkom leta 1997 je Microsoft pripeljal z Windows 98 oz. Internet Explorer četrte generacije svojo implementacijo koncepta RDF ‐ Active Desktop ‐ skupaj s podporo za CDF (Channel Definition Format), kar je bila popolna polomija, ker je ponudba presegala razpoložljive kapacitete in je zato praktično nihče ni koristil – Active Desktop je od povprečnega računalnika iz leta '97 terjal precej moči, poleg tega pa ta tehnologija ni primerna za klicno povezavo.
Spomladi leta '97 sta Microsoft in Netscape vsak podala svoj predlog standarda RDF W3C, nakar je jeseni '97 W3C publiciral prvi osnutek RDF, grajen na Netscape‐ovem MCF in PICS42.
Decembra '97 je podjetje Dave Winerja, UserLand Software, začelo ponujati lastno enačico RSS tehnologije, »« ki močno spominja na Microsoftov CDF. se je v
42 Platform for Internet Content Selection je standard za opis vsebine spletne strani, ki se uporablja pri browserjevih nastavitvah in samostojnih aplikacijah kot filter za občutljivim osebam neprimerne vsebine.
str. 35/84 poznejši verziji prijel šaljiv vzdevek »fat syndication« (obilna sindikacija), ker je napram takratni verziji RSSa nudil bolj obširno vsebino channel‐a.
Prva verzija RSS‐a, 0.9 (alias »RDF Site Summary«) se je pojavila 1999 s prihodom Netscapeovega personaliziranega portala »My.Netscape.Com«. Dejansko je bila za RSS 0.9 uporabljena manj obširna verzija, kot jo je predvideval avtor sintakse Dan Libby. Istega leta je Netscape‐u sledil še UserLand s svojo ponudbo »My.UserLand.Com«, ki je podpiral poleg RSS 0.9 še UserLandov .
Bistvena razlika med in RSS 0.9 je bila ta, da je RSS podpiral le naslove novic, medtem ko je omogočal tudi opis vsebine, ki se skriva za naslovom, oz. prikaz vsebine v celoti.
Kot reakcijo na to potezo je Netscape uvedel RSS 0.91 (tokrat: »Rich Site Summary«), ki je prevzel večino funkcij a, My.UserLand.Com je pa uvedel podporo za RSS 0.91. S tem zadnjim dejanjem Netscape opusti razvoj RSSa.
Decembra 2000 je UserLand publiciral RSS 0.92, ki bazira na Netscape‐ovim RSS 0.91 in omogoča uporabo sintakse HTML (HyperText Markup Language) ter implementira podporo za Cloud element, kar omogoča agregatu (programu, ki bere RSS vire), da ga server obvesti o spremembi vsebine, namesto da bi to moral ugotoviti sam.
Sočasno je pa tudi delovna skupina RSS‐DEV emitirala RSS 1.0, ki je baziral na RSS 0.9 in Dan Libbyjevem originalnem konceptu.
Leta 2002 UserLand izda RSS 2.0. Medtem se tvori nova skupina, ki skuša ustvariti nov format, ki bi prezrl vse historične razlike med obstoječimi RSS formati, pod imenom Atom. RSS 2.0 v razliki do Atom ne uporablja imenskih prostorov.
Kljub množici standardov se resni RSS agregatorji trudijo, da bi podpirali vsakega izmed njih. Večina virov RSS glasom spletnih analiz še vedno uporablja 0.91.
4.3.1 Debata o nekompatibilnih standardih
Sintaksa RSS je dialekt XML, zato je dilema inkompatibilnosti bolj ali manj na strani razvijalca agregatov in drugih aplikacij (npr. spletnih agregatov in različnih pretvornikov).
Netscapeov RSS 0.9 je bil kompatibilen s RDF ter je vseboval svoj imenski prostor. RSS 0.91 je ti dve značilnosti odpravil, zato pa dodal DTD, ki dovoljuje uporabo 96 dodatnih entitet za uprizoritev nestandardnih znakov iz sintakse XHTML.
Po publikaciji Netscapeovega RSS 0.91 in odstopu Netscapea iz te domene, je UserLand ta standard vzel, odstranil DTD, rahlo preimenoval nekaj elementov in ga publiciral kot »svoj« RSS 0.91. Z
str. 36/84 odstranitvijo DTD je bila odstranjena kontrola nad strukturo in s tem kompatibilnost s prejšnjo verzijo.
RSS‐DEVov RSS 1.0 naj bi po lastnih trditvah zagotavljal kompatibilnost s RSS 0.9, Mark Pilgrim pa temu ostro nasprotuje, češ da RSS 1.0 uporablja drugačen Namespace, kot ga je pa imel RSS 0.9. RSS 1.0 je tako nekompatibilen z verzijami 0.9, Netscape 0.91 ter UserLand 0.91 (16).
UserLandov RSS 0.92, ki naj bi bil popolnoma kompatibilen s domačo verzijo 0.91 je spremenil semantiko opisa vsebine iz teksta v HTML, kar je drastično spremenilo uporabnost standarda in potrebe za izdajatelja.
Pred publikacijo verzije 2.0 je UserLand še delal na verzijah 0.93 in 0.94, katerih standarda pa nikoli nista bila dostopna javnosti, a so jih uporabljale nekatere znane firme, ki so s tem hotele biti pred svojim časom. Verzija 0.93 doda vsebini nov element za označitev zapadlosti novice, 0.94 le‐tega zopet zavrže, a se s tem ne vrne na nivo verzije 0.92, ker doda semantiki sporočila izbiro med navadnim tekstom oz. HTML.
UserLand RSS 2.0 odstrani atribut, ki označuje izbiro med navadnim tekstom in HTML, ter tako postavi razvijalca pred nerešljivo uganko, ali je ponudnik vsebine želel uporabiti HTML, ali bi rad zgolj komuniciral vsebino, ki se bavi s HTML in zato uporablja njegovo sintakso. Pod identifikacijsko številko 2.0 je izšel kmalu za tem še RSS 2.01, ki je spremenil semantiko zapisa ure in nato še RSS 2.01 r2, ki je RSS 2.0 zopet dodal element za definicijo primernosti vsebine.
Problematika nekompatibilnosti oz. nekonsistentnosti standardov je za končnega uporabnika in za ponudnika vsebin praktično irelevantna, ker je dolžnost agregatorja, da korektno prikaže vsebino. Tvorba takega agregatorja pa ni ravno trivialna zadeva, ki se s obstojem nejasnih direktiv o načinu transformacije podatkov v vsebino še dodatno zakomplicira. Bistvo (oz. izvor) debate o nekompatibilnosti leži v tem, da sta glavna zagovornika inkompatibilnosti razvijalca pomembnega RSS validatorja in tako gledata na zadevo iz strani kompatibilnosti XML strukture standarda, ki upošteva dejstvo, da je XML case sensitive (zazna razliko med malo in veliko črko) in ob implementaciji imenskih prostorov strogo vezan na le‐te.
4.3.2 RSS v praktični uporabi
Ob adventu ideje o RSS et al. tehnika še ni bila kos potrebam te tehnologije, predvsem se je to kazalo pri razpoložljivi internetni povezanosti. Za izkoriščanje polne funkcionalnosti RSS je potrebna spletna povezava, ki je stalno na razpolago. Na začetku se je pojavila še ideja o potisni komunikaciji, razcvetel se je pravo evforijo, češ da bo internet sedaj omogočal tudi broadcasting, torej dejansko pošiljanje informacij do registriranih odjemalcev.
str. 37/84 Ta ideja se ni uveljavila, čeprav RSS še vedno omogoča integracijo tehnologije SOAP43, s pomočjo katere je možna implementacija procesa za takojšnje obveščanje o spremembi stanja, ki deluje po potisnem principu ter tako omogoča oddajanje naročenim odjemalcem.
Burka o novi killer‐aplikaciji se je hitro ohladila in živela zgolj v ozkih insajderskih sferah, a v bistvu tudi ni bila še zrela za množično uporabo, kaj šele oddajanje. Šele pred kratkim se je RSS zopet pojavil izven scene in se vedno bolj dokazuje.
RSS kot tehnologija se je uveljavila predvsem pri »poll‐pull«‐komunikaciji informacijsko‐ komunikacijskih portalov (novičarski‐portali, občasno tudi forumi) do heavy‐userja spletnih storitev, ki iz ekonomičnosti posega po tej tehnologiji ker mu nudi informacije o spremembah vsebine, ne da bi zato bil primoran sam obiskati stran.
Računica je tako za uporabnika, kot tudi za ponudnika informacij zelo enostavna: uporabnik je stalno na tekočem kar se tiče dogajanja na »njegovih« portalih oz. blogih, pridobitev ponudnika informacij je pa v zgoščenem toku obiskovalcev, v kolikor ponuja zanimive informacije. Oddajnik informacije je namreč tisti, ki jo prvi uspe komunicirati uporabniku. RSS tehnologija ta proces bistveno skrajša, ter tako da prednost tistemu, ki jo zna tudi uveljaviti.
V kombinaciji s SOAP ter rssCloud tehnologijo (RSS‐ova implementacija aktivnega obveščevanja) pa se ta proces iz poll‐pull spremeni v push, kar še dodatno forsira distribucijo informacijskega toka.
5. Bogate spletne aplikacije (Rich Internet Applications)
Marketinški pojmi, kot je to RIA, so v praksi dokaj ohlapne definicije tega, kar tehnološki paket obsega. Tako je težko ločiti med dinamično spletno stranjo (DHTML), “web 2.0” aplikacijo (personalizacija, multimediji, etc.)in namizno aplikacijo, ki se poslužuje spletnih storitev za obdelavo in hrambo podatkov, saj načeloma vsi ti tipi lahko spadajo pod krovni pojem “RIA”, kot to ilustrira Slika 4.
RIA so tradicionalno kompleksnejše in »težje« arhitekture, kot statičen HTML in predstavljajo tkzv. debelega odjemalca (Fat/Rich Client). Debeli odjemalec stremi k temu, da čim več operacij izvede v izvajalnem okolju, ki se nahaja na strani uporabnika storitve, medtem ko se na strežniški strani procesira čim manj podatkov, saj se le‐ti tam po možnosti zgolj shranjujejo.
43 Simple Object Access Protocol, standard za klic funkcij preko HTTP protokola, torej delegacijo procesiranja informacij fizično oddaljenem programu.
str. 38/84 Pomembna prednost RIA kot tip aplikacije med spletno predstavitvijo in izolirano namizno aplikacijo je, da se večina operacij lahko izvede na strani odjemalca, medtem ko ostane opravljanje ponudbe in obsega aplikacije na strežniku. Slednje omogoča, da izdajatelj spreminja obseg storitve, posodablja funkcionalnost in uporabniško izkušnjo, s tem pa ne obremenjuje uporabnika po nepotrebnem, kot je to slučaj pri namiznih aplikacijah. Nadaljnja značilnost RIA je, da se izvajajo v peskovnikih (sandbox), ki posledično skrbijo za varnost pri odjemalcu.
Slika 4: Široka definicija RIA zajema vse, kar je med statično spletno stranjo in klasično namizno aplikacij (17)
RIA pa ne smemo ocenjevati zgolj iz tehničnega vidika, temveč je pomemben faktor za to definicijo tudi bogata uporabniška izkušnja. Če bi namreč sledili zgolj tehnični definiciji, da je vsaka predstavitev, pri kateri se na strežniku hranijo podatki, na odjemalcu pa se izvede transformacija v uporabniško izkušnjo, že kar RIA, bi zašli v paradoks, saj bi XML dokument, ki se s pomočjo XSLT transformira v HTML na strani odjemalca, nujno morali šteti v to kategorijo, kljub temu, da uporabnik ne bi razvidel dodane vrednosti v primerjavi s statično HTML stranjo.
Primarni faktor za definicijo RIA je torej bogata uporabniška izkušnja, ki pa pogojuje uporabo ustreznih naprednih tehnologij in znanj. Od takšne aplikacije se pričakuje intuitivna navigacija, bogata grafična izkušnja, ter predvsem »flicker‐free« uporaba.
str. 39/84 5.1 Uspeh RIA aplikacij
5.1.1 Prostočasni in skupnostniportali
Prostočasni portali so moderna zbirališča mladih, kjer najstniki nekonstruktivno zapravljajo svoj prosti čas, nabirajo virtualna poznanstva in obratovalcem teh portalov dajo neprecenljiv vpogled v njihove potrebe, razmišljanje in razvoj. Podatki, ki jih mladi tako radodarno oddajajo od sebe so pomemben vir za družbene raziskave, strani, katere obiskujejo pa so moderni mediji, ki imajo intimen dostop do te ciljne skupine.
Skupnostni (community)‐portali rastejo kot gobe po dežju, njihovo število je nepregledno in današnji mladi so od družbe praktično prisiljeni, da to industrijo podpirajo in vzdržujejo. Poleg nekaj glavnih večjih rešitev (kot jih kot take vidimo na tej strani zemeljske oble), obstaja še malo morje lokalnih in alternativnih klonov vsake rešitve, ki naslavljajo tržne segmente, katere veliki ne morejo.
5.1.1.1 YouTube
Slika 5: nonsens‐video “fag fuckers” na YouTube
YouTube je trenutno najbolj prepoznaven in posledično največji portal za objavo video posnetkov na spletu. Izdelan in dan v javnost je bil tekom leta 2005 s strani treh nekdanjih uslužbencev podjetja PayPal. (18)
str. 40/84 Ta portal omogoča, da uporabniki objavljajo svoje filme, katere drugi uporabniki gledajo in komentirajo. Faktor zabave izvira iz instantnega in osebnega pristopa k sodelovanju v skupnosti, nivo prispevkov pa je dostikrat preprost (Slika 5).
Kot vse uspešne ideje, je tudi YouTube dobil veliko imitatorjev, ki pokrivajo bodisi isto področje, le da lokalizirano (nemški www.MyVideo.de, slovenski www.MojVideo.com), bodisi pokriva niše, ki jih YouTube ne (pornografske vsebine na www.str8up.com, HD videi na www.vimeo.com).
5.1.1.2 MySpace
Slika 6: MySpace je tudi portal, na katerem se predstavljajo znane in manj znane glasbene skupine (lastnik MySpace je medijska korporacija Fox, kar obrazloži marsikatero vprašanje v tej zvezi)
MySpace se je razvil leta 2003 in predstavlja globalno gledano najpopularnejši skupnostni‐portal (ni pa prvi tak portal, saj za takšnega velja skupnostni portal Friendster). Uporabnikom nudi poosebljeno vstopno točko, kjer se le‐ti lahko predstavijo drugim uporabnikom, nanjo dodajajo fotografije in avdiovizualne vsebine.
Uporabniki se med seboj spoznavajo in si izmenjujejo sporočila (načeloma lahkotni pogovor in flirt), se dodajajo kot prijatelje in se povezujejo v skupine. Ker so osebni stiki intenzivnejši pri osebah iz istega kraja, je uspeh lokaliziranih storitev tega tipa močnejši – to velja tako za nemški klon
str. 41/84 www.StudiVZ.de, kot tudi za lokalizirane globalne variante, kot je to belgijski www.netlog.com. (In tako kot vse drugo na spletu, velja tudi za MySpace &co. »Rule 3444«: www.xPeeps.com.)
MySpace uživa poseben medijski status, saj je njegov lastnik ameriško podjetje Fox Interactive Media, ki spada v medijsko mrežo News Corporation ameriškega tajkuna Ruperta Murdocha. Tako je tudi razumljivo, da se na MySpace predstavljajo že uveljavljene glasbene skupine (Slika 6), medtem ko nanj silijo tudi neuveljavljeni glasbeniki v upanju, da se jih bi opazilo. Lastna predstavitev glasbene skupine na tem portalu spada že med standardni PR‐repertoire vsakega glasbenika, odgovarjanje na komentarje in dodajanje »prijateljev« pa pozitivno vpliva na razpoloženje med oboževalci.
5.1.1.3 Stickam
Slika 7: Uporabniki Stickam so online na vsakem koraku, tudi med spanjem in spolnimi odnosi
Stickam je portal, ki s pomočjo Flash omogoča njegovim uporabnikom prenašanje videa v živo. Uporabniki se snemajo v lastnem bivalnem okolju (Slika 7), pri tem pa se preko te storitve
44 “Rule 34” je spletni žargon, ki stoji za There is porn of it, no exceptions. Spletni žargon je sestavljen iz akronimov (lol, rofl, …), namerno napačno napisanih angleških besed (“liek” namesto like, “caek” namesto cake – pa še to ima globji pomen…, “internets” ), šifer, ikon in simbolov, ki so pogosto nastali situacijsko znotraj nonsens‐portalov kot so www.4chan.org ipd., in so se dogmatično preoblikovali v samosvoj jezik uporabnikov interneta.
str. 42/84 pogovarjajo s prijatelji in popolnimi neznanci. Moto te strani je bil sprva »broadcast yourself – live«, a se je pozneje spremenil v »express yourself – live«, saj je bil »broadcast yourself« že moto od YouTube. Zaradi mikave priložnosti je ta portal postal zbirališče spolnih prestopnnežev, ki – tudi otroke – pozivajo k spolnim dejanjem pred kamero45. Videoposnetki uspelih »flashov« (ko žrtev za hip pokaže intimni del svojega telesa) in daljših intimnih dejanj pa postanejo priljubljen material na portalih s pedofilsko vsebino.
Stickam je vzbudil medijski interes, ko je postalo znano, da je podjetje, ki upravlja Stickam, last Japonca Wataru Takahashi, ki si lasti tudi pornografsko produkcijsko hišo in obratuje več deset spletnih portalov, ki ponujajo spolne predstavitve v živo. (19)
5.1.1.4 I'm in like with you
Slika 8: “Why hang out with your friends in person when you can do it on the internet?” igre, aktivnosti in flirt so centralna dejavnost portala iminlikewithyou
45 Video kamere v otroških in najstniških sobah že od nekdaj veljajo za možen vir zaslužka in za preprost način vzpostavitve stika do mladoletnih oseb v njihovem intimnem okolju. Medijsko odmeven je bil leta 2005 objavljen primer Justina Berry, ki je od svojega trinajstega leta naprej služil denar na način, da je moškim preko interneta nudil spolne usluge. (32)
str. 43/84 IILWY je portal, zgrajen v tehnologiji Adobe Flex (gl. str. 47), ki se totalno poslužuje tehnologije Flash. Tudi IILWY cilja na najstniško populacijo, od MySpace, FaceBook ipd. pa ga loči to, da je njegovim avtorjem uspelo ujeti dušo spletne scene in jo zapakirati v ljubko uporabniško izkušnjo.
Uporabniki na IILWY zbirajo točke, s tem da odgovarjajo na statistična vprašanja, ki jim jih zastavi sistem, nalagajo slike, gradijo na svojem profilu in igrajo igrice (Slika 8). Flirt‐faktor sistem proizvede na način, da uporabniki pozornost druge osebe (npr. zmenek) pridobijo na licitaciji, na kateri zastavijo svoje točke).
IILWY je pretežno US‐ameriški portal in ne nudi lokalizacije, ustrezno je v naših krajih manj poznan in uporabljen (uporabnike, ki kot svoj kraj bivanja navajajo Slovenijo je julija 2008 bilo manj kot 30).
5.1.2 Poslovne aplikacije
Poslovne RIA aplikacije so manj pogoste, kot najstniški portali, in tudi klientela je zahtevnejša. Temu ustrezno so aplikacije bolj resne in se izogibajo uporabi pretiranih animacij in grafik. V to kategorijo lahko štejemo aplikacije, kot so GMail, Flickr in na AIR basirajočega Ebay Desktop.
5.1.2.1 GMail
Slika 9: Verjetno najpopularnejša (in najbolj uporabna) RIA aplikacija ostaja Googlov pristop k pošiljanju mailov – GMail
GMail (Slika 9) je aplikacija, ki zaradi svojega (ob prihodu leta 2004) inovativnega pristopa in močne baze uporabnikov, predstavlja neprecenljiv vir informacij o človeški komunikaciji in osebnih podatkov njegovih uporabnikov, s katerimi Google praktično svobodno lahko razpolaga, saj se precejšnji del komunikacije steka preko njihovih strežnikov.
Sam projekt je obstajal že leta pred tem, a se je uporabljal zgolj za interne potrebe uslužbencev Google. Aplikacija bazira na Ajax tehnologijah, kar je bila leta 2004 presenetljivo inovativna uporabniška izkušnja. S tem inovativnim pristopom je Googlu uspelo izriniti do takrat dominantne ponudnike spletne pošte, kot so bili Microsoftov Hotmail, nemški Lycos ipd.
str. 44/84 Pozneje je Google ponudil še več RIA aplikacij za pisarniško področje ‐ spletni urejevalnik besedil, koledar, aplikacijo za tabelarno kalkulacijo itd.
5.1.2.2 Ebay Desktop
Slika 10: Nakupovanj na Ebay je možno tudi brez brskalnika, kar v tem primeru omogoča Adobe AIR
Posebnost Ebay Desktop je v tem, da je to prva pomembnejša aplikacija, ki gradi na tehnologiji Adobe AIR (gl. spodaj). Program se enostavno namesti preko spletne strani, nadalje pa deluje kot namizna aplikacija ‐ Slika 10 ga prikazuje v okolju Windows Vista.
5.2 Tehnologije
Era RIA se je začela s pojavom Java‐apletov, ki so uporabniku nudili interakcijo na strani uporabnika in bolj sofisticirano uporabniško izkušnjo. A Java‐apleti so že nekaj let (2008) zastarela tehnologija, zamenjali so jih Flash in »Web 2.0« paradigme, kot je Ajax46. Prihod skupnostnih‐portalov, kot so
46 Asynchronous JavaScript & XML je paradigma, ki se poslužuje XmlHTTPRequest objekta, do katerega se iz strani odjemalca dostopa preko JavaScript. Ta objekt kliče strežnik z parametrom niza znakov (praviloma v obliki XML) in vrne odgovor. XmlHTTPRequest je simpatična tehnologija, saj omogoča komunikacijo s strežnikom brez osvežitve strani. »Ajax« per se je zgolj marketinški pojem, ki označuje uporabo te tehnologije.
str. 45/84 YouTube, Habbos, I'mInLikeWithYou in Stickam, je Flash pozicioniral kot absolutnega tržnega vodjo, saj vse aplikacije bazirajo na tej tehnologiji.
Kot odgovor na tržno situacijo je Microsoft začel razvijati platformo Silverlight (XAML), Adobe je nastopil z Flex (MXML), Mozilla foundation je razvila platformo/dialekt XUL (47). Skupno vsem tem platformam pa je, da njihov opisni jezik bazira na lastniškem dialektu XML, da jih je možno uporabiti tako v spletnih, kot tudi namiznih aplikacijah, ter bazirajo na paradigmi delitve programske logike od grafičnega prikaza.
Pri proučevanju RIA je treba razumeti, da gre za krovni pojem, ki obsega tako lastniške, odprte, binarne in tekstovne platforme, ki razvijalcem nudijo širok spekter razvijalskega izkustva, različne nabore programskih jezikov in načinov obdelave informacij. Skupno tem sistemom je le to, da bazirajo na paradigmi strežnik‐odjemalec, pri čemer slednji odigra enakovredno, če ne celo pomembnejšo vlogo pri ustvarjanju interaktivnega uporabniškega izkustva.
Pri odjemalcu se ustvari dodaten sloj, ki vsebuje poslovno logiko za bogato interaktivno izkušnjo. Ta sloj odvisno od storitve tvori koda, sestavljena v skriptnem jeziku ECMA (JavaScript, JScript, ...), ki se izvaja v brskalniku (brskalnik, oz. v operacijski sistem integrirano izvajalno okolje), bodisi je za poslovno logiko pristojno lastniško okolje, ki ga kot plug‐in ali samostojno rešitev ponuja proizvajalec RIA sistema (kot je to pri Flash, Silverlight, Curl,...). Naloga strežnika v tej paradigmi se v pretežni meri zmanjša na posredovanje kode in ogrodja aplikacije (ter preko spletnih storitev in sorodnih metod v posredovanje podatkov), medtem ko se končno izkustvo dinamično zgradi na strani odjemalca.
Sam pojem RIA je marketinški pojem, ki ga je uvedla Macromedia leta 2002, pred tem se je isti princip uporabe tehnologij opisoval kot »X Internet«, »Remote scripting«, »Rich web clients«, »Rich web application«, kar pa ne vpliva na širino pojma in funkcionalnosti.
Pomemben manko večine komercialnih/lastniških RIA sistemov leži v njihovi semantičnosti. Medtem ko je HTML opisni jezik, ki si prizadeva za semantično strukturo, katera je berljiva tudi z nevizualnimi prikazovalniki (braille, zvok…), to pri Flash, XUL &c. tehnično ni nujno predvideno. Za aplikacije, katerih koda ni v naprej prevedena (kompilirana), temveč pride do uporabnika v opisnem jeziku, kot
47 RIA platform je na tržišču več kot zgolj naštetih. Tako se Sun Microsystems pojavlja z JavaFX, Sumisho Computer Systems ponuja Curl, ki je v uporabi predvsem na azijatskem tržišču, pionir te paradigme, Laszlo Systems pa je svojo tehnologijo dal na razpolago odprtokodni skupnosti pod nazivom OpenLaszlo. A tudi Google se pojavlja med ponudniki RIA‐platform s Google Web Toolkit, ki uporablja tehnologijo Google Gears, ki nudi – podobno kot HTML 5 (glej str. 49) – dostop do podatkovne baze na strani odjemalca, s čimer se zagotavlja funkcionalnost aplikacij brez povezave.
str. 46/84 tudi za Ajax‐aplikacije se je razvil koncept WAI‐ARIA48, ki uvaja atribut »role« za elemente. Na ta način je programu, ki bere kodo, moč razbrati semantično strukturo strani, kljub temu, da se uporabljajo klasični oz. lastniške označbe (npr.
). RIA so postali novo veliko bojišče na trgu internetnih storitev, saj gre definitivno za pomemben segment, ki obljublja inovacijo v ponudbi tehnoloških rešitev. Sočasno ko najavljajo RIA revolucijo namiznih aplikacij, postaja strateško pomembno vprašanje, čigav pristop ali standard bo nadvladal tej ponudbi. Da se bi hitrost fizičnega razvoja tehnologij nadaljevala enako kot v zadnjih desetletjih, je sila malo verjetno ‐ glede na aktualni razvoj globalne energetske situacije je prej verjetna stagnacija ali celo upad tehničnih zmožnosti v prihodnosti, a tudi v primeru stagnacije je razvitost infrastrukture danes že dovolj dobra za razcvet takšnih storitev.
Vprašanje, ki se torej postavlja je, kdo bo dominiral na trgu RIA, saj je od tega vprašanja odvisna tudi prevlada v ostalih tržnih segmentih. Platformsko neodvisne programske rešitve, ki ne potrebujejo polnega dostopa do sistemskih resurs pomenijo nov pogled na vlogo operacijskih sistemov, saj bi današnjo vlogo operacijskih sistemov zamenjala izvajalna okolja (runtime environment) za RIA, ki razen skromnega repozitorija in dostopa do spleta praktično ne bi več posegala v integriteto gostiteljskega sistema. Predvsem GUI, ki se je pojavil v 80ih letih prejšnjega stoletja, bi s tem signifikantno zgubil svojo pomembnost.
5.2.1 Adobe Flex
Prednost Flex proti preostalim tehnologijam v tem segmentu je očitna – proizvaja Flash, ki je glede na raznolikost obstoječih izvajalskih okolij (RTE) in z obzirom na močno podprtost te tehnologije najbolj zanesljiva rešitev.
Flex se je pojavil na trgu leta 2004, takrat še pod okriljem Macromedie49. Ta paket bazira na platformi J2EE, opisnem jeziku MXML50in Macromediinem dialektu ECMAscripta51 ‐ ActionScript. Za lažjo upravljanje izgleda je dopustna tudi uporaba CSS. Koda se nato prevede v binarni Flash + ActionScript, ki se servira odjemalcem. (Špekulira se, da bo Adobe v verziji 4.0 – leta 2009 – opustil prevajanje v binarno obliko in dopustil, da se MXML distribuira direktno. (20))
48 (Web Accessibility initiative ‐) Accessible Rich Internet Applications
49 Macromedio je kupil Adobe leta 2005
50 Kaj pomeni »M« v akronimu, ni popolnoma jasno. Ena izmed špekulacij je, da stoji za »Magic« (20), možno pa tudi, da stoji za »Macromedia«, ali izhaja poimenovanja programskega sklopa Creative Suite MX.
51 ECMAScript je nadrejeni standard dialektov, kot so JavaScript, JScript, InScript,…
str. 47/84 Adobe‐jev Flex je v svojem bistvu močno podoben poznejšemu (Microsoft‐ovem) WPF/Silverlight pristopu. Enako kot Microsoftova rešitev, ki je uporabljiva tako na spletu, kot na namizju, tudi Adobe ponuja namizno implementacijo pod imenom AIR52, konkurenčnost teh dveh softverskih velikanov na tem področju pa se opazi tudi pri razvijalskih/oblikovalskih orodjih, ki jih ponujata:
Microsoft razvijalcem nudi stabilnost Visual Studia, oblikovalcem pa predlaga uporabo oblikovalske palete Expression Tools, na čelu z orodjem Blend, s katerim naj bi oblikovalci intuitivno risali in razvijali uporabniške vmesnike, Adobe na drugi strani pa se opira na svojo alfa pozicijo, ki jo ima na oblikovalski sceni s paktom Creative Suite, na Blend pa odgovarja s programom Thermo, ki ponuja rešitve za enake probleme, le da bolj prilagojeno obstoječi oblikovalski logiki.
5.2.2 Microsoft Silverlight
Z .Net 3.0 in Windows Visto je Microsoft uvedel novo predstavitveno platformo, WPF53. V tej paradigmi pride do uporabe lastniškega opisnega jezika, XAML, ki je standard za opis strukture in izgleda aplikacij.
Silverlight54 je omejen nabor XAML, namenjen uporabi v spletnih aplikacijah. Medtem ko WPF nudi tako vektorsko grafiko in animacijo, kot tudi podporo za 3D‐grafične elemente, se Silverlight slednjemu v prid kompatibilnosti odreka. Posledično se uporabna vrednost te tehnologije skrči na alternativo k Flashu, ki pa je bistveno bolj uveljavljen.
V času nastajanja tega besedila (spomlad/poletje 2008) v javnost prihaja druga različica Silverlight. Prva verzija je nudila zgolj XML‐dialekt za opis osnovnega GUI in animacije, pri čemer je vsa interakcija bazirala na »Ajax« paradigmi (skriptni jezik in spletne storitve). Od takšne omejene funkcionalnosti večjega odziva ni mogoče pričakovati, saj animacijske in multimedijske kompetence ne presegajo bistveno možnosti, kot jih nudi uveljavljeni Flash.
Microsoft je spoznal, da zgolj kot spletni RIA Silverlight ni konkurenčni produkt, saj medtem ko prednost WPF leži pri integriranosti v .Net platformo, ki naslavlja večji segment programerjev kot skriptni jeziki, ki jih uporabljajo AIR &c., se ta prednost na spletu zopet izniči ‐ Silverlight omogoča interakcijo zgolj skozi JScript/VBScript. Ta problem rešuje Silverlight 2 (verzijska številka 1.1 se je iz
52 »Adobe Integrated Runtime«, prej znan pod kodnim imenom »Apollo«. Verzija 1.0 se je objavila šele 25.02.2008.
53 Windows Presentation Framework, prej poznan pod kodnim imenom »Avalon« je grafični sistem Viste, ki se poslužuje Direct3D pogona za vizualizacijo.
54 Prej znan kot WPF/E (everywhere)
str. 48/84 marketinških razlogov spremenila na 2), ki tudi na spletu obljublja vso moč .Net platforme, obenem pa nudi enostavno tranzicijo med namizno in spletno RIA.
5.2.3 XUL
XML User Interface Language / XUL, je opisni jezik, ki se je razvil za potrebe projekta Mozilla. Mozillini programi, kot so Firefox, Thunderbird, Seamonkey, danes svoj UI bazirajo na tem ogrodju, kar olajša predvsem prenosljivost na druge operacijske sisteme in platforme (potrebna je le implementacija ogrodja55).
Zanimivost XUL iz oblikovalskega vidika je, da se poslužuje CSS za opis izgleda in le‐ta ni fiksno kodiran v opisni jezik, kot je to pri ostalih alternativah. Na ta način je bistveno lažje izvedljiv zamenjava izgleda programov (kar zgledno deluje pri Firefox/Netscape), v zameno pa ni možno izvesti efektov, kot jih nudijo lastniški načini opisa oblike.
Poleg Firefox‐a je edina pomembnejša (v obče uporabniškem smislu) aplikacija, ki uporablja XUL, p2p‐televizija Joost56, ki se splošno opira na odprtokodne rešitve. (21)
5.2.4 JavaFX
Poleg Silverlight/WPF je JavaFX edina iniciativa, ki naslavlja obstoječ močno razvit trg razvijalcev, torej tisti del programerskega spektra, ki se je specializiral na Javo. JavaFX je RIA platforma/tehnologija, ki jo svojim privržencem že dobro leto obljublja Sun, a je poleti 2008 še (vedno) v plenicah57, izid pa je najavljen za jesen 2008.
JavaFX bazira na Javinem ogrodju za uporabniške vmesnike Swing, iz uporabniškega vidika pa predstavlja platformo, ki nudi bogate grafične in animacijske možnosti ter intuitivno konvergenco različnih uporabniških izkušenj (namizje, splet, mobilne naprave...). V nasprotju z Silverlight, JavaFX dopušča tudi 3D‐grafiko na spletu. Aplikacije se prevedejo v bitno kodo, ki se nato izvaja na JVM, s čimer je JavaFX tehnologija, ki gradi na obstoječi podpori tehnologiji. Hkrati je JavaFX tudi ena redkih
55 Pri tem je potrebno omeniti, da trenutne inštalacije Firefox &co. vsaka s sabo prinese potrebne resurse za izvajalno okolje. V bodoče se namerava to poenotiti s platformo XULRunner.
56 Joost je koncept spletne televizije, ki bazira na P2P principu. Sicer ponuja veliko programov, a vsebinsko nudi le malo, kar bi zanesljivo pritegnilo gledalca. Uporabniki imajo možnost, da komentirajo oddaje, ter se med seboj pogovarjajo, reklama se pa pojavlja v obliki pojavnih oken, na katere je možno klikniti.
57 Med razvijalci, ki uporabljajo Javo, obstaja splošno nezadovoljstvo glede lansiranja novih orodij in tehnologij matičnega podjetja. Tudi JFX glede na razvitost konkurenčnih produktov “caplja” za njimi. JFX je Sun uradno najavil na ključni Java‐konferenci JavaOne, maja 2007.
str. 49/84 RIA tehnologij, ki se ne poslužuje XML kot deklarativne sintakse za izgradnjo strukture, temveč se poslužuje nove sintakse za izgradnjo aplikacij, z istim imenom – JavaFX Script. Ta sintaksa močno spominja na strukturni pristop, kot ga pozna JSON58, a tudi proženje dogodkov, imenovanje in inicializacija spremenljivk so močno poenostavljeni v prid pri spletnih razvijalcih uveljavljeni logiki.
5.2.5 Open Laszlo
Laszlo je edina RIA platforma, ki se prilagaja izvajalnemu okolju in ne pričakuje obratnega. Medtem ko druge platforme bodisi zahtevajo lastne RTE ali skrb za ustrezne pogoje delegirajo brskalnikom, se Laszlo zaveda hib izvajalnih okolij in jih skuša samodejno premostiti.
Izložek (output), kot ga proizvede Laszlo, je bodisi Flash, bodisi “Ajax”, bodisi mobilno okolje – le‐to pa določi razvijalec sam. Do leta 2006 je Laszlo poznal le Flash, pozneje je temu dodal še Ajax/DHTML funkcionalnost, leta 2007 pa še možnost, da se generira vsebina za mobilne in druge naprave (TV,…).
Podobno kot Flex uporablja MXML za projektiranje aplikacije, tudi Laszlo pozna svoj XML opisni jezik LZX, v katerem razvijalec – s pomočjo JavaScript– zgradi aplikacijo in funkcionalnost, katero ogrodje (Java servlet na strežniku) nato prevede v eno izmed izhodnih načinov. (Na tem mestu velja omeniti, da se JavaScript, s katerim se razvija aplikacijo, tudi za potrebe Ajax/DHTML izložka redefinira in optimizira, predvsem iz vidika prilagojenosti različnim platformam.)
5.2.6 Curl
Curl je na občem trgu neuveljavljena in nišna platforma, ki se osredotoča na poslovni trg. Historično gledano je Curl najstarejša modernih RIA platform, saj je bila vzpostavljena že leta 1998 (Flash je sicer izšel leta 1996, ni pa naslavljal istega tržnega segmenta). Pozneje je ameriško podjetje Curl inc. zašlo v finančne težave, nakar so ga kupili Japonci in prelevili v uspešno podjetje s fokusom na poslovnem trgu.
Tako kot Flash in Silverlight, tudi Curl potrebuje lasten RTE, ki se inštalira preko vtičnika, aplikacije pa poganja lastna koda, spisana v svojem programskem jeziku istega imena. Medtem ko Curl ni namenjen animacijam in “bogatim” spletnim vsebinam, kot je to osrednja funkcionalnost Flash in Silverlight, le‐ta nudi zanesljivo in varno platformo za aplikacije znotraj podjetij.
58 JavaScript Object Notation je princip zapisa strukture objektov v JavaScript, ki omogoča dokaj logično in enostavno zapisovanje hierarhije in lastnosti objektov. JSON je postal popularen predvsem v povezavi s spletnimi storitvami, kjer komunikacija poteka opcijsko s pomočjo JSON namesto XML. (JSON in spletne storitve, str. 65)
str. 50/84 5.2.7 Google Web Toolkit
GWT ni RIA platforma v tradicionalnem smislu, saj predstavlja odprtokodno zbirko orodij v Javi za izdelavo klasičnih “Ajax” aplikacij, a hkrati ni zaprta knjižnica funkcij, kot jih obstaja mnogo. Google si z GWT prizadeva razvijalcu nuditi orodje, ki se prilagaja uporabniku aplikacije in njegovemu izvajalnemu okolju.
Koda se piše načeloma v Javi, pri čemer je omogočeno, da se piše lahko tudi “surovi” JavaScript, pozneje pa se prevede v optimiziran in brskalniško neodvisen JavaScript, kakršnega uživa na to uporabnik.
Ustrezno Googlovem globalnem konceptu, je GWT močan uporabnik drugih Googlovih API‐jev, kot je to storitev za shranjevanje podatkov na strani odjemalca, Google Gears.
5.3 Sklep
Ob čedalje kompleksnejši predstavitvi spletnih tehnologij in razcvetu ponudbe RIA aplikacij, se upravičeno sprašujemo, čemu so brskalniki že preko 20 let praktično enake oblike – kockasti, z naslovno vrstico, zavihki in vsemi za navigacijo potrebnimi in nepotrebnimi gumbki.
Zelo predstavljiv in v praski dobrodošel koncept bi bil iskalnik (pa naj bo to kar Google) vgrajen v iskalnik operacijskega sistema59 ‐ tako OS X‐ov Spotlight, kot Vistin Search predstavljata nov koncept uporabniške izkušnje, ki zamenja iskanje po drevesni strukturi v iskanje preko tekstovnega vnosa – spletne strani, ki jih bi uporabnik poklical, pa se bi izvajale v aplikaciji brez izgleda. In namesto, da bi uporabnik shranjeval označbe, bi si virtualno »inštaliral« te spletne programe v repozitorij, kjer se nahajajo programi.
Spletne aplikacije, ki danes konkurirajo »namiznim«, kot so Googlova paleta pisarniških aplikacij (gMail, Google Docs itd.), interchange/storage‐storitve, kot so .Mac/MobileMe, Flickr in individualni spletni portali, aplikacije za elektronsko bančništvo itd. bi lahko realno še naprej eksistirale na spletu, na uporabnikovo zahtevo pa se bi virtualno izvajale, kot da jih bi imel uporabnik inštalirane na lastnem računalniku (OS X‐ov .Mac/MobileMe je že polno integriran v sam operacijski sistem – dostop se vrši preko Finder‐ja (iDisk) in drugih aplikacij).
Ob upoštevanju naprednih konceptov in smernic, katerim sledi razvoj spletnih aplikacij, zlasti iz vidika shranjevanja podatkov na strani odjemalca (Google Gears, DOM Storage in individualni shranjevalni mehanizmi lastniških RIA platform), je to koncept, ki je v bližnji prihodnosti zelo izvedljiv. Meja med
59 Cafeinated Cocoa software ponuja plug‐in za OS X, ki prikaže rezultate iskanja v Spotlight (http://www.caffeinatedcocoa.com/googleImporter/index.html)
str. 51/84 spletnimi in namiznimi aplikacijami ni več tako velika, da bi zahtevala vizualno ločevanje – mini‐ aplikacije, ki se opirajo na spletne tehnologije, kot so Mac Os X‐ovi in Operini »Widgets« ter Windows Vistini »Gadgets«, pa že danes implementirajo ta koncept RIA, ki bazira na odprtih standardih.
Samostojno prikazovanje HTML strani sicer ni nič novega, tudi ne razne integracije v operacijski sistem. Tako je že Windows 98 ponujal Active‐desktop, ki pa nikoli ni zaživel in zašel v pozabo (enako velja za »RSS«, kot ga je predstavil isti OS, ki pa je zaživel nekaj let za tem). Tudi danes Windows še vedno uporablja HTML Applications (.hta), spletnih strani, ki se odprejo v samostojnem oknu in se poslužujejo Trident okolja za prikazovanje.
Podoben, rahlo nadgrajen princip predlaga Mozilla s aplikacijo Prism (pred tem pod imenom WebRunner). Prism je brskalnik, zgrajen v XUL, ki se poslužuje Gecko okolja (Firefox etc.) za izris spletnih strani. Spletne strani smatra kot aplikacije in jih kot take integrira v okolje OS (z bližnjico, shranjevanje med ostale aplikacije,...) in jim omogoča, da imajo svojo ikono. Razvijalec lahko naredi svoje »programske pakete«, ki vsebujejo kodo, grafiko, ikono,..., jih skrči ter jim doda končnico .webapp – takšne pakete Prism prepozna kot virtualne aplikacije in jih odpre v samostojnem brskalniku60.
Obstoječi ponudbi manjka le še, da razvijalci operacijskih sistemov storijo odločujoč korak in »brezšivno« integrirajo koncepte RIA v uporabniško izkustvo svojih operacijskih sistemov. Ta korak bi bil storjen že s tem, da bi Prism nudil možnost odstranitve okvira in ozadja, ter na ta način prepustilo razvijalcu, da sam definira izgled ozadja (efekti prosojnosti s pomočjo PNG oz. SVG) ter načina zapiranja okna. Funkcionalnost, kot opisano, nudijo tako Widgets/Gadgets, kot tudi izvajalno okolje v katerem se izvajajo Silverlight/WPF aplikacije na namizju, ter Flash‐izvajalnega okolja AIR.
Tabela 5 prikazuje analizo prednosti in slabosti (SWOT) posameznih RIA rešitev, iz katere je razvidna jasna prednost rešitev, ki jih ponuja podjetje Adobe.
60 Za ta koncept se uporablja pojem Site Specific Browser (SSB). SSB sicer predvideva integracijo brskalnika v samo aplikacijo, pri čemer se Prism nekoliko oddaljuje od te paradigme v smislu, da ne integrira brskalnika v sam .webapp, temveč asociacijo izvede ad‐hoc (možen bi bil torej tudi scenarij, ko se bi odjemalec želel poslužiti drugega izvajalnega okolja za .webapp aplikacije, recimo WebKit ali Trident. Ker je za takšne implementacije brskalnikov značilno, da ne obremenjujejo uporabnika z nepotrebnimi okvirji in navigacijskimi koncepti, se pojavlja tudi pojem »distraction free browser« (35).
str. 52/84 prednosti slabosti priložnosti tveganja Silverlight Bazira na .net platformi, s čimer Silverlight vnaša novo logiko Kapital, ki ga premore Microsoft bi Silverlight ni inovativna storitev, saj nudi napredno razvijalsko okolje, razvijanja spletnih aplikacij, ki lahko dovedel do brute‐force prevlade konkurira močno uveljavljenemu močna orodja in zanesljivo ni skladna z obstoječo sektorja RIA‐ in namiznih aplikacij Flash. Dominanca Microsoft‐a se tehnološko podporo. Tehnologijo paradigmo, a tudi oblikovalska bodočnosti. občutno zmanjšuje, zamenjujejo jo je mogoče tesno povezati z orodja, ki jih Microsoft nudi odprte rešitve. Internet Explorerjem, kar oblikovlacem v te namene, zagotavlja pomembno podporo. predstavljajo nekaj novega, kar zahteva čas za uveljavitev.
Flex/AIR Tudi to platformo podpira močna Medtem ko so orodja, ki jih Flash je skoraj 100% podprta Flash je sicer neosporavani lider na interesna skupina – Adobe, ki izdeluje Adobe za oblikovalce, platforma, kar pomeni dober začetek. področju bogatih medijskih vsebin drži faktični monopol na vrhunska in vodilna, so orodja Flash je de‐facto dominantna lastniške na spletu, a pri resnejših aplikacijah področju grafičnega in spletnega za razvijalce sorazmerno tehnologija v tem segmentu na spletu, se sooča z uveljavljenimi konkuretni, oblikovanja. Orodja naslavljajo amaterska. s čimer ima AIR pomembno strateško kot sta Microsoft in Sun. Čas bo utečeno ciljno skupino. Podpora prednost proti glavnemu tekmecu pokazal, ali je mogočna baza RTE je zagotovljena. Silverlight. oblikovalcev pomembnejša od ustreznih razvijalskih kadrov.
XUL XUL bazira na spletnih standardih XUL podpira le matična Ker je sestavni del projekta Mozilla, ki Mozilla foundation ni Microsoft, in (XML, CSS) in odprtih organizacija – Mozilla, kar ga uživa vzpon zaradi priljubljenosti tudi ne Adobe. V teh dimenzijah tehnologijah, kar močno olajša kot spletno tehnologijo naredi brskalnika Firefox, ima XUL neko mero relativna majhnost projekta mu ne prehod na to tehnologijo za neuporabnega. potenciala. Njegova prednost leži daje dovolj prostora za uveljavitev. spletne razvijalce. predvsem v tem, da gradi na obstoječih paradigmah.
JavaFX JavaFX nudi intuitivno sintakso, ki Nova sintaksa je presenečenje Java je trenutno najbolj priljubljeni Java vstopa relativno pozno na nagovarja logiko spletnih za večino Java razvijalcev, še programski jezik, JVM pa je zastopana bojišče za RIA tehnologije. razvijalcev (spominja na posebej, ker obstaja veliko RIA na vseh računalniških platformah. Nevarnost obstaja, da bo bitka že mešanico JavaScript in CSS), tehnologij, ki se poslužujejo Nadalje ima Java od vseh obstoječih odločena, predno bo JavaFX sploh hkrati pa utilizira ves potencial, ki ravno Jave za njihov razvoj. alternativ največ izkušenj tako z zaživel (poleti 2008 še ni lansiran). ga nudi Java. spletnimi, kot tudi namiznimi Javino razvijalsko skupnost poleg storitvami. tega osvajajo že tuje iniciative (Flex, GWT,…)
Ajax Ajax je konglomerat različnih Spletni standardi za sabo Ajax in standardi uživajo pozitivno Dostikrat inkonsistentna in standardov, ki nudijo modularen nimajo močnega monopolista, konotacijo svobodnih in univerzalno nepopolna podpora posameznih pristop k izdelovanju aplikacij. temveč bazirajo na principu podprtih tehnologij, ki neodvisno tehnologij odvračata razvijalce od Uporaba različnih XML dialektov demokracije. Slednje pomeni, delujejo na različnih platformah in uporabe le‐teh. Lastniški in in njihova manipulacija omogoča da je implementacija teh napravah. Odprtost standardov nudi konsolidirani RIA sistemi nudijo v za posamezne probleme tehnologij odvisna od dobre priložnosti novim podjetjem, da se tem vidiku jasno prednost. Razvijati individualno krojene aplikacije. volje individualnih organizacij profilirajo, s čimer dobijo razvijalci po standardih in hkrati želeti vso in posameznikov. neodvisno bazo orodij. njihovo teoretično moč, je iluzorno.
GWT GWT nudi razvijalcem Osredotočenost na Java Google velja za uspešen in prodoren GWT ne nudi pravzaprav nič neprecenljive izkušnje, ki si jih je programski jezik izključuje koncern, ki s svojimi storitvami ogroža inovativnega, saj gre zgolj za zbirko pridobil Google tekom delovanja razvijalce iz drugih področij. tržno pozicijo do sedajo uveljavljenih različnih rešitev, zbrano v Java kot največji ponudnik Ajax/RIA Kot na Ajax bazirajoča rešitev, ponudnikov (predvsem Microsoft). Le‐ knjižnico. Ajax knjižnic, ki naslavljajo aplikacij. Ker uporablja principe GWT ne pozna bogate grafične to pa naredi Google za konja, na problem nekompatibilnosti Ajax in bazira na spletnih izkušnje. katerega se splača staviti. brskalnikov, pa obstaja že mnogo. standardih, na ta način spodbuja tudi k boljši podpori le‐teh.
Curl Curl si prizadeva biti Osredotočenost na “resne” Jasna opredeljitev ciljne skupine Curl je sorazmerno majhna iniciativa. najzaneslivejša, najhitrejša in poslovne aplikacije pomeni ustrezno olajša fokusiranje in Uspešnost platforme ni odvisna od najvarnejša RIA platforma za hkrati pomanjkanje “eye‐ optimiziranje ponudbe. Ustvariti si njenih lastnosti in kvalitete, temveč poslovne rešitve, domnevno pa candy”, ergo animacijskih in ime kot najstabilnejši in najhitrejši od uporabnikov in razvijalcev, ki za to tudi je. grafičnih lastnosti, kot jih poslovni sistem je varna investicija v njo ustvarjajo vsebine. Razvijalska poznajo Flash, Silverlight &co. prihodnost spletnih aplikacij. baza za ta produkt je ustrezno skromna.
OpenLaszlo OL je platformsko neodvisna Prilagodljivost širšem spektru Medtem ko se pojavljajo vedno nove Glavna prednost OL je tudi njegov rešitev, ki je koncipirana, da obstoječih platform in RIA platforme, se OL razvija v svoji največji križ – naslavljanje različnih enako deluje na različnih odsotnost lastnega RTE za generični smeri. Potencial, ki ga okolij ni nujno prava rešitev, saj se s napravah, odvisno od potreb sabo prinaša omejen nabor prinaša takšna logika, dopušča, da se tem ne pokrije njihovih specifik. razvijalca pa se prikaže kot bodisi funkcionalnosti. Animacijske in aplikacija prilagodi potrebnemu Takšna taktika se bi sicer izšla, v Flash, ali Ajax. Razvijanje v XML‐ grafične kapacitete, ki bi jih razvijalskemu okolju. Hipotetično bi kolikor bi na trgu obstajale različne dialektu LZX ob uporabi lahko nudila Flash ali SVG, se bilo možno, da bi OL naslavljal tudi platforme (brskalniki ipd.), ki bi JavaScript je za spletnega tako zgubijo. izvajalna okolja, kot so Silverlight, XUL, podpirali izključno eno izvajalno razvijalca razmeroma intuitivno. ter okolja mobilnih aplikacj. okolje, a temu ni tako. Tabela 5: SWOT analiza RIA rešitev
5.4 Povzetek in primerjava RIA tehnologij
Posamezne opisane tehnologije delimo glede na njihovo uporabo na dve glavni skupini – tehnologije odprtih standardov, kamor spadajo XML, (X)HTML, CSS, ter posamezne knjižnice, ki se poslužujejo teh
str. 53/84 pristopov, kot je Google Web Toolkit, ter v drugo glavno skupino, v katero spadajo lastniške tehnologije za razvoj multimedijsko bogatih RIA aplikacij, kjer se nahajajo Flex/Flash, Silverlight, JavaFX.
Medtem ko so si različne tehnologije med seboj glede na potencialni končni rezultat močno podobne, obstajajo velike razlike v principu njihove uporabe (ob razvoju aplikacij) in konzumacije (efekt, ki ga aplikacija doseže pri končnem uporabniku).
Flex/Flash, Silverlight in XUL so ogrodja, ki v očeh uporabnika prednjačijo pri bogati multimedijski izkušnji, katera je integrirana tudi že v sam nabor orodij. Ravno te tri platforme nudijo tudi uporabo 3D‐grafike, ki pa je do nadaljnjega za spletno uporabo zgolj dekadentna opcija in ne predstavlja resne uporabne vrednosti za masovni trg. Bogato multimedijsko izkušnjo je možno ustvariti tudi z uporabo tehnologij odprtih standardov, saj SVG nudi tako interaktivno vektorsko grafiko, kot tudi animacijo.
Razlika, kot jo občuti razvijalec, je predvsem v naboru razpoložljivih tehnologij in marketinškem pristopu posameznih ogrodij, saj v osnovi nudijo tehnologije enak efekt. Vlogo igra tudi razširjenost podpore samemu ogrodju, nič manj pomemben pa ni razvijalski pristop k obvladovanju dotičnega ogrodja. proizvajalec Adobe Microsoft Mozilla Java Laszlo Curl Ajax (W3C) tehnologija Flex Silverlight XUL JavaFX OpenLaszlo Curl JavaScript
Vektorska DA DA SVG DA (Flash) DA SVG grafika
Animacija DA DA SVG DA (Flash) DA SVG + JavaScript
3D grafika NE NE (na spletu ni NE DA NE DA SVG podpore)
Bogate DA DA DA DA DA DA HTML 5 medijske vsebine
Vtičnik Flash Silverlight (le za NE (deluje (Java izvajalno (DA v primeru Curl RTE NE IE, WebKit, samo na ogrodje je Flash) Mozilla) Mozilli) večinoma že prisotno)
Hramba DA (min. DA (privzeto v DA (ne ponuja DA Odvisno od podatkov pri 100kb) Mozilli) privzeto znotraj brskalnika, odjemalcu svoje storitve) (X)HTML 5 to predvideva.
Podprtost > 90% (33) < 15% (33) < 30% (34) > 90% (OpenLaszlo (Curl je strogo (30% – 99%, bazira bodisi na nišna odvisno od Flash, bodisi tehnologija, uporabljenih Ajax) podprtost je tehnologij) praktično nična.) Tabela 6: pregled uporabnosti RIA tehnologij iz oblikovalskega vidika
str. 54/84 Medtem ko je bilo nekaj let nazaj še možno jasno definirati, kdaj se odločimo za katerega ponudnika ogrodja – za enostavne spletne predstavitve je bila odločitev jasno v prid odprtim standardom (oz. tisti mešanici, kot so jo proizvajalci brskalnikov podpirali), pri vektorski grafiki in animaciji pa je dominiral Flash, je ta odločitev leta 2008 bistveno bolj otežena, saj so tehnologije praktično izenačene, razlika je zgolj v njihovi podprtosti pri končnem uporabniku, preferencah razvijalcev in oblikovalcev, ter kvaliteti orodij, ki so za njihov razvoj na razpolago. Tabela 6 taksativno primerja ponujene tehnologije po kriterijih, pomembnih iz vidika prodora do uporabnika.
6. Avantgarde
6.1 Webforms 2.0, XForms
»Webforms« so nabor označb HTML specifikacije, ki služijo interaktivnemu vnosu podatkov in »ukazov« s strani uporabnika. Nabor elementov Webforms se skozi evolucijo HTML ni bistveno spreminjal, tako je HTML 4.x poznal elemente61 »text«, »password«, »checkbox«, »radio«, »submit«, »reset«, »file«, »hidden«, »image« in »button«. Ta nabor elementov je načeloma zadoščal za osnovne funkcije, z nekaj kreativnosti pa tudi za kompleksnejše.
Webforms 2.0 je koncept, ki ga razvija WHATWG62 in v svojem bistvu vpeljuje nove elemente za vnos podatkov, ki večinoma izvirajo iz obstoječih potreb »web 2.0« konceptov. Novi elementi, ki jih WF2 vnaša, so elementi za vnos času (»datetime«, »datetime‐local«, »date«, »month«, »week« in »time« ‐ Slika 11 prikazuje kontrolo za vnos datuma), dva numerična elementa (»number« in »range«) ter »email« in »url«. Dodatno se uvajajo novi atributi »required«, »pattern«, »autocomplete«, »autofocus«, »step«, »min« in »max«.
Potrebe, ki jih lajša WF2, se danes rešuje s pomočjo skriptnih in programskih jezikov, tako na strani odjemalca, kot na strani strežnika. Na strani odjemalca igra vlogo zlasti JavaScript (lahko tudi VBScript, EcmaScript, …), s katerim se validira vnesene podatke (recimo naslov elektronske pošte), kreira dodatne vnosne elemente, kot so koledarji ipd., medtem ko se na strežniku priporočljivo ponovno validira prejet podatek (tega tudi WF2 ne more zadovoljivo rešiti, saj drugače obstaja
61 »Element« je tu napačen izraz, uporablja pa se zaradi lažje plastične predstave. Dejansko gre za zgolj en element ‐ , ki ima atribut »type«, ki sprejme omejen nabor vrednosti.
62 Web Hypertext Application Technology Working Group / www.whatwg.org je neodvisna skupina ljudi, ki jih zanima razvoj spletnih tehnologij. Ustanovila se je na podlagi civilne iniciative posameznikov iz korporacij Apple, Mozilla in Opera, kot reakcija na po njihovem mnenju realne potrebe neupoštevajoče delovanje W3C. Glavni cilj WHATWG je razvoj (X)HTML 5.
str. 55/84 nevarnost za manipulacijo). Programi za razvoj spletnih strani danes ponujajo lastne pristope in kontrole za rešitev te problematike, eden takšnih so validatorske funkcije Microsoftove .Net platforme.
Slika 11: Na Operi 9.5 delujejo WebForms 2.0 že dokaj simpatično. Ker je grafična izbira datuma že integrirana v to tehnologijo, nam tega ni več potrebno graditi z JavaScript.
Nove so tudi možnosti za izdelavo seznamov input‐elementov, kot jih poznamo pri npr. neštetih poljih za nalaganje datotek. Tem seznamom je možno dinamično in brez dodatnega napora dodajati in odstranjevati elemente in le‐te premikati navzgor in navzdol. WF2 nudi tudi preverjanje podatkov znotraj brskalnika, pozna pa tudi poljubno preverjanje s pomočjo RegEx:
Nadaljnja novost je možnost gnezdenja elementov in asociacija elementov, ki se ne nahajajo znotraj njega. Akcije, ki jih sproža nek gumb, lahko vežemo na več formularjev in tako sprožimo več akcij hkrati. Paradigma, ki jo tu uvaja WF2, je poznana že iz programerskih okolij, kot je npr. ASP.Net, kjer se takšna funkcionalnost dosega s pomočjo JavaScript procedur.
WF2 so nastali iz ideje Iana Hickson63, ki je leta 2003 predlagal »XForms Basic« (kljub enakemu imenu WF2 nima nič z XForms, ki so tehnologija zase). Pozneje je ta koncept preimenoval v »Web Forms«, katerega je prevzela WHATWG pod imenom »Web Forms 2.0«. Od oktobra 2006 ima WF2 status »Working Draft« pri WHATWG.
63 Ian Hickson je urednik WHATWG, trenutno zaposlen in predstavnik Google v W3C, s slednjim pa sodeluje že dlje časa. (28)
str. 56/84 XForms
Medtem ko WF2 bazirajo na evoluciji WebForms iz HTML in zadovoljujejo potrebe po novih kontrolah, ki so se razvile tekom časa, so XForms tehnologija, ki se tesneje veže na XML (XML Schema, XPath, XML dogodki) in posledično ni vezan na HTML.
Glavni doprinos XForms k spletu je unifikacija in konsolidacija asinhronega pristopa do interakcije s strežnikom (v te namene se danes uporabljajo principi AJAX‐paradigme) in možnost platformsko neodvisnega opisa formularja.
Ker XForms niso sestavni del HTML, temveč so odvisen dialekt XML, jih je mogoče vnesti v poljubne na XML‐basirajoče dokumente (XHTML, SVG), ki dopuščajo uporabo XForms. Ker se pri tej tehnologiji izogibamo fiksnega opisa elementov, se lahko uporablja en in isti formular na različnih napravah, kjer se možnostim prilagojeno prikaže.
Podatki se pri XForms shranjujejo v obliki XML‐struktur, kar dopušča enostavno validacijo s pomočjo XML Scheme, manipulacijo z XPath, dinamične/matematične operacije in urejeno hrambo podatkov. Takšen pristop nudi jasnejši in bolj sofisticiran način za obdelavo podatkov, tudi v večstopenjskih procesih (od izvira pri uporabniku preko kontrolnih filtrov/akreditacij, do hrambe), brez dodatnih procesov interpretiranja podatkov. (V »klasičnih« spletnih aplikacijah je način distribucije in interpretacije podatkov prepuščen avtorju aplikacije.)
Začetki XForms segajo še pred leto 2000, ko je delovna skupina W3C za HTML prišla do spoznanja, da Web forms, kakršne ponuja HTML, ne zadoščajo več potrebam časa. Osnovna ideja je bila, da se bi postavil nov standard, ki bi drastično poenostavil handling spletnih formularjev. Le redki brskalniki podpirajo v aprilu 2008 to tehnologijo brez transformacije v druge tehnologije – tako nam je uspelo preizkusiti XForms le v Firefox 2 z ustreznim vtičnikom. Komercialno so v uporabi rešitve, ki razvijalcu dopuščajo uporabo XForms, končnemu uporabniku pa funkcionalnost omogočajo preko pretvorbe v npr. JavaScript.
XForms in Web forms 2 si nista konkurenčni tehnologiji, temveč vsaka pokriva svoje področje. Kombinirana uporaba obeh tako ni izključena. WF2 so sestavni del predloga standarda (X)HTML 5.0, medtem ko se XForms predstavljajo v sklopu konkurenčnega XHTML 2.0.
6.2 (X)HTML 5.0, XHTML 2.0
V letih, v katerih se (X)HTML ni več razvijal, se je pojavila vrsta novih načinov uporabe interneta, pogojena z napredkom tehnologije. HTML je zadoščal za snop preko hiperpovezav povezanih strani, tu in tam kakšno slikico, interakcijo, ni pa predvideval današnjih aplikacij, kot so YouTube, MySpace in WordPress.
str. 57/84 Osnovna funkcija – že od samega začetka – je bila vzpostaviti semantični strukturni jezik. Praksa temu ni bila naklonjena in HTML se je divje spreminjal, za kar so bile potrebne korekture standardov, uvedba CSS in vzgoja brskalnikov, da ga uporabljajo. Spletno oblikovanje je postala kreativna veda uporabe različnih tehnologij za dosego določenega cilja.
Povsem normalna je danes masovna uporaba multimedijskih elementov (MySpace, Stickam) in interakcija uporabnikov (blogi, komentarji, RSS). Iz oblikovalskega vidika so vse te zahteve lepo rešljive s pomočjo tehnologij, ki so na razpolago, prihaja pa zopet do iste dileme glede smisla HTML, kakršna je bila v času anarhičnega uvajanja lastniških elementov s strani »velikih«.
(X)HTML je struktura, ki se uporablja v praksi zgolj še iz tradicije, brez globljega razmišljanja. Od uvedbe in popularizacije CSS, je
element postal najpomembnejši gradnik, poleg njega pa oblikovalci vidijo pomembnejšo uporabno vrednost samo še v , in . HTML kot semantični jezik v praksi enostavno ni priznan. Argumenti za semantičnost tega jezika so sicer zanimivi – artikulacija poteka v smeri prilagodljivosti aparaturam za slabovidne, slepe, prilagodljivost mobilnim napravam ipd. – a brez realne vrednosti, saj so to trgi, ki so močno marginalni in za katere se ne gradijo »killer«‐aplikacije, kot je YouTube.
Dopovedati oblikovalcem, naj uporabljajo semantične označbe, je sicer iluzorno, saj isti efekt dosežejo z enostavnimi gradniki, kar pa ne odvrača »stroke« od prizadevanj za ponovni poizkus semantičnega HTML. Oba predloga za naslednika obstoječih specifikacij – (X)HTML 5.0 in XHTML 2.0 tako zasledujeta slične cilje.
Medtem ko XForms in WF2 prinašata novosti, ki bodisi pomembno vplivajo na delovni tok, bodisi prinašajo dobrodošle nove funkcije, so novosti naslednika (X)HTML iz oblikovalskega vidika razmeroma šibke.
Glavna lastnost prizadevanj (X)HTML 5 je vztrajna semantifikacija sintakse. Podkrepljeno s analizo poimenovanja različnih odsekov strani64 (oz. uporabo poimenovanj CSS‐razredov), se je delovna skupina WHATWG lotila uvedbe novih elementov, ki naj bi semantično pokrivala te vsebine. Tako naj bi oblikovalci namesto
uporabljali , , , … 64 http://code.google.com/webstats/2005‐12/classes.html (2006, dosegljivo 2008‐04‐20) ‐ sicer Google ugotavlja, da večina spletnih strani sploh ne uporablja CSS‐razredov za oblikovanje, preostali pa največkrat uporabljajo imena, kot so footer, menu, title/header, text/content/main, nav, …
str. 58/84 Upravičen je dvom v takšno »darilo«, saj se že danes ponujajo elementi
, ,… za uporabo kot naslov, podnaslov itd., a jih v praksi uporabljajo kvečjemu zagrizeni zagovorniki spletnih standardov, medtem ko nekega praktičnega razloga za njihovo uporabo enostavno ni. (Edina praktična korist za spletnega oblikovalca in arhitekta, je boljša podpora pri iskalnikih in drugih avtomatiziranih pristopih do spletne aplikacije – semantično korektne strani tako dobijo višji ranking, ker je tudi iskanje po njih za robote enostavnejše. Ta korist je razmeroma malo poznana in pogosto ne nudi dovoljšno motivacijo za uporabo semantičnega strukturiranja.) Te problematike se zaveda tudi delovna skupina W3C za XHTML 2, ki obstoječih problemov ne skuša rešiti s pomočjo novih paradigem, temveč restruktuira obstoječe. Ravno vprašanja smotra različnih elementov za naslove se loti na način, da uvaja element , ki dopušča rekurzijo, znotraj njega pa se element (headline) obnaša ustrezno glede na nivo.
Koristna novost, ki jo prinaša XHTML 2 je možnost poljubnega elementa, da postane hiperpovezava. Škoda, da te možnosti ne nudi privzeto že XML65, saj bi v takem primeru popolnoma zadoščala kombinacija XML + XForms + CSS za izdelavo spletnih aplikacij.
Funkcionalnost multimedijev, ki jo danes rešujemo s pomočjo vtičnikov (Flash, QuickTime, WMP,…), je področje, ki ga prav tako želi poenostaviti (X)HTML 5. Tako sta predvidena elementa in , katere bi kreator spletne strani uporabil enako preprosto, kot to dela danes z . Posebna poslastica je možnost, da se te nove medijske elemente kontrolira preko JavaScript, kar odpira nove možnosti za kreativni pristop k upravljanju. Na drugi stran pa se XHTML 2 ločuje od specifične deklaracije vsebine in se osredotoča na element, ki sprejme vse mogoče multimedijske tipe – slike, video, avdio, applets,…
(X)HTML je izjemno uspešna tehnologija, ki pa že osem let ni spremenila spremembe specifikacije. Njen namen so si uporabniki sproti prilagajali do te mere, da je od osnovne namembnosti preostala le še gola akademska teorija. Vprašanje je, ali je smiselno po več kot osmih letih (končanje novega standarda se pričakuje v petih do desetih letih, torej ne pred 2013) razdreti obstoječe stanje in ponovno načeti sago HTML, ter ali ne bi bilo bolj racionalno graditi na naprednejših paradigmah, ki bi ustrezale dejanskim potrebam spletne skupnosti?
Semantičnost tehnologije je sicer zanimiv teoretski, a v praksi ne nujno uporabljiv pristop. Da je preprosto ponavadi tudi dobro, je dokazal XML, sicer »otrok« kompleksnejšega in bolj semantično polnega SGML, ki pa uspeva ravno zaradi svoje enostavnosti.
65 XLink specifikacija (gl. str. 25) naj bi zagotavljala sicer ravno to, a je podpora zanjo praktično nična.
str. 59/84 Argumentacija semantizacije (X)HTML v takšni ali drugačni obliki se sicer osredotoča na lažjo določljivost vsebine, ki pride do izraza pri iskanju informacij in prilagodljivosti marginalnim tržnim segmentom, hkrati pa takšni pristopi prinašajo tudi nevarnost poseganja uporabnika v avtorsko storitev oblikovalca66. Bojazen obstaja, da bi ob semantični homogenizaciji spleta uporabnik dobil na razpolago možnost, da na strukturo strani aplicira slogovno datoteko druge. (No, tudi to je bil osnovni namen CSS, a je evolucija dovedla do tega, da takšne teoretske opcije v oblikovalskih krogih ni več.)
6.2.1 Shranjevanje podatkov pri uporabniku
(X)HTML 5 pa prinaša še eno pomembno funkcionalnost – shranjevanje podatkov na računalniku uporabnika. Tradicionalno spletni razvijalci razpolagajo zgolj z enim pomembnim elementom za shranjevanje podatkov pri uporabniku – piškotki (cookies). Medtem ko so piškotki tehnologija, ki je bila koncipirana za sledenje in identifikacijo uporabnika67 (preverjanje, ali je uporabnik že bil na naši spletni strani in ustrezno pozdravljanje je bila ena od osnovnih lekcij bodočih spletnih razvijalcev...), podatki, ki jih shranjujejo, pa se ob vsaki zahtevi pošljejo na server, je to za moderne spletne aplikacije prešibka ponudba.
Lastniški sistemi, kot je Flash, že danes podpirajo standardno shranjevanje podatkov pri uporabniku, s katerimi aplikacije lahko po potrebi razpolagajo. Flash nudi najmanj 100kb prostora za posamezno spletno domeno, ki pa jih lahko uporabnik po potrebi poveča.
Tudi Internet Explorer že od verzije 5 naprej pozna element »userData«, preko katerega je dovoljeno trajno shranjevati podatke na uporabnikov računalnik, velikost pa variira od varnosti spletne strani in konfiguracije brskalnika.
Naprednejši pristop do shranjevanja podatkov, kot pa ga nudijo piškotki, a enako standardiziran, obljublja »WHATWG DOM Storage68«, ki je vključen v (X)HTML 5 prizadevanja – tako sta (oz. bosta) nam na voljo dva nova DOM‐elementa: sessionStorage in localStorage. SessionStorage je objekt, ki nadomešča začasnostno funkcionalnost piškotkov, ob tem pa jo konkretizira. Ta objekt je
66 Ravno
&c. so označbe, ki konotirajo s pomanjkanjem kontrole nad izgledom. (Kar sicer ne odgovarja resnici, temveč je »historično« pogojeno.) 67 Piškotke so razvili na Netscape leta 1994. Že takrat je bil osnovni namen podpora spletnim trgovinam, torej za vzdrževanje seje (session).
68 “DOM Storage” je izraz, ki ga je skovala Mozilla za lažjo identifikacijo mehanizmov za shranjevanje podatkov na strani odjemalca, kot jih predlaga W3C v predmetnem predlogu standarda. Ta izraz si je sposodil Microsoft, ki na enak način promovira to tehnologijo, medtem ko je “uradni” izraz, kot ga navaja specifikacija (http://www.w3.org/TR/html5/structured.html#the‐storage) “Structured client‐side storage”.
str. 60/84 vezan na obstoj seje (session), novost pri tem pa je, da je nujno, da seja poteka zgolj v enem oknu (medtem ko so piškotki vezani na brskalnik in tako en piškotek lahko »preskakuje« iz enega okna v drugega, če se v obeh uporablja ista domena).
LocalStorage pa nadomešča trajnostno funkcionalnost piškotkov in torej funkcionalnost hrambe enostavnejših podatkov na daljši čas.
Storage pa prinaša tudi dostop do podatkovne baze na strani odjemalca, kar za odprte standarde pomeni pomemben korak v konkurenci z lastniškimi RIA‐sistemi. Poleti 2008 to funkcionalnost podpira WebKit 3, Firefox 3 ponuja lasten API za dostop do SQLite pod pojmom »mozStorage«, delno pa funkcionalnosti Storage nudi tudi IE8 (22).
Baza, ki deluje v ozadju, je odprtokodni SQLite, katere glavni podporniki so Adobe, Mozilla in Symbian. Brskalnik sam implementira operacije za postavitev nove baze – v kolikor že ne obstaja (le‐ ta je vezana na domeno, iz katere aplikacija izvira, s čimer se prepreči zloraba podatkov), razvijalec pa bere in piše podatke s pomočjo standardnih SQL stavkov.
V istem času, ko je WHATWG user group razvijala DOM‐Storage v okviru Webapplications 1.0 (pozneje HTML 5), je Google razvil in predstavil storitev Google‐Gears – vtičnik za brskalnike, ki uporabniku nudi enako funkcionalnost. Sicer je bil Gears na začetku nekompatibilen z najavljenim standardom, a je Google takoj najavil, da bo zagotovil kompatibilnost in nudil enak API za upravljanje s podatkovno bazo, kot ga zahteva DOM‐Storage.
6.3 CSS3
Odkar brskalniki dostojno podpirajo CSS, je ta postal zdaleč najpomembnejše orodje spletnega oblikovanja. Medtem ko HTML predstavlja zgolj kalup/strukturo v katero se vnesejo podatki za poznejšo oblikovanje, je CSS edina pomembna točka za oblikovalca, da arhitektonsko izdela izgled.
CSS 2.1, ki je trenutno veljavni, je specifikacija, ki nudi premalo za sofisticirano oblikovanje, saj je za kompleksno postavitev strani potrebna koordinacija strukture in oblike. Odločitve oblikovalca tako pomembno vplivajo na nivo urejenosti in semantičnosti strukture, saj se slednja nujno mora prilagoditi obliki.
Novosti, ki jih prinaša trojka, so glede na razmere revolucionarne69. Revolucionarno je tudi, da se standard predstavlja v dvajsetih modulih. Med moduli se najdejo tudi za zahodnega spletnega oblikovalca praktično nezanimivi »eksoti«, kot so Speech Module (za oblikovanje izgovarjave), Ruby
69 Svoje povedo tudi številke: tako je CSS 1 razpolagal z zgolj 53 atributi, CSS 2.1 jih ima 115, CSS 3 pa jih planira preko 224 (30)
str. 61/84 Module, ki služi kot asistenca za nekatere azijske pisave in Presentation Levels, ki je namenjen prezentacijam (v smislu PowerPoint‐prezentacije). Modularizacija omogoča deljeno razvijanje specifikacije po sklopih, kar se odraža tudi v različnem napredku. Nekateri osnovni moduli (Basic User Interface, Colour Module, Media Queries,…) imajo aprila 2008 že status Candidate Recommendation, medtem ko je večina modulov še pod statusom Working Draft.
Najpomembnejši moduli, ki prinašajo novosti za spletno (vizualno) oblikovanje, so sledeči:
6.3.1 Večstolpični razpored (Multicolumn layout)
Ta način razporejanja je izredno pomembna inovacija, ki omogoča tabelarno pozicioniranje elementov, tudi v večih stolpcih. Te izredno pomembne možnosti, ki je v uporabi zlasti v tiskanih‐ medijih (časopisi, revije, knjige), do sedaj na spletnih medijih ni bilo mogoče izvesti intuitivno in brez znanja programiranja. (Glede na nepredvidljivost spletnih konfiguracij pa tudi praktično ni bila v uporabi.) Doprinos k spletnem uporabniškem izkustvu je velik, saj to pomeni konec izključno vertikalno‐orientiranem razmišljanju in bolj smotrn izkoristek prostora. (Velja pravilo, da je tekst lažje berljiv, če so vrstice omejeno dolge, kar je glavni faktor za širino spletnih strani.)
Znotraj CSS ne bo mogoče oblikovati le stolpcev, temveč celotne tabele. V te strukture se bo potem pozicioniralo elemente. Takšen koncept sicer ni nič novega, saj je grafično strukturiranje spletnih strani pred popularizacijo CSS potekalo izključno na ta način, le da z uporabo/zlorabo tabel HTML. (Med uporabo CSS 2.x se je kot nadomestilo uporabljalo različne načine pozicioniranja – float layout, absolutno pozicioniranje itd.)
Večstolpično razporejanje je pomemben korak tudi v smeri avtomatiziranega oblikovanja tiska, ki je danes še v domeni WYSIWYG‐orodij, kot so InDesign in QuarkXPress. Pogojna vezava na lastnosti prikazovalnika70 (npr. razpoložljive dimenzije, kot je širina), pa omogoča prilagoditev razporeditve elementov. Tako je možno, da se opcionalno prikaže oz. skrije vsebino glede na širino strani.
6.3.2 Modul za zamenjavo in generacijo vsebine (Generated and Replaced Content Module)
Enumeracije, komentarji, opombe, spadajo med elemente, ki trenutno zahtevajo ročno delo ter v naprej določen poseg v strukturo.
70 Z media‐queries je mogoče preveriti lastnosti prikazovalnikov:
@media screen and (min‐width:200px){…} se proži le, če gre za brskalnik, katerega širina je vsaj 200px. V nadaljevanju lahko izključimo ali vključimo dodatne lastnosti (npr. dodatna navigacija), spremenimo vrednosti atributov itd., kar dopušča lažjo prilagodljivost oblike realnim potrebam.
str. 62/84 Če želimo danes prikazati številke ob naštevalnih elementih, jih moramo predvideti že v sami strukturi dokumenta, kar pa ni nujno vedno tudi zaželeno. Bolj smiselna je kontrola nad to strukturo iz CSS, kar trojka tudi uvaja z sistemom števcev.
Spremembe omogočajo tudi dinamično zamenjavo teksta ali vsebine elementov, ko je to želeno, premestitev vsebine (kot to zahtevajo končne in stranske opombe), prilagajanje glede na določene parametre (recimo jezik) in rezanje slik (cropping).
6.3.3 Ozadja in okviri (Backgrounds and Borders Module)
Pomemben problem, ki je doletel napredne kreativce v želji, da je ozadje nekega elementa raztegljivo (npr. okviri okoli slike, kot so senca ali druge kompleksnejše oblike), bo z CSS3 enostavno rešljiv. Sedanja praksa svetuje, da se položi dva elementa enega nad drugega (oz. enega znotraj drugega), ter se jima dodeli različne slike ozadja v levi zgornji oz. desni spodnji kot. Takšen pristop je ne le kompliciran, temveč tudi sintaktično nekorekten, saj ponovno pride do kreativne uporabe elementov HTML v namene, ki so drugačne od njihovih originalnih.
Nova paradigma pozicioniranja ozadja dopušča poljubno število ozadij in obenem njihovo poljubno postavitev znotraj elementa.
Dodatne novosti prinašajo border‐image (slika kot rob), border‐radius (okrogli koti) in box‐shadow (senca). Kakšna pa je njihova realna vrednost, pa bo pokazal čas, saj spadajo bolj v področje kiča, kot pa resnega oblikovanja.
6.3.4 Funkcija calc() (modul Values and Units)
Omembe vredna novost tega modula je funkcija calc(). S to funkcijo dobi CSS izjemno moč preračunavanja posameznih vrednosti.
6.3.5 Selektorji (modul Selectors)
Področje selektorjev, torej načina, kako dostopati do posameznih elementov, je sicer že pri CSS 2.1 dokaj obširno, a je v praksi implementirano le v okrnjeni obliki. Tako se danes uporabljajo le enostavni selektorji, kot so direkten dostop do elementov, tipov in razredov, ter omejen nabor psevdorazredov71.
71 Psevdorazredi v CSS so selektorji, ki se prožijo ob določeni akciji. CSS 2.1 pozna :first‐child, :link, :visited, :hover, :active, :focus in :lang. Enaka definicija se uporablja za psevdo‐elemente, kamor spadajo :first‐line, :first‐letter, :before in :after. Podpora obeh tipov je sorazmerno šibka. V splošni uporabi so samo :visited, :hover in :focus, ki so se sprva uporabljali zgolj na hiperpovezavah (manko IE), pozneje še na ostalih kontrolah.
str. 63/84 Z novimi attribute selectors ne dostopamo le do elementov z fiksiranim ID ali tipom elementa, možna bo kontrola tudi nad elementi, katerih vrednost atributov odgovarja podanim kriterijem.
a[href^='http://']{…} izbere vse hiperpovezave, ki se poslužujejo HTTP protokola. img[src$='.png']{…} naslavlja vse PNG ‐ slike div[title*='foo']{…} vrne vse
elemente, pri katerih naslov vsebuje »foo« Dodatne novosti so novi psevdorazredi (npr. :root, :not(), :last‐child, :only‐child, :nth‐child()72) in preverjanje predhodnika z znakom ~ (h1 ~ div {…} naslavlja vse
elemente, pred katerimi se nahaja ). Psevdo‐razredi in ‐elementi se pri CSS 3 razlikujejo tudi sintaktično, tako se prve piše z enim dvopičjem, druge pa z dvema. 6.3.6 Sklep
CSS 3 obljublja bistven doprinos k lažjem in bolj logičnem spletnem oblikovanju, vprašanje je le, ali, oz. v kakšnem obsegu bo prišlo do implementacije vseh zahtev specifikacije. Avgusta 2008 je sicer že mogoče uživati večino ključnih funkcij, a le na marginalnih brskalnikih, kot so Opera 9.5, Safari 3.1, Firefox 3, pri čemer Safari podpira večino funkcionalnosti. Dodati pa je treba, da za lastnosti, kot so senčenje, večstolpični razpored, zaokroženi koti, tako Firefox, kot Safari uporabljata svoje prefikse (Safari: ‐webkit , Firefox: ‐moz).
72 Posebej zanimiv psevdorazreda sta :nth‐child() in :nth‐of‐type(), ki jih je možno uporabiti za različen prikaz naštevalnih elementov, recimo tabel. Medtem ko se prvi uporabi zgolj za elemente otrok, ki odgovarjajo iterativnim kriterijem, se drugi uporabi za elemente, ki so dotičnega tipa (img:nth‐of‐type(2n) tako naslavlja vsako drugo sliko). Ta problematika se do sedaj rešuje izključno z uporabo kode na strani odjemalca oz. strežnika, kjer se kontrolira uporabljen razred.
str. 64/84 7. Portal MMSM
Slika 12: Ko uporabnik vstopi na stran www.mmsm.si/mmsm_page, je v njegovem centru pozornosti informacijska vrednost, namreč kaj se dogaja – koledar nudi vpogled, kaj se bo dogajalo, galerija pa prikazuje aktualne fotografije.
Dinamičen razvoj spletnih tehnologij in vedno večja funkcionalnost, ki jih le‐te omogočajo, a nenazadnje tudi spreminjajoča se moda in ambicije posameznikov, so dovedle do situacije, ko se je vodstvo Mestnega Mladinskega sveta Maribor (MMSM) odločilo za modernizacijo obstoječe spletne strani (Slika 12 prikazuje prenovljeno spletno aplikacijo).
Mladinski svet je organizatorična oblika mladinskih organizacij za sistematsko nastopanje na ravni lokalne politike. V svojem bistvu gre za krovno organizacijo, neke vrste sindikat mladih – naloge v tem smislu naj bi bile odpiranje in vodenje javnega dialoga na področju mladinske problematike, zastopanje skupnih stališč in interesov proti Mestni občini Maribor. Realne naloge in dejavnosti pa to rdečo nit razširijo do mere, ko MMSM izvaja lastne interesne dejavnosti ‐ mladinske projekte, prireja družabne dogodke za vodilne včlanjenih organizacij ipd. Če bi ostali na teoretskem nivoju, bi novi portal lahko predstavljal demokratično platformo za izmenjavo mnenj mladih v obliki foruma, mogoče celo z dodatkom skupnostnih orodij za povezovanje mariborske mladine. Na to ogrodje bi se dalo povezati še avtomatizirano obveščanje o dogodkih članic MMSM in na ta način mreženja spodbujati razvoj mladinske dejavnosti v Mariboru.
A ker sta teorija in praksa dve že v konceptu različni stvari, moramo tudi tu praktične potrebe obravnavati izven teoretičnega konteksta. MMSM ne le da ne premore fundirane teoretske osnove
str. 65/84 za svoje delovanje, tudi motivacija članic predstavlja poglavje zase. Realne potrebe izgradnje portala so tako prepuščene na milost in nemilost tistemu, ki postavi koncept in ga je zmožen realizirati.
V svojem življenju sem zgradil že dva portala »iz nule« ‐ enega v PHP 4 + MySQL, drugega v .NET 2.0 + MSSQL. Pri obeh projektih je bil moj izključni cilj, naučiti se programskega jezika – temu ustrezno je izpadla tudi (deloma pretirana in zavirajoča) kompleksnost in eksperimentalnost implementirane funkcionalnosti. Izziv, ki sem si ga zadal pri tem projektu je portal, ki shaja brez baze in s čim manj kode na strežniški strani. Tej težnji je najbolje ustrezal koncept »Ajax« + XSLT, torej uporaba JavaScript za izgradnjo strani na strani odjemalca, ter spletne storitve za izvajanje operacij na strežniku.
7.1 Izhodiščne potrebe
Krovna mladinska organizacija naj posluje vzorno transparentno in javno, ter tako vzgojno vpliva na poslovanje njenih organizacij članic. Med maksime javnega poslovanja se šteje zlasti transparentna poraba javnih finančnih sredstev, ter dosledno objavljanje zapisnikov sej organov (obe načeli se zelo redko izpolnjujeta v mladinskopolitični sferi).
Obiskovalec (zlasti s strani zainteresirane javnosti in organizacij članic) naj bi torej dobil možnost, da se preko spletne strani ažurno informira o tem, za kakšne namene MMSM porablja javnofinančna sredstva, obenem pa bi dobil preko detajliranih zapisnikov sej organov vpogled v aktualno dogajanje na MMSM ter informacije o sklicu naslednje seje.
Preko spleta naj bi bilo administratorju ali drugi pooblaščeni osebi možno, da sestavlja vabila in zapisnike na spletu, kateri se nato brez pretvorb prenesejo v sistem – sklic seje bi bil tako povsem avtomatiziran in standardiziran, pooblaščena oseba bi le vnesla podatke v sistem ter označila vabljene osebe, katere bi sistem nato obvestil.
Poleg sistema zapisnikov in objave porabe financ naj bi sistem nudil tudi pregled nad preteklimi aktivnostmi Mladinskega sveta in ev. tudi članic, ter tako gradil na zaupanju javnosti.
Nadalje naj bi portal nudil pregled nad članicami, s čimer se bi na eni strani nudila možnost za promocijo posameznih članic preko skupne vstopne točke, hkrati pa bi MMSM dobil vir informacij o delovanju in aktivnosti njegovih članic. Podatki, ki so krucialni iz našega vidika, so zlasti podatki o številu članov posamezne organizacije, njihovih aktivnostih, ter strukturi vodstva (starost, trajanje mandata, hierarhija, ...).
str. 66/84
Slika 13: V osnovi razlikujemo tri tipe uporabnikov ‐ administratorja, ki ima absoluten dostop do podatkov v vseh oblikah, uporabnika, ki ima dostop do sicer zaščitenih informacij in možnost interakcije, ter gosta, ki ima dostop le do osnov.
V sklopu storitev, ki jih MMSM nudi svojim članicam, naj bi bila preko spletne aplikacije možna tudi avtomatizirana rezervacija prostorov za aktivnosti in projekte članic.
Sistem je razdeljen na tri skupine uporabnikov – administratorja, ki dostopa do sistema iz ozadja (in direktno dostopa do kode), avtoriziranega uporabnika (predstavniki članic in druge pooblaščene osebe), ki ima razširjen dostop do informacij, ter gosta, ki ima omejen dostop do informacij in nima možnosti vplivati na podatke. Slika 13 tako prikazuje glavne primere uporabe za predvidene tipe uporabnikov.
(Slika 14 prikazuje zaporedje ukazov pri rezervaciji prostorov, Slika 15 pa vnos finančnih transakcij preko spletnega vmesnika – dostop do tega modusa je mogoč le administratorju sistema.)
str. 67/84
Slika 14: Rezervacija prostorov je možna le avtoriziranim osebam
Slika 15: Vnos podatkov o finančnih tokovih izvaja administrator preko poljubnega vmesnika (spletni vmesnik, gadget,...), ki preko spletne storitve podatke zapisuje v XML format na strežniku. Ta model dopušča tudi avtomatiziran vnos podatkov (npr. direktno iz knjigovodstva)
str. 68/84 7.1.1 Arhitektura portala
Slika 16: Glavna poslovna logika aplikacije se vrši v obliki JavaScript kode na strani odjemalca. Za potrebe interakcije s strežnikom iz te kode kličemo .Net spletne storitve, ki prevzamejo filtriranje, zbiranje in avtoriziranje podatkov, ki jih shranjujemo v obliki XML na strežniku.
str. 69/84 7.2 Tehnologije
Med variantami RIA sistemov, kot smo jih opisali v poglavju Bogate spletne aplikacije (Rich Internet Applications (str. 38), smo se odločili za paket, kot nam ga nudi W3C. Flash je ogrodje, ki se pretežno koristi za multimedialne aplikacije in v vseh kriterijih ustreza klišeju, da je oblikovalsko orodje za animirane spletne strani – to pa je funkcionalnost, ki bi bila za naš problem nepotrebna in bi otežila delo, saj bi pretežni del aplikacije še vedno upravičeval uporabo XHTML. Silverlight je tehnologija, ki je še premalo uveljavljena, ne nudi pa tudi nikakršnih prednosti proti Flash‐u (vsaj ne iz oblikovalskega vidika), saj igra v enaki ligi. Nadalje zahteva Silverlight/WPF tako od spletnega oblikovalca, kot tudi –razvijalca osvojitev novih konceptov in paradigem kreiranja vsebin za splet, ki ne odgovarjajo nujno ustaljeni praksi, kot jo je definiral koncept DOM/XHTML/CSS – enak preskok v razmišljanju zahtevajo tudi Flex in JavaFX. Medtem ko XUL nagovarja ravno to ciljno skupino, pa kot spletna tehnologija ne nudi dovolj razlogov za uveljavitev, saj je to tehnologija, ki prenese sintakso iz namizja na splet in ne obratno, njena podpora pa je preveč skromna, da bi lahko resno konkuriral (X)HTML.
Silverlight bi imel izredno močan potencial, v kolikor bi znal ustvariti tekoč prehod med logiko spletnega razvijalca/oblikovalca ter svojo novo platformo, saj je moč, ki jo ima .Net neosporavano pomembna. Novi načini izrisovanja strani, navigacije po njih, dostopanje do podatkov etc., kot jih predlaga WPF/Silverlight, pa v logiko spletnih razvijalcev vnese kvečjemu zmedo. Na enake probleme je naletel pri platformi Asp.net, kateri je vsilil svoja poimenovanja html‐gradnikov, ter tako skušal poenostaviti spletno programiranje za razvijalce, ki se s tem področjem pred tem niso srečali. Da se obstoječ razvijalski trg in s tem področje da osvojiti zgolj na način, da se k obstoječi paradigmi doda novo korist, pri tem pa ne poseže v obstoječo logiko, ki se je obveljavila v dotični ciljni skupini, dokazuje tudi močna popularnost73 jezikov, kot je PHP – slednji uvaja funkcionalnost strežniškega programiranja, razvijalcu pa pusti, da še naprej razmišlja v XHTML.
DOM/XHTML/CSS je torej najbolj »naraven« koncept spletnih tehnologij za spletnega oblikovalca/razvijalca, ki se je na ta sistem navadil (sem pač spadajo vse dosedanje generacije). Preskok iz HTML 4x na XHTML in (X)HTML 5 je intuitiven in logičen, podpora s strani uporabnikov je zagotovljena in tudi aspekt tradicije govori v prid W3C paketu za RIA aplikacije.
Glede na močno uporabo avantgardnih oz. še ne uveljavljenih tehnologij, ki jih uporabljamo pri tem projektu, se pri gradnji projekta opiramo na platformo WebKit (Safari, OS X) 3.1.1, ki je v tem
73 Glede na TIOBE, je najpopularnejši programski jezik sicer še vedno Java, preseneča pa močna prednost popularnosti PHP (10,206%) v primerjavi z glavnim .Net jezikom – C# (4,058%). (31)
str. 70/84 trenutku (pomlad/poletje 2008) edina nudi zadostno podporo tako iz vidika CSS3, HTML5 (žal še ne podpira WebForms 2, zato pa DOM Storage), XHTML in SVG.
7.2.1 Anomalije implementacij standardov
XHTML ni nujno to, kar XML obljublja, zlasti takrat ne, ko gre za naprednejše funkcije, kot so to imenski prostori. Če sledimo goli teoriji, naj bi XHTML, kot dialekt XML, dovolil uporabo mešanja različnih imenskih prostorov – v praksi nam je to še posebej pomembno, ker želimo direktno v strukturo zapisati grafike SVG in mešati različne dialekte (X)HTML74. V realnosti pa se soočamo s težavo, da validatorji (tudi »uradni« W3C‐jev) takšnega scenarija ne podpirajo in javijo napake, češ da shema za XHTML ne predvideva označb, kot so »svg:svg« ipd.
Naslednja anomalija, s katero smo se soočili, je problematična implementacija funkcionalnosti XPath v ogrodju .Net. Za transformacijo občutljivih podatkov (pregled nad porabo finančnih sredstev) smo se odločili, da XSLT procesiramo na strežniku in tako do odjemalca spustimo le filtrirane podatke – v XML se hranijo ažurni finančni tokovi, ki vključujejo detajlirane podatke o porabljenih sredstvih, ki bi pri uporabniku povzročili kvečjemu zmedo. Naloga XSLT v tem primeru je, da sešteje postavke posameznih kategorij in vrne končne rezultate – porabo/priliv sredstev v posamezni kategoriji, ter skupno porabo in prilive. Te naloge smo se lotili s pomočjo XPath 2.0 ukaza: sum(//leto[@leto='2008']
//transakcija[starts‐with(@tip, '5')]/number(translate(@znesek, ',', '.')))
Medtem ko gre tu za popolnoma pravilen XPath ukaz, s katerim prvo spremenimo vse zapisane zneske v številke (prej pride še do zamenjave vejic za pike kot ločila pri številkah, ker smo zapis podatkov zasnovali na človeški berljivosti – vejica pa je pri nas pač standardno ločilo), nato pa vsa števila seštejemo da dobimo rezultat, pa .Net razčlenjevalnik ta izraz bojkotira, ker Microsoft še ne podpira XSLT 2.0/XPath 2.0 (23).
74 Za vnos večjih količin teksta v sistem se uporabljamo brezplačnih WYSIWYG‐editorjev, ki s pomočjo JavaScript emulirajo uporabniško izkušnjo programov, kot so Microsoft Word. Kljub temu, da so ti editorji v teku zadnjih let močno izboljšali svojo kvaliteto, zlasti v smislu upoštevanja spletnih standardov – z uporabo CSS namesto HTML 4 tag‐ov, adaptacija zahtev standarda XHTML, …, pa še vedno kažejo pomanjkljivosti pri kreiranju XHTML 1.1 skladne strukture. Za našo aplikacijo smo uporabili v danem trenutku najnovejšo verzijo aplikacije FCK‐ Editor, ki uživa sloves najbolj kompletne implementacije spletnih standardov, delovala pa naj bi na vseh pomembnejših brskalnikih (IE, Firefox, Opera, Safari) – a kljub temu XHTML, ki ga proizvaja, še vedno vsebuje kršitve pri uporabi entitet ( š…) ki jih pa XHTML 1.1 ne podpira.
str. 71/84 Problemi pri pravilnem prikazu standardov so odvisni deloma kar od uporabljene končnice datoteke, kar je jasen indikator za nekonsistentno in nepravilno implementacijo spletnih standardov v brskalnikih. Medtem ko teorija veli, da naj tip dokumenta in stopnjo strogosti standarda definira naveden DTD, prihaja v praksi do napak, saj se nekateri brskalniki še vedno držijo naukov »Quircks‐ mode«. Dostikrat vpliva že sama sprememba končnice iz .html v .xhtml na to, ali aplikacija uporabi standarde, ali pa jih interpretira po svoje. (Najbolj nenavadno pa je delovanje IE, ki dokument s končnico .xhtml sploh ne procesira, temveč ga ponudi za snetje.)
Naslednji pomembnejši problem predstavlja neobstoječa podpora DOM 2 s strani Trident (Internet Explorer). To ogrodje podpira le specifikacijo DOM 1, ki pa ne pozna imenskih prostorov in drugih naprednih funkcionalnosti, ki jih za naše delo potrebujemo. Slednje vpliva nevzdržno negativno na delovne pogoje za gradnjo Ajax aplikacij, saj bi bili prisiljeni uporabiti ločene pristope za manipulacijo z DOM za različne ciljne platforme.
7.2.2 XSLT transformacije na strežniku in spletne storitve
Transformacije, ki jih iz varnostnih ali praktičnih razlogov izvajamo na strežniku, prožimo preko abstraktne spletne storitve, ki za parametre sprejema naslov do XML in XSLT datoteke, ter ev. dodatnih parametrov (za dinamično procesiranje), kot rezultat pa vrne XML, kot ga generira XSLT transformacija.
Spletne storitve kličemo preko XMLHttpRequest – objekta/vmesnika, ki ga nudi JavaScript in ga podpirajo vsi pomembnejši brskalniki.
7.2.3 Grafi
Pomemben sestavni del vizualizacije porabe finančnih sredstev sestavljajo dinamični grafi. Osnovni graf, ki se prikaže gostu na strani in prikazuje grobo strukturo porabe sredstev, je sestavljen v XHTML z uporabo DIV‐elementov, katerih širina ustreza odstotnemu deležu postavke.
Zahtevnejšo funkcionalnost nudijo grafi za podroben pregled določene postavke, ki so sestavljeni v SVG (Slika 17). Ti grafi se generirajo dinamično po potrebi. Uporabnik sproži zahtevo, ko se premakne z miško preko postavke v XHTML‐grafu. Ta akcija proži spletno storitev, ki s pomočjo XSLT pretvori in preračuna podatke zapisane v XML. Strukturo, ki jo vrne spletna storitev nato s pomočjo JavaScript preberemo in prožimo generacijo SVG‐grafa.
Dele grafa rišemo s pomočjo elementa, s katerim tvorimo »kose torte«. Path je najbolj univerzalen element SVG, saj omogoča izrisavo poljubne vektorske oblike po principu risanja kontinuiranih in diskontinuiranih črt, obliki, ki jo dobimo na ta način, pa lahko kontroliramo lastnosti
str. 72/84 barve, debeline robu,.. Na koncu teh kosov nato izpišemo še ime kategorije s pomočjo . Ta element nam omogoča, da izrišemo tekst po poteku krivulje, kar je za potrebo grafa idealno.
Slika 17: Na kakšen način so bila porabljena finančna sredstva, prikažemo grafično s pomočjo JavaScript, DOM dogodkov in SVG, podatke pa pridobimo preko spletne storitve.
Pri uporabi pathText je prišlo do anomalije (oz. do iz uporabniškega vidika nepričakovanega rezultata), ko smo želeli, da bi tekst pri vseh grafih stal na isti oddaljenosti od centra – radii posameznih grafov so namreč relativni glede na vrednost postavke. Edina možnost, ki nam jo SVG nudi kot ekvivalent »margin« oz. »padding« atributa v CSS, sta atributa »dx« in »dy« starševska‐ elementa , s katerim ovijemo element , ki vsebuje besedilo. Namesto da bi premaknil celoten tekst za določeno razdaljo (kot smo to intuitivno predvidevali, saj se operacija izvaja nad celim elementom), je prikazovalnik vsako črko zamaknil za podano distanco v smeri proti zunanjosti in s tem ustvari nekonsistentne razmake med črkami.
Ta problem smo rešili tako, da smo ustvarili za vsak kos torte nov ob zunanjem robu kroga, po katerem se sedaj izpiše besedilo. (Te dodatne elemente smo pozneje še obarvali in spremenili njihovo prosojnost, s čimer smo dobili večjo informativno vrednost in berljivost.)
Presenetljivo frustrirajoče so tudi (žal kljub vsem standardom še vedno obstoječe) razlike kvalitete in konsistentnosti prikaza v različnih brskalnikih in na različnih platformah. Rešitev smo sproti testirali na dveh različnih platformah (Mac OS X 10.5.2 in Microsoft Windows Vista) ter devetih različnih
str. 73/84 kombinacijah brskalnikov (Safari 3.1.1 /OSX, Safari 3.1 /Vista, Firefox 3 /OSX, Firefox 2 /OSX, Firefox 2 /Vista, Internet Explorer 8 /Vista, Opera 9.23 /Vista, Opera 9.5 /OSX in Opera 9.5 /Vista).
Medtem ko ne preseneča nepodprtost SVG v Explorerju (tam se SVG izrisuje s pomočjo plug‐in‐a od Adobe, pa še ta je ustavil razvoj zanj z obrazložitvijo, da SVG dobiva dovolj podpore s strani skupnosti, da je njihova podpora postala redundantna (24)), nas tem bolj čudijo razlike med ostalimi. Najboljšo podporo uporabljenim tehnologijam (in njihovim kombinacijam – uporaba imenskih prostorov, ad‐ hoc sestava strani preko JavaScript in DOM, SVG, ...) nudi aktualni Safari na OSX, medtem ko njegov brat na Visti zataji pri dinamični konstrukciji SVG drevesa.
Do anomalij pri prikazu prihaja praktično pri vseh brskalnikih. Tako Firefox 3 zataji pri animaciji, Opera 9.5 ne zna spremeniti velikosti vsebine SVG risbe, Safari pa ne osveži pravilno slike, če nad njo prožimo dogodke (recimo, da želimo spremeniti barvo ob onmouseover).
7.2.4 DateTime / ISO 8601
Zapis datuma in časa je standardiziran, če gledamo iz vidika XSD75, pomanjkljive pa so ponudbe za razvijalce, če gledamo iz vidika uporabe razpoložljivih orodij.
Vse bazira na standardu za časovni format ISO 8601, ki na široko opisuje in dopušča različne nevtralne zapise časa, tudi v obliki časovnih razponov. ISO 8601 bazira na greogorianskem koledarju in posledično ustreza zahodnim in kolonialnim standardom, ki so trenutno aktualni tudi globalno. Specifikacija XML predvideva uporabo podnabora tega standarda, pri čemer se izogiba v standardu tudi predvidene opcije zapisa datuma brez ločil. Klasičen zapis v XML/XSD ustreza strukturi 2008‐ 06‐10T23:05:00Z, pri čemer »Z« na koncu označuje UTC76.
Čeprav pravila dopuščajo zapis časa tudi na druge načine, smo se zaradi enostavnejše uporabe in bistveno manj kompleksnih manipulacijah odločili za uporabo prej omenjene strukture. Glavna težava, na katero smo naleteli pri uporabi takšnega zapisa v praksi je, da orodje – v tem primeru JavaScript – ne pozna nativne implementacije za razčlenjevanje in obdelavo takšnega formata.
JavaScript s časom upravlja preko dokaj fleksibilnega objekta Date(). Ta objekt je možno primerjati, mu spreminjati čas in datum ter adirati/subtrahirati čas, privzeto pa vrača trenutek, v katerem je bil sestavljen. Kljub hvalevrednemu naboru možnosti pa ne zna razčlenjevati XSD‐jevega zapisa
75 XML Shema Definition – DateTime predstavlja podatkovni tip v shemah.
76 Coordinated Universal Time / »Greenwich«. UTC ne upošteva zimskega/poletnega časa, srednjeevropski časovni pas je ali UTC +01 oz. UTC +02.
str. 74/84 DateTime. Iz tega razloga smo bili prisiljeni datum analizirati s pomočjo RegEx77 in rezultat pretvoriti v JavaScriptov datumski objekt.
Na dodatne probleme z datumskim objektom naleti Srednjeevropejec, ko ugotovi, da se tedni začnejo z nedeljo, meseci pa končajo z 11. mesecem, saj se začnejo z 0‐tim. Ustrezno kompleksnejša je kreacija koledarja, kot smo se je lotili, saj je treba nedeljo vsiliti na konec tedna.
7.2.5 DOM dogodki
Koledar, ki predstavlja vstopno točko portala MMSM, je kompleksna RIA aplikacija, ki združuje rezervacijo prostorov, upravljanje s dogodki, galerijo in vstopno točko za dostop do informacij o članicah obenem. Izvedba intuitivne aplikacije za rezervacijo prostorov je zahteven podvig, saj zahteva obvladovanje večih lokacijskih in časovnih dimenzij – ločevati je potrebno med zasedenimi in nezasedenimi termini odvisno od prostorske konfiguracije (vsi prostori, samo določen prostor, samo anotacija termina brez rezervacije prostora) – ter na podlagi teh informacij urediti prikaz prostih terminov in kontrolirati vnos novih rezervacij.
Slika 18: Termin si uporabnik rezervira tako, da prvo na časovni tabeli označi željen okvir, nato pa na modelu prostora označi željen prostor. Tehnično rešimo to nalogo s pomočjo DOM dogodkov, SVG in JavaScript.
77 Uporaba Regular Expressions je v JavaScript razmeroma preprosta in integrirana kar med metode String‐ objekta.
str. 75/84 Sam postopek rezervacije termina poteka po principu, da uporabnik na časovno tabelo vriše željen časovni razpon ter s klikom na grafični prikaz tlorisa MMSM izbere željen prostor (Slika 18). Oba postopka bazirata na manipulaciji DOM s pomočjo JavaScript, pri čemer je tloris zgrajen v SVG, časovna tabela pa v XHTML.
S pomočjo dogodkov ugotavljamo, kdaj je uporabnik kliknil (Element.onclick) na DOM element, kdaj se nahaja nad drugim (Element.onmouseover) in kdaj spusti miškin gumb nad tretjim (Element.onrelease). Elementi v časovni tabeli so fiksne višine in vsak zase predstavljajo eno uro. Njihova lokacija v hierarhiji je znana, tako da razpolagamo z informacijo o časovnem razponu, s pomočjo katere narišemo okvir. Okviri na to ob vsakem novem dogodku osvežimo, tako da uporabnik dobi občutek, da “riše” termin.
Nadaljnjo kontrolo nad časovno lestvico si ustvarimo z globalnimi spremenljivkami, s pomočjo katerih preverjamo status uporabniškega vmesnika.
Možnosti za ugotavljanje dogodkov so v JavaScript dokaj omejene. Tako ni možno intuitivno definirati lastnih dogodkov, kot je to pri drugih programskih jezikih, temveč je za takšno funkcionalnost potrebno poskrbeti z lastno iznajdljivostjo.
Ko nastopi potreba po lastnih dogodkih, si po navadi pomagamo z uporabo eval(arg) funkcije, s katero JavaScript izvajalno okolje interpretira podan argument kot programsko kodo in jo izvede.
7.2.6 JSON in spletne storitve
Eval() uporabljamo tudi, ko operiramo s spletnimi storitvami, ki vračajo rezultat v zapisu JSON. Akronim stoji za “JavaScript Object Notation” in predstavlja strukturni zapis objektov v JavaScript.
{ 'photos': { 'photo': [ { 'src': 'urlA' }, { 'src': 'urlB' } ] }
} Tabela 7: JSON (levo) je bistveno manj podatkovno zahteven kot XML, ustrezno pa tudi manj informativen
str. 76/84 JSON kot alternativa k XML pri spletnih storitvah nudi sicer tudi pomembne prednosti pri obsegu vrnjenega rezultata – JSON je bistveno lažji od XML (kot je razvidno iz tabele 6, zahteva isti podatek predstavljen v JSON bistveno manj znakov, kot podatek v XML ), ki so pomembne iz vidika porabe resurs, pasovne širine (bandwidth) in procesne moči, a najpomembnejši faktor iz vidika razvijalca ostane njegova enostavna uporaba kot gotov objekt, ki razen klica funkcije eval() ne zahteva dodatnega razčlenjevanja, obvladovanja DOM itd.
Pri spletnih storitvah se pojavi še en faktor, ki govori v prid JSON, ki ni vezan na praktično uporabno vrednost, temveč na obhod varnostih mehanizmov. Tako vsi pomembni “alternativni” brskalniki onemogočajo uporabo XMLHttpRequest objekta pri klicu spletnih storitev, ki niso v isti domeni, kot je izvirna koda.
Ta problem se rešuje na različne načine – bodisi s posebnimi heki, ki so odvisni od uporabljenega brskalnika, bodisi s zahtevo za soglasje uporabnika po izvajanju takšne “ne varne” kode, bodisi s pomočjo proksi rešitve, pri kateri se na lastnem strežniku prvo kliče in procesira tujo spletno storitev, na to pa iz skriptne kode uporabi ta rezultat.
Tudi uporaba JSON pri tujih spletnih storitvah zahteva nekaj iznajdljivosti, ki pa upravičuje trud. Tako je ustaljena praksa, da se rezultat spletne storitve injicira v aplikacijo preko DOM na način, da se v glavo ad‐hoc generira script‐označbo, kateremu se kot vir nastavi pot do spletne storitve vključno s potrebnimi spremenljivkami. Koda, ki se na ta način generira, načeloma vsebuje funkcijo za samodejni povratni klic, ki se proži ob uspešni interpretaciji rezultata spletne storitve ‐ v to funkcijo se pridobljen objekt vnese v obliki parametra, s čimer nato lahko razpolagamo poljubno.
Ta način pridobitve podatkov je v svojem bistvu asinhron, kar pa je funkcionalnost, ki je lahko tudi nezaželena.
Varnostne omejitve, ki jih zastavljajo izvajalna okolja XMLHttpRequest‐objektu so razumljiva, še večjo varnostno tveganje pa predstavlja ravno JSON – medtem ko je XML, ki ga prejmemo iz spletne storitve v svojem bistvu le način zapisa podatkov, predstavlja JSON direktno injekcijo kode v aplikacijo.
Za predstavljeno metodo pridobivanja podatkov iz spletne storitve smo se pri portalu MMSM odločili za dostop do API, ki ga ponuja Flickr78. Ta API nam omogoča, da v našo aplikacijo integriramo spletno
78 Flickr je trenutno (poleti 2008) največji (in najbolj medijsko podprt) portal za izmenjavo fotografij, na katerega uporabniki objavljajo svoje fotografije. Flickr, ki je del skupine Yahoo, nudi dobro podporo za razvijalce, ki se želijo poslužiti njihovega sistema in ga integrirati v lastne aplikacije. Ravno posebnost grupiranja fotografij različnih avtorjev glede na podano označbo je funkcionalnost, ki izjemno pripomore k medijski
str. 77/84 galerijo tipa mash‐up: v sam dogodek zapišemo označbo, ki se vede kot identifikator dogodka, katerega uporabniki, ki so na tem dogodku napravili fotografije, navedejo ob nalaganju lastnih del. Koledar ob klicu novega meseca pregleda, ali je v tem mesecu prišlo do dogodka, ki razpolaga z ustreznim Flickr‐identifikatorjem in takrat izriše spletno galerijo, ki vrne niz fotografij, ki se nahajajo v Flickr sistemu.
Decentralizacija shranjevanja fotografij nam bistveno olajša razvoj in delovanje sistema ter razbremeni razpoložljive kapacitete (pa četudi so to samo pasovna širina, čas in osebna energija). Bistveno olajšana je tako tudi implementacija koncepta na druge dele aplikacije (npr. namizna varianta, znotraj različnih gadgetov, za mobilne naprave ipd.)
7.2.7 Hrošč 98168
“It’s not a bug, it’s a feature” je stavek, ki ga humoristično radi povezujemo s podjetjem Microsoft, a tudi odprte in “čiste” tehnološke rešitve poznajo ta fenomen. Poseben pomen ima Mozillin hrošč št. 98168 za spletne razvijalce, saj predstavlja močan hendikep te, sicer opevane, razvijalske platforme.
XSL pozna atribut “disable‐output‐escaping”, ki nam omogoča, da posredujemo nespremenjen niz, torej niz, ki vsebuje tudi znake <, & in druge, ki imajo lahko semantično vrednost za sestavo strukture strani. V kombinaciji s CDATA‐sekcijo nam ta atribut dovoli, da v XML datoteko zapišemo HTML kodo, oz. poljubno drugo kodo, ki ne spada v trenutni imenski prostor.
Na hrošč št. 98168 smo naleteli, ko smo želeli transformirati zapisnike sej s pomočjo XSLT v očem prijaznejšo obliko. Zapisnike hranimo v XML obliki, ki pa se generira bodisi ročno, bodisi programatsko – slednji primer pa predvideva uporabo WYSIWYG‐urejevalca, ki izdela XHTML kodo. Zapis, ki smo ga dobili iz urejevalca, smo direktno prenesli v XML zapis seje, pri čemer smo ga ovili v CDATA‐sekcijo, kar je nujno, saj se koda prenaša preko spletne storitve, ki na strežniku preveri validnost poslane strukture.
Izrisovanje tako shranjenih podatkov smo želeli izvesti na “grob” način, tako da smo izpisali vsebino CDATA sekcije, ob tem pa nastavili atribut “disable‐output‐escaping” na “true” (privzeta vrednost je “false”). Ta način je povsem logičen in jasen, in deluje na vseh brskalnikih, razen Mozille.
Hrošč 98168 je bil prvič uradno javljen leta 2001, leta 2008 pa še vedno ni razrešen. Posamezni pomembnejši razvijalci so se postavili na stališče, da to ni hrošč, temveč je funkcionalnost, ki prepreči zmedo. Večkrat citirano pojasnilo h tem hrošču je komentar št. 11, avtorja Peter Van der Beken
prepoznavnosti te aplikacije, saj zabavna industrija javnost poziva, da svoje fotografije žigosajo s določeno označbo glede na dogodek (koncert, show, …).
str. 78/84 (https://bugzilla.mozilla.org/show_bug.cgi?id=98168#c11 ‐ Van der Beken je soustanovitelj Mozilla Europe in eden vodilnih razvijalcev tega projekta), ki zatrjuje, da ne bo prišllo do popravka tega hrošča, ker da to sploh ni. Funkcionalnost atributa d‐o‐e naj bi pogojevala zmožnost XSLT procesorja, da vrši nadzor nad tem, kako se DOM‐drevo serializira na izhodu. Mozillin modul “Transformiix” pa naj te zmožnosti ne bi imel, saj omenjeni modul zgolj generira DOM drevo, ne serializira ga pa.
Slika 19: Zapisnik se s pomočjo XSLT, JavaScript in CSS transformira v uporabniku prijazno in logično obliko
Stališče, da se tekst znotraj CDATA prikaže kot tekst in ne del DOM drevesa, je razumljivo in – kljub pričakovanjem uporabnikov – tudi legitimno. Uporabnik, ki želi, da bi DOM vseboval separatno DOM strukturo (XHTML znotraj XML), je dolžan to vprašanje urediti s pomočjo imenskih prostorov.
Razlika med Transformiix pri Mozilli in drugimi sorodnimi moduli je ta, da prvi generira DOM, katerega brskalnik direktno prevzame (torej se CDATA obravnava kot tekst), medtem ko moduli drugih brskalnikov prvo generirajo DOM, le‐tega serializirajo v tekst, tekst nato podajo brskalniki, ki ga zopet spremeni v DOM in na ta način interpretira elemente znotraj CDATA kot del celotnega DOM drevesa.
Rešitev, kot smo jo uporabili pri našem primeru je ta, da smo HTML elemente ovili v div‐označbe, s XHTML imenskim prostorom. Ta način ne moti validnosti XML dokumenta, hkrati pa se vsebina pravilno interpretira kot XHTML in kot taka tudi izpiše. (Slika 19 prikazuje s pomočjo XSLT pravilno izrisan zapisnik, ki se sicer hrani v XML obliki.)
str. 79/84 8. Zaključek
Analizirali smo tehnologije, ki se danes uporabljajo za ustvarjanje spletnih aplikacij – tako odprte tehnologije (»odprti standardi« W3C ipd.), kot tudi lastniške rešitve, ki jih ponujajo softverski giganti, kot so Microsoft (Silverlight), Adobe (Flash/Flex) idr. (JavaFx, Curl, OpenLaszlo).
Pri izdelavi praktičnega primera – RIA aplikacije za organizacijo poslovanja mladinske organizacije – smo ugotovili, da so odprti standardi, ki se uporabljajo za izdelavo RIA aplikacij sicer dobro, a še vedno premalo podprti s strani industrije, s čimer postane njihova uporaba iz oblikovalskega in razvijalskega vidika nepredvidljiva in preveč kompleksna. Pomanjkanje podpore izkazujejo vsi obstoječi brskalniki, tako največji, kot tudi manjši, kar pa pomeni, da se razvijalec nujno mora prilagoditi specifikam posameznih izvajalnih okolji (brskalnikov), kar potegne za sabo dodatno posvečanje univerzalnim rešitvam.
Nadaljnji velik problem odprto‐standardnih tehnologij je poleg tega to, da je njihov razvoj odvisen od verige birokratskih odločitev akademskih delovnih skupin, ki niso nujno v stiku z realnimi potrebami trga. Tako se razvoj standardov načrtuje v smeri, kjer komercialne rešitve že so, razvoj torej caplja za potrebami trga, birokratski aparat pa ne dohaja več potrebam. Pri tem je treba upoštevati tudi aspekt, da organizacije, ki vplivajo na razvoj teh standardov (tudi Microsoft, Adobe in Google), same vlagajo velika sredstva in dosti energije v razvoj lastnih RIA tehnologij, s čimer prihaja do konflikta interesov. Brskalniki, ki podpirajo le eno skupno definirano izvajalno okolje (za odprte standarde), ne ustrezajo več dikciji časa, saj postaja vključenost drugih izvajalnih okolij (preko vtičnikov) čedalje bolj pomembna. Posledično za komercialne rešitve velja, da bodisi delajo, bodisi ne (ker ni nameščen vtičnik), za odprte standarde pa, da bodisi delajo le deloma, bodisi ne, bodisi pa popolno – to pa je lahko prevelik riziko za razvoj resnih rešitev.
Alternative, ki jih »standardom« nudijo komercialne rešitve, so zato še posebej mikave, saj nudijo celovit pristop k rešitvi problema, načeloma dobro podprt s strani podjetja, ki rešitev ponuja. A tudi med temi tehnologijami obstajajo močne razlike, ki se vidijo predvsem v deležih podpore med uporabniki. Najbolj pomembna tehnologija je – tako iz razvijalskega, ko tudi uporabniškega vidika – Adobe Flex (oz. Flash), saj je podpora iz strani trga zdaleč največja in najbolj zanesljiva. Najmočnejša konkurenca Adobe‐jevem programju je Microsoftova rešitev Silverlight, ki pa uživa prešibko podporo s strani uporabnikov, da bi bila zanimiva za razvoj tržnih aplikacij. Preostale rešitve pa predstavljajo zanemarljive tržne deleže.
Pomemben faktor spletnih tehnologij prihodnosti postaja tudi konvergenca spleta in namizja. Aplikacije, ki jih razvijamo za splet, pričenjajo prodirati na namizja in pomemben postaja faktor
str. 80/84 enostavne tranzitivnosti iz brskalnika na namizje. Takorekoč vsi pomembni na področju RIA (Microsoft: Silverlight/WPF, Adobe: Flex/AIR, Java: JavaFX) ponujajo svoje tehnologije in razvijalska orodja tako za splet, kot tudi za namizje. Pojavljajo pa se tudi pristopi za tranzicijo spletnih aplikacij odprtih standardov na namizje preko »brskalnikov«, ki zaganjajo le eno aplikacijo.
Prva velika vojna na področju spletnih tehnologij je bila med brskalniki v 90ih letih prejšnjega stoletja, ko je bilo vprašanje, kdo bo zavladal temu trgu. Vojna za prevlado RIA aplikacij je naslednja velika bitka za prevlado na spletu in le čas bo pokazal, kdo ima trenutno boljše karte v rokah.
str. 81/84 9. Citirana dela
1. Wikipedia ‐ HTML. Wikipedia. [Elektronski] [Navedeno: 09. april 2008.] http://en.wikipedia.org/wiki/HTML.
2. Wikipedia ‐ Tim Berners‐Lee. Wikipedia. [Elektronski] [Navedeno: 09. april 2008.] http://en.wikipedia.org/wiki/Tim_Berners‐Lee.
3. Wei, Pei‐Yuan. Pei's Home Page. [Elektronski] [Navedeno: 12. april 2008.] http://www.xcf.berkeley.edu/~wei.
4. —. Montage of the 1991 Vintage Viola. [Elektronski] [Navedeno: 12. april 2008.] http://www.xcf.berkeley.edu/~wei/viola/vintage/montage.html.
5. Wikipedia ‐ Mosaic (web browser). Wikipedia. [Elektronski] [Navedeno: 09. april 2008.] http://en.wikipedia.org/wiki/Mosaic_(web_browser).
6. Wikipedia ‐ Usage share of web browsers. Wikipedia. [Elektronski] [Navedeno: 13. april 2008.] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers.
7. Kyrnin, Jennifer. Tags for One Browser. About.com. [Elektronski] [Navedeno: 13. april 2008.] http://webdesign.about.com/cs/htmltags/a/aa012300a_2.htm.
8. Wilson, Brian. Index DOT Html ‐ The Advanced HTML Reference. [Elektronski] 01. 10 2003. [Navedeno: 13. april 2008.] http://www.eskimo.com/~bloo/indexdot/html/supportkey/a.htm.
9. Zeldman, Jeffrey. Why IE5/Mac matters. A List Apart. [Elektronski] 31. 03 2000. [Navedeno: 15. april 2008.] http://www.alistapart.com/articles/ie5mac.
10. MacIE5 CSS Hack. [Elektronski] [Navedeno: 16. april 2008.] http://www.sam‐i‐ am.com/work/sandbox/css/mac_ie5_hack.html.
11. Gustavson, Aaron. A List Apart: Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8. A List Apart. [Elektronski] 21. 01 2008. [Navedeno: 13. april 2008.] http://www.alistapart.com/articles/beyonddoctype.
12. Lie, Håkon Wium. Cascading HTML STyle Sheets ‐ A Proposal. [Elektronski] 10. 10 1994. [Navedeno: 18. april 2008.] http://www.w3.org/People/howcome/p/cascade.html.
13. Lie, Håkon Wium in Bos, Bert. Chapter 20 The CSS saga. [Elektronski] 1999. [Navedeno: 18. april 2008.] http://www.w3.org/Style/LieBos2e/history/.
str. 82/84 14. Eriksson, Jan Roland. About NS4x and JSSS. [Elektronski] 29. 07 2007. [Navedeno: 19. april 2008.] http://www.dev‐archive.net/articles/About‐JSSS.html.
15. Dodge, Martin. Fly Through the Web. Mappa.Mundi Magazine. [Elektronski] 12. januar 2001. [Navedeno: 2. maj 2008.] http://mappa.mundi.net/maps/maps_018/.
16. Pilgrim, Mark. The myth of RSS compatibilty. dive into mark. [Elektronski] 4. februar 2004. [Navedeno: 2. maj 2008.] http://diveintomark.org/archives/2004/02/04/incompatible‐rss.
17. Moritz, Florian. Diploma Thesis: RIA ‐ A Convergence of User Interface Paradigms of Web and Desktop Exemplified by JavaFX. [Elektronski] januar 2008. [Navedeno: 31. julij 2008.] http://www.flomedia.de/diploma/documents/DiplomaThesisFlorianMoritz.pdf.
18. Wikipedia ‐ YouTube. WikiPedia. [Elektronski] [Navedeno: 30. julij 2008.] http://en.wikipedia.org/wiki/YouTube.
19. der Spiegel. Teenie‐Chat im Porno‐Universum. Spiegel online. [Elektronski] 11. julij 2007. [Navedeno: 31. julij 2008.] http://www.spiegel.de/netzwelt/web/0,1518,493751,00.html.
20. Wikipedia ‐ MXML. Wikipedia. [Elektronski] [Navedeno: 1. maj 2008.] http://en.wikipedia.org/wiki/MXML.
21. Wikipedia ‐ XML User Interface Language. Wikipedia. [Elektronski] [Navedeno: 29. april 2008.] http://de.wikipedia.org/wiki/XML_User_Interface_Language.
22. Cubrilovic, Nik. TechCrunch. The Next‐Gen Web: Browser Storage Support. [Elektronski] 29. maj 2008. [Navedeno: 25. junij 2008.] http://www.techcrunch.com/2008/05/29/the‐next‐gen‐web‐ browser‐storage‐support/.
23. Novachev, Dimitre. Re: XPath anomaly. MSDN Forums. [Elektronski] 01. junij 2008. [Navedeno: 01. junij 2008.] http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3426519&SiteID=1.
24. Adobe. [Elektronski] [Navedeno: 30. julij 2007.] http://www.adobe.com/svg/eol.html.
25. Wikipedia ‐ ENQUIRE. Wikipedia. [Elektronski] [Navedeno: 12. april 2008.] http://en.wikipedia.org/wiki/ENQUIRE.
26. Wikipedia ‐ Gecko (layout_engine). Wikipedia. [Elektronski] [Navedeno: 13. april 2008.] http://en.wikipedia.org/wiki/Gecko_(layout_engine).
27. Wikipedia ‐ Standard Generalized Markup Language. Wikipedia. [Elektronski] [Navedeno: 12. april 2008.] http://en.wikipedia.org/wiki/SGML.
str. 83/84 28. Hickson, Ian. Ian Hickson's Resumé. [Elektronski] 2005. [Navedeno: 19. april 2008.] http://ian.hixie.ch/career/resume.html.
29. Lie, Håkon Wium. The Acid2 challenge to Microsoft. C|Net News.com. [Elektronski] 15. marec 2005. [Navedeno: 19. april 2008.] http://www.news.com/The‐Acid2‐challenge‐to‐Microsoft/2010‐ 1032_3‐5618723.html?tag=nefd.ac.
30. Meiert, Jens. Übersicht aller CSS‐Eigenschaften ‐ Index von Jens Meiert. [Elektronski] 27. marec 2008. [Navedeno: 26. april 2008.] http://meiert.com/de/publications/indices/css‐properties/.
31. TIOBE Software BV. [Elektronski] junij 2008. [Navedeno: 28. junij 2008.] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html.
32. Eichenwald, Kurt. Through His Webcam, a Boy Joins a Sordid Online World. New York Times. [Elektronski] 19. december 2005. [Navedeno: 31. julij 2008.] http://www.nytimes.com/2005/12/19/national/19kids.ready.html?hp&ex=1135054800&en=5eb58e 4d773204ee&ei=5094&partner=homepage.
33. Rich Internet Applications Statistics. [Elektronski] 26. september 2008. [Navedeno: 26. september 2008.] http://riastats.com
34. Cabello, Percy. Firefox takes 28% market share in Europe. Mozilla Links. [Elektronski] 13. julij 2007. [Navedeno: 26. september 2008.] http://mozillalinks.org/wp/2007/07/firefox‐takes‐28‐ market‐share‐in‐europe/.
str. 84/84