HUMIT1731 Hypermedier Introduksjon til Extensible Markup Language (XML)

HUMIT1731 uke42 Kåre A. Andersen 2 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 3 Eksempel 2.1: Et meget enkelt XML-dokument, lagret som filen eks2_1.xml eks2_1.xml Aasen, Ivar Millom bakkar og berg

HUMIT1731 uke42 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. 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. Hvis et element er tomt, kan vi sløyfe slutt-taggen og heller skrive. Dette gjelder f.eks. og i et XHTML-dokument. Her kan vi altså bruke og som erstatning for og Til slutt skal bare nevnes at XML skiller mellom store og små bokstaver: er forskjellig fra og. 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: og. Vi vil forsøke å gjennomføre små bokstaver i elementnavn.

HUMIT1731 uke42 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. XML tillater imidlertid også, 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.

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

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

HUMIT1731 uke42 Kåre A. Andersen 8 Eksempel 2.2: Et XML-dokument med blandet innhold (mixed content). I perioden finner vi flere store forfattere. <forfatter fodt="1832" dod="1910"> Bjørnstjerne Bjørnson er en av de mest kjente, men også Camilla Collett ga viktige bidrag, som f.eks. Amtmannens Døttre. Denne boka er blitt kalt vår første tendensroman. Ivar Aasen er vel mest kjent for sine bidrag til språkvitenskapen, men mange vil kanskje helst minnes ham som forfatter av det kjente dikt et "Millom bakkar og berg..." ? eks2_2.xmleks2_2.xml m/stilark: eks2_2css.xml (Stilarkfil) eks2_2css.xmlStilarkfil

HUMIT1731 uke42 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: Et tilsvarende mønster finnes i XML, og vi har brukt noen allerede:. 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:

HUMIT1731 uke42 Kåre A. Andersen 10 Eksempel 2.3: Et utvidet XML- dokument. Aasen, Ivar Millom bakkar og berg I utval ved Magne Myhren DnB 1980 Oslo Fil: eks2_3.xml eks2_3.xml

HUMIT1731 uke42 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: Lyrikk. 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?

HUMIT1731 uke42 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 <. Tilsvarende har vi > (>) & (&) " (") og &apos; ('). Av disse fem entitetene er det bare < og & som er obligatoriske.

HUMIT1731 uke42 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 <. I XML-sammenheng kan vi enkelt skrive koden i en seksjon som begynner med.

HUMIT1731 uke42 Kåre A. Andersen 14 CDATA <![CDATA[ Aasen, Ivar Millom bakkar og berg I utval ved Magne Myhren DnB 1980 Oslo ]]> Vis eksempelVis eksempel....

HUMIT1731 uke42 Kåre A. Andersen 15 Kommentarer Ønsker man å kommentere XML-koden, brukes samme syntaks som ved HTML-dokumenter: Kommentaren innledes 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.

HUMIT1731 uke42 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 -taggen: <!-- Skjule for eldre nettlesere document.write("Jeg er et JavaScript..."); // slutt på å skjule --> Av og til ser vi også konstruksjoner som muliggjør inkludering av eksterne filer 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 17 Prosesserings-instruksjoner XML tilbyr et alternativ, nemlig prosesserings- instruksjoner. Disse innledes 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:

HUMIT1731 uke42 Kåre A. Andersen 18 Knytte stilark til et XML-dokument vha. prosseseringsinstruks Aasen, Ivar Millom bakkar og berg

HUMIT1731 uke42 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}

HUMIT1731 uke42 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: Aasen, Ivar Millom bakkar og berg

HUMIT1731 uke42 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 " i XML versjon 1.0. standalone Dette "attributtet" har verdien "yes" hvis dokumentet kan prosesseres uten en ekstern DTD. (Mer om DTD senere.)

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

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

HUMIT1731 uke42 Kåre A. Andersen 24 La oss hente fram det meget enkle XML-dokumentet fra eksemple 2.1: Aasen, Ivar Millom bakkar og berg DnB

HUMIT1731 uke42 Kåre A. Andersen 25 DTD for bok-dokumentet

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

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

HUMIT1731 uke42 Kåre A. Andersen 28 Eksempel 3.1 XML-dokument med intern DTD <!DOCTYPE bok [ ]> Aasen, Ivar Millom bakkar og berg DnB fil: eks3_1.xml eks3_1.xml

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

HUMIT1731 uke42 Kåre A. Andersen 30 Eksempel 3.2 XML-dokument med ekstern DTD Aasen, Ivar Millom bakkar og berg DnB fil: eks3_2.xmleks3_2.xml

HUMIT1731 uke42 Kåre A. Andersen 31 Deklarasjon av elementer Et element deklareres altså slik: (punkt 1 og 2 nedenfor) eller (punkt 3-5 nedenfor) hvor navn er et gyldig XML-navn og innhold/innholdsmodell ulike innholdskategorier:

HUMIT1731 uke42 Kåre A. Andersen 32 Innholdskategorier 1. ANY velformete XML-data uten nærmere spesifisering 2. EMPTY et element uten innhold (men gjerne med attributter) 3. Ren tekst Benevnt PCDATA (parsed character data) 4. Elementer kun andre elementer 5. Blandet innhold elementer er blandet med vanlig tekst.

HUMIT1731 uke42 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: Merk at vi kan bruke ekstra parenteser for å lage mer kompliserte innholdsmodeller.

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

HUMIT1731 uke42 Kåre A. Andersen 35 Eksempel 3.3: Et utvidet XML- dokument m/intern DTD. <!DOCTYPE bok [ <!ELEMENT bok ( forfatter, tittel+, (forlag | år | sted | isbn)*, merknad? ) > ]> Aasen, Ivar Millom bakkar og berg I utval ved Magne Myhren DnB 1980 Oslo Fil: eks3_3.xmleks3_3.xml

HUMIT1731 uke42 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: Her må en tittel etterfølges av "null eller ingen" tittel - som vi jo ønsket...

HUMIT1731 uke42 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..... > Dette gir best oversikt, men vi kan også angi en ny ATTLIST for hvert attributt til samme element:

HUMIT1731 uke42 Kåre A. Andersen 38 Attributter Den mest vanlige deklarasjonen er som denne: 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. 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 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.

HUMIT1731 uke42 Kåre A. Andersen 40 Attributtyper Oppramsingsvedier (enumerated values) Ønsker vi å angi at et attributt kan ha en av flere verdier: ID 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 41 Attributtyper IDREF Anta følgende utsnitt av et XML- dokument: Ajar, Emilie Med livet foran seg Anne Ringnes En tilhørende attributtliste kan da se slik ut:

HUMIT1731 uke42 Kåre A. Andersen 42 IDREFS Ønsker vi å åpne for at en oversetter skal kunne knyttes til flere bøker, bruker vi IDREFS Anne Ringnes <!ATTLIST oversetter oversetterID ID #REQUIRED har_oversatt bokNR IDREFS #REQUIRED >

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