1. Institutionen för Data- och systemvetenskap
Stockholms Universitet / Kungliga Tekniska Högskolan
Maj 2002
XML som informationsbärare vid epidemiologisk forskning
Folke Naredi
Clas Persson
Sammanfattning
XML används idag inom många områden för att transportera och utbyta information. Dock är
XML ett i det närmaste okänt begrepp hos aktörer inom epidemiologisk forskning.
I Sverige finns ett antal stora register varifrån information inhämtas vid epidemiologiska studier.
Det rör sig ofta om stora datamängder som ska transporteras från en part till en annan för att
användas i analys. Ofta måste dessa data korrigeras av mottagaren för att passa just dennes
ändamål eftersom inga gemensamma riktlinjer finns för hur informationen ska se ut.
I detta arbete har ett program konstruerats som transformerar en textfil till ett XML-dokument.
Målet med detta har varit att med ett praktiskt exempel kunna upptäcka och analysera möjligheter
och eventuella problem med XML-dokument som lagringsalternativ.
Studien tyder på att XML-baserad teknologi kommer att ge mycket goda möjligheter till kontroll
av att data följer angiven standard. Däremot uppstår ofta problem då XML-dokument skall
användas för överföring av större datamängder mellan system.
Nyckelord:
1. XML
2. Epidemiologi
3. Java
4. Information
5. Standard
6. Tillförlitlighet
7. XML Schema
8. XSL
9. Validering
10. Variabler

2. Abstract
Today XML is used within many branches and disciplines. In the area of epidemiology though,
XML is almost unknown. In Sweden there are a few large registers where information is gathered
for epidemiological studies. Thus large quantities of data are often collected from these registers to
be used for analysis. Since there are no common rules or guidelines about the structure of this
information it often has to be corrected by the receiver to suit their specific needs.
In this work, an application has been created with the purpose of transforming a raw text file to
an XML document. By this practical example the goal has been to discover and analyze
possibilities and problems handling large amounts of stored data as XML documents.
The conclusions are that XML can be an aid in checking information against a standard, but
most expectedly problems will arise by transferring large quantities of data stored in XML format
between systems.

3. Tack
Vi vill rikta ett varmt tack till vår handledare Gunnar Björkman som alltid har funnits till hands
och varit ett stort stöd för oss under uppsatsskrivandet. Han har även kommit med många idéer och
lockat till nya infallsvinklar.
Från MEP vill vi främst tacka Jan-Eric Litton som varit vår kontaktperson under hela arbetet.
Jan-Eric har sett till att vi kommit i kontakt med viktiga personer på institutionen samt varit
mycket behjälplig när skrivandet i perioder har gått trögt. Vi uppskattar också hans goda förmåga
att förklara vad som kan tänkas vara intressant för läsaren.
Vi vill även tacka all personal på MEP som tagit sig tid att svara på våra frågor. Särskilt tack till
Fredrik Granath som stått för många viktiga idéer och tankar kring funktioner i programmet.
Slutligen vill vi rikta ett tack till alla som under arbetets gång har hjälp oss att läsa igenom
uppsatsen och kommit med konstruktiv kritik, inte minst våra familjer.

4. Innehållsförteckning
1 Inledning ............................................................................................................................................... 2
1.1 Bakgrund och problem ............................................................................................................ 2
1.2 Uppdrag .............................................................................................................................................. 3
1.3 Arbetsmetod .................................................................................................................................... 3
2 Institutionen för Medicinsk Epidemiologi .................................................................. 5
3 XML-konceptet .................................................................................................................................. 7
3.1 Extensible Markup Language 1.0 ........................................................................................ 7
3.2 Namnrymder ................................................................................................................................. 13
3.3 W3C XML Schema .......................................................................................................................... 13
3.4 Extensible Stylesheet Language ...................................................................................... 16
4 Kravspecifikation ........................................................................................................................ 19
4.1 Framtagning .................................................................................................................................. 19
4.2 Presentation ................................................................................................................................. 19
5 Konstruktion av Pilot-programmet .............................................................................. 21
5.1 Källfilen ......................................................................................................................................... 21
5.2 Användargränssnittet ........................................................................................................... 21
5.3 Parsning ........................................................................................................................................... 23
5.4 Validering ....................................................................................................................................... 25
6 Testning och utvärdering ..................................................................................................... 27
6.1 Testkörningarna ........................................................................................................................ 27
6.2 Presentation ................................................................................................................................. 27
7 Epilog .................................................................................................................................................... 32
7.1 Slutsatser ....................................................................................................................................... 32
7.2 Diskussion ....................................................................................................................................... 32
7.3 Förslag till vidare studier ................................................................................................. 34
Referenslista ............................................................................................................................................. 35
Appendix A ..................................................................................................................................................... 37
Appendix B ..................................................................................................................................................... 38
Appendix C ..................................................................................................................................................... 40
Ordlista .......................................................................................................................................................... 44

5. 1 Inledning
1.1 Bakgrund och problem
Vid alla datastyrda processer är det viktigt att bevara informationens tillförlitlighet. Inom många
områden är det informationen som är väsentlig och ligger till grund för hela verksam-heten [4], [5].
Samtidigt är det viktigt att alla system som ingår i en verksamhet har möjlighet att tillgodogöra sig
den informationsmängd som efterfrågas, och detta måste ske på ett för systemet korrekt sätt.
Exempelvis kan det röra sig om kommunikation mellan applikationer, databaser, läsbara
publikationer eller mobiltelefoner. Inom vart och ett av dessa specifika områden förekommer ofta
fler än ett leverantörssystem, och ofta ställer varje system egna krav på hur ingående data skall
vara strukturerad.
Många gånger har företag, organisationer, hela branscher och även enskilda användare gjort
kostsamma investeringar i att spara och återanvända viktig information. Det är därför förenligt
med ekonomiska besparingar att undvika resurskrävande konverteringar mellan olika data-format
när informationen skall flyttas mellan system samt vid upphandling av nya system. En mjukvara
som används idag bör kunna uppdateras eller bytas ut mot en ny utan begränsning till
leverantörsspecifika system. Leverantörsberoende är idag ett vanligt förekommande problem, och
orsakas ofta av att leverantörer skapat egna dataformat som endast i bästa fall ett fåtal andra
leverantörer stödjer [6]. Om det går att utarbeta standarder som leverantörer av system såväl som
användare accepterar och stimuleras att använda sig av, ökar möjligheterna till kommunikation
mellan olika systemområden samt mångfalden bland valbara system vid eventuella uppdateringar.
En ytterligare fördel med standardisering är möjligheten att skapa gemensamma regler för
informationshantering mellan användare inom samma intressesfär med ökade chanser för dessa att
utbyta information mellan varandra [27].
Extensible Markup Language (XML) är en standard som tagits fram ur metaspråket Standard
Generalised Markup Language (SGML) i avsikt att vara ett mer användaranpassat sätt att hålla
information [11]. Idag sker en kontinuerlig utveckling av en rad tekniker för presentation, tolkning,
transformering, definition, snabb sökning o s v med XML-konceptet som gemensam nämnare. De
standarder som utvecklas enligt detta koncept kommer att ge möjlighet att skapa riktlinjer för
plattformsoberoende kommunikation. Därför är det intressant att se i vilken utsträckning
kommunikationsproblem mellan olika system kan lösas med hjälp av denna teknik. Enligt samma
tankesätt är programmeringsspråket Java menat att skapa plattformsoberoende applikationer och
ett omfattande arbete pågår att få dessa två koncept att verka åt samma håll [28].
Ett fält där information definitivt utgör grunden för verksamheten är forskning. För att kunna
möta framtidens alltmer komplexa utmaningar anses det, bland annat inom epidemio-logisk
forskning, komma att krävas en ökad integration av forskningsområden som hittills varit åtskilda
[9]. På Institutionen för medicinsk epidemiologi (MEP) på Karolinska Institutet i Solna,
Stockholm, bedrivs arbeten inom biostatistik och epidemiologisk forskning. Som
informationskällor till dessa arbeten hämtas idag data från ett antal nationella register samt från
riktade enkätundersökningar jämte ett antal internt uppbyggda register.
Problem med data som hämtas från externa register uppstår då de ska föras in i olika pro-gram
som används på MEP. Till exempel måste variablers namn och innehåll se ut på ett visst sätt för att

6. vissa statistikprogram skall ha förmåga att ta emot dem.
På MEP används i många forskningsprojekt olika utdrag ur Svenska Cancerregistret * . Dessa
utdrag kommer i form av teckenbaserad kod i en vanlig textfil. En sådan fil är oftast ofullständigt
och även felaktigt ifylld vilket leder till att en programmerare eller biostatistiker först måste gå
igenom och korrigera filen för att den ska vara användbar för analys. Detta tillvägagångssätt är
tidskrävande och inte helt tillförlitligt. Institutionen önskar, att med ett praktiskt exempel, bilda sig
en uppfattning om huruvida XML-konceptet har något att tillföra informationshanteringen i detta
sammanhang.
1.2 Uppdrag
Uppdraget från MEP har bestått i att konstruera ett program som omvandlar ett utdrag ur
Cancerregistret till ett tillförlitligt XML-dokument.
1.3 Arbetsmetod
För uppdragets utförande har information över vilka krav som skall ingå i kravspecifika-tionen
inhämtats. Parallellt med detta arbete har litteraturstudier gjorts för att finna synpunkter på vilka
funktioner som kan vara lämpliga att bygga in i programmet samt vilka tekniker i XML-konceptet
som är aktuella.
Programmet är utvecklat i Java, eftersom väl utvecklade APIer * finns framtagna för att skriva
XML-applikationer. Dessutom kompletterar Java och XML varandra bra med tanke på att båda
koncepten lägger stor vikt vid hög portabilitet. Öppna standarder och hjälpverktyg med öppen
källkod har uteslutande använts med avsikt att underlätta konstruktionen av programmet.
I den process som programmet skall genomföra ingår anpassning, viss korrigering och kontroll
av inkommande data. All anpassning och korrigering av data måste vara tillförlitlig.
Förarbete
Inledningsvis gjordes försök att finna arbeten som relaterar till både medicinsk informatik och
informationshantering med hjälp av XML. Inom Stockholms Läns Landsting pågår för närvarande
ett projekt med att binda ihop olika patientjournalhanteringssystem med hjälp av XML [30].
Storleksskillnaden mellan en patientjournal från detta projekt och ett utdrag från Cancerregistret är
dock markant. Arbeten där så omfattande informationsmängder hanteras på liknande sätt har inte
gått att finna.
I förarbetet har även ingått litteraturstudier främst med avseende på Java, XML och relate-rade
tekniker [1], [2], [3]. Många av dessa utvecklas fortfarande så snabbt att det enbart går att hitta
aktuell information över Internet * . World Wide Web Consortium (W3C) * har i så stor
utsträckning som möjligt valts som referent för XML-relaterade tekniker, eftersom organisa-tionen
administrerar och rekommenderar utvecklingsarbetet inom området.
Vidare har information inhämtats vid möten i det inledande skedet av utarbetandet av
institutionens variabelstandard, samt vid diskussioner med Data- ITenheten på institutionen

7. rörande planer på att införa ett nytt nätverkssystem. Dessa möten har givit en bättre inblick i hur
framtida krav kan komma att se ut.
Metod för framtagning av kravspecifikation
Kravspecifikationen har tagits fram genom en upprepad diskussion med kontaktpersoner på
MEP. Personal på MEP har viktat kraven som ställs i specifikationen utifrån vilken relevans de
ansetts ha.
Vissa revideringar av kravspecifikationen och därmed även programmet har gjorts under
arbetets gång vilket till stor del beror på att nya krav tillkommit på XML-dokumentet. Arbetet med
institutionens variabelstandard har förändrat förutsättningarna för namngivning av variabler och
därmed även kraven på de tekniker som skall tillgodose att XML-dokumentet följer nämnda
standard.
Konstruktion av programmet
Innan konstruktionen av programmet inleddes inhämtades kunskaper om XML-program-mering
med Java genom litteraturstudier. På grund av att den mest aktuella informationen inom detta
område ofta inte går att finna i böcker, har liksom under förarbetet stora delar inhämtats genom
sökning på Internet.
Kraven i kravspecifikationen har legat till grund för programmets utformning och funktionalitet.
För att tillmötesgå kraven på att de data som hålls av resulterande XML-dokument följer den
kommande variabelstandarden på MEP har en egendefinierad och anpassad standard konstruerats
med hjälp av XML Schema (se kap 5.4.2 och Appendix B).
Metod för testning och utvärdering
Testning har skett genom att använda programmet för att transformera textfilen med
registerutdraget till olika XML-dokument. Ett absolut krav på programmet har varit att det skall
kunna välja ut endast de variabler som efterfrågas. Denna egenskap har kunnat användas under
testning av de krav i kravspecifikationen som avsett datainnehållet i dokumenten. Resultaten av
testerna har legat till grund för utvärderingen. Denna har gjorts utifrån hur väl resultaten uppfyller
de krav som angivits i kravspecifikationen.

