De ’browserwar’ zoals we die op Internet kennen, zal verbleken bij de strijd die er op de mobiele markt losbreekt. Nu al kan men zien dat er diverse spelers op de markt zijn, elk met zijn eigen apparaat. En elk van de apparaten heeft niet alleen zijn eigen fysieke afmetingen, ook de toegepaste software (browsers) verschilt onderling sterk. Verschillende termen vliegen door de lucht: WAP, i-mode, HTML en compact-HTML. Veel IT-managers en beslissingsmakers zullen met een onzekere situatie worden geconfronteerd. Er moet een mobiele site worden opgezet terwijl het niet bekend is op welke apparaten en infrastructuur deze informatie aangeboden gaat worden.
De oorsprong van al de verwarring ligt in de brede definitie van de verschillende opmaaktalen op het world wide web (WWW). Begin 1999 kwam onder leiding van Phone.Com een aantal van de grote GSM-producenten bij elkaar om een vergelijkbare situatie op het mobiele Internet te voorkomen. Men sloeg de handen ineen om een nieuwe opmaaktaal te ontwikkelen. Dit consortium, wat door het leven gaat als het WAP-forum, stelde zich ten doel een, voor de aangesloten bedrijven, acceptabele standaard te ontwikkelen die voor al hun mobiele apparaten gehanteerd zou kunnen worden.
De eerste versie van WAP zag het licht, maar bevatte een aantal zwakheden. Deze versie 1.0 is niet in veel apparaten geïmplementeerd en werd al snel opgevolgd door versie 1.1. Dit leidde in de herfst van 1999 tot het begin van de zogenaamde WAP-hype. Elke kenner voorspelde dat WAP binnen afzienbare tijd populairder zou worden dan het huidige WWW. De geschiedenis heeft echter geleerd dat het anders is gelopen dan de meeste telecombedrijven hadden gehoopt.
Aan de andere kant van de wereld, in Japan, werd door NTT-Docomo, onder de naam ’i-mode’, een alternatieve datadienst voor mobiele apparaten in de wereld gezet. I-mode is, in tegenstelling tot WAP, een totaalconcept. Het is een totaaldienst waarbij een gebruiker een ’vaste verbinding’ krijgt en afgerekend wordt op basis van het verbruik van data. NTT-Docomo stelt zich hiertoe op als totaalregisseur van het concept en bepaalt welke aanbieder van diensten wel en niet toegang tot het netwerk krijgt.
Er is dus geen sprake van mobiel Internet waarbij een mobiel apparaat toegang heeft tot geheel Internet. Het is vergelijkbaar met hoe Compuserve in de VS vroeger was georganiseerd: gebruikers konden toegang krijgen tot een afgesloten netwerk dat in handen was van een commerciële instelling. Deze instelling bepaalde vervolgens wat werd aangeboden en tegen welke tarieven. Dit model heeft echter niet lang stand gehouden tegen de oprukkende concurrentie van via het WWW opererende aanbieders.
Rond kerst 1999 kwam in Nederland de Nokia 7110 mondjesmaat beschikbaar. Met 1397 bytes intern geheugen en een schermgrootte van 96x65 pixels is dit nu het referentietoestel bij uitstek geworden. Sindsdien is het aantal toestellen met WAP-ondersteuning zo fors toegenomen dat tegenwoordig vrijwel elk nieuw GSM-toestel ermee werkt. Helaas stemmen de producenten hierbij onderling niet op elkaar af zodat elk toestel andere beperkingen qua geheugen- en beeldschermgrootte heeft.
Wat het probleem nog schrijnender maakt is dat het niet alleen tússen GSM-producenten optreedt maar ook aanwezig is in de verschillende GSM-toestellen van één producent. Bij de Nokia-toestellen bijvoorbeeld mag een plaatje op de 6210 96x41 pixels groot zijn. Op de 9110 daarentegen mag deze zelfs 480x200 pixels zijn. Gezien de verschillende toestellen lijkt dit logisch, maar zelfs bij vergelijkbare toestellen als de 7110 en de 6120 heeft Nokia verschillende schermgroottes toegepast.
Dit illustreert de moeilijkheden bij het ontwerpen van een site voor mobiel Internet. Er dient rekening gehouden te worden met al de verschillende soorten mobiele browsers die verschillende standaarden ondersteunen.
Ook kennen de apparaten verschillende fysieke begrenzingen. En die zullen in de toekomst alleen maar groter worden. Er komen meer toestellen met meer mogelijkheden en meer diversiteit. Daarnaast is er ook nog sprake van een ’vast’ Internet dat HTML spreekt en een ’mobiel’ Internet dat met WML is opgebouwd. Het ene deel kan niet zonder meer – uitzonderingen als de webbrowser Opera 5.0 daargelaten – informatie uit het andere deel verwerken en tonen.

