XML-versionen avgörande problem tillstöter

Arbetet med att implementera prototypsystemet som XML, inleddes med utvecklingen av de DTD:er som systemet skulle komma att behöva. Redan i detta skede tillstötte det första problemet vilket bestod i frågan vilka DTD:er som skulle utvecklas för att representera den information som modellerats enligt Figur 10. Vi fann följande omedelbara problem:

• Modelleringsunderlaget i form av information uttryckt i relationer

(relationsdatamodell) kunde inte direkt översättas till XML.

Med stöd i genomgången av de klassiska datamodellerna i [Elm94], där den ”hierarkiska datamodellen” lyfts fram, anade vi att XML snarare kunde matchas mot en hierarkisk datamodell än en relationsbaserad. Då litteraturstudien inte gav någon vägledning kring XML:s dataegenskaper än annat att XML är av semistrukturerad typ, bedömdes XML:s datamodell vara hierarkisk. Bedömningen motiverades med följande resonemang:

XML är ett märkordsspråk där märkorden utgör taggar. I DTD:erna beskrivs innebörden av taggarna i av termer av element, attribut och entiteter. Alla XML-dokument måste beskrivas mot någon DTD för att vara valid enligt XML-standarden. DTD:ernas struktur kan ritas som ett hierarkiskt träd (se Figur 2) men inte som ett ER-diagram. Således borde XML:s datamodell snarare vara av hierarkisk typ än relationsbaserad.

Med utgångspunkt i den hierarkiska datamodellen uppstod problemet med M:N- relationer till följd av att det inte gick att modellera ett ”Parent-Child-Relationship” (PCR) [Elm94] som M:N. En förälder kan ha relationen 1:N till sina barn men ett barn kan endast ha relationen 1:1 till respektive förälder.

Vidare fanns det inget stöd för att till exempel kunna avgöra om ett nyckelattribut i relationsdatamodellen motsvarades av ett eget element med ett indexattribut av datatypen ”#ID” (se avsnitt 2.2) eller om det skulle representeras av ett eget element. Figur 12a och 12b illustrerar, med hjälp av prototypens entitet ”Projekt” och dess nyckelattribut ”littera”, problematiken på nyss nämnda område. Exemplet är hämtat ur DTD:n för XML-versionens (Bilaga 6) ”projekt.xml”, där Figur 12a motsvarar den lösning som implementerades och 12b det alternativ som utgjorde det bästa alternativet att använda, men som vi ansåg inte skulle koppla lika väl mot relationsdatamodellen av prototypsystemet.

<!ELEMENT enskilt_projekt (projektInfo, beskrivning+)> <!ATTLIST enskilt_projekt

totalEntreprenad (ja | nej) "ja" bild ENTITY #IMPLIED>

(…)