8. 2 Institutionen för Medicinsk Epidemiologi
MEP etablerades på Karolinska Institutet i Solna, Stockholm 1997 [9]. MEP består idag av
c:a 120 anställda varav sju tjänster är professurer. U rsprungligen bedrevs epidemiologisk
forskning framför allt inom cancerområdet. Forskningsprogrammet har nu expanderat till att även
omfatta genetisk epidemiologi, biostatistik och klinisk forskning. Knutna till institu-tionen finns
några av världens största register för medicinsk forskning. Bland annat administ-rerar man själva
det svenska Tvillingregistret [10], som har blivit en unik informationskälla bland annat för att
kunna separera genetiska faktorer från miljöfaktorer vid studier av sjukdomar och deras uppkomst.
Epidemiologi innebär studie av frekvens och utbredning av hälsa och sjukdom i en popula-tion
samt orsaker till dessa. Ordet epidemiologi kommer från grekiskans epi, demos och logos och
innebär läran om det som drabbar befolkningen. Idag delas epidemiologi in i två huvud-områden,
beskrivande respektive jämförande epidemiologi.
Biostatistik går ut på att ta fram och använda statistiska metoder för att lösa problem och besvara
frågor som uppstår inom det humanbiologiska och det medicinska området. Biosta-tistikgruppen
på MEP bedriver aktiv forskning speciellt inom områden som statistisk genetik och
epidemiologisk modellering.
De datakällor som används för att kunna bedriva denna forskning kan idag indelas i tre
kategorier:
1. Enkätstudier
2. Register uppbyggda på MEP (t ex Tvillingregistret, Byggarbetarregistret)
3. Externa register som används av MEP (t ex Svenska Cancerregistret)
I framtiden kommer information inte bara att bestå av teckenbaserad data. Bild- och
video-information kommer att öka, biobanker planeras och datalager med genetisk information
kommer att byggas upp. Fler system och olika användare kommer att ha allt större behov av att
utbyta data mellan varandra. Kravet på att insamlat material följer överenskomna riktlinjer
kommer därmed att öka. Allt detta ställer mycket höga krav på de system som är tänkta att lagra
och stödja sökning i lagrat material.
På MEP pågår för tillfället ett arbete med att utveckla regler för hur variabelnamn och värden
ska anges. Målsättningen är att dessa regler ska bilda en användbar variabel- och formatstandard.
Avsaknaden av en sådan är ett problem som försvårar informationsutbytet på fler än ett sätt:
· Riktlinjer för hur insamlandet av data skall ske finns inte. Enkätundersökningar och
registerfiler måste ofta kompletteras och anpassas för att bli användbara.
· Det finns ingen sammanhållande modell för hur resultaten efter datainsamlingar skall
vara strukturerad för lagring i databaser på institutionen. Detta medför att det inte går att
binda ihop dessa på ett enkelt sätt, och att sökning efter gammal information blir
slumpartad och godtycklig. Även om en tidigare skapad databas med ett liknande
innehåll skulle påträffas, finns inga garantier för att funnen data kan jämställas med den
information man söker.

9. · Databaser och applikationer ställer ofta specifika krav på format, struktur och innehåll
vid inläsning av data. Eftersom kraven inte är samma för alla blir det ofta nödvändigt att
på olika sätt anpassa filernas innehåll innan data kan flyttas mellan system på
institutionen. Detta är ofta en mycket tidskrävande uppgift.
Målet är satt till att den nya variabel- och formatstandarden skall kunna tillämpas på alla
framtida projekt och om så är möjligt även på pågående projekt. Meningen är att standarden ska
underlätta arbetet i alla faser av ett projekt. Således skapas förutsättningar för enklare och klarare
kommunikation mellan doktorander, biostatistiker, databasadministratörer och programmerare.
Med hjälp av standardiserade variabelnamn, till exempel ”age” för ålder och ”sex” för kön,
kommer all nyinsamlad data med samma innebörd att se likadan ut. På samma sätt standardi-seras
dataformaten, till exempel anges ”sex” med ett positivt ensiffrigt heltal. Om det finns anledning
kan också värden på variabler begränsas till exakta angivelser, exempelvis siffran 1 för man och 2
för kvinna. I förlängningen kommer dokumentation och lagring av data att kunna bli enhetlig,
vilket ökar möjligheterna för strukturerad lagring och effektiv sökning i detta material.
En nödvändig förutsättning för att en standard skall fungera i framtiden är att den tillämpas av
alla. Detta kan bara uppnås om den är tillräckligt kraftfull för att tillgodose allas behov. Å andra
sidan är det ingen poäng om det tar mer tid att uppdatera en standard än att följa den. Därför är
målsättningen idag att införa standarden i små steg och i första hand rikta in sig på data inhämtade
från enkätstudier och interna register.
Inledningsvis är inte data från externa register inkluderade i standardiseringsarbetet på grund av
att det idag inte finns något enkelt sätt att transformera dessa data till ett för standarden korrekt
format. Data som hämtas utifrån måste först analyseras, sedan bedömas och slutligen omvandlas
samt eventuellt korrigeras. För detta finns inga färdiga metoder och det bedöms som alltför
resurskrävande att utföra ett sådant arbete manuellt.
Däremot finns ett intresse av att utföra tester för att hålla sig uppdaterade på vilka möjligheter
som finns att bygga ut systemet och eventuellt i framtiden kunna kommunicera information
externt. Här har bedömningen gjorts att system i omvärlden, som man kan tänkas vilja ha
informationsutbyte med, sannolikt kommer att följa XML-konceptet. Därför finns det ett intresse
för utvärdering av konceptet med avseende på dess möjligheter och begränsningar. Eftersom det
bygger på öppna standarder är det uppenbart att ekonomiska besparingar går att göra om
administrering, modellering och hantering av XML-tekniker kan skötas internt på institutionen.
Pågående experimentella studier medför ett bättre sätt att utvärdera aktuella tekniker inom
konceptet. Detta är kostnadseffektivt och ökar också institutionens möjligheter att införliva
XML-konceptet i sina egna system.

10. 3 XML-konceptet
Med XML-konceptet avses i denna uppsats ett obestämbart antal standarder som samverkar för
att binda samman information över nätverk. Antalet är obestämbart därför att konceptet i nuläget
befinner sig i stark utveckling vilket medför att det ofta tillkommer och faller bort standarder. En
trend som får starkt stöd av utvecklare är att skriva dessa standarder med XML-syntax. XML är ett
metaspråk vilket innebär att dess huvudsakliga uppgift är att till-handahålla en enkel syntax och
struktur i syfte att skapa självbeskrivande märkspråk. Det är dessa märkspråk som genom att
samverka ökar portabiliteten, d v s flyttbarheten, av informa-tion mellan olika system. Hög
portabilitet medför att de flesta leverantörer av mjukvara har möjlighet att anpassa sina system för
att kunna dela strukturerad data mellan varandra.
Syftet med detta kapitel är att ge en närmare förklaring av innebörden i begrepp som meta-språk,
märkspråk, syntax, portabilitet och strukturerad data. Kortfattade beskrivningar av de
XML-relaterade tekniker som ingått i arbetet presenteras också, jämte ett antal exempel.
XML-konceptet grundar sig på att många enstaka tekniker kompletterar varandra och att varje
enskild teknik fyller en funktion i det övergripande konceptet. XML-syntaxen bildar till exempel
basen för hur information skall omhändertas, med XML Schema [se kap 3.3 ] sätts regler upp för
hur information får se ut och med XSL [se kap 3.4 ] och tillhörande tekniker hanteras sökning och
presentation av information. Som nämnts sker fortfarande förändringar även av de mest
grundläggande teknikerna med målsättning att de problemfritt skall kunna fungera ihop. En
naturlig följd av detta är att många kompletterande tekniker dyker upp, förändras och försvinner.
Denna förändringsprocess pågår alltjämt (maj 2002) och det vore därför inte meningsfullt att
tränga djupare in i konceptet än nödvändigt. Den omfattande mängd av övriga tekniker som faller
inom konceptets ramar men utanför uppdraget ute-lämnas.
Intresset bland företag och branschorganisationer är stort för vad XML kan komma att erbjuda i
framtiden. Antalet som ansluter sina system till konceptet ökar ständigt. Många stora leverantörer
av datorbaserade system, såsom Sun, IBM, Novell, Oracle, och Microsoft, ger alla sitt fulla stöd åt
XML-standarden. Stabilitet, livsduglighet, öppenhet, portabilitet samt stöd från många leverantörer
har lett till en positiv utvecklingsspiral. Ett mycket viktigt gemensamt mål är att färsk och därmed
mer trovärdig information skall gå att dela över nätverk. Detta förklaras av att system som byggs
upp med XML-relaterade tekniker skapar möjlighet för snabba och enkla uppdateringar av
informationen som slår igenom över hela nätverket.
3.1 Extensible Markup Language 1.0
3.1.1 XML-historia
Utvecklingen av XML-syntaxen är relativt ung och påbörjades så sent som 1996. En
dataingenjör på Sun Microsystems, Jon Bosak, förstod orsakerna bakom de begränsningar som
HTML uppvisade. Han gavs möjlighet att bilda en arbetsgrupp, "the SGML Editorial Review
Board" [11], för W3C. Sedermera lade denna grupp fram XML-specifikationen vilken varit en
stabil W3C-rekommendation sedan februari 1998.

11. XML-syntaxen härstammar från industrins etablerade metaspråk SGML [6]. En viktig princip
att följa under utvecklingsarbetet med XML var att kompatibiliteten med SGML skulle behållas.
Skälet till detta var att mycket arbete och kapital redan offrats på fungerande system baserade på
SGML. Genom att behålla strikta kopplingar mellan de två metaspråken kunde
konverteringsprocessen från SGML till XML underlättas.
En annan viktig aspekt vid utvecklingen var a tt skapa ett språk som skulle vara lika kraft-fullt
som SGML, men med betydligt mindre komplexitet och därmed enklare att använda. XML har
alltså hämtat merparten av sitt ramverk ur SGML men all syntax som inte varit absolut nödvändig
för kommunikation har utelämnats. En del tillägg har gjorts för att öka användbarheten på Internet.
Både SGML och XML är metaspråk, vilket innebär att de är språk med vilka man kan
specificera nya märkspråk. Tvingande begränsningar för märkspråken bygger man in med hjälp av
så kallade scheman. Det finns hundratals olika märkspråk definierade i SGML. De flesta av dessa
språk har inte fått några formella namn, som t ex HTML, utan man använder ofta namn baserat på
syfte eller den standard de använder.
Standard Generalised Markup Language
Standard Generalised Markup Language (SGML) är en ISO-standard (ISO 8879) som funnits
sedan 1986. Den används oftast i samband med affärskritisk, kvalificerad teknisk dokumentation,
inom företag. Sådan information är ofta komplex med lång livslängd och används än idag i ganska
stor omfattning inom bil-, flyg-, läkemedels-, militär- och telekom-industrin. Huvudskälet till att
denna standard utarbetades var att man ville uppnå leveran-törsoberoende, d v s att företag och
branscher skulle vara oberoende av vilken datorleverantör man anlitade. Grundidén är alltså
densamma som för XML och liknar de tankar som idag diskuteras bland annat inom hälso-,
sjukvård och forskning.
Kopplat till specifikationen för SGML finns också ett regelverk för hur dess schematyp DTD
(Document Type Definitions) skall skrivas. I en DTD sätts begränsande regler upp för vad ett
SGML-dokument får innehålla. Det är dessa regler som företag inom samma bransch har möjlighet
att förenas kring och göra till branschstandard. Leverantörer måste sedan an-passa sina system till
reglerna för att kunna tala samma språk.
I många avseenden har det inte varit kostnadseffektivt att använda SGML. Orsaken går att finna
i att SGML är en omfattande och komplex standard vilket har varit tidskrävande när man
strukturerat affärsbrev, PM, e-post och dyl. med kort livslängd.
Hyper Text Markup Language
SGML var redan ett etablerat och väl använt metaspråk när webben skapades. Hyper Text
Markup Language (HTML) började utvecklas 1990 av ett antal programmerare på CERN * efter
att en av dessa, Tim Berners-Lee, året innan funderat ut ett lämpligt sätt att dela doku-ment mellan
varandra över nätverk. Man fann att det kunde vara ett smidigt sätt att kom-municera över Internet
om detta märkspråk skapades. Därför utgick man från vissa delar i SGML-syntaxen och skrev
märkspråket HTML med hjälp av dessa [7].
För att skapa ett språk som var lätt att hantera frångicks regeln att separera innehållet från dess
presentation, vilket är en av de grundläggande principerna i SGML.

12. HTML byggs upp av en begränsad mängd fördefinierade märkord som vanligtvis kallas taggar.
De inleds med tecknet ’<’, avslutas med tecknet ’>’, och används för att förklara innehållet i ett
HTML-dokument. På grund av att taggarna är fördefinierade och har fixa förklaringar har man låst
uttryckskraften i språket. Om man i HTML skriver följande rad:
< h1 > När började Du röka? </ h1 > ,
kommer < h1 > att stå för starttaggen och </ h1 > för sluttaggen. Utskriften på skärmen blir:
”När började Du röka?”
Starttaggen < h1 > talar om för webbläsaren att texten ska presenteras på skärmen som en rubrik
med storlek 1. Sluttaggen </ h1 > talar om att här slutar data. HTML klarar inte av att tala om att
det rör sig om en fråga eller att svaret ska anges på ett visst sätt, t ex med någon viss datatyp som
representerar datum.
HTML är statiskt. Med detta menas att innehållet inte kan ändras interaktivt. < h1 > är alltid en
rubrik1, < p > är alltid ett stycke (eng. paragraph) o s v. För att få mer dynamik har man lagt till
möjligheten att använda olika skriptspråk * och stilmallar. Detta löser dock inte de begräns-ningar
som en gång för alla byggdes in genom att man lät ett begränsat antal taggar represen-tera ett
begränsat antal presentationsmöjligheter. Detta har visat sig vara ett hinder för enkelt datautbyte
mellan system över Internet.
3.1.2 Syftet med XML
Följande tio punkter sattes upp av "the SGML Editorial Review Board" 1996 och återger på ett
bra sätt vilket syfte man hade med XML [ 9 ]:
1. XML ska utan begränsningar kunna användas över Internet.
2. XML skall stödja en stor variation olika applikationer.
3. XML skall vara kompatibelt med SGML.
4. Det ska vara lätt att skriva program som bearbetar XML-dokument.
5. Antalet tilläggsfunktioner till XML skall hållas nere till ett absolut minimum, helst noll.
6. XML-dokument skall vara läsbara för det mänskliga ögat och förhållandevis tydligt.
7. XML-designen skall vara snabbt framställd.
8. Designen av XML skall vara formell och koncis.
9. XML-dokument skall vara lätta att skapa.
10. Fåordighet i XML-märkord är av mindre betydelse.
3.1.3 XML-syntaxen
XML är en syntax, d v s en samling detaljerade regler för hur en informationsmängd tekniskt
skall vara uppbyggd och strukturerad. Målet är att man ska få med all väsentlig information som är
kopplad till data tillsammans med respektive data i en och samma fil. Detta är innebörden i att
XML är självbeskrivande.

