I det här kapitlet presenteras en analys av vad som framkommit under genomförandedelen av projektet.
6.1 Litteraturstudie
En analys av litteraturstudien ger initialt att det finns två stora grupper av aktörer inom produktionen av material om XML, då ur ett perspektiv av XML som datalagringsteknik eller som komponent i sammansatta system. De två grupperna utgörs av programutvecklingsindustrins tongivande företag respektive forskare inom databaskollegiet. Övrigt material utgörs främst av introduktioner och presentationer av XML som en ny teknik. XML framställs som tekniken som skall lösa många av de problem som vuxit fram med HTML, vad gäller till exempel behovet av att kunna uttrycka egna element och attribut, att kunna deklarera strukturella regler samt att kunna utforma olika publiceringsmallar utifrån en central datakälla. Facklitteratur på området är i det närmaste obefintlig och den facklitteratur som detta projekt har studerat ger ett ytligt och i fråga om XML som datalagrare, till och med ett något förvirrat och ofullständigt intryck. En gemensam nämnare hos alla källor som studerats är dock att XML betraktas som en positiv utveckling och en teknik som kommer att möjliggöra nya former av transaktioner inom kommersiellt aktuella områden som mobila applikationer, mobilt Internet och e-handel.
6.1.1 XML som datalagrare
Vad som däremot framstår som en gemensam nämnare vad gäller problem med XML, är att standarden indirekt har kommit att ges en datalagrande funktion. Då fokus på arbetet med XML har varit att, via SGML, utveckla ett botemedel på HTML:s främsta brister (lös struktur, brist på flexibilitet och integrerad metadata- och layouthantering) så förefaller XML:s indirekta datalagringsuppgifter ha kommit lite som en överraskning för såväl W3C som de företag som agerar inom XML:s utvecklingsprocess. I datalagringsuppgiften låter databaskollegiet sina resonemang ta sin början, genom att anmärka och angripa XML:s semistrukturerade karaktär som direkt ålderdomlig och i de flesta fall otillräcklig för de krav på funktionalitet som ställs på moderna datalagringsmiljöer. Som bakgrund till detta resonemang så beskriver till exempel [Elm94] den hierarkiska datamodellen, vid vilken XML enligt oss kan liknas, som direkt problematisk vad gäller de grundläggande koncept som kom att avhjälpas med presentation av relationsdatamodellen [Cod70].
Primärt gäller för den hierarkiska datamodellen i perspektiv av XML att modelleringen har sin grund i semistrukturen det vill säga i elementen och attributen. Således bildar till exempel varje ”entitet” i detta projekts prototyp en egen hierarki. Rotelementet utgörs av dokumentet självt (till exempel <projekt></projekt>) som i sin tur har ett antal konceptuella instanser som barn (motsvarande <enskilt_projekt> </enskilt_projekt>, se Bilaga 6). På detta sätt ges inga verktyg för att uttrycka att varje uppräknat projekt i hierarkin ”Projekt”, måste ha en beställare som finns uppräknad i hierarkin ”UppdragsGivare”. Det går förvisso att ange beställarens namn för varje projekt med hjälp av elementet ”beställare”. Värdet kan anges antingen direkt eller med
en extern systementitet, men det finns inget i XML-strukturen som uttrycker att det finns en relation mellan dessa hierarkiers element och att relationen är av en viss ställighet. Det går ej heller att kontrollera referensintegriteten hos relationen, till exempel att vi för ett projekt försöker ange en beställare som inte finns inlagd i hierarkin ”UppdragsGivare”. För att klara av att representera till exempel relationer, ställigheter och referensintegriteter krävs någon form av DBHS och det har vi inte tillgång till för XML- versionen.
I diskussionen om den hierarkiska datamodellen finner vi att [Elm94] lyfter fram följande typer av relationer som mycket besvärliga att hantera i den hierarkiska datamodellen:
W M:N-relationer, vilket har sin grund i att en förälder kan ha ett 1:N-förhållande till
sina barn medan ett barn endast kan ha ett 1:1-förhållande till sin förälder.
W Relationer där en typ av nod (till exempel ”enskild_medArbetare”, se Bilaga 6)
utgör ett barn till olika typer av föräldranoder (i det här fallet både ”enskilt_Projekt” och ”beställare”). Detta problem beror på att det inte går att ange vilken relation som skall behandlas först eftersom relationen för barnet ”enskild_medArbetare” är på samma nivå för bägge föräldrarna.
Mot bakgrund av ovanstående problemframställning om den hierarkiska datamodellen, framstår det för oss som tämligen klart att XML skulle vara behäftat med problem vad gäller dess egenskaper som datalagrare. Detta gäller i synnerhet vid en jämförelse av XML och RDBHS.
6.1.2 Utvecklingsförslag
I ett för detta projekt mycket centralt dokument, lyfter [Bon99] fram ett antal föreslagna frågespråk för XML-baserad data. Jämförelsen görs dels mellan de olika föreslagna teknikerna men också mot ett helhetsperspektiv bestående i den samlade funktionaliteten hos dagens RDBHS med SQL som frågespråksmiljö. [Bon99] presenterar följande språk:
W W3C:s eget förslag kring metafrågespråk för XML, det vill säga XQL. W XML-QL, vilket är ett språk som har sin grund i en omarbetning av SQL. W Ett grafiskt grafbaserat frågespråk kallat XML-GL.
W Formateringsspråket XSL.
W En helt egen DBHS-miljö för XML, kallad LORE.
Jämfört med SQL lider samtliga föreslagna frågespråksmiljöer, utom LOREL, av att de inte utvecklas med avseende på eller i integration med något DBHS. På detta sätt begränsas XQL av att det definieras utifrån XML och därför måste baseras på XML:s semistrukturella konstruktion. Vidare lider XQL av att inte kunna arbeta med flera XML-dokument oberoende av varandra eller med möjlighet att kunna ställa deras respektive innehåll i relation till varandra enligt vad som i SQL kallas för ”joins”. XQL- frågans ”Search Context” (se Figur 9) avser endast ett XML-dokument. Att ange flera XML-dokument som kontext är inte möjligt eftersom det inte finns någon hantering av relationer, ställighet eller referensintegritet (se avsnitt 6.1.1) i XML.
XML-QL och XML-GL har båda utrustats med egna datamodeller, men även i fallen med dessa förslag märks avsaknaden av ett bakomliggande DBHS. XSL har tagits fram med avseende på en något annorlunda uppgift än att agera renodlat frågespråk och då XSL även det är definierat utifrån XML lider det av XML:s datalagringsmässiga tilllkortakommanden. Mest lovande förefaller XML-GL då det baseras på en grafrepresentation av XML-dokumenten och DTD:erna. På motsvarande sätt låter LORE:s OEM representera XML-dokumenten vid grafer, men går därefter ett steg längre och instansierar XML-dokumentens innehåll till egna objekt. Det bör dock påpekas att samtliga föreslagna frågespråksmiljöer samtliga befinner sig i ett relativt tidigt utvecklingsskede och att de därför kan komma att vidareutvecklas till att avhjälpa de brister som vi och [Bon99] ser hos dem idag. Mest komplett förefaller dock LORE och LOREL vara.
Programutvecklingsföretagens dokument är inte lika öppet ifrågasättande av XML som datalagringsteknik, men de lyfter ändå fram förslag till kompletterande tekniker, ofta utvecklade i det objektorienterade programmeringsspråket Java, som på olika sätt strävar efter att transformera XML-data från att vara semistrukturell till att vara objektbaserad. De mest ambitiösa förslagen, enligt vår uppfattning, utgörs av projektet kring LORE och LOREL, samt Sun:s generella Java-klasser via SAX för XML-baserad data. Den interna representationen av datan skall dock även i detta fall transformeras från semistrukturell till objektorienterad. Detta visas i fallet med LORE genom att systemet är ett ODBHS, och i fallet med de generella Java-klasserna genom att Java är ett objektorienterat programmeringsspråk. Således tycks hos såväl databaskollegiet, som hos programutvecklingsföretagen, objektorientering i någon form vara den bästa lösningen på XML:s problematiska datalagringsegenskaper.
I samtliga förslag och exempel som lyfts fram från programutvecklingsföretagen, med ett undantag, föreslås Java som plattform för allt utvecklingsarbete. Undantaget utgörs av Microsoft som med sitt operativsystem Windows som grund, har genomfört ett hittills mycket omfattande arbete kring XML. Företagets XML-relaterade material fokuserar starkt på direkt tillämpning och utveckling av webbaserade lösningar som byggts upp av Microsofts servermiljöer, webbservrar och skriptspråk för integration av Windows och webbservern (ASP). Microsoft uttalar inte i direkta ordalag att XML som datalagrare skulle vara ett problem, men löser enligt vår uppfattning problemet på motsvarande sätt som med LORE-projektet och Sun med flera, genom att transformera XML till objektbaserad data. Skillnaden mellan Microsoft och de övriga aktörerna är dock att Microsoft väljer att transformera XML-dokumenten till den objektmodell som återfinns i operativsystemet Windows, istället för det Java-baserade koncept som de övriga aktörerna förespråkar. Microsoft har dock kommit mycket långt med sitt XML- utvecklingsarbete och erbjuder till exempel en egen element och attributstandard (XML Scheman), en egen XML-tolk (msxml), en XDOM baserad på Windows API (åtkomligt via t.ex. ASP och Visual Basic) samt en applikation som kan åskådliggöra och formatera XML- och XSL-dokument (Internet Explorer 5.x). Ingen annan aktör, vetenskaplig som kommersiell, erbjuder idag så mycket XML-funktionalitet i sina produkter och tekniker. Detta förhållande kan ge som konsekvens att om till exempel ett företag vill implementera XML i sina system, är de i dagsläget i princip hänvisade till enbart Microsofts tekniker och produkter. Eftersom Microsoft utvecklar XML-anpassad teknik vid sidan av de standarder som W3C tagit fram, kan de ge en komplicerad situation kring
vilken aktör det egentligen är som kommer att få det praktiska inflytande över hur XML fortsättningsvis kommer att definieras.
6.2 Simulering
Arbetet med simuleringsdelen av projektet utgick från att via en implementation av en prototyp till ett typiskt webbaserat informationssystem, som vi i förväg visste skulle vara möjlig att genomföra, jämföra motsvarande försök till implementation av en XML- baserad version av systemet. Upprättandet av den RDBHS-baserade versionen av prototypen, tillsammans med den IIS/ASP-baserade gränssnittslösningen, avlöpte därför mest som en formalitet.
Inför upprättandet av den XML-baserade versionen kan vi nu se att allvarliga och avgörande problem tillstötte. Den XML-baserade versionen av systemet kom aldrig att kunna färdigställas längre än till en grunduppsättning av XML-filer med tillhörande DTD:er och XSL-mallar. Än mindre kunde frågespråket XQL prövas och jämföras med SQL. XML-versionen av simuleringen misslyckades till följd av att:
W XML baseras på en annan datamodell än det RDBHS-baserade systemet. Då
RDBHS är baserat på relationsdatamodellen är XML-systemets datamodell mer oklar, men troligtvis att klassficiera som hierarkisk. Detta skapar vidare problem med att till exempel översätta en relationsdatamodell till en semistrukturerad. En översättning kan ej heller göras utan förlust av information, då den semistrukturerade datamodellen till exempel har mycket stora svårigheter med att uttrycka M:N-relationer, vilka är mycket centrala i relationsdatamodellen. Problematiken kring att modellera nycklar, främmande nycklar och relationer i övrigt, försvårar ytterligare översättningsarbetet av en relationsdatamodell till en semistrukturerad datamodell. Avslutningsvis saknar XML koncept om andra datatyper än textsträngar, vilket gör att RDBHS-systemets mer detaljerade datatypsdefinition gör att viktig metainformation om systemet går förlorad.
W XQL är en definition på metanivå och finns således inte implementerad i någon
applikation, i något operativssystem eller i någon DBHS-miljö. [Mor99, W3C00c] respektive framställningar av XQL gav inte den bild av ett metaspråk som senare visade sig vara fallet med XQL. Vid perioden för detta projekts genomförande kunde det inte hittas någon implementation av XQL. Då språket vid detta projekts avslutande fortfarande är på förslagsnivå hos W3C, kommer det sannolikt att dröja ännu ett tag innan XQL-implementationer kommer att finnas tillgängliga.
W Det saknas ett API för att kunna kommunicera via en webbserver och XML-
dokument och DTD:er. För RDBHS-versionens vidkommande svarar ODBC för denna funktion. Ett ”ODBC för XML” kommer att vara beroende av vilket frågespråk som det skall hantera, så några implementationer av ”ODBC för XML” kommer högst osannolikt att finnas tillgängliga innan något eller några förslag till frågespråk nått en tillräcklig nivå av mognad.
Kärnan i problematiken med XML-versionen och den avgörande anledningen till att simuleringen misslyckades, står att finna i oklarheterna kring XML:s datamodell och vilka egenskaper och framförallt brister som denna bjuder. De efterföljande problemen
med frågespråk, algoritmer för transformering av RDBHS-baserad data till XML med flera, följer på att de bägge miljöernas datamodell så markant skiljer sig åt.
En avslutande observation kring simuleringsdelen är avsaknaden av utvecklingsverktyg och hanteringssystem för de till antal och i storlek omfattande textfiler som XML- systemet kom att utgöras av. Utvecklingsarbetet fick bedrivas med en textredigerare utan stöd för indentering, färgkodning av syntax eller en för ändamålet anpassad avlusare. Utvecklingsarbetet med XML-versionen kom således att bli mycket ineffektivt och tidskrävande i jämförelse med utvecklingsarbetet av RDBHS-versionen.