HUMIT1731 Hypermedier

Transkript

1 HUMIT1731 Hypermedier Introduksjon til Extensible Markup Language (XML) XML-dokumentet XML-dokumentet består av ren tekst og kan følgelig leses av mennesker. Dette er for så vidt et viktig moment all den tid man da "alltid" vil kunne bruke innholdet på en meningsfull måte. Dette i motsetning til f.eks. det binære Word-formatet som enten krever tekstbehandlingsprogrammet selv for å kunne nyttiggjøres - evt. et konverteringsprogram som gir oss innholdet i klartekst. I denne sammenheng må det også understrekes at til forskjell fra bl.a. tekstbehandlingsprogram, så er det et hovedpoeng ved XML å skille mellom innhold/struktur og f.eks. layout. HUMIT1731 uke42 Kåre A. Andersen 2 Eksempel 2.1: Et meget enkelt XML-dokument, lagret som filen eks2_1.xml <bok> Elementer Dokumentet i eks. 2.1 består av fire elementer: bok, forfatter, tittel og isbn. De fleste vil umiddelbart forstå og kunne behandle informasjonen/innholdet i dokumentet all den tid navnene på taggene er selvforklarende. I eksemplet er altså bok et XML-navn mens start-taggen utgjøres av <bok>. Tilsvarende slutt-tagg er. Mellom disse taggene finner vi elementets innhold - på engelsk blir alt som står mellom start- og slutt-tagg betegnet character data. Taggene har en syntaks som vi kjenner igjen fra bl.a. HTML: tegnet < innleder start-taggen mens slutt-taggen må ha </ først. Begge avsluttes med >. Hvis et element er tomt, kan vi sløyfe slutt-taggen og heller skrive <tittel />. Dette gjelder f.eks. <hr> og <br> i et XHTML-dokument. Her kan vi altså bruke <hr /> og <br /> som erstatning for <hr></hr> og <br></br> Til slutt skal bare nevnes at XML skiller mellom store og små bokstaver: <bok> er forskjellig fra <BOK> og <Bok>. Alle tre alternativer er lovlige (i motsetning til XHTML, som bare godtar små bokstaver), men i forbindelse med elementnavn må selvfølgelig start- og slutt-tagg være like: <Bok> og </Bok>. Vi vil forsøke å gjennomføre små bokstaver i elementnavn. HUMIT1731 uke42 Kåre A. Andersen 3 HUMIT1731 uke42 Kåre A. Andersen 4 XML-navn XML-trær Hvilke tegn er så lovlige i elementnavn? I Norge er vi tradisjonelt forsiktige med å bl.a. bruke æ, ø og å i slike sammenhenger - for å være på den sikre side anvender vi oftest de engelske bokstavene. I eks. 2.1 kan vi tenke oss et ekstra element for utgivelsesår og et "safe" valg kan være <aar>. XML tillater imidlertid også <år>, ja faktisk også ideogrammer. Dette er nettopp for å garantere språk- og systemuavhengighet. (Erfaring med ulike parsere/nettlesere tilsier imidlertid at vi i kanskje bør unngå norske tegn i XML-navn?) Holder vi oss til hovedreglene, er det lettere å si hvilke tegn som ikke får være med i XML-navn: apostrof, anførselstegn, dollar, prosent og semikolon. I tillegg er det krav om at tall, bindestrek og punktum ikke må innlede et XML-navn. Over har vi dels snakket om elementnavn, dels brukt betegnelsen XML-navn. Faktum er at navnereglene gjelder generelt i XML-sammenheng - i elementnavn, attributtnavn m.m. Fellesbetegnelsen på disse og andre mer generelle konstruksjoner er altså XML-navn. Eksempel 2.1 viser at elementet bok inneholder tre underelementer forfatter, tittel og isbn. Bok-elementet blir vanligvis betegnet forelder til de tre andre - som i sin tur altså blir barn av bok. Skal vi holde oss til familiemetaforen, blir også forfatter, tittel og isbn søsken-elementer. Imidlertid, til forskjell fra i virkeligheten: et barn-element han bare ha en forelder. I eksemplet er bok også det ytterste elementet - det som omslutter hele dokumentet. Vi snakker om dokument-elementet eller mer vanlig rot-elementet. Vi skal senere se at for at et XML-dokument skal være velformet, så må det ha ett og bare ett rot-element. Med en slik oppbygging vil alle XML-dokumenter kunne sees på som en tre-struktur. HUMIT1731 uke42 Kåre A. Andersen 5 HUMIT1731 uke42 Kåre A. Andersen 6