13. XML har liksom HTML skapats genom att samla det bästa från SGML och undvika att ta med
sådana delar som i praktiken aldrig har använts. Skillnaden är att det är SGML-syntaxen som
förändrats, inte att man skapat ett nytt märkspråk. Precis som SGML-syntaxen utgör grunden för
HTML som märkspråk, gör XML det möjligt att skapa märkspråk som alla klarar att skriva och
läsa. XML klarar UNICODE * vilket möjliggör användning av teckenuppsätt-ningar från de flesta
av de talade världsspråken.
Att använda teckenformatet istället för binär kod gör det möjligt för en programmerare och även
en slutanvändare att läsa och använda data utan att vara beroende av programmet som framställde
det. Om data hanteras i binär form mellan applikationer är data inte läsbar för det mänskliga ögat.
För att filen skall kunna tolkas rätt av den som läser eller, vilket är vanligare, det program som
läser är strukturen standardiserad. XML-standarden har länge befunnit sig i version 1.0. Det är
ännu inte säkert om en ny version kommer att införas. Detta är ett tecken på stabilitet.
Även om både producenter och konsumenter av ett XML-dokument oftast är datorprogram,
vilket i och för sig inte kräver visuell läsbarhet och därför inte textbaserad hantering, finns det
andra fördelar med XML-konceptet. Det ligger en mycket stor vinst i att konceptet är öppet för alla
och att leverantörer inte kan gömma sig bakom egna filformat och standarder. Att standarden går
att använda av många olika system medför hög portabilitet.
3.1.4 XML-syntaxens struktur och uppbyggnad
All information som skall hanteras med XML byggs upp i ett så kallat XML-dokument. Ett
XML-dokument ska betraktas som en samlad enhet av information som tagits om hand på ett
strukturerat sätt. Ett metaspråk som XML beskriver i sig själv inte vilka regler som måste finnas
med i ett XML-dokument, utan reglerar bara sättet det skrivs på.
Den som skriver ett fristående XML-dokument eller ett XML-dokument som är kopplat till ett
egendefinierat schema (se kap. 3.3 ) skriver definitionsmässigt varje gång ett helt nytt märkspråk.
Om det finns en mjukvara som klarar av att läsa och tolka detta märkspråk är dokumentet fullt
användbart för kommunikation. Detta är vad som så framgångsrikt skett med märkspråket HTML
där utvecklingen av olika webbläsare lett fram till en sådan succé.
<?xml version=”1.0” encoding=”ISO-8859-1” standalone=”yes”?>
<forskningsdata>
<studieobjekt>
<diagDat>1975-01-03</diagDat>
<diagNr version=”ICD8”>C170</diagNr>
</studieobjekt>
<studieobjekt>
<diagDat>1958-11-17</diagDat>
<diagNr version=”ICD7”>C174</diagNr>
</studieobjekt>

14. </forskningsdata>
Fig. 3.1 Exempel på ett XML-dokumentet i sin helhet.
Ett XML-dokument är alltid uppbyggt i formen av ett upp- och nervänt träd. Man säger att
dokumentet har en hierarkisk struktur. Dokumentet är alltid själva roten på trädet och är i sig
namnlöst [1]. Till roten binds rot-elementet, men före detta skrivs alltid en maskininstruktion vars
uppgift är att annonsera för mjukvaran att filen är ett XML-dokument:
<?xml version=”1.0”?>
För att ge maskinvaran information om vilken kodningsstandard som gäller kompletteras ofta
maskininstruktionen med följande: ’…encoding=”ISO-8859-1”…’.
Det är vanligt att man bygger upp sina dokument enligt ett DTD. En del mjukvaror kräver
information om att man valt bort denna metod. Därför är det mycket vanligt med tillägget:
’…standalone=”yes”…’. Om värdet är ”yes” tolkas det som att dokumentet kan läsas fristående
utan koppling till någon DTD:
<?xml version=”1.0” encoding=”ISO-8859-1” standalone=”yes”?>
<forskningsdata>
… Här läggs resten av XML-dokumentet in. …
</forskningsdata>
XML-dokumentet måste vara välutformat (”well-formed”), vilket innebär att fyra kriterier måste
vara uppfyllda [12]. Dessa kriterier är:
1. Alla XML-dokument måste innehålla ett och endast ett rot-element.
Detta rot-element omsluter resten av innehållet i dokumentet.
2. Alla element måste ha en start- och en slut-tagg.
3. Alla element måste vara nästlade på ett korrekt sätt.
4. XML-syntaxen är känslig för stora och små bokstäver.
Detta innebär att start-taggen och slut-taggen måste vara identiskt lika.
Enligt den första regeln för välutformning måste alla XML-dokument ha ett och enbart ett
rot-element; I exemplet är rot-elementet av typen forskningsdata.
Innanför rot-elementets avgränsningar placeras hela dokumentets innehåll vilket kommer att
bestå av en eller flera grenar. Varje gren utgörs av ett nytt element, som i sin tur skulle kunna
utgöras av ytterligare element. Ibland väljer man att säga att elementen utgör noder. Den nod som
befinner sig längst ut på trädet, och som alltså inte innehåller fler element, kallas löv-nod.
Ytterligare ett vanligt sätt är att benämna elementens inbördes ordning är enligt föräldra- /
barn-principen.
Ett element ser alltid ut på följande sätt:
<studieobjekt> Mellan taggarna skrivs elementats datainnehåll </studieobjekt>

15. Enligt den andra regeln måste alla element ha en start- och en sluttagg. Här utgör
<studieobjekt> den så kallade starttaggen och </studieobjekt> sluttaggen, precis som i HTML.
Observera ’ / ’-tecknet i sluttaggen samt att XML-syntaxen alltid kräver en sådan i motsats till
HTML. Tillsammans utgör de ett märkord eller en tagg av typen studieobjekt. Datamängden är i
detta fall ett rent textinnehåll, men det kunde lika gärna ha varit en eller flera nya element eller till
exempel en maskininstruktion.
<?xml version=”1.0” encoding=”ISO-8859-1” standalone=”yes”?>
<forskningsdata>
<studieobjekt>
Mellan taggarna skrivs elementats datainnehåll
</studieobjekt>
</forskningsdata>
Varje element har aldrig mer än en förälder. I detta fall har studieobjekt forskningsdata som
förälder. Enligt regel nummer tre måste studieobjekt avslutas före forskningsdata. Om de två
elementen hade avslutats i omvänd ordning skulle de inte ha varit korrekt nästlade.
Den fjärde regeln beskrivs bäst med att till exempel sätta typnamnet diagNr i en starttagg. Skulle
namnet i starttaggen skrivas med ett stort N, måste enligt regel nummer fyra även sluttaggen bestå
av samma namn med stort N på samma position.
<diagNr version=”ICD7”>C174</diagNr>
Ibland vill man koppla information till ett element som mera är att betrakta som en egen-skap
hos elementet än ett innehåll. Då passar det utmärkt att använda sig av något som kallas attribut.
Alla attribut skrivs innanför klamrarna och efter elementets typnamn.
<... version=”ICD7”> ...
Attribut kan varken innehålla egna attribut eller element utan utgörs endast av ett namn med ett
tillhörande värde. De två apostroferna som omger attributets värde får till skillnad från i HTML
aldrig glömmas i märkspråk skrivna med XML-syntax. Detta är lika viktigt att komma ihåg som
att alla element avslutas med en sluttagg.
Attribut har många användningsområden. För att nämna något används det för länkning till
andra element i dokumentet eller som en URL till en annan entitet utanför dokumentet.
3.1.5 Validering och scheman
För att kontrollera att ett XML-dokument överensstämmer med vissa uppställda krav, t ex en
standard, krävs validering av dokumentet. För detta ändamål skriver man ett så kallat schema som
innehåller de begränsningar och beskrivningar som ska gälla för XML-dokumen-tet. Detta
refererar man till i XML-dokumentet som därigenom kan valideras.
DTD DTD är fortfarande den mest använda varianten av schema. Det saknar dock

16. ett fullständigt stöd för namnrymder (se kap 3.2 ) har dessutom endast
begrän-sade möjligheter att bestämma datatyper. Fördelen är att den än så
länge har störst stöd bland mjukvaruleverantörer.
W3C_
XML_Schema
W3C XML Schema är efter DTD det vanligaste schemaspråket. Det skrivs i
XML men är i viss mån komplext på grund av dess många egenskaper.
Namnrymder stöds och det är starkt typat för att kunna säkra att det inte råder
några tveksamheter vid bestämningen av datatyp. Tack vare att det är en
W3C-rekommendation är stödet bland mjukvaruleverantörer stort.
RelaxNG RelaxNG är ett språk som till stora delar liknar W3C XML Schema, men har
en syntax/semantik som mer liknar vanlig engelska och därför borde vara
lättare att använda och förstå. Det har stöd för namnrymder medan stödet för
datatyper kräver att man refererar till externt definierade typer. Däremot är
stödet hos mjukvaruutvecklare för närvarande osäkert.
Övriga Det finns ytterligare alternativ till de ovan beskrivna, men de har ett så
begränsat stöd bland utvecklare att vi inte funnit det intressant att närmare
studera dessa.
Tabell 3.1 Det finns flera olika schemaspråk och alla har sina för- och nackdelar [13].
Då XML skapades ärvdes kanske något olyckligt DTD som schemaspråk från SGML. DTD är
tyvärr inte skrivet med SGML-syntax och brister bland annat därför i uttryckskraft på de punkter
som nämns i ovanstående tabell.
Det begränsade stödet för namnrymder och för användning av datatyper har på senare tid
uppmuntrat utvecklare att lägga ner mycket arbete på att få fram schematyper som är skrivna med
XML-syntax. Målsättningen är för närvarande (maj 2002) att få fram ett schemaspråk som täcker
de behov och krav man ställer på ett schema.
3.2 Namnrymder
Namnrymder (eng. namespaces) är hittills det enda tilläget till XML-syntaxen [14]. Det är inget
krav att ett märkord ska vara förbundet med en definition. Däremot uppstår namnkol-lisioner då
två ingående element är kopplade till samma märkord och har liknande attribut. Sådana kollisioner
kan omöjliggöra mjukvaruanvändning och dessutom leda till onödig för-virring om man försöker
tolka ett XML-dokument genom att läsa det. För att skilja element åt säger man att de ska ingå i
olika namnrymder.
I ett dokument som innehåller följande element, <snickeriet:fil>järnfil</snickeriet:fil> och
<ica:fil>gräddfil</ica:fil>, är ordet fil detsamma och bildar det lokala namnet, medan snicke-riet:
och ica: kallas prefix och står för olika namnrymder.
Fenomenet att en term kan stå för två eller flera begrepp är inte unikt för XML utan är lika
mycket ett allmängiltigt, vardagligt fenomen. Det är inte ovanligt att enskilda termer ofta har mer
än en innebörd. Man säger att de bildar homonymer. Ett bra exempel i svenska språket är just ordet
”fil” och dess olika förekomster. Det går inte att läsa ut om det förkommer i orda-lydelsen

17. ”redskap som man nöter bort ojämnheter med” eller ”sur mjölkprodukt som ofta äts på morgonen”.
Det finns till och med tredje och fjärde varianter som ”del av vägbana” eller ”lagringsenhet för
data”.
3.3 W3C XML Schema
XML Schema [15] är det schemaspråk som än så länge bäst lämpar sig för att beskriva
datatyper, vilket är nödvändigt för att kraven skall kunna uppfyllas i specifikationen för detta
arbete.
Detta schemaspråk följer XML-syntaxen vilket gör att det, trots sin komplexitet, inte är alltför
svårt att lära sig.
Författaren av ett XML Schema bestämmer exakt vilka element som får förekomma och vilka
attribut och subelement det får eller måste innehålla. Språket har många inbyggda data-typer och
ger dessutom möjlighet att skapa egna genom att begränsa inbyggda enkla datatyper (”Simple
Types”) till så kallade härledda typer. Författaren har också möjlighet att skapa helt egna
datatyper, så kallade komplexa typer (”Complex Types”). Genom att använda sig av namnrymder
går det att importera hela eller delar av andra scheman till det egna.