Fout gedrag
De toekomst voor mobiel Internet staat sinds het begin van dit jaar vast. Als drager zal men in eerste instantie gebruik maken van het low-end GPRS en in een latere fase van het meer krachtige UMTS. De van deze netwerken gebruikmakende apparaten zullen voornamelijk zijn uitgerust met browsers gebaseerd op de nog uit te brengen WAP-2.0-standaard. Deze standaard is nog dermate nieuw – hij is nog niet geheel vastgesteld – dat er relatief weinig over bekend is. Wat er wel bekend is, is dat het een onderdeel is van Xhtml. Xhtml is een volledig nieuw uitgebrachte versie van HTML die het nu nog populaire HTML 4.x op het WWW moet vervangen.
Xhtml kent twee belangrijke vernieuwingen. Ten eerste, hij is gebaseerd op XML. Het huidige HTML laat veel toe. Het maakt het de ontwerper mogelijk zich niet geheel aan de standaard te houden. De een noemt dit flexibiliteit, de ander verkeerd gedrag. Deze flexibiliteit/dit fout gedrag echter leidt regelmatig tot problemen wanneer een site op een andere browser of besturingssysteem wordt bekeken dan waarvoor hij in eerste instantie is ontwikkeld. Het zorgt voor langere ontwikkelingstijden tijdens de bouw van een site.
Een oriëntering op XML lost dit probleem op. XML is erg strikt tijdens de validatie. De ontwerper moet zich exact aan de standaard houden of er treedt een foutmelding op. De tweede vernieuwing is dat het een modulaire standaard is, waarmee wordt bedoeld dat er afgebakende onderdelen vallen te onderscheiden binnen de standaard.
Het belangrijkste onderdeel is Xhtml-Basic. Het is door het W3.org op 19 december vorig jaar uitgebracht als een zogenaamde ’recommendation’, wat in W3.org-taal zoveel betekent dat het een standaard is geworden. Xhtml-Basic is, zoals de naam al aangeeft, de basis waarop geheel Xhtml ’rust’. Elk apparaat dat de intentie heeft Xhtml te spreken, ook al is het een computer, pager, telefoon of tostiapparaat, dient over de Xhtml-Basic-module te beschikken. Hij bevat eigenschappen als tekstopmaak, hyperlinks, rudimentaire formulieren, rudimentaire tabellen, plaatjes en meta-informatie. Wanneer een apparaat meer fysieke mogelijkheden heeft (meer geheugen, betere/grotere schermen, betere processor) dan kunnen er meerdere modules worden ondersteund.
Een browser op een mobiele telefoon zou bijvoorbeeld alleen de rudimentaire formulieren ondersteunen. Deze kent alleen ondersteuning voor: ‹input›, ‹label›, ‹select›, ‹option› en ‹textarea›. Een PDA of een mobiele telefoon met PDA-functionaliteit (en afmetingen) zou naast de Xhtml-Basic-module ook de forms-module kunnen bevatten. Deze biedt naast de voorgenoemde tags ook: ‹button›, ‹fieldset›, ‹label›, ‹legend› en ‹optgroup›.
Op dit moment is nog niet geheel bekend hoe de WAP-2.0-standaard eruit komt te zien, de voltooiing is gepland rond het midden van dit jaar. Echter, tijdens de bijeenkomst van het internationale WAP-forum in München in december vorig jaar zijn de ruwe schetsen voor de 2.0-standaard vastgelegd. Zo zal WML worden uitgefaseerd en worden vervangen door Xhtml. Ook krijgt de nieuwe versie mogelijkheden voor popup-menu’s, animatie en een groter scala aan multimedia-functionaliteit.
Hiermee wordt tegemoetgekomen aan de wens die bij veel ontwikkelaars en consumenten leeft om meer i-mode-’achtige’ functionaliteit op te nemen. De verwachting is dat mobiel Internet op deze wijze een hogere vlucht zal nemen dan nu het geval is. Deze verwachting is gestaafd op de resultaten van i-mode in Japan.
Het probleem nu is dat door de veelheid aan verschillende mobiele apparaten gecombineerd met de verwachte migratie van WML naar Xhtml, veel beleidsmakers een beslissing dienen te nemen over investeringen in mobiel Internet. Het dilemma daarbij is dat de site nu of binnen afzienbare tijd operationeel dient te zijn en dat deze enige tijd operationeel dient te blijven. Bestaan er mogelijkheden waarmee nu een site gemaakt kan worden die zonder veel problemen ook in de toekomst met WAP-2.0/Xhtml kan werken?