2 Innhold: data-orientert eller dokument-orientert. Vårt bok-dokument har et innhold som lett forbindes med en bok-database. Vi kan imidlertid godt blande inn mer prosatekst i et XML-dokument. Elementet litteraturhistorie er et eksempel på blandet innhold (mixed content). Selv om det er mer komplisert å nyttiggjøre seg informasjonen i slike "fortellende" XMLdokumenter, er de likevel et bevis på XMLs store fleksibilitet. Eksempel 2.2: Et XML-dokument med blandet innhold (mixed content). <litteraturhistorie> I perioden finner vi flere store forfattere. <forfatter fodt="1832" dod="1910"> <fnavn>bjørnstjerne</fnavn> <enavn>bjørnson</enavn></forfatter> er en av de mest kjente, men også <forfatter fodt="1813" dod="1895"> <fnavn>camilla</fnavn> <enavn>collett</enavn></forfatter> ga viktige bidrag, som f.eks. <romantittel>amtmannens Døttre</romantittel>. Denne boka er blitt kalt vår første <sjanger>tendensroman</sjanger>. <forfatter fodt="1813" dod="1896"><fnavn>ivar</fnavn> <enavn>aasen</enavn> </forfatter> er vel mest kjent for sine bidrag til <fag>språkvitenskapen</fag>, men mange vil kanskje helst minnes ham som forfatter av det kjente <sjanger>dikt</sjanger>et <dikttittel>"millom bakkar og berg..."</dikttittel>? </litteraturhistorie> eks2_2.xml m/stilark: eks2_2css.xml (Stilarkfil) HUMIT1731 uke42 Kåre A. Andersen 7 HUMIT1731 uke42 Kåre A. Andersen 8 Attributter Fra HTML vet vi at ulike HTML-elementer også kan ha attributter. F.eks. kan vi endre bakgrunnsfarge i et dokument ved å endre color-attributtet i body-elementet: <body color="yellow"> Et tilsvarende mønster finnes i XML, og vi har brukt noen allerede: <forfatter fodt="1813" dod="1896">. Legg merke til at attributtverdier i XML alltid omgis av anførselstegn - enkle eller doble. Blanke tegn rundt f.eks. = er valgfritt. På denne bakgrunn kan vi kanskje utvide vårt bokeksempel til følgende: Eksempel 2.3: Et utvidet XMLdokument. <bok id= _1" sjanger="lyrikk" regdato=" "> <tittel>i utval ved Magne Myhren</tittel> <aar>1980</aar> <sted>oslo</sted> <merknad></merknad> Fil: eks2_3.xml HUMIT1731 uke42 Kåre A. Andersen 9 HUMIT1731 uke42 Kåre A. Andersen 10 Element vs. attributt Her har vi tre attributter: id, sjanger og regdato med tilhørende verdier. Noen vil kanskje spørre om hvorfor ikke i det minste sjangeropplysninger kan angis som eget element: <sjanger>lyrikk</sjanger>. Svaret er ikke absolutt: noen ganger passer det best å bruke et eget element, mens det i andre sammenhenger er mest naturlig å utnytte de muligheter som attributt-konstruksjonen gir. Bl.a. kan det i noen applikasjoner være lettere å få tak i og tolke attributtverdier, men som sagt - det finnes ingen fasitløsning. I vårt tilfelle virker det mest naturlig å plassere all tilleggsinformasjon i attributter? Entiteter Som en forstår er bl.a. tegnet < reservert i XML. Det betyr at vi må ha mekanismer som skiller bruk av < i element-innholdet fra < som del av start-tagger. Løsningen er såkalte entiteter. Har man bruk for <, må man bruke konstruksjonen <. Tilsvarende har vi > (>) & (&) " (") og &apos; ('). Av disse fem entitetene er det bare < og & som er obligatoriske. HUMIT1731 uke42 Kåre A. Andersen 11 HUMIT1731 uke42 Kåre A. Andersen 12

3 CDATA Vi har altså en mulighet for å erstatte reserverte tegn med entiteter. Bruker man en teksteditor som ikke automatisk kan foreta slike erstatninger, vil det bli svært tungvint å skrive alle spesialkoder for flere tegn. En løsning er da å definere egne CDATA-seksjoner hvor innholdet ikke blir tolket som XML-markup. I denne teksten har vi f.eks. flere ganger hatt behov for å skrive eksemplekode i klartekst. Siden teksten som sådan er et HTML-dokument, må vi/editoren bl.a. erstatte < med <. I XML-sammenheng kan vi enkelt skrive koden i en seksjon som begynner med <![CDATA[ og avsluttes med ]]>. CDATA <![CDATA[ <bok id="1" sjanger="lyrikk" regdato=" "> <tittel>i utval ved Magne Myhren</tittel> <år>1980</år> <sted>oslo</sted> <merknad></merknad> ]]> Vis eksempel... HUMIT1731 uke42 Kåre A. Andersen 13 HUMIT1731 uke42 Kåre A. Andersen 14 Kommentarer Prosesserings-instruksjoner Ønsker man å kommentere XML-koden, brukes samme syntaks som ved HTML-dokumenter: <!-- Dette er en kommentar --> Kommentaren innledes med <!-- og avsluttes med -->. Det betyr at man ikke kan bruke dobbel bindestrek før kommentaren virkelig avsluttes. Det er heller ikke lov å avslutte med tre bindestreker: --->. Siden kommentarer ikke er elementer, kan de godt forekommer utenfor rotelemetet. Noen applikasjoner utnytter innholdet i kommentarene som tilleggsinformasjon til selve prosesseringen. Selv om dette ikke er ulovlig, bør man avstå fra slik bruk av kommmentar-konstruksjonen og heller bruke såkalte prosesseringsinstruksjoner. I HTML-verdenen blir kommentarene brukt til mer enn bare å kommentere. F.eks. utnyttes kommentarer for å skjule javascript-kode for de nettleserne som ikke forstår <script>-taggen: <script language="javascript"> <!-- Skjule for eldre nettlesere document.write("jeg er et JavaScript..."); // slutt på å skjule --> </script> Av og til ser vi også konstruksjoner som muliggjør inkludering av eksterne filer <!--#include file="enfil.txt" --> Poenget er at slike konstruksjoner utnytter sideeffekter ved kommentarene. Noen ganger kan det virke ok, men faren for ulik behandling i i ulike applikasjoner/nettlesere er stor. HUMIT1731 uke42 Kåre A. Andersen 15 HUMIT1731 uke42 Kåre A. Andersen 16 Prosesserings-instruksjoner XML tilbyr et alternativ, nemlig prosesseringsinstruksjoner. Disse innledes med <? og avsluttes med?>, og på samme måte som kommentarene er det ikke snakk om elementer. Følgelig kan også prosesserings-instruksjoner forekomme utenfor rot-elementet. En mye brukt instruksjon er den som forteller nettleseren at et stilark skal benyttes sammen med XML-dokumentet: <?xml-stylesheet type="text/css" href="bok.css"?> Knytte stilark til et XML-dokument vha. prosseseringsinstruks <?xml-stylesheet type="text/css" href="bok.css"?> <bok> HUMIT1731 uke42 Kåre A. Andersen 17 HUMIT1731 uke42 Kåre A. Andersen 18

4 Eks. på stilark XML-deklarasjonen Selve stilarket (bok.css) har dette innholdet: forfatter {display:block; font-size:14pt;} tittel {display:block; font-size:12pt; font-weight:bold; font-style:italic} forlag {display:block; font-size:12pt;} isbn {display:block; font-size:12pt; font-weight:bold} I eksemplene over har vi utelatt selve XMLdeklarasjonen. Dette er ikke ulovlig, men vi bør alltid ha den med. Eksempel 2.1 får da formen: <?xml version="1.0" encoding="iso "?> <bok> HUMIT1731 uke42 Kåre A. Andersen 19 HUMIT1731 uke42 Kåre A. Andersen 20 XML-deklarasjonen encoding Som vi ser inneholder deklarasjonen to attributt-liknende deler. En har fått navnet "encoding" - og som betegnelsen kanskje antyder forteller den parseren hvilket tegnsett som er benyttet. Standardverdien er UTF-8 (Unicode), mens vi ofte har brukt tegnsettet Latin-1. Dette tegnsettet har navnet "ISO " i XML versjon 1.0. standalone Dette "attributtet" har verdien "yes" hvis dokumentet kan prosesseres uten en ekstern DTD. (Mer om DTD senere.) Et velformet (well-formed) XMLdokument Vi kan nå oppsummere de viktigste kravene til et velformet XML-dokument: Enhver start-tagg må ha en korresponderende slutt-tagg (evt. spesialavsluttes som tom tagg). Tagger kan nestes, men ikke overlappe Det må være ett og kun ett rot-element Attributtverdier må settes i anførselstegn Et element kan ikke ha to attributter med samme navn Kommentarer og prosesserings-instruksjoner kan ikke forekomme inne i tagger. < og & kan ikke forekomme i element-innholdet Den enkleste måten å teste om et XML-format er velformet, er å laste det inn i en nettleser som støtter XML. Det finnes også egne parsere som bedre sjekker XML-dokumenter. HUMIT1731 uke42 Kåre A. Andersen 21 HUMIT1731 uke42 Kåre A. Andersen 22 Document Type Definition (DTD) Krav til et gyldig dokument (valid document) Fram til nå har vi kun snakket om et velformet dokument. Kravet til velformethet angår for det meste "overflatiske", syntaktiske forhold som at alle start-tagger må ha en korresponderende slutt-tag, ett rotelement osv. Men vi kan ikke sjekke om visse elementer er til stede, rekkefølgen mellom dem m.m. Skal vi stille slike krav, må vi ha et sett med regler å sjekke mot. Hvis så er tilfelle, er dokumentet ikke bare velformet, det er også gyldig (valid). Altså: et gyldig XML-dokument har en DTD og følger denne. La oss hente fram det meget enkle XML-dokumentet fra eksemple 2.1: <bok> HUMIT1731 uke42 Kåre A. Andersen 23 HUMIT1731 uke42 Kåre A. Andersen 24

5 DTD for bok-dokumentet <!ELEMENT bok ( forfatter, tittel, forlag, isbn ) > <!ELEMENT forfatter ( #PCDATA ) > <!ELEMENT tittel ( #PCDATA ) > <!ELEMENT forlag ( #PCDATA ) > <!ELEMENT isbn ( #PCDATA ) > Element-deklarasjoner Hver linje i eksemplet over er elementdeklarasjoner. En deklarasjon begynner med <! etterfulgt av det reserverte ordet ELEMENT. Deretter følger navnet på elementet før selve elementinnholdet i parenteser. Deklarasjonen avsluttes med >. Rekkefølgen på deklarasjonene er likegyldig, men ofte vil vi begynne med rotelemenetet og fortsette etter den logiske oppbygningen av dokumentet. HUMIT1731 uke42 Kåre A. Andersen 25 HUMIT1731 uke42 Kåre A. Andersen 26 Intern eller ekstern DTD DTD'en kan enten plasseres innledningsvis etter XML-deklarasjonen, men foran rotelementet, eller lagres på en ekstern fil. Det er enklere og raskere å validere et dokument med intern DTD, men ofte bruker vi andres/offentlige DTD'er som ligger på eksterne filer/uri'er Eksempel 3.1 XML-dokument med intern DTD <?xml version="1.0" encoding="utf-8" standalone="yes"?> <!DOCTYPE bok [ <!ELEMENT bok ( forfatter, tittel, forlag, isbn ) > <!ELEMENT forfatter ( #PCDATA ) > <!ELEMENT tittel ( #PCDATA ) > <!ELEMENT forlag ( #PCDATA ) > <!ELEMENT isbn ( #PCDATA ) > ]> <bok> fil: eks3_1.xml HUMIT1731 uke42 Kåre A. Andersen 27 HUMIT1731 uke42 Kåre A. Andersen 28 Document Type Declaration Eksempel 3.2 XML-dokument med ekstern DTD Merk forskjell på Declaration og Definition. Det siste reserveres til forkortelsen DTD, og knyttes til innholdet mellom klamme-parentesene (se nedenfor) i en Document Type Declaration. I eksempel 3.1 har vi f.eks. <!DOCTYPE bok [...]>. Deklarasjonen skal alltid begynne med <! etterfulgt av det reserverte ordet DOCTYPE samt navnet på rotelementet (her bok) i XML-dokumentet. Mellom [] deklareres elementer m.m. hvis DTD'en er intern. Ønsker vi en ekstern DTD, er det bare snakk om at det samme som står mellom parentesene lagres på fil, som f.eks.: bok1.dtd. Filreferansen kan være en fullstendig URL, en relativ URL, men også et enkelt filnavn hvis dokument og DTD ligger i samme katalog. Det reserverte ordet SYSTEM brukes for å markere at DTD'en vi anvender er vår egen - i motsetning til mer kjente/offentlige DTD'er som innledes med PUBLIC etter navnet. <?xml version="1.0" encoding="utf-8" standalone="no"?> <!DOCTYPE bok SYSTEM "bok1.dtd"> <bok> fil: eks3_2.xml HUMIT1731 uke42 Kåre A. Andersen 29 HUMIT1731 uke42 Kåre A. Andersen 30

6 Deklarasjon av elementer Et element deklareres altså slik: <!ELEMENT navn innhold> (punkt 1 og 2 nedenfor) eller <!ELEMENT navn (innholdsmodell) forekomstindikator> (punkt 3-5 nedenfor) hvor navn er et gyldig XML-navn og innhold/innholdsmodell ulike innholdskategorier: Innholdskategorier 1. ANY velformete XML-data uten nærmere spesifisering <!ELEMENT hvasomhelst ANY> 2. EMPTY et element uten innhold (men gjerne med attributter) <!ELEMENT bilde src="bilde.jpg" bredde="150" hoyde="100" EMPTY> 3. Ren tekst Benevnt PCDATA (parsed character data) <!ELEMENT forfatter (#PCDATA)> 4. Elementer kun andre elementer <!ELEMENT bok (forfatter, tittel, år, isbn) > 5. Blandet innhold elementer er blandet med vanlig tekst. <!ELEMENT litteraturhistorie ( #PCDATA dikttittel fagområde forfatter romantittel sjanger )* > HUMIT1731 uke42 Kåre A. Andersen 31 HUMIT1731 uke42 Kåre A. Andersen 32 Innholdsmodell (content model) og grupppebinderne (, og ) Punkt 3 i lista over sier bare at elementet forfatter må bestå av "ren" tekst. Når derimot et element har element-barn, må også disse angis i modellen. I dette tilfellet ramser vi opp forfatter, tittel, år og isbn i parentes. Deklarasjonen forteller at bok må inneholde de fire elementene nevnt - og i oppgitt rekkefølge! Komma mellom elementene angir kravet til rekkefølge, mens en vertikal strek ( ) representerer "eller"- altså: (forlag år isbn) - betyr forlag eller år eller isbn. Et problem oppstår hvis vi åpner for "ingen eller flere" av disse elementene, men en løsning kan være: <!ELEMENT bok (forfatter, tittel, (forlag år isbn)*) > Merk at vi kan bruke ekstra parenteser for å lage mer kompliserte innholdsmodeller. Forekomstindikatorer Legg merke til at vi bruker en stjerne for å angi "null eller flere forekomster. Hadde vi utelatt *, så måtte forlag, år eller isbn ha forekommet én gang etter tittel. Det finnes også to andre forekomstindikatorer? og +. Altså:? Null eller èn forekomst av elementet * Null elle flere forekomster av elementet + Én eller flere forekomster av elementet HUMIT1731 uke42 Kåre A. Andersen 33 HUMIT1731 uke42 Kåre A. Andersen 34 Eksempel 3.3: Et utvidet XMLdokument m/intern DTD. Attributter <!DOCTYPE bok [ <!ELEMENT bok ( forfatter, tittel+, (forlag år sted isbn)*, merknad? ) > <!ATTLIST bok bokid ID #REQUIRED > <!ATTLIST bok regdato NMTOKEN #REQUIRED > <!ATTLIST bok sjanger NMTOKEN #REQUIRED > <!ELEMENT forfatter ( #PCDATA ) > <!ELEMENT tittel ( #PCDATA ) > <!ELEMENT forlag ( #PCDATA ) > <!ELEMENT år ( #PCDATA ) > <!ELEMENT sted ( #PCDATA ) > <!ELEMENT isbn ( #PCDATA ) > <!ELEMENT merknad ( #PCDATA ) > ]> <bok bokid="_1" sjanger="lyrikk" regdato=" "> <tittel>millom bakkar og berg</tittel> <tittel>i utval ved Magne Myhren</tittel> <år>1980</år> <sted>oslo</sted> <merknad></merknad> Fil: eks3_3.xml Først skal vi bare kommentere tittel-elementet. I deklarasjonen over står det tittel+. Det betyr at tittel må forekomme en eller flere ganger for hver bok. Nå viser det seg at ingen bøker har mer enn to titler: hoved- og undertittel (se eks. 3.3). Èn løsning kunne vært å lage et element for hver titteltype- f.eks. htittel og utittel. En annen løsning, hvis vi bare ønsker maksimalt to tittel-elementer, kan være denne deklarasjonen: <!ELEMENT bok ( forfatter, tittel, tittel?, (forlag år sted isbn)*, merknad? ) > Her må en tittel etterfølges av "null eller ingen" tittel - som vi jo ønsket... HUMIT1731 uke42 Kåre A. Andersen 35 HUMIT1731 uke42 Kåre A. Andersen 36

7 Attributter I vårt eksempel er det bare bok-elementet som har attributter, nemlig bokid, sjanger og regdato. De to siste av type NMTOKEN, og vi forstår kanskje at begge må være til stede: #REQUIRED. På samme måte som for elementer, må også attributtene deklareres - i en ATTLIST. Syntaksen er slik: <!ATTLIST elementnavn attributtnavn type startbetingelser attributtnavn type startbetingelser attributtnavn type startbetingelser... > Dette gir best oversikt, men vi kan også angi en ny ATTLIST for hvert attributt til samme element: <!ATTLIST bok bokid ID #REQUIRED > <!ATTLIST bok regdato NMTOKEN #REQUIRED > <!ATTLIST bok sjanger NMTOKEN #REQUIRED > Attributter Den mest vanlige deklarasjonen er som denne: <!ATTLIST bok omboka CDATA "Ikke så verst"> Attributtet omboka kan inneholde vanlig tekst (CDATA) og får her startverdien "Ikke så verst". Ofte vil vi angi andre betingelser til attributtet enn en startverdi. Her bruker vi noen reserverte ord: #REQUIRED Attributtet må finnes i alle forekomster av elementet og må bli tildelt en lovlig verdi. Ingen startverdi. #IMPLIED Attributtet er valgfritt. Ingen startverdi. #FIXED Attributtet er valgfritt, men hvis det finnes må det ha oppgitt startverdi. F.eks. <!ATTLIST dataprogram versjon CDATA #FIXED "1.0"> Elementet dataprogram har et attributt versjon av type CDATA og hvis versjonsnummer er angitt, så må det være 1.0. En annen verdi vil være ulovlig. HUMIT1731 uke42 Kåre A. Andersen 37 HUMIT1731 uke42 Kåre A. Andersen 38 Attributtyper CDATA Attributtverdien er en vanlig tekststreng, dvs. tekst som er godkjent i et velformet dokument. NMTOKEN Samme type som XML-navn, men verdien kan også innledes med f.eks. punktum (.) og kolon (:). NMTOKENS NMTOKEN kan ikke inneholde blanke tegn. Det gjør derimot NMTOKENS. Attributtyper Oppramsingsvedier (enumerated values) Ønsker vi å angi at et attributt kan ha en av flere verdier: <!ATTLIST manus publisert (stensil trykket web) #REQUIRED> ID <!ATTLIST bok bokid ID #REQUIRED > ID-typen brukes hvis vi ønsker en entydig identifikasjon av et element. Verdien som tilordnes må være unik, men også være et XML-navn. Det siste betyr at vi ikke kan bruke et rent tall som ID fordi XML-navn ikke tillater siffer først. Derimot vil _1 være lovlig. (Se eks. 3.3) HUMIT1731 uke42 Kåre A. Andersen 39 HUMIT1731 uke42 Kåre A. Andersen 40 Attributtyper IDREF Anta følgende utsnitt av et XMLdokument: <bok bokid="b25"> <forfatter>ajar, Emilie</forfatter> <tittel>med livet foran seg</tittel> <oversatt_av oversetternr="o3" /> <oversetter oversetterid="o3"> <navn>anne Ringnes</navn> <har_oversatt boknr="b25" /> </oversetter> En tilhørende attributtliste kan da se slik ut: <!ATTLIST bok bokid ID #REQUIRED > <!ATTLIST oversetter oversetterid ID #REQUIRED > <!ATTLIST oversatt_av oversetternr IDREF #REQUIRED > <!ATTLIST har_oversatt boknr IDREF #REQUIRED > IDREFS Ønsker vi å åpne for at en oversetter skal kunne knyttes til flere bøker, bruker vi IDREFS <oversetter oversetterid="o3"> <navn>anne Ringnes</navn> <har_oversatt boknr="b25 b27 b108" /> </oversetter> <!ATTLIST oversetter oversetterid ID #REQUIRED har_oversatt boknr IDREFS #REQUIRED > HUMIT1731 uke42 Kåre A. Andersen 41 HUMIT1731 uke42 Kåre A. Andersen 42

8 XSL Transformation (XSLT) men det blir neste gang. HUMIT1731 uke42 Kåre A. Andersen 43