18. <xsd:schema xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns=”http://www.anywhere.com/MEP/schema”
targetNamespace=”http:// www.anywhere.com/MEP/schema”
elementFormDefault=”qualified”>
<xsd:element name=”forskningsdata” type=”forskningsdataTyp”/>
<xsd:complexType name=”forskningsdataTyp”>
<xsd:sequence>
<xsd:element name=”studieobjekt” type=”studieobjektTyp” minOccurs=”1”
maxOccurs=”unbounded”>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name=”studieobjektTyp”>
<xsd:all>
<xsd:element name=”diagDat” type=”xsd:date”>
<xsd:element name=”diagNr” type=”diagNrTyp”>
</xsd:all>
</xsd:complexType>
<xsd:simpleType name=”diagNrTyp”>
<xsd:restriction base=”xsd:string”>
<xsd:pattern value=”[A-Z]{1}d{3}”/>
<xsd:attribute name="version" type="xsd:string" use="required"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
Fig. 3.2 Exempel på XML Schema
3.3.1 XML Schema syntax
Eftersom XML Schema följer XML-syntaxen krävs ett rot-element även för
schemadoku-mentet. De attribut som ingår i denna del är nödvändiga för en exakt tolkning och
tillförlitlig association mellan schemadokumentet och de XML-dokument som ska styras av detta.
Att förstå innebörden av dessa attribut är inte självklar och utgör kanske den mest invecklade delen
av ett XML Schema. Det krävs med andra ord viss vana för att kunna förstå dess innehåll.

19. <xsd:schema xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns=”http://www.anywhere.com/MEP/schema”
targetNamespace=”http:// www.anywhere.com/MEP/schema”
elementFormDefault=”qualified”
>
På första raden knyts ett prefix, xsd, till XML Schema-namnrymden för schemadoku-mentet,
vilket gör att samtliga komponenter med detta prefix tolkas på rätt sätt av en validerande parser.
Den andra raden kopplar ihop schemadokumentets namnrymd med den namnrymd som definierar
de ingående elementen och attributen i XML-dokumentet. Attributet targetNamespace anger för
schemat den namnrymd för vilken elementen och attributen ska styras. Det sista attributet
elementFormDefault talar om att kvalificerade namn ska användas för element och attribut [1].
Resten av schemadokumentet är mer rättframt och beskriver de regler som styr uppbyggnad och
begränsningar av elementen och attributen i XML-dokumentet. Först i denna del anges namnet för
XML-dokumentets rot-element, i detta fall <forskningsdata>:
<xsd:element name=”forskningsdata” type=”forskningsdataTyp” />
Denna rad deklarerar också elementets typ som ”forskningsdataTyp”. Detta element ska tillåtas
innehålla ett eller flera element av typen <studieobjekt> vilket innebär att det måste definieras som
en komplex typ. Definitionen görs på följande sätt:
<xsd:complexType name=”forskningsdataTyp”>
<xsd:sequence>
<xsd:element name=”studieobjekt” type=”studieobjektTyp” minOccurs=”1”
maxOccurs=”unbounded”
</xsd:sequence>
</xsd:complexType>
På liknande sätt definieras elementet <studieobjekt> enligt följande:
<xsd:complexType name=”studieobjektTyp”>
<xsd:all>
<xsd:element name=”diagDat” type=”xsd:date”>
<xsd:element name=”diagNr” type=”diagNrTyp”>
</xsd:all>
</xsd:complexType>
Det som framförallt skiljer definitionen av forskningsdata från studieobjekt är använd-ningen av
xsd:sequence och xsd:all. Genom att använda xsd:all tillåts elementen som ingår i datatypen att
förekomma i godtycklig ordning, och som regel bara 0 eller 1 gång. xsd:sequence kräver att
elementen används i den ordning de definierats.
Attributen minOccurs och maxOccurs talar om hur många gånger ett element får förekomma.

20. Som tidigare nämnts innehåller XML Schema ett antal inbyggda enkla datatyper. För att
ytterligare kunna begränsa innehållet i ett element eller attribut går det genom härledning och arv
att skapa mer exakta definitioner av de inbyggda datatyperna.
<xsd:simpleType name=”diagNrTyp”>
<xsd:restriction base=”xsd:string”>
<xsd:pattern value=”[A-Z]{1}d{3}”/>
</xsd:restriction>
</xsd:simpleType>
Här används den inbyggda typen xsd:string för att beskriva hur diagNrTyp ska se ut. Genom att
använda xsd:string som bas och sedan xsd:pattern för att skapa ett mönster begrän-sas värdet i
strängen till att börja med exakt en versal följt av exakt tre siffror. Syntaxen som används för att
beskriva xsd:pattern är densamma som för t ex skriptspråket Perl.
Som exemplet visar kommer det att finnas bra möjligheter att med hjälp av XML Schema skapa
exakta beskrivningar av hur ett XML-dokument ska vara utformat. Detta är givetvis endast en liten
del av alla möjligheter som finns, men det är ett försök att ge en bild av hur XML Schema kan
användas och skrivas.
3.4 Extensible Stylesheet Language
Extensible Stylesheet Language (XSL) [16] är ett språk som används för att skriva stilmal-lar
(eng. stylesheets). En XSL-stilmall beskriver hur ett XML-dokument skall presenteras. XSL består
av tre delar: XSLT [17], XPath [18] samt XSL-FO [19] XSLT och XPath är de delar som är mest
intressanta för detta arbete. När en XSL-stilmall skrivs används således minst två språk. XSLT
används för logiken och inbäddade XPath-uttryck för att hämta in de data som behövs från
källdokumentet. Eventuellt kan XSL-FO användas för formatering av text.
3.4.1 XSL-Transformations
XSL-Transformations (XSLT) är ett högnivåspråk som används för att definiera
XML-transformeringar. Det används i ett antal olika sammanhang, t ex för [ 2 ]:
- presentation av data. Presentation är kanske det vanligaste användningsområdet. Här
sker transforme-ringen från rådata till ett format som innehåller information om hur
data skall presenteras. Vanligtvis används HTML eller XHTML, men det kan även
vara PDF * , SVG * eller liknande.
- att utbyta data mellan olika system.
Även om användningen av XML ökar kommer inte behovet av att flytta data mel-lan olika
format att försvinna. Transformeringar kommer att ske mellan olika XML-format.
Hur en transformering fungerar förklaras enklast med hjälp av denna bild:

21. XML-
dokument
XSLT
stilmall
XSLT-processor
Nytt dokument (XML, XHTML, WML, PDF etc)
Fig. 3.3 Exempel på transformering av XML med hjälp av XSLT
Tre delar behövs för att genomföra transformeringen, ett XML-dokument, en XSLT-stil-mall
(eng. XSLT stylesheet) samt en XSLT-processor. Notera att XSLT-stilmallar inte alls har samma
funktion som Cascading StyleSheets (CSS) * där stilmallen beskriver utseende på fonter, färger
mm. Istället innehåller XSLT-stilmallen regler för hur transformeringen ska ske [3]. En
XSLT-processor är en applikation som tar ett befintligt XML-dokument och en XSLT-stilmall som
input och skapar ett nytt dokument. Processorn använder sig av en parser för att bygga upp en
trädstruktur av källdokumentet. Därefter skapas ett nytt dokument utifrån regler givna i stilmallen.
XSLT följer samma tradition som många andra språk avsedda för textbehandling. Man anger ett
antal regler för hur behandlingen ska ske. När indata matchar ett visst mönster anger regeln hur
texten ska behandlas. En detalj som skiljer XSLT från exempelvis Perl är att det behandlar en
hierarki snarare än en sekventiell textfil.
Reglerna kallas mallregler (eng. template rules). Varje regel har ett matchningsmönster (eng.
match pattern) som beskriver vilken typ av noder i trädet som det är tillämpligt på och en
mallkropp (eng. template body) som definierar vad som ska ske när regeln utlöses.
<xsl:template match=”/”>
<xsl:for-each select=”forskningsdata/studieobjekt”
<xsl:value-of select=”diagDat”/>
<xsl:value-of select”diagNr”>
</xsl:for-each>
</xsl:template>

22. Fig. 3.4 Exempel på XSLT-stylesheet
3.4.2 XML-Path Language
XML-Path Language (XPath) används i huvudsak för att navigera i ett XML-dokument. Det har
stora likheter med hur sökvägar ser ut och hur de används i ett hierarkiskt filsystem. Utöver detta
innehåller det vissa funktioner för strängmanipulering samt hantering av tal och booleska värden.
Det är utformat för att på ett naturligt sätt kunna användas för matchning när det används i
samband med XSLT.
XPath-uttryck är ofta så enkla som i exemplet ovan. Där är uttrycket, forskningsdata /
stu-dieobjekt , helt enkelt sökvägen från rot-elementet (forskningsobjekt) till dess barn
(stu-dieobjekt). Det går också att göra mer raffinerade sökningar med XPath.
Xpath-uttryck Beskrivning
/studieobjekt/diagNr
../@id
/studieobjekt[3]/diagNr[2]
Utgå från rot-elementet, hitta
elementet studieobjekt och slut-ligen
elementet diagNr.
Välj attributet id från nu-varande
elements förälder.
Välj det andra diagNr-elementet
från det tredje studieobjektet som i sig
är barn till rot-elementet.
Fig. 3.5 Exempel på XPath-uttryck
3.4.3 XSL-Formatting-Objects
XSL-Formatting-Objects (XSL-FO) är den del av XSL som beskriver formateringen av den text
som ska visas. Det är i huvudsak utformat för utskrifter på papper. XSL-FO tar ett XML-dokument
som input och producerar en utskrift. Idag stöds PDF och PostScript, men arbete med stöd för
Microsofts Rich Text Format pågår [20].

23. 4 Kravspecifikation
4.1 Framtagning
Kravspecifikationen har tagits fram i samråd med personer inom Data- ITenheten samt
statistiker på MEP. Kraven har i första hand varit inriktade på det XML-dokument som framställs,
d v s att informationen i detta är tillförlitlig och korrekt. De flesta krav var definierade av
uppdragsgivaren redan innan arbetet inleddes, vilket medfört att relativt få diskussioner angående
dessa har krävts. Under arbetets gång har nya krav på variabelnamn och dess definitioner lagts till
då arbetet med en variabelstandard inletts.
Eftersom detta arbete till stor del går ut på att kunna se möjligheter och svårigheter med XML
har det inte ställts några krav på hög användarvänlighet.
4.2 Presentation
Nedan följer en presentation av samtliga krav i kravspecifikationen. De är värderade och
grupperade som Absoluta krav , Krav eller Önskemål .
Absolut krav 1 Alla datum i det framställda XML-dokumentet måste vara fullständiga.
En av de viktigaste variablerna för analyser vid epidemiologisk forskning är datum. Det är alltså av
största vikt att dessa är kompletta och tillgängliga, d v s innehåller år, månad och dag. I utdragen
från Cancerregistret är datumen ofta ofullständigt ifyllda. Vanligt är att det finns år och månad,
men ingen dag angiven. Även enbart år förekommer. Detta åtgärdas genom att 15 läggs till om dag
saknas och om endast år finns angivet fylls det i med 1:a juli.
Absolut krav 2
Det ska vara möjligt att välja ut ett godtyckligt antal variabler ur utdraget från
Cancerregistret.
Eftersom det är mycket sällsynt att alla variabler används i en och samma analys skall möjlighet
finnas att själv välja vilka variabler som ska ingå i det framställda XML-dokumentet.
Absolut krav 3
Det ska vara möjligt att spara en mall över valda variabler.
Vid presentation av forskningsrapporter krävs att dokumentation finns över hur resultaten
uppnåtts. Källfilen och programmet tillsammans med mallen över utvalda variabler utgör en del av
denna dokumentation.
Absolut krav 4
ICD-versionen för två variabler i filen, underliggande och bidragande dödsorsak, måste
kunna beräknas.

24. Variablerna för underliggande och bidragande dödsorsak anges i form av en ICD-kod * .
Dessa koder har under åren förändrats och befinner sig idag i version 10. I utdrag från
Cancer-registret kommer dödsorsakskoderna i version 7, 8, 9 eller 10. Koden för en specifik
döds-orsak varierar alltså beroende på när döden inträffade. För att dessa variabler skall kunna
användas vid en analys måste det gå att få veta i vilken ICD-version dödsorsaken är angiven.
Krav 1
Det framställda XML-dokumentet ska följa en variabelnamnsstandard som är under
utveckling på MEP.
Ett arbete har inletts med att utforma en standard för namngivning av variabler på institutio-nen.
Till exempel skall alla variabelnamn vara på engelska. Det är då viktigt att element-namnen i
XML-dokumentet följer denna standard.
Krav 2
Det framställda XML-dokumentet ska följa en standard för hur variabelvärden ska anges
som är under utveckling på MEP.
För att minska problemen med att lagrad information ofta är svårtolkad för andra än den som gjort
datainsamlingen, beslutas regler för hur lagrade värden ska anges. Detta gäller standard-variabler
som ingår i många analyser. Exempel på detta kan vara att kön alltid ska anges med siffran 1 för
man och 2 för kvinna. Inga andra värdeangivelser får förekomma.
Önskemål 1
Det är önskvärt att de två ICD-kodsvariabler som finns i filen, underliggande och
bidragande dödsorsak, anges tillsammans med den ICD-version de anges i.
Enligt ett av de absoluta kraven skall det gå att ta fram versionsnumret på ICD-klassifika-tionen
för de två variablerna. Det skulle därför underlätta om denna redan var beräknad och lagrad
tillsammans med respektive variabel.
Önskemål 2
Värden som förändrats från källfilen bör markeras.
Vid analys av information är det ibland värdefullt att kunna beräkna hur stor del av infor-mationen
som förändrats. Ett önskemål är därför att alla värden som förändrats har markerats på något sätt.
Önskemål 3
Det bör vara möjligt föra in det framställda XML-dokumentet i en analys via exempelvis
statistikprogrammet SAS.
För att utföra statistiska beräkningar vid olika analyser är det vanligt på MEP att använda sig av
programmet SAS. Därför är det önskvärt att på ett enkelt sätt kunna föra data från
XML-dokumentet in i detta program.

