430 likes | 583 Views
HUMIT1731 Hypermedier. Introduksjon til Extensible Markup Language (XML). 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.
E N D
HUMIT1731 Hypermedier Introduksjon til Extensible Markup Language (XML)
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. XML-dokumentet Kåre A. Andersen
Eksempel 2.1: Et meget enkelt XML-dokument, lagret som filen eks2_1.xml <bok> <forfatter>Aasen, Ivar</forfatter> <tittel>Millom bakkar og berg</tittel> <isbn>82-525-0298-9</isbn> </bok> Kåre A. Andersen
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 </bok>. 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. Kåre A. Andersen
XML-navn • 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. Kåre A. Andersen
XML-trær • 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. Kåre A. Andersen
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" XML-dokumenter, er de likevel et bevis på XMLs store fleksibilitet. Kåre A. Andersen
<litteraturhistorie> I perioden 1850-1900 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) Eksempel 2.2: Et XML-dokument med blandet innhold (mixed content). Kåre A. Andersen
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: Kåre A. Andersen
<bok id=”_1" sjanger="Lyrikk" regdato="1999.06.16"> <forfatter>Aasen, Ivar</forfatter> <tittel>Millom bakkar og berg</tittel> <tittel>I utval ved Magne Myhren</tittel> <forlag>DnB</forlag> <aar>1980</aar> <sted>Oslo</sted> <isbn>82-525-0298-9</isbn> <merknad></merknad> </bok> Fil: eks2_3.xml Eksempel 2.3: Et utvidet XML-dokument. Kåre A. Andersen
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? Kåre A. Andersen
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 ' (') . • Av disse fem entitetene er det bare < og & som er obligatoriske. Kåre A. Andersen
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 ]]>. Kåre A. Andersen
CDATA <![CDATA[ <bok id="1" sjanger="Lyrikk" regdato="1999.06.16"> <forfatter>Aasen, Ivar</forfatter> <tittel>Millom bakkar og berg</tittel> <tittel>I utval ved Magne Myhren</tittel> <forlag>DnB</forlag> <år>1980</år> <sted>Oslo</sted> <isbn>82-525-0298-9</isbn> <merknad></merknad> </bok> ]]> Vis eksempel.... Kåre A. Andersen
Kommentarer • Ø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 rot-elemetet. • 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 prosesserings-instruksjoner. Kåre A. Andersen
Prosesserings-instruksjoner • 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. Kåre A. Andersen
Prosesserings-instruksjoner • XML tilbyr et alternativ, nemlig prosesserings-instruksjoner. • 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"?> Kåre A. Andersen
Knytte stilark til et XML-dokument vha. prosseseringsinstruks • <?xml-stylesheet type="text/css" href="bok.css"?> • <bok> • <forfatter>Aasen, Ivar</forfatter> • <tittel>Millom bakkar og berg</tittel> • <isbn>82-525-0298-9</isbn> • </bok> Kåre A. Andersen
Eks. på stilark • 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} Kåre A. Andersen
XML-deklarasjonen • I eksemplene over har vi utelatt selve XML-deklarasjonen. 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-8859-1"?> • <bok> • <forfatter>Aasen, Ivar</forfatter> • <tittel>Millom bakkar og berg</tittel> • <isbn>82-525-0298-9</isbn> • </bok> Kåre A. Andersen
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-8859-1" i XML versjon 1.0. • standalone • Dette "attributtet" har verdien "yes" hvis dokumentet kan prosesseres uten en ekstern DTD. (Mer om DTD senere.) Kåre A. Andersen
Et velformet (well-formed) XML-dokument 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. Kåre A. Andersen
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. Kåre A. Andersen
La oss hente fram det meget enkle XML-dokumentet fra eksemple 2.1: <bok> <forfatter>Aasen, Ivar</forfatter> <tittel>Millom bakkar og berg</tittel> <forlag>DnB</forlag> <isbn>82-525-0298-9</isbn> </bok> Kåre A. Andersen
DTD for bok-dokumentet • <!ELEMENT bok ( forfatter, tittel, forlag, isbn ) > • <!ELEMENT forfatter ( #PCDATA ) > • <!ELEMENT tittel ( #PCDATA ) > • <!ELEMENT forlag ( #PCDATA ) > • <!ELEMENT isbn ( #PCDATA ) > Kåre A. Andersen
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. Kåre A. Andersen
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 Kåre A. Andersen
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> • <forfatter>Aasen, Ivar</forfatter> • <tittel>Millom bakkar og berg</tittel> • <forlag>DnB</forlag> • <isbn>82-525-0298-9</isbn> • </bok> • fil: eks3_1.xml Kåre A. Andersen
Document Type Declaration • 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. Kåre A. Andersen
Eksempel 3.2 XML-dokument med ekstern DTD <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE bok SYSTEM "bok1.dtd"> <bok> <forfatter>Aasen, Ivar</forfatter> <tittel>Millom bakkar og berg</tittel> <forlag>DnB</forlag> <isbn>82-525-0298-9</isbn> </bok> • fil: eks3_2.xml Kåre A. Andersen
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: Kåre A. Andersen
Innholdskategorier • ANYvelformete XML-data uten nærmere spesifisering<!ELEMENT hvasomhelst ANY> • EMPTYet element uten innhold (men gjerne med attributter)<!ELEMENT bilde src="bilde.jpg" bredde="150" hoyde="100" EMPTY> • Ren tekstBenevnt PCDATA (parsed character data)<!ELEMENT forfatter (#PCDATA)> • Elementerkun andre elementer<!ELEMENT bok (forfatter, tittel, år, isbn) > • Blandet innholdelementer er blandet med vanlig tekst.<!ELEMENT litteraturhistorie ( #PCDATA | dikttittel | fagområde | forfatter | romantittel | sjanger )* > Kåre A. Andersen
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. Kåre A. Andersen
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 Kåre A. Andersen
<!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="1999.06.16"> <forfatter>Aasen, Ivar</forfatter> <tittel>Millom bakkar og berg</tittel> <tittel>I utval ved Magne Myhren</tittel> <forlag>DnB</forlag> <år>1980</år> <sted>Oslo</sted> <isbn>82-525-0298-9</isbn> <merknad></merknad> </bok> Fil: eks3_3.xml Eksempel 3.3: Et utvidet XML-dokument m/intern DTD. Kåre A. Andersen
Attributter • 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. • Én 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... Kåre A. Andersen
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 > Kåre A. Andersen
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: • #REQUIREDAttributtet må finnes i alle forekomster av elementet og må bli tildelt en lovlig verdi. Ingen startverdi. • #IMPLIEDAttributtet er valgfritt. Ingen startverdi. • #FIXEDAttributtet 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. Kåre A. Andersen
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. Kåre A. Andersen
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) Kåre A. Andersen
IDREF Anta følgende utsnitt av et XML-dokument: <bok bokID="b25"> <forfatter>Ajar, Emilie</forfatter> <tittel>Med livet foran seg</tittel> <oversatt_av oversetterNR="o3" /> </bok> <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 > Attributtyper Kåre A. Andersen
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 > Kåre A. Andersen
XSL Transformation (XSLT) • …men det blir neste gang. Kåre A. Andersen