Opphavsrett: Forfatter og Stiftelsen TISIP
Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag
Mer om oppbyning av XML-dokument Lene Hoff
2.9.2013
Lærestoffet er utviklet for faget XML Teknologi
1. Mer om oppbyning av XML-dokument Resymé: I denne leksjonen skal vi fortsette med oppbygning av XML-dokumenter. I forrige leksjon avsluttet vi
med behandling av en del spesielle tegn. Dette skal vi fortsette med i denne leksjonen. Videre har vi en del andre
viktige byggeklosser, som prosessorinstruksjoner og navnerom. Til slutt i leksjonen skal vi også se på
modellering og strukturering av XML-dokumenter.
Innhold 1.1. INNLEDNING ......................................................................................................................................... 1 1.2. ENTITETER ............................................................................................................................................ 2
1.2.1. Generell entitet ................................................................................................................................ 2 1.3. PROSESSORINSTRUKSJONER .................................................................................................................. 5 1.4. NAVNEROM .......................................................................................................................................... 6 1.5. DEN HIERARKISKE STRUKTUREN TIL XML ........................................................................................... 8 1.6. XML PARSERE ................................................................................................................................... 11 1.7. MODELLERING .................................................................................................................................... 12
1.1. Innledning
I denne leksjonen vil en del viktige byggeklosser som brukes i XML-dokumenter bli
gjennomgått. Som vi så på i forrige leksjon er det en del tegn som ikke kan brukes helt uten
videre. Dette gjelder for eksempel de særnorske tegnene. I forrige leksjon så vi på mulige
løsninger på dette. Vi kunne bruke CDATA-seksjoner eller sette korrekt tegnsett. Nå skal vi
fortsette med en del spesielle tegn. I kap 1.2 ser vi på bruk av entiteter. Det betyr at vi kan
navnsette spesielle tegn slik at disse navnene kan brukes i selve XML-dokumentet. Entiteter
vil også være nyttig hvis vi bruke en lang tekst flere ganger i samme dokument. Da kan vi gi
teksten en forkortelse, og bruke den forkortelsen i fortsettelsen.
Videre kommer vi inn på prosessorinstruksjoner i kapittel 1.3. Dette benyttes for eksempel i
forbindelse med stilark til et XML-dokument. Deretter vil vi se på navnerom. Dette er en
standard som brukes mye i forbindelse med XML-skjema og XSLT (kommer senere i kurset).
Når du lager dine egne XML-dokument, er det viktig at du tenker over hvordan dataene i
XML-dokumentet skal brukes før du setter opp strukturen. Av den grunn skal vi bruke de 3
siste kapitlene på å se hvordan du bør modellerer (strukturere) XML-dokumenter. Vi vil også
Mer om oppbyning av XML-dokument side 2 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
komme litt innom hvordan XML-parsere fungerer. Målet er at dette vil gi deg en bedre
forståelse av hvordan hele prosessen med å vise XML-dokumenter fungerer. Dette hjelper deg
også når du forsøker å finne ut av eventuelle feil i XML-dokumentet ditt.
1.2. Entiteter
Det er ikke uvanlig å ha XML-dokumenter der tekst eller grafikk går igjen mange ganger.
Eksempel på dette kan være bedriftsnavn og bedriftslogoer. Tenk deg å lage et XML-
dokument for HIST hvor du må skrive; Høgskolen i Sør-Trøndelag flere ganger. I slike
tilfeller kan det være hensiktsmessig å skrive navnet et sted og henvise til dette i resten av
XML-dokumentet. For eksempel kan vi bruke forkortelsen HIST på alle steder i XML-
dokumentet hvor vi ønsker å skrive Høgskolen i Sør-Trøndelag. Dette kan gjøres ved hjelp av
entiteter. Ved bruk av entiteter kan du for eksempel koble et navn til en lengre tekst. En lager
da en entitet med navn HIST, som står for Høgskolen i Sør-Trøndelag. Hver gang HIST
forekommer i selve XML-dokumentet, byttes det ut med Høgskolen i Sør-Trøndelag. Teksten
vil skiftes ut hver gang XML-dokumentet prosesseres (for eksempel vises i en nettleser).
Vi har allerede sett eksempel på entiteter i forrige leksjon. Der brukte vi blant annet navnet
amp for å sette inn en & som innhold til elementet. Dette er en allerede navngitt entitet.
En entitet består av to deler; deklarasjonen (i en DTD) og entitetsreferansen (i XML-
dokumentet). Videre deler vi entiteter i to typer;
- Generelle entiteter: brukes i XML-dokumentet. Når vi bare bruker ordet entitet er det
denne typen vi tenker på.
- Parameterentiteter: brukes i en DTD.
Begge typer krever at vi deklarerer entiteten. Her vil vi gjennomgå generelle entiteter.
Parameterentiteter inngår ikke i pensum.
1.2.1. Generell entitet
En generell entitet består altså av to deler; en deklarasjon og en entitetsreferanse.
Deklarasjon av entitet
Her er deklarasjonen på en intern entitet:
<!ENTITY NavnPåEntitet ”Dette er et eksempel på en intern entitet. All
teksten som står innenfor hermetegn vil brukes når vi benytter
entitetsnavnet NavnPåEntitet”>
!ENTITY brukes for å fortelle at her deklareres det en entitet. Videre kommer navnet på selve
entiteten; NavnPåEntitet. Det er dette navnet som skal brukes som innhold i XML-
elementer. Til slutt kommer en tekst innenfor ” … ”. Denne teksten vil benyttes når navnet
NavnPåEntitet brukes i XML-dokumentet.
Det finnes også eksterne entiteter. Teksten vil da ligge i en annen fil:
<!ENTITY NavnPåEksternEntitet SYSTEM
”http://www.aitel.hist.no/fag/xml/lukket/lek04/entitetEks.txt”>
Navnet på denne entiteten er NavnPåEksternEntitet. Videre har vi ordet SYSTEM. Det
forteller XML-prosessoren at dette er en ekstern entitet, og at innholdet ligger på URI’en som
Mer om oppbyning av XML-dokument side 3 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
kommer rett etter ordet SYSTEM. URI’en her er filen entitetEks.txt. Innholdet i denne filen
kan være (filen er ikke opprettet, den brukes bare som eksempel):
Dette er et eksempel på en ekstern entitet. All teksten i dette dokumentet
vil bli skrevet inn når vi bruker navnet NavnPåEksternEntitet.
Entitetsreferanse
For å bruke entitetene som er opprettet over, benytter vi samme fremgangsmåte som vi så i
kapittel 1.5.1 i forrige leksjon. Det vil si at vi skriver & foran navnet og ; etter navnet:
&NavnPåEntitet;
Det samme gjelder for eksterne entiteter:
&NavnPåEksternEntitet;
Bruk av entiteter i XML-dokumenter
Over har vi sett på de ulike delene som trengs ved entiteter separat. For å bruke dem i et
XML-dokument må selve entitetsdeklarasjonen legges i et spesielt element:
<!DOCTYPE NavnPåRotElement [ … ]>
Dette er måten en DTD lages. Mer om dette oppsettet vil kommer i leksjonen om DTD.
Foreløpig trenger du bare å vite at entitetsdeklarasjoner må legges inn i et slikt element.
For å samle sammen disse delene kan vi vise et eksempel hvor vi lager en entitet og bruker
den i et element:
<?xml version="1.0" encoding=”ISO-8859-1”?>
<!DOCTYPE skole [
<!ENTITY HIST "Høgskolen i Sør-Trøndelag">
]>
<skole>&HIST;</skole>
XML-dokumentet kan nå åpnes i en nettleser. I Internet Explorer vil det se ut som:
Mens i Netscape Navigator:
Mer om oppbyning av XML-dokument side 4 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
I begge nettleserne er teksten HIST byttet ut med hele teksten Høgskolen i Sør-Trøndelag
akkurat som spesifisert i entiteten.
Bokstavene æ, ø og å
I leksjon 1 så vi på hvordan vi kan bruke ulike ”ulovlige tegn” ved å bruke forhåndsdefinerte
navn eller tegnverdier. Disse forhåndsdefinerte navnene var egentlig entiteter som allerede
ligger i XML-standarden. Det er også mulig å lage egne entiteter. Dette kan være nyttig for
våre særnorske tegn; æ, ø og å. En må vite Unicode-tegnverdien for disse bokstavene, og
under er verdiene (forskjell på store og små bokstaver) listet opp:
Tegn Tegnverdi Tegn Tegnverdi
æ 230 Æ 198
ø 248 Ø 216
å 229 Å 197
Tegnverdiene kan brukes direkte som innhold i elementene i XML-dokumentet. Det vil si
med &# foran tegnverdien og ; etter. Teksten:
æ ø Å
blir:
æ ø Å
Og Høgskolen i Sør-Trøndelag blir dermed:
Høgskolen i Sør-Trøndelag
Disse tegnverdiene kan du bruke som innhold i XML-elementer. Slike tegnverdier i teksten
kan både være vanskelig å lese, og ikke minst vanskelige å huske. Av den grunn skal vi nå
opprette entiteter for disse verdiene.
Her vises et XML-dokument hvor de 6 tegnene er lagd som entiteter:
<?xml version="1.0"?>
<!DOCTYPE test [
<!ENTITY ae "æ">
<!ENTITY oe "ø">
<!ENTITY aa "å">
<!ENTITY AE "Æ">
<!ENTITY OE "Ø">
<!ENTITY AA "Å">
]>
<test>&ae; &oe; &AA; H&oe;gskolen i S&oe;r-Tr&oe;ndelag
</test>
Mer om oppbyning av XML-dokument side 5 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
1.3. Prosessorinstruksjoner
Prosessorinstruksjoner brukes for å formidle beskjeder til applikasjonen som skal bruke
XML-dokumentet. XML-parseren forholder seg ikke til prosessorinstruksjonene, den sender
dem bare videre. Hva som gjøres med dem, avhenger av hvilken applikasjon som får dem. I
dette kurset bruker vi mest nettlesere som applikasjon, men det kan også være mange andre
programmer som bruker XML-dokumenter. Vi kommer i dette kurset til å bruke
prosessorinstruksjoner for å styre hvordan XML-dokumentet vises.
Til nå har vi sett på to ulike prosessorinstruksjoner (de to vanligste). Den første er XML-
deklarasjonen i starten av prologen:
<?xml version=”1.0”?>
Dette er en spesiell form for prosessorinstruksjon for å fortelle at dokumentet er et XML-
dokument (den blir ofte ikke sett på som en prosessorinstruksjon). Den andre
prosessorinstruksjonen brukes for å legge til et stilark, og skal også ligger i prologen:
<?xml-stylesheet type=”text/css” href=”Boksamling.css”?>
Nettleseren, eller en annen applikasjon, vet da at stilarket Boksamling.css skal brukes for å
vise frem dataene i XML-dokumentet.
En prosessorinstruksjon skrives på følgende form:
<?program kommando ?>
<? forteller at dette er starten på en prosessorinstruksjon. program er den applikasjonen
kommandoen sendes til, og kommando er hva som skal gjøres. Merk at vi ikke kan ha
mellomrom eller andre whitespace-tegn mellom ? og program. Selve navnet på programmet
må skrives med små bokstaver.
I dette kurset vil det være programmene xml og xml-stylesheet (se over) som brukes. Vil
samtidig gjøre oppmerksom på at det finnes mange andre. I følgende eksempel blir begge
prosessorinstruksjonene brukt:
<?xml version="1.0"?>
<?xml-stylesheet type=”text/css” href=”Boksamling.css”?>
<boksamling>
<bok>
<tittel>XML Content and Data</tittel>
<forfatter>Kelly Carey</forfatter>
<forfatter>Stanko Blatnik</forfatter>
<sider>408</sider>
<pris>410 kroner</pris>
</bok>
<bok>
<tittel>Programmering i Java</tittel>
<forfatter>Else Lervik</forfatter>
<forfatter>Vegard Havdal</forfatter>
<sider>795</sider>
<pris>528 kroner</pris>
</bok>
</boksamling>
Mer om oppbyning av XML-dokument side 6 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
1.4. Navnerom
Hvis XML-data kombineres fra flere kilder, kan det resultere i navnekonflikter for elementer
og attributter. Tenk deg to XML-dokumenter, hvor en inneholder en boksamling mens den
andre inneholder en cd-samling. Her er boksamlingen:
<?xml version=”1.0”?>
<samling>
<post>
<tittel>The Adventures og Huckleberry Finn</tittel>
<forfatter>Mark Twain</forfatter>
<pris>350kr</pris>
</post>
… <!-- Flere poster -->
</samling>
og her er cd-samlingen:
<?xml version=”1.0”?>
<samling>
<post>
<tittel>Violin Concerto in D</tittel>
<komponist>Beethoven</komponist>
<pris>430kr</pris>
</post>
… <!-- Flere poster -->
</samling>
I disse to dokumentene er det brukt mange av de samme elementene; samling, post ol. Hvis
disse to XML-dokumentene slås sammen til et XML-dokument, vil det oppstå problemer med
elementnavnene som er like. Applikasjonen som leser XML-dokumentet vil for eksempel
ikke kunne skille mellom en bok-post og en cd-post (post-elementet). Dette gjelder også for
tittel og pris elementene. Det finnes to alternativer for å løse dette. Enten å skrive om hele
XML-dokumentet, eller å benytte navnerom (namespace). Navnerom skiller mellom ulike
typer elementer med samme navn ved å gi dem separate navnerom. Det første som må gjøres
er å definere navnerommet. Det gjøres som regel i rotelementet, men kan også gjøres i andre
elementers startmerke. Følgende attributt legges i rotelementet:
xmlns:bok=”http://www.mjyOnline.com/books”
Her defineres et navnerom ved bruk av xmlns (XML namespace), for så å gi dette
navnerommet et navn, bok (kalles et prefiks). Deretter gir vi attributtet en verdi;
”http://www.mjyOnline.com/books”. Denne verdien skal være en URI. Det trenger ikke
være noen informasjon på denne URI’en. URI brukes bare fordi det er en unik identifikator.
For å bruke dette navnerommet, settes prefikset bok foran elementnavnet:
<bok:tittel>
Nå vil dette tittel-elementet tilhør navnerommet bok.
Mer om oppbyning av XML-dokument side 7 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
Eksempelet under viser det samlede XML-dokumentet fra tidligere, men nå med bruk av
navnerom:
<?xml version=”1.0”?>
<samling
xmlns:bok=”http://www.mjyOnline.com/books”
xmlns:cd=”http://www.mjyOnline.com/cds”>
<bok:post>
<bok:tittel>The Adventures og Huckleberry Finn</bok:tittel>
<bok:forfatter>Mark Twain</bok:forfatter>
<bok:pris>350kr</bok:pris>
</bok:post>
<cd:post>
<cd:tittel>Violin Concerto in D</cd:tittel>
<cd:komponist>Beethoven</cd:komponist>
<cd:pris>430kr</cd:pris>
</cd:post>
… <!-- Flere poster -->
</samling>
Nå vil XML-applikasjonen som leser dokumentet skille mellom bok-elementer og cd-
elementer.
Det er også mulig å sette et navnerom som default. Dermed slipper vi å benytte et prefiks, og
alle elementer som ikke bruker et prefiks i XML-dokumentet hører til dette default
navnerommet. Det eneste du trenger å gjøre er å ta bort selve prefikset:
<samling
xmlns=”http://www.mjyOnline.com/books”
xmlns:cd=”http://www.mjyOnline.com/cds”>
Her har vi tatt bort prefikset for bok-elementene. Dermed vil alle elementer som ikke benytter
et prefiks, høre til dette bok-navnerommet.
Navnerom brukes i forbindelse med mange av de andre standardene som hører til XML. For
eksempel XSLT og XML-skjema som vi kommer tilbake til i senere leksjoner. I den
forbindelse brukes navnerom for å fortelle XML-prosessoren hvordan de ulike elementene
skal tolkes. For XSLT brukes en bestemt URI, og XML-prosessoren vet hva det vil si.
Mer om oppbyning av XML-dokument side 8 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
1.5. Den hierarkiske strukturen til XML
Store deler av kap 2 i læreboken1 tar for seg hvordan man bør planlegge strukturen på dataene
helt fra bunnen av. Hver del i prosessen er godt forklart. Dette kan være nyttig for deg hvis du
skal jobbe en del med XML-dokumenter. Du vil også ha utbyttet av det når du skal begynne å
strukturere dine egne XML-dokumenter i dette kurset. Les derfor gjennom kapittelet i boken.
I resten av denne leksjonen vil det komme noe om oppsett av XML-dokumenter som du vil
trenge i fortsettelsen.
Nå skal vi se på en del egenskaper rundt den hierarkiske strukturen til et XML-dokumenter.
Vi begynner med å definere ordet dokumenttre. Dokumenttre brukes for å beskrive den
hierarkiske strukturen til XML-dokumenter. Et dokumenttre består av en rotnode med flere
barneelementer. Den kan ha uendelig mange noder. Hver barnenode kan ha ulikt antall noder
under seg.
Dokumenttreet kaller vi også for et foreldre-barne hierarki, med en foreldrenode, og mange
barnenoder. Her er en figur som viser sammenhengen mellom de ulike nodene:
Et slikt dokumenttre kan blant annet brukes til å planlegge, organisere og aksessere data. Ved
å sette opp et tre på denne måten blir det enklere å navigere mellom nodene og å manipulere
dataene som ligger i nodene. Det er denne hierarkiske strukturen som DOM (Document
Object Model) og XSLT utnytter. DOM og XSLT omtales i egne leksjoner senere i kurset.
1 "XML Primer Plus" av Nicholas Chase (2003) , eller "Beginning XML" av David Hunter m.fl.(2007).
Søsken Søsken
Barn
Barn Barn Barn Barn Barn
Barn
Foreldre
Søsken
Mer om oppbyning av XML-dokument side 9 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
Eksempel
Tenk deg et XML-dokument som lagrer data om flere personer. For hver person har man
ulike informasjoner. For Ola har man kanskje informasjon om 2 telefonnr og en e-
postadresse. Mens for Kari har man et telefonnr, et faksnr og to e-postadresser. Dette betyr at
det kreves ulike elementer for å lagre informasjon om de to personene. Se på eksempelet her:
<?xml version="1.0"?>
<personregister>
<person>
<navn>
<fornavn>Ola</fornavn>
<etternavn>Nordmann</etternavn>
</navn>
<telefon>99998888</telefon>
<telefon>70707070</telefon>
<epost>[email protected]</epost>
</person>
<person>
<navn>
<fornavn>Kari</fornavn>
<mellomnavn>Larsen</mellomnavn>
<etternavn>Nordmann</etternavn>
</navn>
<telefon>70707070</telefon>
<faks>89898989</faks>
<epost>[email protected]</epost>
<epost>[email protected]</epost>
</person>
</personregister>
Her ser du at for Ola er det registrert to telefon-elementer, mens Kari har ett. Men Kari har
et faks-element i tillegg. Det lagres altså bare den informasjonen som trengs for hver person.
Dersom vi mangler en opplysningen på en person, for eksempel telefonnr, så lar vi være å
sette opp dette elementet.
Etter hvert vil vi komme inn på DTD og XML-skjema som begrenser hvilke elementer som
kan brukes og hvor de kan brukes.
Mer om oppbyning av XML-dokument side 10 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
Vi kan nå lage et dokumenttre av XML-dokumentet over (tar bare med en person på grunn av
plassen):
Her ser du at person-elementet er et barneelement til personregister-elementet. Videre har
person-elementet flere underliggende barneelementer. Elementene navn og epost kaller vi
søskenelementer.
Når man begynner å lage XML-dokumenter har man en tendens til å lage veldig flate filer.
Med det menes filer som har få nivåer av elementer. I eksemplet over ville du kanskje ikke
hatt med navn-elementet, men heller skrevet alle elementene som inneholder informasjon
direkte under person-elementet. Her ser du hvordan et slikt XML-dokument kan se ut:
<?xml version="1.0"?>
<personregister>
<person>
<fornavn>Ola</fornavn>
<etternavn>Nordmann</etternavn>
<telefon>99998888</telefon>
<telefon>70707070</telefon>
<epost>[email protected]</epost>
</person>
<person>
<fornavn>Kari</fornavn>
<mellomnavn>Larsen</mellomnavn>
<etternavn>Nordmann</etternavn>
<telefon>70707070</telefon>
<faks>89898989</faks>
<fornavn> <etternavn>
…..
<person>
<navn> <telefon> <telefon> <epost>
<person>
<personregister>
99998888 70707070 [email protected]
Ola Nordmann
Mer om oppbyning av XML-dokument side 11 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
<epost>[email protected]</epost>
<epost>[email protected]</epost>
</person>
</personregister>
Selv om dette er et velformet dokument, kan det være mindre effektivt ved datamanipulering.
Foreløpig vil det være vanskelig å tenke seg hvordan dette blir mindre effektivt, men det vil
komme etter hvert. Det som er viktig å merke seg er hvordan brukerne skal aksessere og
bruke dataene. Tenk på hvordan du strukturerer dokumentet og vær ikke er redd for å bruke
noen ekstra elementer for å få en bedre struktur (som et ekstra navn-element).
1.6. XML Parsere
En parser er et verktøy som analyserer et XML-dokument og sjekker om syntaksen er korrekt.
For at du skal få en bedre forståelse av hvordan et XML-dokument leses av et program, skal
vi se på hvordan en parser fungerer.
Det finnes to typer parsere:
1. Ikke-validerende parsere. Sjekker bare om XML-dokumentet er velformet.
2. Validerende parsere. I tillegg til å sjekke om XML-dokumentet er velformet, sjekkes det
også om det er i henhold til en DTD (Document Type Definition) eller et XML-skjema.
Parsere sjekker kun syntaksen til XML-dokumentet. Den tar ikke hensyn til om selve
strukturen du har brukt er god. Den bryr seg heller ikke om selve innholdet i dokumentet.
Når en parser sjekker et XML-dokument, begynner den på toppen av XML-dokumentet for å
finne det første elementet (som regel i prologen). Her sjekker den om elementet har rett
syntaks. Hvis den finner en feil på elementet, skriver den ut en feilmelding og parsingen
stopper. Når brukeren har rettet opp feilen kan vi fortsette med parsingen. Parseren kjører da
til den finner en ny feil. Når et element ikke inneholder flere feil, lagres informasjon om
nodetypen i en tabell, før parseren fortsetter med neste element. Når parseren sjekker et
element med barnenoder, så sjekkes alle barnenodene før den går videre til neste søskennode.
Når parseren har kommet gjennom hele dokumentet og det ikke er flere feil (altså XML-
dokumentet er velformet), lages et parser tre. Treet blir sendt videre til XML-prosessoren.
Dermed kan prosessoren behandle treet som det ønsker.
For validerende parsere må det i tillegg sjekkes om elementene i XML-dokumentet er i
henhold til en DTD. Parseren har da to alternative fremgangsmåter. Den kan enten bygge en
logisk struktur ut av DTD-en og sammenligne denne med strukturen i dokumentet.
Alternativet er å gå gjennom XML-dokumentet enda en gang etter at syntaksen er sjekket, for
å sammenligne et og et element med DTD-en.
Det som er beskrevet over kalles en trebasert parser. Det finnes også noe som heter
hendelsesbasert parsere. Det vil vi ikke gå inn på her.
Når XML-dokument åpnes i en nettleser, vil nettleseren først parse XML-dokumentet (en
ikke-validerende parsing) før det vises. Det er derfor feilmelding vises i nettleseren når XML-
dokumentet ditt ikke er velformet.
Mer om oppbyning av XML-dokument side 12 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
1.7. Modellering
Målet med dette kapitlet er å få deg til å tenke over hvordan du strukturer XML-dokumentet
ditt. Det som er viktig før du begynner å lage et XML-dokument, er å tenke over hva som skal
gjøres med dataene som legges i XML-dokumentet.
Tenk deg at du skal lagre flere opplysninger om personer. Det kan i utgangspunktet høres
greit ut. Det første en må ta hensyn til er hvilke data som er viktig. Som oftest bestemmes
dette ut i fra hvordan XML-dokumentet skal bruke. Det vil være stor forskjell på om XML-
dokumentet skal brukes som en gjesteliste til et hotell eller om det er et politiregister som
inneholder et strafferegister. Det vil være ulike opplysninger som vektlegges, og en må ta
hensyn til hvilke opplysninger en får tilgang til. Dette påvirker hva som skal settes opp i
XML-dokumentet.
Det er viktig hvordan selve dataene lagres i elementene. Vi har følgende XML-dokument over
datamaskinprodukter med priser:
<varelager>
<produkt>
<navn>PC skjerm</navn>
<pris>2500 kr</pris>
</produkt>
<produkt>
<navn>Harddisk</navn>
<pris>1400 kr</pris>
</produkt>
</varelager>
Kan vi nå utvide programmet som leser dette XML-dokumentet til å legge sammen prisene?
Innholdet i elementene er en tekststreng og en kan ikke gjøre om teksten 2500 kr til et tall.
Samtidig kan vi ikke bare fjerne kr, siden vi da ikke vet hvilken valuta prisen er oppgitt i.
Dette kan løses ved å legge til et attributt til pris-elementet som forteller hvilken valuta det
var snakk om:
<varelager>
<produkt>
<navn>PC skjerm</navn>
<pris valuta=”kr”>2500</pris>
</produkt>
<produkt>
<navn>Harddisk</navn>
<pris valuta=”kr”>1400</pris>
</produkt>
</varelager>
Nå kan vi utføre matematiske operasjoner på prisen, fordi teksten 2500 kan gjøres om til et
tall. Samtidig vet vi hvilken valuta det er snakk om. Her ser dere altså et område hvor
attributter absolutt trengs.
Mer om oppbyning av XML-dokument side 13 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
Et annet eksempel er registrering av flere opplysninger om en person. Vi hadde følgende
XML-dokument (dårlig modellert i forhold til hva vi trenger):
<?xml version="1.0"?>
<personregister>
<person>
<fornavn>Ola</fornavn>
<etternavn>Nordmann</etternavn>
<telefon>99998888</telefon>
<telefon>70707070</telefon>
<telefon>73737373</telefon>
<epost>[email protected]</epost>
<epost>[email protected]</epost>
</person>
</personregister>
Her ser du at vi har lagt til noen flere opplysninger fra eksemplet over. Men nå er det ikke så
greit å vite hvor de ulike telefonnr og e-postadressene gjelder. Noen av dem er private og
noen er til jobben. Dette burde vært spesifisert nærmere. Da kan vi enten legge til attributt
med kontaktinformasjon, eller vi kan legge til et nytt element som skiller mellom
kontaktinformasjon hjemme og til jobben:
<?xml version="1.0"?>
<personregister>
<person>
<fornavn>Ola</fornavn>
<etternavn>Nordmann</etternavn>
<telefon type=”hjem”>99998888</telefon>
<telefon type=”hjem”>70707070</telefon>
<telefon type=”jobb”>73737373</telefon>
<epost type=”jobb”>[email protected]</epost>
<epost type=”hjem”>[email protected]</epost>
</person>
</personregister>
eller:
<?xml version="1.0"?>
<personregister>
<person>
<fornavn>Ola</fornavn>
<etternavn>Nordmann</etternavn>
<kontakt type=”hjem”>
<telefon>99998888</telefon>
<telefon>70707070</telefon>
<epost>[email protected]</epost>
</kontakt>
<kontakt type=”jobb”>
<telefon>73737373</telefon>
<epost>[email protected]</epost>
</kontakt>
</person>
</personregister>
Mer om oppbyning av XML-dokument side 14 av 14
Opphavsrett: Forfatter og Stiftelsen TISIP
Her ser du at det er flere måter å modellere dette på. Det viktigst er at du tenker over hvilke
programmer som skal lese dataene og hvordan de er kommer til å lese dem. Så modellerer du
ut i fra det.