25. Önskemål 4
Användargränssnittet bör vara fönsterbaserat.
Användargränssnittet bör vara fönsterbaserat för att göra programmet så lättanvänt som möjligt,
dock ställs inga specifika krav på utseendet.

26. 5 Konstruktion av Pilot-programmet
Detta kapitel innehåller en översiktlig beskrivning av de tekniker som använts vid
konstruk-tionen av programmet, som döpts till Pilot. Huvudsakligen behandlas parsning och
validering. Även den grafiska utformningen och tillvägagångssättet för användning av programmet
be-skrivs kort. Egenskaper och funktioner i programmet som hör ihop med de enskilda kraven i
kravspecifikationen beskrivs utförligare i kapitlet om testning och utvärdering.
Programmet ska användas för att läsa in en textfil, utföra vissa korrigeringar och leverera ett
XML-dokument.
5.1 Källfilen
Utdrag ur Cancerregistret är en ren textfil och består av c:a 200 000 rader med 151 tecken på
varje rad. Varje enskild rad representerar en individ och i detta fall är det alla personer bosatta i
Sverige med diagnosen bröstcancer. Registret omfattar alla diagnostiserade fall sedan 1958. För
varje person finns 35 olika variabler på olika positioner. Exempelvis position 1-12 för
personnummer, position 13 för kön och så vidare (se Appendix A). Filen är drygt 28Mb.
5.2 Användargränssnittet
Användargränssnittet är utformat så att det ska vara enkelt och funktionellt. Dock finns i
kravspecifikationen inga direkta krav på utseende eller användarvänlighet. Därför har inga tester
med avseende på enkelhet eller val av namn på knappar och liknande genomförts.
Fig 5.1 Användaren väljer variabler som ska ingå
Det finns två sätt att välja ut vilka variabler som ska ingå i XML-dokumentet. Har en mall
sparats tidigare går det att söka upp och öppna denna via Arkiv-menyn. Strukturen på det
resulterande XML-dokumentet kommer då att vara identisk med strukturen på de dokument som
tidigare framställts med mallen. Det alternativa sättet är göra ett nytt val av vilka variabler som ska
ingå i XML-dokumentet. Dessa variabler väljs ur en flervalsmeny för elementnamn (se fig 5.1).
För den senast valda variabeln visas typ av data samt start- och slutpositioner i textfilen. Samtliga
valda variabler redovisas på listan i den nedre delen av fönstret. Funktionsvalet för att spara de
valda variablerna i en ny mall finns i Arkiv-menyn.
För att konvertera källfilen klickar användaren på knappen ”Konvertera” och söker sig sedan
fram till och väljer den aktuella textfilen i en dialogruta. Därefter får användaren automatiskt en
förfrågan om var XML-dokumentet ska sparas.
Fig 5.2 Användaren väljer textfil för transformering
I alla dialogrutor där filer ska väljas för läsning eller skrivning visas bara den filtyp som är

27. aktuell för tillfället. Då till exempel användaren vill öppna en textfil för konvertering visas endast
filer med ändelsen ’.txt’ och då XML-dokumentet ska sparas, visas ändelsen ’.xml’. När
konverteringen är klar får användaren ett slutmeddelande och en fråga om dokumentet ska
valideras.
Fig 5.3 Validering bekräftas av användaren
5.3 Parsning
Den grundläggande teknik som används för att framställa ett XML-dokument från en textfil
kallas parsning. I huvudsak finns två olika metoder för parsning, SAX [21] och DOM [22].
5.3.1 Presentation av alternativen
Simple API for XML
Simple API for XML (SAX) var ursprungligen ett API endast för Java, men finns numera
implementerat i ett flertal programmeringsspråk och anses vara en de factostandard. SAX är ett
händelsebaserat (eng. eventbased) API, vilket betyder att det rapporterar händelser genom så
kallade callbacks * . Exempel på händelser är start-på-element och slut-på-element. Applika-tionen
måste implementera metoder som tar hand om dessa callbacks. En direkt jämförelse kan göras med
hur man programmerar för att ta hand om händelser i ett grafiskt användar-gränssnitt. Då utlöser
den som trycker på knappen en händelse via ett metodanrop till en lyssnare. Vid parsning med
SAX utlöses istället callbacks direkt av programmets egna metoder och väsentligt för att
XML-dokumentet ska bli välutformat är också att alla callbacks sker i en given ordning och på
lämpliga ställen i programmet. Dessa callbacks är metodanrop till ett speciellt gränssnitt, som
kallas ContentHandler * , som alltså motsvarar lyssnaren i ett grafiskt användargränssnitt. För att
tydliggöra hur ett händelsebaserat API arbetar visas nedan ett exempel.
<?xml version="1.0"?>
<doc>
<data>Hello, world!</data>
</doc>
Fig 5.4 Enkelt XML-dokument
Detta enkla exempel läses rad för rad och bryts ned till följande händelser:
start document
start element: doc

28. start element: data
characters: Hello, world!
end element: data
end element: doc
end document
Fig 5.5 Exempel på händelser vid SAX-parsning
Fördelen med detta tillvägagångssätt är att applikationen alltså läser rad för rad och sedan
släpper informationen utan att lagra något i minnet.
Document Object Model
Document Object Model (DOM) är utvecklat av W3C och är en standard. Det är hierarkiskt
uppbyggt vilket betyder att det bygger upp ett träd av hela dokumentet i minnet. Den
imple-menterande applikationen kan sedan navigera i trädet.
En fördel med DOM är att det är förhållandevis lätt att förändra dokumentet som man vill
eftersom det går att navigera i trädet och söka efter specifika element och sedan backa till ett
tidigare element. En stor nackdel när det gäller stora dokument är dock att det är mycket
minneskrävande.
5.3.2 Parsning i Pilot
Utdraget ur Cancerregistret är som tidigare nämnts drygt 28Mb vilket innebär att SAX är den
enda användbara metoden i detta fall då DOM är alltför minneskrävande [1]. I textfilen finns
givetvis inga element som parsern kan rapportera tillbaka, men en SAX-parser kan även användas
för att generera SAX-händelser från en vanlig textfil. Programmet läser in textfilen rad för rad och
plockar ut de variabler som valts från rätt positioner. Varje variabel förses med det namn som finns
i menyn. En kontroll görs om korrigeringar av värdet ska ske innan pro-grammet anropar metoder
för till exempel ”start på”, ”innehåll i” och ”slut av” element. På detta sätt skrivs varje variabel
stegvis och strukturerat till resultatfilen.

29. 5.4 Validering
I kapitlet om XML beskrivs kort valideringsmöjligheten av XML-dokument med hjälp av
scheman. I kravspecifikationen finns inte något direkt krav eller önskemål på denna möjlig-het,
men funktionen är relativt enkel att implementera. Valideringsfunktionen är även till stor hjälp vid
testning av ett antal krav och önskemål. Av denna anledning finns den inbyggd i programmet.
Validering sker mot ett schema som beskrivs nedan. För valideringsfunktionen används, precis
som vid transformeringen av textfilen, SAX-parsning.
5.4.1 Val av schematyp
De viktigaste aspekterna att ta hänsyn till vid valet av schema i detta arbete är om det finns stöd
för datatyper, namnrymder och om schemat stöds av aktuella mjukvaruleverantörer. Med
utgångspunkt från dessa kriterier framstår W3C XML Schema som det bästa valet. Det är
des-sutom en W3C-rekommendation vilket ökar dess chanser att överleva som standard bland de
stora aktörerna.
5.4.2 MEP-schemat
För att kunna validera och därmed kontrollera att XML-dokumentet överensstämmer med de
krav som framkommit under arbetet med en kommande variabelstandard på MEP har en fiktiv
standard beskrivits med hjälp av XML Schema (se Appendix B). Schemat beskriver följande
struktur:
<forskningsdata>
<studieobjekt>
...
godtyckligt antal variabler ur Cancerregistret
...
</studieobjekt>
<forskningsdata>
Fig 5.6 Enkel beskrivning av MEP-standardens struktur
Hela utdraget betraktas som forskningsdata och varje rad i textfilen, dvs en individ, som ett
studieobjekt. Varje studieobjekt får innehålla ett eller flera element som alltså motsvarar de i
textfilen positionsbestämda variablerna.
Vissa av variablerna, alla datum samt dödsorsakskoder (ICD-koder), begränsas med hjälp av
inbyggda eller härledda datatyper i XML Schema.

30. <xsd:element name="deathDat" type="extendedDateType" minOccurs="0"/>
<xsd:element name="ulCofD" type="extendedIcdType" minOccurs="0"/>
<!--Definition av extendedDateType //-->
<xsd:complexType name="extendedDateType">
<xsd:simpleContent>
<xsd:extension base="xsd:date">
<xsd:attribute name="orig" type="xsd:string" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!--Definition av codeType //-->
<xsd:simpleType name="codeType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="ICD-7" />
<xsd:enumeration value="ICD-8" />
<xsd:enumeration value="ICD-9" />
<xsd:enumeration value="ICD-10" />
<xsd:enumeration value="Dödsdatum tidigare än 1958" />
<xsd:enumeration value="Felaktigt datum. ICD-version obestämbar" />
</xsd:restriction>
</xsd:simpleType>
<!--Definition av extendedIcdType //-->
<xsd:complexType name="extendedIcdType">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="icd_ver" type="codeType" use="required" />
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
Fig 5.7 Utdrag ur XML Schema för MEP
I exemplet visas hur datum och dödsorsakskoder begränsas. Elementet deathDat (för
döds-datum) ska vara av typen extendedDateType. Innehållet i element av denna typ ska, som
an-ges av xsd:extension base="xsd:date" , följa formatet ÅÅÅÅ-MM-DD. Detta format följer
ISO-standard ISO8601. Dessutom ges möjlighet att lägga till ett attribut orig , för ursprungs-värdet
om korrigering av datumet skett.
Dödsorsakskoder beskrivs i typen extendedIcdType. Det enda kravet på innehållet i dessa
element är att de ska vara av typen string , d v s alla UNICODE-tecken godtas. Attributet icd_ver
måste finnas med och ska vara av typen codeType. Detta attribut kan endast ha ett av följande
värden:
· ICD7

31. · ICD8
· ICD9
· ICD10
· Dödsdatum tidigare än 1958
· Felaktigt datum. ICD-version obestämbar
Övriga variabler som alltså inte är datum eller dödsorsakskoder begränsas bara till namnet på
elementet.

32. 6 Testning och utvärdering
6.1 Testkörningarna
Tester har i huvudsak utförts genom att med hjälp av programmet transformera utdraget ur
cancerregistret till ett XML-dokument och därefter med olika metoder kontrollera detta. Olika
problem har uppstått vid testkörningarna. Den främsta orsaken till detta har varit att en del av de
applikationer som ingått fortfarande inte är färdigutvecklade. En annan detalj som påverkat
testningen är att variabelstandarden som XML-dokumentet ska följa inte är färdigställd.
De tester som avses i detta kapitel utfördes efter att programmet var färdigkonstruerat.
6.2 Presentation
Nedan presenteras testerna samt resultat och utvärdering av dessa i den ordning de presenteras i
kravspecifikationen.
Absolut krav 1
Alla datum i det framställda XML-dokumentet måste vara fullständiga.
För att åtgärda felaktiga eller inkompletta datum kontrolleras om datumet består av åtta siffror, dvs
ååååmmdd. Om så inte är fallet kompletteras värdet enligt kravet. Består datumet av ett ojämnt
antal siffror betraktas det som felaktigt ifyllt och korrigeras inte.
Testning : För att testa att korrigeringar sker på ett korrekt sätt har hela textfilen transfor-merats
och sedan validerats med hjälp av programmets inbyggda funktion för validering. Detta har gjorts
mot ett schema som kräver att alla datum finns angivna enligt formatet
åååå-mm-dd.
Resultat : Samtliga korrigeringar validerades och visade sig vara korrekt utförda.
Kommentar : Testningen av detta krav visar tydligt en av fördelarna med XML. Möjligheten att
validera gör att det på ett enkelt och tillförlitligt sätt går att kontrollera att datum verkligen följer
det format man på förhand bestämt. Genom användning av XML Schema och dess inbyggda
datatyp date säkerställs formatet på datum.
Absolut krav 2
Det skall vara möjligt att välja ut ett godtyckligt antal variabler ur utdraget från
Cancerregistret.
Alla ingångsvariabler har gjorts valbara i en meny. De variabler som väljs i menyn läggs till en
mall som presenteras i en lista. Valda variabler kan också markeras i listan och plockas bort. Alla
variabler presenteras tillsammans med en kort beskrivning. Dessutom anges start- och
slutpositioner i den ursprungliga textfilen. För den senast valda variabeln presenteras också
datatypen i en separat ruta. Programmet framställer ett XML-dokument som endast innehåller de