<!ELEMENT littera (#PCDATA)> (…)

<!ELEMENT enskilt_projekt (littera, projektInfo, beskrivning+)> <!ATTLIST enskilt_projekt

littera #ID

totalEntreprenad (ja | nej) "ja" bild ENTITY #IMPLIED>

Figur 12b. – Nyckelattributet ”littera” som attribut av #ID-typ

Beslutet att välja upplägget enligt Figur 12a grundades på två faktorer:

1. Datatypen ”#ID” visade sig endast kunna lagra strängar och inte numeriska värden, till exempel ett heltal. Vi har inte kunnat förstå vad i XML-standarden som ligger till grund för denna begränsning.

2. Inför det kommande arbetet med att konstruera XSL-mallar för XML- dokumenten, visade det sig vara en väsentlig skillnad på att ordna poster i XML- dokumenten baserat på ett unikt värde för ett element respektive ett unikt värde för ett attribut inuti ett element (Se Bilaga 8).

Vi observerade att ett element har högre precedens i XDOM:en än vad ett attribut har, vilket skulle förklara att XSL-mallarna fungerade bättre med nyckelattributen modellerade som egna element än som attribut till rotelementet för varje instans av en entitet (till exempel <ett_projekt></ett_projekt>).

Problemet med att avgöra om ett attribut, enligt relationsdatamodellen av prototypsystemet, skulle modelleras som ett eget element eller som ett attribut i XML, följde under hela utvecklingsarbetet av XML-versionen. Endast ifråga om att kunna uttrycka multivärda attribut, som till exempel att en beställare kan ha flera adresser (representerat i RDBHS-versionen i den egna tabellen ”beställare_Adress”), visade det sig att ett numreringsattribut till respektive element i det sammansatta elementet (se Bilaga 7, ”projekt.xml” – ”<adress adressNr=”x”></adress>), möjliggjorde implementation av unikt åtskiljbara instanser av informationspartiet ”adress”.

Vad gällde problematiken med att korrekt översätta entiteter till egna XML-dokument eller till någon annan strukturell lösning, fann vi oss vara försatta i en komplicerad situation. Eftersom det med största sannolikhet, med stöd av [Elm94], vid denna tidpunkt var möjligt att betrakta XML vara baserat på en hierarkisk datamodell, drabbades detta projekt också av de svårigheter som [Elm94] lyfter fram hos den hierarkiska datamodellen. Således skulle det innebära stora problem att representera M:N-relationer, men också relationer mellan olika hierarkier, vilket skulle bli resultatet om varje entitet modellerades som ett eget XML-dokument. Ett alternativ skulle då vara att representera hela datamodellen och därmed systemet, i ett enda XML-dokument. Vi valde dock att avstå från detta alternativ vilket grundandes på den konstruktionsmässiga ambitionen till decentralisering och dekomponering av data och funktioner, som vi tyckte oss kunna se i definitionerna av XML, DTD och XSL Att klumpa hela systemet i ett enda XML- dokument tyckte vi inte låg i linje med avsikterna med XML.

Vidare blev vi tvungna att på nytt försöka modellera RDBHS-versionen att representeras i en hierarkisk datamodell, eller att försöka konstruera XML-versionen med relationsdatamodellen som grund. Att försöka skapa en RDBHS-baserad implementation på en hierarkisk datamodell ansågs strida mot själva syftet och definitionen av RDBHS- miljön. Orimligheten i kopplingen hierarkisk datamodell – RDBHS kompletterades med bedömningen att det är avgjort mer sannolikt att XML kommer att behöva implementeras i befintliga och RDBHS-baserade system, än tvärtom, till ett beslut som gick ut på att försöka implementera XML-versionen med utgångspunkt från relationsdatamodellen enligt Figur 10.

Problemen under transformeringsprocessen från relationsbaserad modell till XML- dokument och DTD:er, berodde på att det saknades en algoritm eller en arbetsheuristik för att i XML korrekt modellera relationsdatamodellen. Problemen kan sammanfattas i följande punkter:

• Kopplingen mellan entiteter och XML-strukturen • Relationer mellan XML-dokument

• M:N-relationer • Främmande nycklar

• Modelleringen av nycklar som egna element, eller som attribut med unika värden

till rotelementet av varje instans av en entitet.

Bilagorna 6 – 8 beskriver i tur och ordning källkoden för DTD:er, XML-dokument och XSL-mallar. Vi avstod från att utveckla en XSL-mall för ”dokument.xml” eftersom det huvudsakliga innehållet i respektive instans av entiteten ”dokument” utgörs av en i XML- dokumentet externt refererad systementitet som skall hanteras av en applikation, MSWord.exe, och inte av en XSL-mall. För att åskådliggöra XSL-mallarnas formatering av XML-dokumenten, användes uteslutande Microsoft Internet Explorer 5.01. Valet av Microsoft:s webbläsare som åskådliggörande applikation baserades på att denna applikation var den enda applikation som vi fann att ha något sorts stöd för kombinationen XML/XSL. Bilaga 9 innehåller exempel på hur XSL-mallarna formaterade XML-dokumenten i webbläsaren.

I sammanhanget med XML-kompatibla applikationer och verktyg för XML-utveckling visade det sig att det nästan helt saknades tillämpningar av den senare kategorin, det vill säga utvecklingsverktyg för XML. Under hela arbetet utfördes all utveckling av DTD:er, XML-dokument och XSL-mallar med ett textredigeringsverktyg. För att validera XML- dokumentens mot sina DTD:er och XSL-mallarna mot sina respektive XML-dokument användes även till dessa uppgifter Microsoft Internet Explorer 5.01. En klar brist hos webbläsaren ifråga är dock att dess felsökningsmeddelanden beträffande DTD, XML och XSL snarare uttrycker webbläsarens interna problem med att tolka koden än vad som egentligen är fel i dokumenten relativt definitionerna av de respektive standarderna.