Download
humit1731 hypermedier n.
Skip this Video
Loading SlideShow in 5 Seconds..
HUMIT1731 Hypermedier PowerPoint Presentation
Download Presentation
HUMIT1731 Hypermedier

HUMIT1731 Hypermedier

122 Views Download Presentation
Download Presentation

HUMIT1731 Hypermedier

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. HUMIT1731 Hypermedier Introduksjon til Extensible Markup Language (XML)

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

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

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

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

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

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

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

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

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

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

  12. 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 &lt;. • Tilsvarende har vi &gt; (>) &amp; (&) &quot; (") og &apos; (') . • Av disse fem entitetene er det bare &lt; og &amp; som er obligatoriske. Kåre A. Andersen

  13. 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 &lt;. • I XML-sammenheng kan vi enkelt skrive koden i en seksjon som begynner med <![CDATA[ og avsluttes med ]]>. Kåre A. Andersen

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  35. <!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

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

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

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

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

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

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

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

  43. XSL Transformation (XSLT) • …men det blir neste gang. Kåre A. Andersen