33. variabler som användaren valt.
Testning : Testning har genomförts genom att transformera hela och delar av källfilen och
kontrollera att XML-dokumentet endast innehåller de variabler som valts.
Resultat : XML-dokumentet överensstämmer med valda variabler.
Absolut krav 3
Det ska vara möjligt att spara en mall över valda variabler.
För varje vald variabel skapas i programmet ett objekt som bland annat innehåller variabelns namn
samt start- och slutposition i textfilen. Dessa objekt lagras i en vektor som i sin tur kan sparas för
att utgöra mall på en fil. På detta sätt kan användaren när som helst framställa ett identiskt
XML-dokument. När mallen öppnas i programmet visas alla variabler i listan.
Testning : Ett antal godtyckligt valda variabler har sparats som en mall och sedan öppnats för att
kontrollera att rätt variabler lagrats. För att kontrollera att objekten lagras korrekt har text-filen
transformerats dels med alla variabler, dels med ett antal utvalda variabler. Mallar för båda fallen
har sparats. Sedan har mallarna öppnats och textfilen har transformerats igen. Resultatfilerna har
sedan jämförts för att kontrollera att de är identiska. Tester har även gjorts med att flytta mallar
mellan olika datorer.
Resultat : Testerna visar att mallarna sparas korrekt. Mallar har kunnat återanvändas även om
programkoden uppdaterats, dock under förutsättning att inga ändringar gjorts i klasser och metoder
som påverkat mallen. Den har kunnat flyttas och användas på alla datorer där programmet finns.
Absolut krav 4
ICD-versionen för två variabler i filen, underliggande och bidragande dödsorsak, måste
kunna beräknas.
För att beräkna ICD-version används årtalet i dödsdatum. Positionerna för detta är kända av
programmet vilket gör att ICD-versionen kan beräknas oavsett om användaren valt variabeln för
dödsdatum eller inte. Om dödsdatumet saknas i textfilen kan således inte ICD-version beräknas
och anges istället med ett felmeddelande i XML-dokumentet.
Testning : För att kontrollera att korrekt ICD-version anges har delar av källfilen tagits ut och en
mindre fil skapats för att manuellt kunna jämföra årtal och version.
Resultat : Jämförelser visar att korrekt ICD-version anges.
Kommentar : Dessa beräkningar kräver givetvis att källfilen innehåller korrekt information, dvs
att den patolog som fyllt i uppgifterna angivit den ICD-version som vid dödstillfället var aktuell.
Det finns ingen garanti för att en äldre version inte använts, i synnerhet om en ny version nyligen
tagits i bruk.
Krav 1
Det framställda XML-dokumentet ska följa en variabelnamnsstandard som är under

34. utveckling på MEP.
I programmet finns de variabler som ingår i textfilen namngivna och valbara i en meny. I den
första versionen av programmet lämnades användaren full frihet att själv välja namn på variabeln,
men efter beslut på MEP att alla variabler skall följa institutionens standard finns inte längre skäl
att ha med denna valbarhet. I den slutliga versionen är därför valmöjligheten låst till givna
variabelnamn. Hänsyn har tagits till de generella regler som föreslagits:
· Språk: engelska
· Maximal längd: 12 (om möjligt, högst åtta) tecken
· Variabelbeskrivning (beskrivning av variabelns betydelse)
· Värdebeskrivning (beskrivning av värdets format, t ex YYYY-MM-DD)
· Specialtecken såsom / - : , blanksteg eller punkter är inte tillåtna
· Versaler och gemener ska inte blandas
Testning : Jämförelser mellan de valbara variabelnamnen i programmet och det utkast som finns
för en föreslagen variabelstandard.
Resultat : Kravet uppfylls delvis enligt följande:
Regel Följs
helt
Följs
delvis
Följs
inte
Språk X
Maximal längd X
Variabelbeskrivning X
Värdebeskrivning X
Specialtecken X
Versaler och gemener X
Fig. 6.1 Sammanställning över hur väl kraven följer reglerna i variabelstandarden.
Kommentar : Arbetet med MEP:s variabelstandard har inte slutförts och därför kan inte kravet
uppfyllas fullt ut. Ett tänkbart sätt att lägga till variabel- och värdebeskrivningar är att lägga till ett
attribut i XML-dokumentets rot-element innehållande en referens till en separat fil. Denna fil,
bestående av metadata * , beskriver bara innehållet i XML-dokumentet, men håller inga data.
Anledningen till att det förekommer en blandning av versaler och gemener i variabelnamnen är att
det är ett mycket vanligt sätt att namnge element i XML. Konventionen säger att elementnamnet
börjar med en gemen och varje nytt ord markeras med en versal.
Krav 2
Det framställda XML-dokumentet ska följa en standard för hur variabelvärden ska anges
som är under utveckling på MEP.

35. Programmet använder sig av validering för att möjliggöra kontroll av variablernas värden. Schemat
som används vid valideringen är utformat utifrån den variabelförteckning som erhållts från
Cancerregistret samt de regler som utformas på MEP. För variabelvärden har endast regler från
MEP beaktats.
Testning : Hela textfilen har transformerats med hjälp av programmet och sedan validerats.
Resultat : XML-dokumentet validerades och visade sig vara korrekt.
Kommentar : De enda regler för variabelvärden som hittills framkommit och innefattar variabler
från Cancerregistret är hur kön och datum ska anges. Dessa värden beskrivs i schemat som
använts, och stämmer alltså överens med MEPs krav. På grund av att antalet variabler som kan
kontrolleras är så få har ytterligare kontroll av fler värden ansetts vara värdefull. Därför har ett
annat schema tillverkats (se Appendix C) där fler värden har begränsats utifrån värdebeskrivningen
i variabelförteckningen från Cancerregistret. När validering sker mot detta utvidgade schema
upptäcks ett flertal felaktigheter i filen. T ex anges på flera ställen värdet 4 för tumörens
lokalisation (sida). Enligt variabelförteckningen ska det vara 1 för höger sida, 2 för vänster eller 9
för okänd. Denna typ av felaktigheter kommer av att filen från början är felaktig och korrigeringar
kan inte göras av programmet. Istället måste slutanvändaren ta ställning till och utföra
korrigeringar i varje specifikt fall. Notera att denna kontroll faller utanför kraven och endast är
gjord för att visa på värdet av att kunna validera ett dokument.
Önskemål 1
Det är önskvärt att två variabler i filen, underliggande och bidragande dödsorsak, anges
tillsammans med den ICD-version de anges i.
ICD-versionen beräknas och lagras som ett attribut (icd_ver) i respektive element. Om
döds-datumet inte kan beräknas får attributet värdet ’ Felaktigt datum. ICD-version obestämbar ’,
och kan således tolkas som ett felmeddelande. Om döden inträffat tidigare än 1958 beräknas inte
ICD-version, men detta betraktas inte som felaktigt.
Testning : För att testa att ICD-versionen anges har hela textfilen transformerats med pro-grammet
och sedan validerats. Schemat anger att dessa element måste innehålla attributet ’ icd_ver ’ som får
ha ett av följande värden:
· ICD7
· ICD8
· ICD9
· ICD10
· Dödsdatum tidigare än 1958
· Felaktigt datum. ICD-version obestämbar
Resultat : Dokumentet validerades och visade sig vara korrekt. Detta innebär att samtliga element
innehåller attributet icd_ver samt att inga otillåtna värden för attributet förekommer.
Kommentar : Enligt samma resonemang som för det absoluta kravet att ICD-version måste kunna
beräknas, förutsätts här att rätt ICD-version använts av vederbörande patolog.
Önskemål 2

36. Värden som förändrats från källfilen bör markeras.
Samtliga värden som förändras från källfilen lagras som attribut i respektive element. Om t ex ett
datum inte är fullständigt ifyllt kompletteras detta enligt vissa regler och det ursprungliga värdet
lagras i attributet ’ orig ’. Om värdet inte förändras får elementet inget attribut. Förekomsten av
detta attribut i elementen fungerar alltså som en flagga för förändrade värden.
Testning : Dessa tester har utförts genom att mindre delar av utdraget från Cancerregistret
transformerats med hjälp av programmet. Därefter har det framställda XML-dokumentet jämförts
med källfilen för att kontrollera att alla värden som förändrats innehåller attributet ’ orig ’ och att
detta har korrekt värde angivet.
Resultat : Samtliga förändrade värden markerades.
Kommentar : Programmet uppfyller kravet och anger vilka värden som förändrats. Det utför dock
inga beräkningar av hur många eller hur stor del som förändrats. Dessa beräkningar måste utföras i
efterhand.
Önskemål 3
Det bör vara möjligt föra in det framställda XML-dokumentet i en analys via exempelvis
statistikprogrammet SAS.
Programmet framställer ett XML-dokument som följer den struktur som SAS kräver för att kunna
importera direkt. Dvs, det har under rotelementet endast ett element, studieobjekt, som i sin tur
innehåller flera olika element men bara på en nivå.
Testning: Hela och delar av källfilen har transformerats. Försök har sedan gjorts att importera
dessa med hjälp av ett tillägg, SAS XML engine. Tester har utförts på en dator med 128Mb
internminne.
Resultat: Endast mindre filer kan importeras. Vid försök med filer större än c:a 12Mb kommer ett
felmeddelande om att minnet är slut och importen avbryts.
Kommentar: XML-dokumentet som framställs har den struktur som krävs för att kunna
im-porteras till SAS. Önskemålet uppfylls dock endast delvis då det inte går att importera hela den
transformerade filen. Om hela textfilen används blir resultatfilen drygt 12Mb redan då man väljer
endast en variabel. Detta betyder givetvis att det inte är särskilt meningsfullt att använda
programmet i detta avseende. De tillägg för XML som finns för SAS är fortfarande på
experimentstadiet och det är svårt att bedöma framtiden för dessa tillägg [23]. Vid mindre studier
än detta, som ju innefattar närmare 200 000 personer, är det dock fullt möjligt att använda denna
metod för att föra in data från ett externt register till en analys på MEP.
Önskemål 4
Användargränssnittet bör vara fönsterbaserat.
Programmet har ett fönsterbaserat användargränssnitt med komponenter som liknar de som
återfinns i många andra vanligt förekommande applikationer.
Kommentar: Inga tester har utförts på detta önskemål eftersom det av uppdragsgivaren inte setts

37. som särskilt viktigt att det är lättanvänt. Den relativa enkelheten och de få funktionella kraven i
programmet medför ändå att det inte blir alltför svårt att lära sig. Dessutom har de tilltänkta
användarna relativt kvalificerad datorvana.

38. 7 Epilog
7.1 Slutsatser
Uppdraget att framställa ett program som transformerar ett utdrag ur Svenska Cancerregist-ret i
form av en strukturerad textfil till ett XML-dokument, visade sig fullt genomförbart. Detta
resulterade i ett XML-dokument som var nästan tio gånger större än den ursprungliga textfilen.
Valet av Javabaserade APIer för framställning av programmet har visat sig bra både med tanke
på hantering av uppställda krav och med tanke på programspråkets starka koppling till olika
parsningsmetoder. Uppgiften att genomföra korrigeringar av felaktig data blir relativt enkel för en
programmerare och flera APIer finns att välja på för att producera resultat i form av
XML-dokument. Dock har SAX visat sig vara den enda tillämpbara parsningsmetoden på så stora
textfiler som ingått i uppdraget.
Studien har visat att en mellanlagring av externt importerad data i XML-format ger
institu-tionen utmärkta möjligheter att kontrollera data med avseende på innehåll och struktur. Ett
liknande förfaringssätt borde kunna tillämpas även på information som flyttas mellan
institu-tionens egna system. Valideringsfunktionen medger kontroll av alla producerade
XML-dokument, och kraven på data kan styras av separat framställda XML Scheman.
Uppdragets experimentella karaktär har på flera sätt präglat arbetet med att ta fram programmet.
7.2 Diskussion
Uppgiften att dokumentera möjligheter och eventuella problem med XML-formatet, har inte
varit lika enkel och självklar som att ta fram Pilot-programmet. För att kunna dokumen-tera
möjligheter har det dels krävts en beskrivning av XML-konceptet och dess generella för- och
nackdelar och dels har det funnits ett behov av en modell över det sammanhang där infor-mationen
är tänkt att förekomma. XML-konceptet har redovisats i ett eget kapitel. Däremot används varken
formatet eller XML-tekniker ännu i någon större utsträckning inom epidemio-logisk forskning, och
på institutionen ingår heller inte XML som standard. Någon modell över liknande system har inte
gått att finna vid litteratursökning och sökning på Internet.
Det ursprungliga målet med att ta fram resultatet i form av ett XML-dokument var att
un-dersöka möjligheten att föra informationen vidare in i olika system på institutionen. Om det
redan idag skulle gå att relativt enkelt bygga ett antal XSLT-processorer som kunde tolka
framställda XML-dokument till respektive system skulle institutionen mycket väl direkt kunna
komma igång med att utnyttja XML-konceptet. XML-dokument bestående av t ex externt
inhämtade data skulle kunna:
- hanteras, presenteras och lagras av institutionens system
- tillsammans med programmet och tillhörande dokumentmall bilda en fullgod
dokumentation
- lagras i komprimerad form och vara sökbart genom framställning av metadata,

