1. mer om oppbyning av xml-dokument2.9.2013 lærestoffet er utviklet for faget xml teknologi 1. mer...

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


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



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:



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>



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-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>

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:


<samling>

<post>

<tittel>The Adventures og Huckleberry Finn</tittel>

<forfatter>Mark Twain</forfatter>

<pris>350kr</pris>

</post>

… 

</samling>

og her er cd-samlingen:


<samling>

<post>

<tittel>Violin Concerto in D</tittel>

<komponist>Beethoven</komponist>

<pris>430kr</pris>

</post>


</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.



Eksempelet under viser det samlede XML-dokumentet fra tidligere, men nå med bruk av

navnerom:


<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>


</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.



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



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:


<personregister>

<person>

<navn>

<fornavn>Ola</fornavn>

<etternavn>Nordmann</etternavn>

</navn>

<telefon>99998888</telefon>


<epost>[email protected]</epost>

</person>

<person>

<navn>

<fornavn>Kari</fornavn>

<mellomnavn>Larsen</mellomnavn>


</navn>


<faks>89898989</faks>



</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.



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:


<personregister>

<person>






</person>

<person>

<fornavn>Kari</fornavn>

<mellomnavn>Larsen</mellomnavn>



<faks>89898989</faks>

<fornavn> <etternavn>

…..

<person>

<navn> <telefon> <telefon> <epost>

<person>

<personregister>

99998888 70707070 [email protected]

Ola Nordmann





</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.



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.



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):


<personregister>

<person>








</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:


<personregister>

<person>



<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:


<personregister>

<person>



<kontakt type=”hjem”>




</kontakt>

<kontakt type=”jobb”>



</kontakt>

</person>

</personregister>



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.

1. mer om oppbyning av xml-dokument2.9.2013 lærestoffet er utviklet for faget xml teknologi 1. mer...

Documents