Superieur
Het antwoord hierop is ja. Er zijn zelfs verschillende manieren. Het is mogelijk een oplossing te kiezen die gebruik maakt van meerdere templates met elk zijn eigen logica en opmaaktaal. Voor elke opmaaktaal ((X/c)HTML, WML) en elk mobiel apparaat zal logica ontwikkeld moeten worden. Tijdens het weergaveproces van de site zal de software moeten achterhalen over welke opmaaktaal en welke fysieke dimensies het apparaat beschikt om vervolgens de juiste logica te activeren. Dit proces leidt ertoe dat de juiste template gevuld wordt met de juiste data.
Deze oplossing wordt nu door sites in veel situaties gekozen. Algemeen wordt echter een XML/XSLT-toepassing als een superieure oplossing gezien. Ook in deze situatie is er sprake van templates, het aantal is alleen veel kleiner en ze zijn veel flexibeler aan te passen aan nieuwe situaties.
De data die op de site getoond dienen te worden kunnen, net als in de voorgaande situaties, uit een database afkomstig zijn. Zij dienen nu echter in XML-vorm aan de software aangeboden te worden. Vervolgens worden door translatie de data aangepast aan het apparaat dat de data oproept. Deze translatie wordt uitgevoerd door de zogenaamde XSLT-XSL Transformation Language.
Met XSLT wordt er een bestaand XSL-document opgepakt en getransformeerd door de XSL-stylesheet. De instructies in het document bepalen wat het output-formaat wordt. Wanneer er nu een HTML-browser voorbijkomt kunnen de data door de stylesheet getransformeerd worden naar een ’rich-media’ HTML-document. De bezoeker met een WAP-telefoon echter zorgt ervoor dat er een andere stylesheet wordt aangeroepen die de informatie zodanig transformeert dat deze leesbaar is voor de WAP-telefoon. Het maakt hiervoor gebruik van zogenaamde ’transformation rules’. Deze regels bepalen wat er met welke XML-content gedaan moet worden.
Het woord ’welke’ geeft aan wat de kracht is van XML. Omdat de XSLT ’weet’ welke data in het XML-document welke betekenis hebben, kan er een zeer specifieke transformatie worden uitgevoerd. Zonder dit zou het alleen met specifiek ontwikkelde programmatuur gerealiseerd kunnen worden. En dit zou eindeloos herhaald moeten worden bij het uitkomen van nieuwe apparaten met weer nieuwe mogelijkheden. En iedere keer moet men weer hopen dat de programmeurs nog snappen wat de code doet en betekent. In een situatie waarbij de XML-data door een XSLT getransformeerd worden, hoeft men alleen de browserdetectieroutine aan te passen en een nieuwe XSLT-stylesheet bij te voegen.

Zelfbouw
Tot nu toe is het probleem relatief theoretisch benaderd, een meer praktische benadering is te kijken wat er gedaan moet worden om de gewenste XML/XSLT-situatie te bereiken.
Men moet ervoor zorgen dat de zogenaamde ’middleware’ op basis van XML/XSLT gaat werken. Hiertoe zijn er twee mogelijkheden, of men bouwt het zelf of men koopt een kant-en-klare-oplossing. De ’zelfbouwmethode’ wordt op dit moment goed ondersteund door het Windows-NT-platform. Met de introductie van Msxml-3.0 in de herfst van vorig jaar heeft Microsoft zich geheel gecommitteerd aan de XSLT-1.0-specificatie van het W3.org. Het is dus goed mogelijk om een dergelijke oplossing op dit platform te realiseren.
Bij bijvoorbeeld Linux liggen de zaken wat onduidelijker. Veel dynamische sites die gebruik maken van het Linux-besturingssysteem zijn gebouwd op basis van PHP. In de huidige versie (versie 4.0) biedt dit standaard ondersteuning voor XML, maar nog niet voor XSLT zodat een ontwikkelaar gedwongen is te kiezen voor PHP-modules van buiten de standaard-PHP-omgeving.
De tweede mogelijkheid is het kopen van een kant-en-klaar-pakket. Het gaat hierbij dan vaak om een zogenaamde ’applicatieserver’. Deze applicatieservers bieden de mogelijkheid relatief snel een site in de lucht te helpen. Hiertoe biedt het een uitgebreid scala aan diensten die met relatief weinig programmeerwerk – men noemt dit liever configuratie – in werking gebracht kan worden.
Het aanbod van applicatieservers is echter groot. Zo brengen onder andere Netscape, IBM, Haht, Apple en Oracle applicatieservers uit. In dit kader echter is de Oracle 9i Applicatieserver illustratief. Deze komt namelijk in een speciale ’Wireless Edition’ uit. Oracle stelt dat het met de applicatieserver mogelijk is de content aan te passen aan elk apparaat, opmaaktaal en beeldschermgrootte. Het garandeert zelfs dat de server zodanig in te richten is dat dezelfde data transparant op websites en mobiele sites gebruikt kunnen worden.
Richard Flapper is als senior WAP-developer werkzaam bij Allwap.com, te Den Haag (richard@allwap.com).

Links
Applicatieserver
http://www.oracle.com/ip/deploy/ias/index.html
Ontwikkelingsomgeving
http://msdn.microsoft.com/xml/default.asp
Wap, Xhtml
http://www.WAP-forum.org/what/technical.htmb0,5
http://www.w3.org/MarkUp/
Wap-2.0
http://www.32bitsonline.com/article.php3?file=news/200012/nb20001213&page=
http://www.theregister.co.uk/content/6/12304.html