39. bestående av id-nummer, en beskrivande text och en länk till det komprimerade
dokumentet
- bli refererade till via id-numret av andra dokument
Många av de utmaningar och fallgropar som framkommit under utvecklingen av program-met är
troligen i många fall förenade med att XML-konceptet inte är färdigutvecklat som standard. Som
testerna har utvisat är inte de XSLT-processorer som tillhandahålls bland öppna standarder ännu
redo att ta hand om XML-dokument av en storlek av 200Mb och större. Vid detta arbete har en
Xalan-processor använts, vilken levereras tillsammans med Java 2 Platform, Standard Edition 1.4.
Principen som Xalan bygger på, liksom alla andra processorer vi kommit i kontakt med, är att den
på ett sätt som liknar DOM bygger upp hela dokumentet i en trädstruktur som kräver väldigt
mycket minne. Joseph Kesselman, en av Xalans utvecklare, uttrycker det på följande sätt i ett
diskussionsforum [24]:
Vi vill verkligen utveckla Xalan till att tillåta den att upptäcka när information
inte längre behövs och att den kan undvika att spara det i minnet, men det är ett
pågående forskningsarbete.
Storleken på källdokumenten måste alltid sättas i relation till storleken på datorernas
arbets-minne. Mer arbetsminne tillåter naturligtvis större källdokument. En del utdrag kan dock
vara så stora som 200Mb vilket leder till XML-dokument i storleksklassen 2Gb. Det skulle i sin tur
uppskattningsvis krävas tio gånger denna storlek i arbetsminne för problemfri körning. Att tillämpa
XSL för direkt bearbetning av denna typ av stora informationsmängder kan därför ifrågasättas.
XML-konceptet är inte tillräckligt färdigutvecklat för att kunna tillgodose uppdrags-givarens
alla önskemål. Frågan blir då om det går att finna andra försvarbara skäl att trans-formera externa
data till XML-dokument. Betraktandet av XML-dokument som ett portabelt intermediärformat för
vidare transport in i institutionens befintliga system är en så kraftfull och löftesrik tanke, att det
måste till starka motargument för att förkasta den.
Ett skäl till att transformera information till XML-format skulle kunna vara att all ingående data
då kunde valideras mot institutionens variabel- och formatstandard. Institutionen räknar med att ha
en, om än begränsad, variabelstandard i drift under hösten 2002. Om en enhetlig modell för hur
variabler skall tas omhand i ett XML-dokument utvecklades, skulle det vara mycket enkelt att
kontrollera alla variabler mot ett standardschema. Exempelvis kunde strukturen för alla dokument
vara som i detta arbete:
<forskningsdata>< studieobjekt>< variabel />< / studieobjekt>< /forskningsdata>
Att implementera denna i ett XML Schema borde vara fullt möjligt att genomföra.
Valideringsfunktionen jämte det starka leverantörsstödet för XML-konceptet kan vara tillräckligt
för att stödja tanken på användandet av XML-dokument för mellanlagring av information.
Beträffande den interna hanteringen av externt inhämtad information finns det ett antal tänkbara
alternativ. Med tanke på XML-dokumentens storlek torde det ligga ekonomi i att på något sätt föra
all information vidare från XML-dokumenten in i någon form av databas. Idag satsas mycket
resurser på att skapa scheman som i sin tur styr innehållet i XML-dokument till att passa in i
befintliga databaser. Under arbetets gång har det framkommit att åtminstone en stor aktör på
marknaden, Oracle, är i full färd med att anpassa sin programvara efter W3C XML Schema. [29]
Förutom att flytta dokumentets innehåll in i traditionella relationsdatabaser eller

40. objekts-databaser kan någon form av semistrukturerad lagring och hantering vara tänkbara [8].
Det förefaller sammanfattningsvis som att XML-dokument de närmsta åren främst kommer att
vara ett standardformat för att transportera mindre informationsmängder mellan system, och att
dess fördelar ska sökas i portabiliteten, hög acceptans hos användare och möjligheten till
validering. Valideringsfunktionen ger dessutom användare av XML-dokument fördelen att kunna
knyta innehållet till en eller flera exakta standarder vilket leder till kontrollmöjligheter av
informationens tillförlitlighet.
7.3 Förslag till vidare studier
Om XML-format nu eller i framtiden kommer att användas för så stora dokument som 200Mb
och större måste man se över hur befintliga system ska kunna tillgodogöra sig dessa dokument.
Det förefaller som att det idag endast är möjligt att åstadkomma detta med program som skapar
någon slags bryggor mellan dokumenten och det mottagande systemen. Detta får ses som en mer
resurskrävande metod än enkel XSLT-editering. Noggrannare under-sökningar av XSL än vad som
gjorts i detta arbete kunde därför vara värdefullt och även att utforska vilka andra tekniker som kan
tänkas för att lösa problemet. Till exempel kan en app-likation som bygger på SAX-parsning läsa
in och transformera dessa jättelika XML-dokument steg för steg med en ström av XML-dokument
av en betydligt mindre storlek som resulteran-de mellanled, som sedan problemfritt kan köras i en
integrerad XSLT-processor.
För MEP bedömer vi det som värdefullt med noggrannare studier av möjligheten att defi-niera
den kommande variabelstandarden med hjälp av XML Schema eller annat schemaspråk.
Närmare information över metadata har efterfrågats av uppdragsgivaren. Ett flertal standar-der
och arbeten finns för att med XML som grund hantera denna typ av data. Exempelvis har mycket
arbete lagts ner på Resource Description Framework (RDF) [25]. Detta är en XML-applikation,
utvecklad av W3C, anpassad att koda, utbyta och återanvända strukturerad meta-data. Ett annat
alternativ är XML Linking Language (XLink) [26], som även det utvecklats av W3C. Med XLink
kan element som beskriver länkar till andra dokument eller delar av samma dokument infogas i ett
dokument. Praktiska försök att beskriva metadata, med hjälp av dessa eller liknande tekniker,
borde vara intressant för den information man har.

41. Referenslista
Litteratur
[ 1] Brett McLaughlin, Java & XML.
Oreilly, 2001
[ 2] Kevin Williams, Professional XML Databases.
Wrox Press Ltd, 2000
[ 3] Eric M Burke, Java & XSLT.
Oreilly, 2001
[ 4] Peter P. Schoderbek et al., Management Systems
The McGraw-Hill Companies, 1998
[ 5] ITS Rapport, Terminologi för Informationssäkerhet
Informationstekniska standardiseringen, 1994
[ 6] Lars Celander, XML – en skonsam men effektiv introduktion.
Azelia AB, 2001
[ 7] FitzGerald & Dennis, Bussines Data Communications and Networking.
John Wiley & sons INC, 1998
[ 8] Abiteboul, Buneman & Suciu, Data on the Web.
Morgan Kaufmann Publishers, 2000
Internetkällor
[ 9] Institutionen för medicinsk epidemiologi (MEP)
URL: http://www.mep.ki.se/mep_se.html (april, 2002)
[10] Svenska Tvillingregistret
URL: http://w w w.mep.ki.se/twin/index_en.html (april, 2002)
[11] Extensible Markup Language (XML) 1.0 W3C Recommendation 10 February 1998
URL: http://www.w3.org/TR/1998/REC-xml-19980210 - sec-origin-goals (april, 2002)
[12] Extensible Markup Language (XML) 1.0 (Second Edition) W3C Recommendation
6 October 2000
URL: http://www.w3.org/TR/REC-xml - sec-well-formed (april, 2002)
[13] Comparing XML Schema Languages by Eric van der Vlist, 12 december 2001
URL: http://www.xml.com/pub/a/2001/12/12/schemacompare.html (april, 2002)
[14] Namespaces in XML World Wide Web Consortium 14 January 1999
URL: http://www.w3.org/TR/1999/REC-xml-names-19990114/ (april, 2002)
[15] W3C XML Schema
URL: http://www.w3.org/XML/Schema (april, 2002)
[16] W3C The Extensible Stylesheet Language (XSL)

42. URL: http://www.w3.org/Style/XSL/ (april, 2002)
[17] XSL Transformations (XSLT) Version 1.0 W3C Recommendation 16 November 1999
URL: http://www.w3.org/TR/xslt (april, 2002)
[18] XML Path Language (XPath) Version 1.0 W3C Recommendation 16 November 1999
URL: http://www.w3.org/TR/xpath (april, 2002)
[19] E xtensible Stylesheet Language (XSL) Version 1.0 W3C Recommendation
15 October 2001 – Formatting Objects
URL: http://www.w3.org/TR/xsl/slice6.html - fo-section (april, 2002)
[20] An introduction to XSL Formatting Objects by Dave Pawson, 1 st Edition, 2001
URL: http://www.dpawson.co.uk/xsl/sect3/bk/ch02.html (april, 2002)
[21] About SAX (officiell sida för SAX)
URL: http://www.saxproject.org (april, 2002)
[22] W3C Document Object Model (DOM) URL: http://www.w3.org/DOM / (april, 2002)
[23] Using the Enhanced SAS XML LIBNAME Engine
URL: http://www.sas.com/rnd/base/topics/sxle82/exp82/index.html (april, 2002)
[24] Xalan-J-Users Mailinglist
URL: http://marc.theaimsgroup.com/?l=xalan-j-users&m=101525940011512&w=2
(april, 2002)
[25] Resource Description Framework (RDF) W3C
URL: http://www.w3.org/RDF/ (april, 2002)
[26] XML Linking Language (XLink) Version 1.0 W3C Recommendation 27 June 2001
URL: http://www.w3.org/TR/xlink/ (april, 2002)
[27] Swedish Standards Institute (SIS)
URL: http://www.sis.se/om_standardisering/varfor/sekel.asp (maj, 2002)
[28] Java Technology & XML
URL: http://java.sun.com/xml/ (maj, 2002)
[29] Oracle XML DB, Technical White Paper, Release 9.2, January 2002
URL: http://otn.oracle.com/tech/xml/xmldb/pdf/xmldb_92twp.pdf (maj, 2002)
[30] Juliusprojektet, slutrapport förstudie, 2001-09-27
URL: http://www.hsn.sll.se/projekt/Projektkatalog/Proj_IT_Julius Förstudie/slutrapport julius
förstudie.pdf (maj, 2002)

43. Appendix A
Variabelförteckning för Cancerregistret
Position Beskrivning
1 – 12 Personnummer
13 Kön
14 – 19 Län, kommun och församling vid
dignostilfället
20 – 25 Kod för det sjukhus som anmält tumören
26 – 28 Kod för den klinik som anmält tumören
29 – 36 Journalnummer/år
37 – 44 Diagnosdatum
45 Malign/benign tumör
46 Sida
47 – 50 Kod för tumörens lokalisation, ICD-7
51 – 55 Kod för tumörens lokalisation, ICD-9
56 – 59 Kod för tumörens lokalisation, ICD-10
60 – 65 Systemized Nomenclature of Medicine
66 – 68 Histopatologisk diagnos
69 – 71 Patolog/cytologavdelning
72 – 79 Preparatnummer och år
80 Diagnosgrund
81 Obduktionsfynd
82 Avliden i cancer
83 Region
84 – 91 Dödsdatum
92 – 96 Underliggande dödsorsak
97 – 103 Bidragande dödsorsak
104 Grund för dödsorsaksuppgiften, obduktion
105 - 110 Län, kommun och församling vid död
111 – 118 Datum för senaste träff mot FoB
119 – 126 Datum för tidigaste invandring

44. 127 – 134 Datum för senaste utvandring
135 – 136 Födelseland (alternativt födelselän)
cancerfallet
137 – 138 Födelseland (alternativt födelselän)
cancerfallets mor
139 – 140 Födelseland (alternativt födelselän)
cancerfallets far
141 – 142 Tumörnummer i diagnostidsordning, samtliga
tumörer
143 – 144 Tumörnummer i diagnostidsordning, maligna
tumörer
145 – 150 Framskriven hemort
151 Felkod för den framskrivna hemorten

45. Appendix B
XML Schema för MEP
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.dsv.su.se/~folke-na/MEP/schema"
targetNamespace="http://www.dsv.su.se/~folke-na/MEP/schema"
elementFormDefault="qualified"
>
<xsd:element name="forskningsdata" type="forskningsdataType"/>
<!--*************************************************************************-->
<xsd:complexType name="forskningsdataType">
<xsd:sequence>
<xsd:element name="studieobjekt" type="studieobjektType" minOccurs="1"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!--*************************************************************************-->
<xsd:complexType name="studieobjektType">
<xsd:all>
<xsd:element name="id" type="xsd:string" minOccurs="0"/>
<xsd:element name="sex" type="oneOrTwoType" minOccurs="0"/>
<xsd:element name="diagLoc" type="xsd:string" minOccurs="0"/>
<xsd:element name="repHosp" type="xsd:string" minOccurs="0"/>
<xsd:element name="repClin" type="xsd:string" minOccurs="0"/>
<xsd:element name="caseBook" type="xsd:string" minOccurs="0"/>
<xsd:element name="diagDat" type="extendedDateType" minOccurs="0" nillable="true"/>
<xsd:element name="malBen" type="xsd:string" minOccurs="0"/>
<xsd:element name="side" type="xsd:string" minOccurs="0"/>
<xsd:element name="tumLoc7" type="xsd:string" minOccurs="0"/>
<xsd:element name="tumLoc9" type="xsd:string" minOccurs="0"/>
<xsd:element name="tumLoc10" type="xsd:string" minOccurs="0"/>
<xsd:element name="snomed" type="xsd:string" minOccurs="0"/>
<xsd:element name="padCode" type="xsd:string" minOccurs="0"/>
<xsd:element name="patLoc" type="xsd:string" minOccurs="0"/>
<xsd:element name="prepNo" type="xsd:string" minOccurs="0"/>
<xsd:element name="diagMeth" type="xsd:string" minOccurs="0"/>
<xsd:element name="autFind" type="xsd:string" minOccurs="0"/>
<xsd:element name="deadCa" type="xsd:string" minOccurs="0"/>

46. <xsd:element name="region" type="xsd:string" minOccurs="0"/>
<xsd:element name="deathDat" type="extendedDateType" minOccurs="0" nillable="true"/>
<xsd:element name="ulCofD" type="extendedIcdType" minOccurs="0"/>
<xsd:element name="coCofD" type="extendedIcdType" minOccurs="0"/>
<xsd:element name="cOfDMeth" type="xsd:string" minOccurs="0"/>
<xsd:element name="deathLoc" type="xsd:string" minOccurs="0"/>
<xsd:element name="latHitDat" type="extendedDateType" minOccurs="0" nillable="true"/>
<xsd:element name="imDat" type="extendedDateType" minOccurs="0" nillable="true"/>
<xsd:element name="emDat" type="extendedDateType" minOccurs="0" nillable="true"/>
<xsd:element name="birthLoc" type="xsd:string" minOccurs="0"/>
<xsd:element name="birthLocM" type="xsd:string" minOccurs="0"/>
<xsd:element name="birthLocF" type="xsd:string" minOccurs="0"/>
<xsd:element name="allTumNo" type="xsd:string" minOccurs="0"/>
<xsd:element name="malTumNo" type="xsd:string" minOccurs="0"/>
<xsd:element name="forwLoc" type="xsd:string" minOccurs="0"/>
<xsd:element name="errCode" type="xsd:string" minOccurs="0"/>
</xsd:all>
</xsd:complexType>
<!--*************************************************************************-->
<!--Definition of oneOrTwoType. Restricted to be 1 or 2.//-->
<xsd:simpleType name="oneOrTwoType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="1"/>
<xsd:enumeration value="2"/>
<xsd:enumeration value=" "/>
</xsd:restriction>
</xsd:simpleType>
<!--*************************************************************************-->
<!--Definition of extendedDateType. //-->
<xsd:complexType name="extendedDateType">
<xsd:simpleContent>
<xsd:extension base="xsd:date">
<xsd:attribute name="orig" type="xsd:string" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!--*************************************************************************-->
<xsd:simpleType name="codeType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="ICD-7" />

47. <xsd:enumeration value="ICD-8" />
<xsd:enumeration value="ICD-9" />
<xsd:enumeration value="ICD-10" />
<xsd:enumeration value="Dödsdatum tidigare än 1958" />
<xsd:enumeration value="Felaktigt datum. ICD-version obestämbar" />
</xsd:restriction>
</xsd:simpleType>
<!--*************************************************************************-->
<xsd:complexType name="extendedIcdType">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="icd_ver" type="codeType" use="required" />
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!--***************************************************************************-->
</xsd:schema>

48. Appendix C
Utökat XML Schema för MEP
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.dsv.su.se/~folke-na/MEP/schema"
targetNamespace="http://www.dsv.su.se/~folke-na/MEP/schema"
elementFormDefault="qualified"
>
<xsd:element name="forskningsdata" type="forskningsdataType"/>
<!--*************************************************************************-->
<xsd:complexType name="forskningsdataType">
<xsd:sequence>
<xsd:element name="studieobjekt" type="studieobjektType" minOccurs="1"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!--*************************************************************************-->
<xsd:complexType name="studieobjektType">
<xsd:all>
<xsd:element name="id" type="idType" minOccurs="0"/>
<xsd:element name="sex" type="oneOrTwoType" minOccurs="0"/>
<xsd:element name="diagLoc" type="xsd:string" minOccurs="0"/>
<xsd:element name="repHosp" type="xsd:string" minOccurs="0"/>
<xsd:element name="repClin" type="xsd:string" minOccurs="0"/>
<xsd:element name="caseBook" type="xsd:string" minOccurs="0"/>
<xsd:element name="diagDat" type="extendedDateType" minOccurs="0" nillable="true"/>
<xsd:element name="malBen" type="malBenType" minOccurs="0"/>
<xsd:element name="side" type="sideType" minOccurs="0"/>
<xsd:element name="tumLoc7" type="icd7Type" minOccurs="0"/>
<xsd:element name="tumLoc9" type="icd9Type" minOccurs="0"/>
<xsd:element name="tumLoc10" type="icd10Type" minOccurs="0"/>
<xsd:element name="snomed" type="xsd:string" minOccurs="0"/>
<xsd:element name="padCode" type="xsd:string" minOccurs="0"/>
<xsd:element name="patLoc" type="xsd:string" minOccurs="0"/>
<xsd:element name="prepNo" type="xsd:string" minOccurs="0"/>
<xsd:element name="diagMeth" type="diagMethType" minOccurs="0"/>
<xsd:element name="autFind" type="oneOrTwoType" minOccurs="0"/>
<xsd:element name="deadCa" type="deadCaType" minOccurs="0"/>

49. <xsd:element name="region" type="regionType" minOccurs="0"/>
<xsd:element name="deathDat" type="extendedDateType" minOccurs="0" nillable="true"/>
<xsd:element name="ulCofD" type="extendedIcdType" minOccurs="0"/>
<xsd:element name="coCofD" type="extendedIcdType" minOccurs="0"/>
<xsd:element name="cOfDMeth" type="xsd:string" minOccurs="0"/>
<xsd:element name="deathLoc" type="xsd:string" minOccurs="0"/>
<xsd:element name="latHitDat" type="extendedDateType" minOccurs="0" nillable="true"/>
<xsd:element name="imDat" type="extendedDateType" minOccurs="0" nillable="true"/>
<xsd:element name="emDat" type="extendedDateType" minOccurs="0" nillable="true"/>
<xsd:element name="birthLoc" type="xsd:string" minOccurs="0"/>
<xsd:element name="birthLocM" type="xsd:string" minOccurs="0"/>
<xsd:element name="birthLocF" type="xsd:string" minOccurs="0"/>
<xsd:element name="allTumNo" type="xsd:string" minOccurs="0"/>
<xsd:element name="malTumNo" type="xsd:string" minOccurs="0"/>
<xsd:element name="forwLoc" type="xsd:string" minOccurs="0"/>
<xsd:element name="errCode" type="xsd:string" minOccurs="0"/>
</xsd:all>
</xsd:complexType>
<!--*************************************************************************-->
<!--Definition of idType. Restricted to be exactly twelve digits.//-->
<xsd:simpleType name="idType">
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="d{12}"/>
</xsd:restriction>
</xsd:simpleType>
<!--*************************************************************************-->
<!--Definition of oneOrTwoType. Restricted to be 1 or 2.//-->
<xsd:simpleType name="oneOrTwoType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="1"/>
<xsd:enumeration value="2"/>
<xsd:enumeration value=" "/>
</xsd:restriction>
</xsd:simpleType>
<!--*************************************************************************-->
<!--Definition of sideType. Restricted to be 1, 2 or 9.//-->
<xsd:simpleType name="sideType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="1"/>
<xsd:enumeration value="2"/>

50. <xsd:enumeration value="9"/>
<xsd:enumeration value=" "/>
</xsd:restriction>
</xsd:simpleType>
<!--*************************************************************************-->
<!--Definition of diagMethType. Restricted to be 1,2,3,4,5,6 or 7.//-->
<xsd:simpleType name="diagMethType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="1"/>
<xsd:enumeration value="2"/>
<xsd:enumeration value="3"/>
<xsd:enumeration value="4"/>
<xsd:enumeration value="5"/>
<xsd:enumeration value="6"/>
<xsd:enumeration value="7"/>
<xsd:enumeration value=" "/>
</xsd:restriction>
</xsd:simpleType>
<!--*************************************************************************-->
<!--Definition of deadCaType. Restricted to be 1, 2 or 3.//-->
<xsd:simpleType name="deadCaType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="1"/>
<xsd:enumeration value="2"/>
<xsd:enumeration value="3"/>
<xsd:enumeration value=" "/>
</xsd:restriction>
</xsd:simpleType>
<!--*************************************************************************-->
<!--Definition of regionType. Restricted to be 1,2,3,4,5 or 7.//-->
<xsd:simpleType name="regionType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="1"/>
<xsd:enumeration value="2"/>
<xsd:enumeration value="3"/>
<xsd:enumeration value="4"/>
<xsd:enumeration value="5"/>
<xsd:enumeration value="7"/>
<xsd:enumeration value=" "/>
</xsd:restriction>
</xsd:simpleType>

51. <!--*************************************************************************-->
<!--Definition of extendedDateType. //-->
<xsd:complexType name="extendedDateType">
<xsd:simpleContent>
<xsd:extension base="xsd:date">
<xsd:attribute name="orig" type="xsd:string" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!--*************************************************************************-->
<!--Definition of malBenType. Restricted to be blank for malignant or 3 for benign.//-->
<xsd:simpleType name="malBenType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value=" "/>
<xsd:enumeration value="3"/>
</xsd:restriction>
</xsd:simpleType>
<!--*************************************************************************-->
<!--Definition of icd7Type. Restricted to consist of three or four digits. //-->
<xsd:simpleType name="icd7Type">
<xsd:union>
<xsd:simpleType>
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="d{3}d?"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="s{3}s?"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>
<!--*************************************************************************-->
<!--Definition of icd9Type. Restricted to consist of three to five digits. //-->
<xsd:simpleType name="icd9Type">
<xsd:union>
<xsd:simpleType>
<xsd:restriction base="xsd:positiveInteger">
<xsd:pattern value="d{3}d?d?"/>

52. </xsd:restriction>
</xsd:simpleType>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="s*"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>
<!--*************************************************************************-->
<!--Definition of icd10Type. Restricted to begin with one capital letter followed by two or three
digits. //-->
<xsd:simpleType name="icd10Type">
<xsd:union>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[A-Z]{1}d{2}d?"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="s*"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>
<!--*************************************************************************-->
<xsd:simpleType name="codeType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="ICD-7" />
<xsd:enumeration value="ICD-8" />
<xsd:enumeration value="ICD-9" />
<xsd:enumeration value="ICD-10" />
<xsd:enumeration value="Felaktigt datum. ICD-version obestämbar" />
<xsd:enumeration value="Dödsdatum tidigare än 1958" />
</xsd:restriction>
</xsd:simpleType>
<!--*************************************************************************-->
<xsd:complexType name="extendedIcdType">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="icd_ver" type="codeType" use="required" />

53. </xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!--***************************************************************************-->
</xsd:schema>

54. Ordlista
API Application Programming Interface. I Java är ett API en
samling klasser och gränssnitt som genom sina publika metoder görs
tillgängliga för programmerare.
Callback Metoder i den implementerande applikationen som vid
parsning med SAX anropas av parsern.
CERN European Organization for Nuclear Research, världens
största center för partikelfysik. Programmerare inom CERN (bl a Tim
Berners-Lee) var de som skapade den första webbklienten, protokollet
HTTP och märkspråket HTML. Detta låg sedan till grund för World
Wide Web (WWW).
ContentHandler Samling callbacks definierade i SAX som implementeras av
programmeraren för att ta hand om viktiga händelser vid parsning av ett
dokument.
CSS Cascading Style Sheet. Används för att beskriva utseendet för en
webbsida. Exempelvis fontstorlek, bakgrundsfärg mm.
ICD Den mest utbredda klassifikationen inom hälso- och sjukvård, både
inom forskning och klinisk verksamhet. Administreras på
interna-tionell nivå av WHO och nationellt av Socialstyrelsen.
Sjukdomar delas främst in efter orsaker och orsakssamband, men
tilläggsklas-sifikationer finns som knyter ICD till y tterligare koder för
att kun-na klassificera andra yttringar av sjukdomar. Utkommer med en
ny version ungefär vart tionde år. Förändringar i kodningsprinciper och
gruppering av sjukdomar har skett mellan varje revision vilket givit att
det inte finns något tillförlitligt och enkelt samband mellan koder i de
olika versionerna.
Internet Det världsomspännande nätverk som förbinder mer än 40 miljoner
användare. Om Internet stavas med stort I jämställs det ofta med det
som i dagligt tal kallas World Wide Web (WWW).
Metadata Termen metadata används för att beskriva både hur information är

55. strukturerad och vad den betyder. Data om data.
PDF Portable Document Format. Filformat för dokument som gör att de ser
lika ut på alla plattformar. Kräver gratisprogrammet Acrobat Reader
från Adobe för läsning.
Skriptspråk Språk för att skriva skript. Alltså program eller instruktioner som körs av
ett annat program, t ex en webbläsare, snarare än av datorns processor.
Exempel på skriptspråk är: JavaScript, VBScript och Perl.
Svenska Nationellt, befolkningsbaserat cancerregister för att kunna kart-
Cancerregistret lägga cancersjukdomarnas förekomst och förändring över tiden, startade
1958.
SVG Scalable Vector Graphics. Textuell beskrivning av en bild med hjälp av
XML. Program som hanterar XML kan visa bilden utifrån den
information som tillhandahålls i SVG-formatet.
UNICODE Teckenstandard som använder sig av två byte till varje tecken, vilket ger
drygt 65 000 möjliga kombinationer även om standarden bara använder
drygt 40 000 av dessa. Det är nog för att rymma tecken i de flesta språk
på jorden.
W3C World Wide Web Consortium. Utvecklar och står bakom
de flesta viktiga standarder för kommunikation över Internet.
* Alla ord med en asterisker finns förklarade i ordlistan i slutet av dokumentet.