XML
informasjon
oppdatert: 3. april 2012

XML
XML er designet for å lagre og transporte data. XML ser nesten ut som HTML med tagger, elementer og atributer med tilhørende verdier. Se beskrivelsen av XHTML for hvordan HTML kan bli til lovlig XML-dokument. XML er en ikke propretær spesifikasjon. XML er utviklet av W3C og kan gratis brukes av alle som ønsker det. Denne åpne standarden gir store og små organisasjoner, uavhenging av maskinvare, mulighet til å utveksle informasjon.

I XML kan en definere sitte eget markup language, kalt en XML applikasjon. En kan bruke egne navn på elementene og atributter samt bestemme hvilke verdier som lovlig å tilordne atributtene. Eksemplet på registreringsskjema vi har benyttet i beskrivelsen av HTML 4.1 kan bli til følgende XML dokument:

<?xml verstion="1.0" ?>

<regSkjema1>
<advarsel>(demo)</advarsel>
<overskrift>Registreringsskjema side 1</overskrift>
<tekstCelle>Navn:</tekstCelle>
<boksCelle verdi="tekst" />
<knappCelle>registrer</knappCelle>
<!-- Dette er en kommentar -->
<![CDATA[ alt som skrives her blir tolket som tekst av XML-prosessoren. Dette er ikke en tagg <ikkeTagg> ]]>
</regSkjema1>

Den første linjen <?xml version="1.0" ?> er XML deklarasjonen som sier hvilken versjon av XML en bruker. Neste linje inneholder taggen <regSkjema1>. Elementet "regSkjema1" avsluttes på siste linje med taggen </regSkjema1>. Elementet "regSkjema1" innholder 7 elementer, henholdvis "advarsel", "overskrift", "tekstCelle", "boksCelle", "knappeCelle", kommentar og tekstkonstant. Elementet "regSkjema1" kalles root-elementet. XML-dokumtet kan bare innholde et root-element. De andre elementete må være innenfor root-elementet. Navn på elementene er fritt valg. Navnet må starte på bokstav, lav bindestrek eller kolon og deretter innholde det alfanummeriske engelske alfabetet, lav bindestrek, punktum, kolon eller apostrof. Navnet er case-sensitivt. Elementet "boksCelle" har atributtet "verdi" som er tilordnet verdien "tekst". Verdier til atributter må være omsluttet med ansførselstegn. Hvert element kan innholde mange atributter. Elementet "boksCelle" er et såkalt tomt element. Tomme elementer kan avsluttes ved å skrive avsluttningstegnet "/" rett føre >-tegnet. Ønsker en å legge til kommentarer i XML-dokumentet benyttes HTML-taggen kommentar, se tredje siste linje i dokumentet over. Nest siste linje innholder tekstdata som ikke blir lest av XML-prosessoren. JavaScript i XML-dokumenter blir plasset i CDATA-elementer. En ting som er viktig å merke seg er at kun "ampersand-tegnene" &amp;, &lt; og &gt; er lovlig i XML, altså de mye brukte &aelig;, &oslash; og&aring; er ikke forhånds definert som lovlig i XML 1.0.

Dokumentet over er et velformulert (fullstendig) XML dokument. Siden dokumentet ikke innholder noe informasjon om layout velger netteleserene og vise all tekst i dokumentet (også tagger), trykk her for å se dokumentet. En kan fortelle nettleseren hvordan XML-dokumentet skal vises ved å bruke XSL (eXtensible Stylesheet Language). XSL bestå av tre språk XSLT, XPath og XSL-FO. Disse tre språkene kan oversette XML-dokumentet til HTML-fil, pdf-dokument eller nær sagt hva som helst. XSLT-FO brukes til formate XML-dokumenter til utskriftsformater slik som pdf. Nettleserene støtter ikke XSL-FO. XSLT og XPath støttes av nettleseren og kan brukes til oversettelse av XML til HTML, XML og tekst-fil.

XPath
XPath er en standardisert måte å angi spesielle deler at et dokument. XPath benyttes bl.a. i XPointer- og XSLT-standardene, se egne kapitler på denne siden. XPath betrakter XML-dokumentet som et node-tre. Det er 7 typer noder i treet: root-, element-, text-, attribute-, namespace-, processing-instruction-, comment-node. For vårt eksempel vil treet se ut som følger:

XPath standarden definere 20-30 såkalte "expression". Det viktigste utrykket er "LocationPath Expression" som angi en gruppe med noder. Vi vil nedenfor først se på LocationPath expression relativt til en node i treet. "LocationPath Expression" består av tre deler og starter med et standard gruppenavn, deretter følges :: og spesifikasjon av navn på noder eller type noder gruppen skal innholde, den siste delen er en valgfrie betingelse medlemene i gruppen må tilfredstille.

Det er definert 13 standard grupper. Respektive medlemer i de 13 gruppene beregnes relativt til hvor en befinner se i treet. I oppramsingen av de 13 gruppene nedenfor er det i parantes angitt hvilke noder dette representer i eksemplet over hvis en befinner seg i noden med navnet "tabel". (vi har dessverre ikke fått verifesert tolkingen)

  • child (alle noder direkte under: tr, border, cellpadding, cellespacing)
  • descandent (alle noder under: border, cellpadding, cellespacing, tekstCelle, boksCelle, knappeCelle og alle tekst-nodene under disse)
  • parent (forelder til noden: regSkjema1)
  • following-sibling (alle etterfølgende søsken: advarsel)
  • preceding-sibling (alle foregående søsken: advarsel, overskrift)
  • following
  • preceding
  • attribute (alle atributt-noder direkte under: border, cellpadding, cellespacing)
  • namespace (navnrom atributtet til noden en befinner oss i, dette er ikke oppgitt)
  • ancestor (alle forfedre til node: /, regSkjema1)
  • self (den noden en er i: table)
  • descendant-or-self (alle noder under og en en selv: tr, border, cellpadding, cellespacing, tekstCelle, boksCelle, knappeCelle og alle tekst-nodene under disse)
  • ancestor-or-self (alle forfedre til node: /, regSkjema1, tabel)
I tillegg til en av gruppe angivelsene over må "LocationPath-expressen" innholde begrensning om hvilke node-navn eller node-typer den skal innholde. I eksemplene nedenfor har en valgt standarden gruppen "child" og følgende begrensinger er mulig (vi befinner oss forsatt i "tabel"-noden):
  • child::*
  •    Alle noder tilhørende gruppen: tr, border, cellpadding, cellespacing
  • child::tr
  •    Kun medlem med angitt navn og i vårt tilfelle er kun et barn med dette navnet: tr-noden)
  • child::node()
  •    Alle noder i tilhørende gruppen: tr, border, cellpadding, cellespacing
     
  • child::text()
  • child::comment()
  • child::processing-instuction()
  • etc
  •    Kun noder av angitt type er med i gruppe.
       Siden "tabel"-noden kun har barn av typen element og attribut
       vil bare disse mengdene være forskjellig fra tom)
Den siste og valgfrie del av "LocactionPath-expression" er enda en betingelse. Betingelsen er omsluttet av to hakeparanter som kan lese som "hvis". Oppfyller ingen noder betingelsen returneres en tom mengde. I XPath er det definer en 20-30 funksjoner (andre expression) som kan benyttes i betingelsene. Nedenfor følger eksempler på bruk av betingelser og funksjoner for å angi noder (vi befinner oss forsatt i "tabel"-noden)
  • child::*[position()=3]
  •    Returnerer barn (node) nr 3 i gruppen: cellpadding
  • child::*[postition()>1]
  •    Alle barn (noder) untatt det første: border, cellpadding, cellespacing
  • child::*[postition()=count()]
  •    Expression "count()" returnerer antall barn (noder i gruppen): cellespacing
  • child::*[postition()=last()]
  •    Expression "last()" returnerer størrelsen på konteksten: cellespacing
  • child::*[child::attribut::verdi='tekst']
  •    Gruppen innholder alle barn som har barn med attributtet verdi='tekst': tr
Det er innført noe forkortete skrivemåter for "LocalePath Expression". Følgende forkortelser er mulig:
  • @
  •    attribute::
  • .
  •    self::node()
  • ..
  •    parent::node()
  • //
  •    descendant-or-selv::node()
  • *
  •    child::*, om ikke annet er oppgitt er "child::" default
  • *[2]
  •    child::*[postion()=2]
Vi har til nå sett på hvordan LocationPath expression kan angi grupper relativt til en noden i treet, i vårt eksempel "tabel"-noden. For absolutt identifikasjon av en gruppe benyttes velkjent unix-sti-notasjon fra roten og til den relative node. Eksempler:
  • /regSkjema1/tabel/td/*
  •    Alle barna til td-noden: tekstCelle, boksCelle, knappeCelle
  • /regSkjema1/advarsel[2]
  •    Den andre "advarsel"-noden treet
Sti-notasjon kan også benyttes relativt til en node, eller mengde med noder. I eksemplet nedenfor angis alle barnebarn som heter "boksCelle":
  • */boksCelle
  •    Relativt til tabel-noden er det et barnebarn som heter boksCelle
Generelt sett kan stien (path) tilføyes alle XPath expression, derav navnet. De andre XPath expression returnerer en av følgende typer verdier: en mengde noder, tekst streng, tall eller boolean. I omtale av XPointer nedenfor benyttes XPath expression "id()" til å velge ut alle noder i dokumentet med hensyn til verdien til atributtet id. For videre fordypning se standarden, se her XPath 1.0

XSLT
I en verden der ikke alle maskiner har full støtte for XML er det en god løsning å oversette XML-dokumenter til andre formater. I XSLT er det mulig å lage et sett med regler som kan benyttes til å oversette alle dokumenter i ditt egendefinerte XML-språk til f.eks. HTML. XSLT er et XML-basert språk og regelsettet blir dermed et XML-dokument, kalt stylesheet. Selve omformingen utføres av en XSLT-prosessor. XSLT-prosessorer er idag innebygd i nettleserene. Webservere kan også ha innebygd XSLT-prosessor.

XSLT beskriver hvordan et helt nytt og separat node-tre (resultat-treet) genereres ut i fra et kildetree. XSLT prosessorene starter med å genererer et kildetreet av XML-dokumenter identisk med hva som er beskrevet i XPath kapittelet over. Resultat-treet kan få fullstendig forskjellig struktur i forhold til kildetreet. Ved oversettelsen fra kildetreet til resultat-treet kan noder bli filtrert bort, kopiert over og nye lagt til.

I XSLT standarden versjon 1.0 er det definert noe over 20 ulike XML-elementer. Det mest brukte elementet for oversettels er "template". Template kan sammenliknes med prosedyre/funksjon/metode i andre programmeringspråk. Template beskriver hvordan en node kildetreet skal oversettes til resultatreet. I template er det lov å beskrive nodene i resultattreet ved tekstelig beskrivelse av elementene, kall på andre template eller kall på andre XSLT-instruksjoner. Hvert template er tilknyttet en gruppe med noder i kildetreet. Gruppen blir identifisert av "pattern". Pattern består av en eller flere expression av typene LocationPath, id() og key()separert med "|", her tolket som union av mengdene. Det er kun tillatt å benytte standardmengdene "child", "attribute" og "//" i LocationPath-expression. Template beskriver hvordan et eventuelt medlem av gruppen kan oversettes til resultat-treet. Det skjer ikke noe oversettelse før selve templatet kalles.

Selve kallet utføres av "apply-template"-elementer inne i "template"-elementet. Apply-template kaller ikke direkte på andre template, men det oppgis ved hjelp av "expression" hvilke noder XSLT-prosessoren skal gå til i kildetreet å utføre matchende template for. På denne måten vandrer XSLT-prosessoren rundt i kildetreet og utfører tilhørende template. Resultatet blir et nytt tre.

Alle XSLT stylesheet starter med elementet <xslt:stylesheet > eller <xslt:tranformer >. Bruken av disse to elementer er ekvivalente og begge må innholde atributtet som angir navnrommet, xmlns:xsl="http://www.w3.org/1999/XSL/Transform". Nedenfor følger et eksempel på XSLT stylesheet for omforming av dokumenter i vårt egendefinerte XML-språk til et html-dokument.

<?xml version="1.0"?>

<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">

<xsl:output method="html" indent="yes" />

<xsl:template match="/">
<html>
<head><title>Registrerings Skjema</title>
</head>
<body>
<form methode="post" acttion="min">
<xsl:apply-templates select="regSkjema1/advarsel" />
<xsl:apply-templates select="regSkjema1/overskrift" />
<table border="1" cellpadding="2">
<tr>
<xsl:apply-templates select="regSkjema1/tekstCelle" />
<xsl:apply-templates select="regSkjema1/boksCelle" />
<xsl:apply-templates select="regSkjema1/knappCelle" />
</tr>
</table>
<xsl:apply-templates select="regSkjema1/advarsel" />
</form>
</body>
</html>
</xsl:template>

<xsl:template match="advarsel">
<p><xsl:value-of select="." /></p>
</xsl:template>

<xsl:template match="overskrift">
<h1><xsl:value-of select="." /></h1>
</xsl:template>

<xsl:template match="tekstCelle">
<td class="tekstCelle"> <xsl:value-of select="." /></td>
</xsl:template>

<xsl:template match="boksCelle">
<td class="boksCelle"><input type="text" size="30" value="{.}"/></td>
</xsl:template>

<xsl:template match="knappCelle">
<td class="knappCelle"><input type="submit" value="{.}" /></td>
</xsl:template>

</xsl:stylesheet>

I selve XML-dokumentet angis hvilken XSLT-styelsheet som skal brukes ved å legge til direktivet
<?xml-stylesheet type="text/xsl" href="side1.xsl" ?>
etter xml-versjon direktivet. Trykk her for å se dokumentet oversatt av XSLT-stylesheet overfor.

Oversettelsen starter med at XSLT-prosessoren kaller template til root-noden . Alt som stå elementet fram til <xsl:apply-templates select="regSkjema1/advarsel"> blir skrevet direkte inn i resultat-treet. apply-template forflyter XSLT-prosessoren til "advarsel"-noden i kildetreet og tilhørende template kalles. Alt som blir skrevet ut bli lagt under "form"-noden i resultat-treet. Nest apply-template instuksjon forflytter XSLT-prosessoren videre til overskrift-noden og tilhørende template blir kalt. XSLT-prosessoren kjenner deretter igjen taggen som følger og skriver disse rett ut til en kommer <xsl:apply-template select="regSkjema1/tekstCelle">. XSLT-prosessoren går til noden "tekstCelle" og kaller på den template osv. Til slutt gå XSLT-prosessoren til "advarsel"-noden på nytt å skriver denne ut denne en gang til. Helt til slutt skrives resten av innholdet rot-noden og og resultat-treet er ferdig.

Alle elementer i XSLT-stylesheet som ikke tilhører XSLT-navnerommet lager element-noder i resultat-treet. Eventuelle atributter til elementet som ikke tilhører XSLT-navnerommet vil også bli lagt til resultat-treet. Nedenfor følger kort presentasjon av øvrige XSLT-elementer:

  • element
    Elementet lager en element-node i resultat-treet. Navnet til noden angis ved name-atributt.
  • attribute
    Elementet lager en attribute -node i resultat-treet. Navnet til noden angis ved name-atributt. Atributt-elementer må spesifisiers i i xsl:element før andre barn tilhørende elementet. Atributt-elementer kan kun innholde xsl:text-element. Atributt-noder kan kun tilordnes element-noder.
  • attribute-set
    Elementet inneholder attribute-elementer og /eller andre attribute-set. Gruppen tilordnes navn ved hjelp av "name"-atributtet. Atributt-gruppen kan tilordnes følgende elementer: xsl:element-, xsl:copy- og xsl:attribute-set. Tilordningen skjer ved oppgi gruppenavnet i xsl:user-attribute-set atributtet til elementet. Det er også mulig å bruke xsl:user-attribute-set i elementer som ikke tilhører XSLT-navnerommet, se eksemplet over.
  • text
    Elementet lager en text-node i resultat-treet. Verdien som skrives mellom start og stopp tag blir lagret i noden.
  • processing-instruction
    Elementet lager en processing-instructiont-node i resultat-treet. Verdien som skrives mellom start og stopp tag blir lagret i noden.
  • comment
    Elementet lager en comment-node i resultat-treet. Verdien som skrives mellom start og stopp tag blir lagret i noden.
  • copy
    Elementet kopiere noden XSLT-prosessoren befinner seg i kildetreet over til resultat-treet, men hverken barn eller atributt-noder blir kopiert. Følgende template kopiere hele kildetreet over til resultat-treet.
    <xsl:template match"@*|node()">
    <xsl:copy>
    <xsl:apply-template select="@*|node()" />
    </xsl:copy>
    </xsl:template>
  • value-of
    Elementet benyttes til å hente ut verdier til tekst-noder og xslt-variabler. Hvilken tekst-node eller XSLT-variabel som skal leses spesifisers i "select"-atributtet til elemenentet.
  • value-of
    Elementet benyttes til å hente ut verdier til tekst-noder og xslt-variabler. Hvilken tekst-node eller XSLT-variabel som skal leses spesifisers i "select"-atributtet til elemenentet. Alternativt er mulig å direkte hente kopiere over verdier fra kildetreet der expression omsluttet av {}-parenteser angir noden, se template til boksCelle og knappeCelle over.
  • number
    Elementet benyttes til legge en node med formatert nummer i resultat-treet.
  • for-each
    Elementet benyttes til å få XSLT-prosessoren til hoppe gå igjennom alle noder i kildetreet spesifisert i select-atributtet til elementet. XSLT-prosessoren vil på normal måte starte template tilhørende noden den er på.
  • if
    Elementet har et test-atributt som innholder en expression som kan være sann eller usann. Avhengig av testen blir innholdet i elementet utført eller ikke av XSLT-prosessoren.
  • choose
    Elementet gjør omtrent det samme som switch i java. Elementet innholder when-elementer. Hvert when-element har et test-atributt. Innholdet i første when-element med der testen er sann blir utført. Kun innholdet i ett when-element blir utført og om ingen har en sann test kan et otherwise-element bli utført.
  • sort
    Elementet benyttes til endre hvilke rekkefølgen XSLT-prosessoren går til ulike noder i kildetreet. Elementen kan inkluderes i xsl:apply-templates eller xsl:for-each elementer.
  • variable
    Elementet benyttes til å lage lokale variabler i XSLT-stylsheet. Variablen blir navngitt av name-atributtet. Verdien er innholdet i elementet. Variablen kan leses ved å prefikse navnet med $-dollartegn.
XSLT-prosessorere
Når en ønsker å benytte XSLT-prosessoren til nettleseren må XML-dokumentet ha følgende processing-instruction elementet rett etter XML-versjons processing-instruction elementet. Filnavn angitt i "href"-atributtet må selvsagt byttes ut med aktuel lokasjon til .xslt-fil
<?xml-stylesheet type="text/xsl" href="side1.xslt" ? >

Det finne flere tilgjengelige XSLT-prosessorer på nett som kan lastes ned. Følgende er javabasert og open-source:

  • Xalan
    Dette er javabasert XSLT-prosessor som kan lastes ned fra http://xml.apache.org/xalan-j/. Etter ha lastet ned zip-filen må tre .jar-filer legges til CLASSPATH, xalan.jar, xercesImpl.jar og xml-apis.jar. Programmet kjøres med kommandoen: java org.apache.xalan.xslt.Process
  • Michael Kay's SAXON
    Den mest komplette gratis XSLT 2.0 prosessoren er SAXON. Prosessoren er skrevet av forfatteren av XSLT 2.0 standarden. Den er java baset og tilgjengelig på http://saxon.sourceforge.net. Etter nedlasting av zip-filen må du legge saxon9.jar til CLASSPATH. Programmet kjøres med kommandoen: java net.sf.saxon.Transformer. Det finnes en Instant versjon som er lett å installere på windows se http://users/iclway.co.uk/mhkay/saxon/instant.html
  • Altova XSLT engine
    Den eneste gratis XSLT 2.0 prosessor som støtter skjema. Den finne kun i windows versjon. Laste ned fra http:/www.altova.com/altovaxml.
For vider fordyping se standarden XSLT 1.0.

Navnerom i XML
XML åpner for en verden der en fritt kan definere egne navn på elementer og deres atributter. Her kan det fort oppstå konflikter der flere dokumenter bruke samme navn i ulike betydning. XML-standardene baserer seg på at navn på xml-elementer og deres atributter blir unikt og likt tolket av alle programmer som støtter standarden. Derfor er det behov for en universell navnestandard. Dette er løst ved at navnene er definert innenfor et navnerom. Intensjonen er her at like navn innenfor samme navnrommet skal tolkes likt av alle programmer. Navn på elementer som defineres i standardene tilhører standardiserte navnrommet, dette er fellesrom med fellesnavn. Alle programmer skal tolke fellesnavnene likt. En kan fritt opprette privaterom med egennavn som kun er tiltenkt eget bruk. Hvert navnrom blir identifisert med av URI. Navnrommet Xlink heter http://www.w3.org/1999/xlink. En kan fritt velge identifikatorer så lengde de tilfredstiller kravene til URI, men for å sikre unikhet bør en basere navnet på egne domenenavn. Vær oppmerksom på at identifikatoren skiller mellom store og små bokstaver. Identifikatoren til rommet har samme syntaks som webadresse, men identifikatoren er kun et logisk navn, har ingen knytning til noe fysisk webside og ingen henvendelse til w3-serveren vil bli generet til ved bruk av rommet.

I et XML-dokument kan elementer tilhøre ulike navnerom. I dokumentet deklarer en hvilket navnerom som skal bruks, deretter referer hvert element eksplisitt eller implisitt til aktuelt navnrom. Deklares ingen navnerom og elementet ikke referer til noe navnerom betraktes navnene å tilhøre "ikke navnerommet". Deklarasjon av navnromm kan legges inn i hvilken som helst element. Deklarasjonen gjelder for/referes til av elementet og elementes barn. En kan skille mellom default og prefiks deklarasjon. XML-dokumentet nedenfor innholder begge deler.

<?xml verstion="1.0" ?>

<regSkjema1 xmlns="http://registrar.no/dokumentasjon/klient/regSkjema/1.0"
xmlns:xlink="http://www.w3.org/1999/xlink" >

<xlink:simple xlink:href="bilde.gif" xlink:role="image" xlink:title"test bilde" xlink:show="embeddded" xlink:actuate="onload" />
<advarsel>(demo)</advarsel>
<boksCelle verdi="tekst" />

</regSkjema1 >

Atributtet "xmlns" er definert i XML-standarden til å angi navnerom. Vær oppmerksom på at alle atributtnavn, elementnavn og prefiks som begynner med xml, i alle kombinasjoner av store og små bokstaver, er reservert. Navnerommet ""http://registrar.no/dokumentasjon/klient/regSkjema/1.0" er deklarert som default navnerom. Alle navn på elementer i dokumentet tilhører implesitt navnerommet til registrar. Selv om registrar er default navnerom vil ikke atributt-navn implesitt tilhøre dette navnerommet. Atributtet "verdi" i elementet "boksCelle" vil tilhører navnerommet "ikke navneromm". Dette har i praksis liten betydning da atributter blir refert til innenfor "scoped"/rammen til elementet. I deklarasjonen av navnerommet Xlink er prefikset xlink definert. Alle elementnavn og atributtnavn som blir prefikset med "xlink:" tilhører dette navnerommet. En kan fritt valge navn p&arign; prefikset. Benyttes samme prefiks til annet navnerom ved bruk av xmlns atributtet i under-element vil ikke lenger det første rommet være tilgjenlig inne i dette elementet.

DTD (Document Type Definition)
I boks-elementet i vårt eksempel er det svært ønskelig å kunne spesifisere lovlige verdier. Ved å benytte et felles språk til å definere syntaksen er det også mulig å benytte en felles metode for validering av om dokumentet i henhold til spesifikasjonene. I praksis betyr det at mottager (webhotellet) kun trenger en valideringsmetode for alle skjemaer istedet en spesialtilpasset validering av hver enkelt side med html-forms som idag.

For å definere syntaksen til vårt eget markup language er det to vanlige standard metoder. Syntaksen bestemmer hvilke elementer og atributter etc. som er lovlig og påkrevet i dokumentene. Det er to ulike standerene er: DTD (Docoment Type Definitions) og XML-skjema. XML-skjema er utviklet av W3C har og har flere fordeler framfor DTD, bla mulighet for typedefinering av innholdet.

<!ELEMENT regSkjema1 (advarsel?, overskrift, navnCelle+, boksCelle+, knappCelle+)>

<!ELEMENT advarsel (#PCDATA)>
<!ELEMENT overskrift (#PCDATA)>
<!ELEMENT navnCelle (#PCDATA)>
<!ELEMENT boksCelle EMPTY>
<!ATTLIST boksCelle verdi (tekst | text) #REQUIRED
<!ELEMENT knappCelle (#PCDATA)>

DTD kan brukes for XML-dokument "regSkjema1". Det første elementet definer hvilke barn-elementer regSkjema1-elementet innholder. Spørsmålstegnet etter navnet på barne-element betyr at dette elementet skal forekomme 0 eller 1 gang. Pluss-tegnet etter navnet på barne-elemen betyr at dette elementet skal forekomme 1 eller flere ganger. Alternativt kunne det kunne stjerne-tegnet blitt brukt for angi 0 eller flere ganger. Oppgis ikke antall etter barne-elemente skal det opptre nøyaktiv 1 gang. Deretter følger noen linjer med hvilke type data barne-elementene kan innholde. PCDATA betyr elementet bare kan innholde tekst/tall og ikke andre elementer. "boksCelle" elementet skal være tomt og kan dermed heller ikke innholde tekst, men det skal ha ett atributt med navn "verdi". Lovlig verdi til atributtet er "tekst" eller "text". Andre vanlige verdier til atributter er CDATA, ID, IDREF, IDREFS og NMTOKEN. CDATA betyr ikke parsert tekst. ID betyr at ingen andre elementer har samme atributtet med samme verdi. IDREF betyr at verdien skal være lik en eksisterende ID. IDREFS er white-space-seperatet liste med eksisterende ID'er. NMTOKEN er ord med syntaks lik lovlig XML tag-navn.

I selve XML-dokumentet kan en refere til DTD-filen ved !DOCTYPE-elementet. Elementet innholder navnet på root-elementet i dokumentet kodeordet SYSTEM og til slutt filnavnet til DTD-filen, slik som nedenfor:
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<!DOCTYPE regSkjema1 SYSTEM
"http://registrar.no/dokumentasjon/klient/xml/skjema.dtd">

<regSkjema1>
...resten av xml-dokumentet

Atributtet SYSTEM i DOCTYPE-elementet gir parseren beskjed om å hente inn deklarsjoner fra oppgitt URL. Legg også merke til at XML direktivet øverst har fått en nytt atributt "standalone". Det eksistrer også en standard for å gi navn til DTD. Dette er med henblikk på at DTD kan lagres i flere server på nettet og kan der hentes ut ved å referer til til navn på DTD. Slike standardiserte navn begynner med tegnet + eller - som angir om DTD'en er godkjent av en standardiseringsorganisasjon eller ikke. Etter doble skråstreker følger navnet på den som eier DTD'en. Deretter en kort beskrivelse av DTD og til slutt en forkortelse for hvilket språk av XML-dokumentet DTD skal anvendes for, i dette tilfelle norsk. Den nasjonale forkortelsen skal følge ISO 639 standarden. For å gi parseren beskjed om å prøve å finne DTD i nærmeste "DTD-server" må nøkkelordet SYSTEM i DOCTYPE-element over byttes ut med PUBLIC og etterfølges av både navnet på DTD og URL'en. Parseren vil først prøve å finne DTD i en nærmeste DTD-server, hvis negativ respons vil URL benyttes.

I tillegg til å definere regler for gyldig XML-dokument deklarer DTD også entiteter og notasjoner. Entiter definerer referanser til tekst og filer som kan ekspanderes i XML-dokumentet. Det er 5 typer entiteter se figuren nedenfor:

Før de ulike entiteten blir nærmere omtalt nedefor skal vi se litt på hvordan en DTD ser ut og hvordan en kan deklarerer eksterne tillegg. DTD'en plasseres øverst i XML-dokumentet den skal benyttes. Her følger eksempel på en DTD som inneholder deklararsjon av en Generell Ekstern Entitet:
<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE regSkjema1 [
<!ENTITY adr "Forskninsparken, 0349 Oslo" >
]>

<regSkjema1>
...resten av xml-dokumentet
<adresse>&adr;</adresse>
</regSkjema1>

Nedenfor følger en beskrivelse av overnevnte ulike entiter

  • Generell Intern Entitet kan deklarere forkortelser for tekst som kan ekspanders i XML-dokumentet ved presentasjon. Ovenfor er forkortelsen "adr" deklarert for teksten "Forskninsparken, 0349 Oslo". For at XML parseren skal tolke forkortelsen korrekt må den omsluttes av &-tegnet og ;-tegner. Altså parseren vil ersatte &adr; med: Forskninsparken, 0349 Oslo. I XML er det fem innebygde generelle interne entiteter som alltid er tilgjengelig: &amp;, &lt;, &gt;, &qout;, &apost;

  • Generell Ekstern Parsed Entitet referer til ekstern fil som ekspanderes i XML-dokumentet av parseren. Parseren vil også parsere innholdet i filen og den må derfor innholde tekst. For å kunne refere til eksterne filer XML direktivet øverst innholdet atributtet standalone="no". Vider må selve deklarasjone av entiteten innholdet SYSTEM etterfult av url til ekstern fil, f.eks
    <!ENTITY adr SYSTEM "http://registrar.no/dokumentasjon/klient/xml/adr.txt" >

  • Generell Ekstern Unparsed Entitet referer til ekstern fil som ekspanderes i XML-dokumentet av parseren. Parseren vil ikke parsere innholdet i fil og den kan dermed innholde bilder etc. Deklarasjon av unparsed entiteter i forhold til parsed entiteter også innholde informasjon om datatype, se eksemplet nedenfor
    <!ENTITY adr SYSTEM "http://registrar.no/dokumentasjon/klient/xml/adr.gif" NDATA gif>
    <!NOTATION gif SYSTEM "image/gif" >
    <!ELEMENT adresse EMTPY >
    <!ATTLIST adresse src ENTITY #REQUIRED >
    NDATA identifiser notasjonen som beskriver datatypen. I NOTATION kan en etter nøkkelordet SYSTEM angit datatypen. Det er her ikke standardisert angivelse, slik at det er opp applikasjonen som skal presenter XML-dokumentet å tolke beskrivelse av datatypen. Til forskjell fra parsed entiteter er det ikke mulig å referere til unparsed entiteter direkte i XML-dokumenter. Unparsed entiter kan kun referes til i atributter til elementer. I eksemplet er lagt inn synaksregler som sier at elementet "adresse" må ha atributtet "src". Bruk av nøkkelordet ENTITY i ATTLIST-elementet betyr at attributtet kan referere til en unparsed entitet. Referanse til unparsed entitet XML-dokumentet blir som følger:
    <adresse src="adr" />

  • Parameter Entitet definerer forkortelse for deklarasjoner i DTD. Referanser til parameter entiteter kan dermed kun benyttes innefor DTD. Ekstern Parameter Entitet deklarasjon til en DTD og bruk av denne i vårt eksempel blir som følger
    <?xml version="1.0" encoding="UTF-8" standalone="no" ?>

    <!DOCTYPE regSkjema [
    <!ENTITY % skjema SYSTEM "http://registrar.no/dokumentasjon/klient/xml/skjema.dtd" />
    %skjema;
    ]>

    ...resten av xml-dokumentet

Det hvert å merke seg at DTD er en forkortelse som står for både Document Type Declaration og Docucument Type Definition. Den første betydningen av forkortelsen referer til selve DOCTYPE elementet i XML-dokumentet, den andre referer til deklarasjonene DOCTYPE-elementet innholder. Slik at såkalte eksterne tillegg over også kan betegnes som DTD til dokumentet. Over har vi kun benyttet DTD i betydninge Document Type Declaration.
XML Schema
Ideen med XML Schema er kunne formalisere regler for validering av XML-dokument. I praksis betyr det at en definer hvordan struktur og innhold til XML-dokumentet skal være ved bruke språket definert i XML Schema. Dermed kan samme validering-prosessor/programm brukes til &arging; validere ulike XML-dokumenter med hensyn til lovlig form og innnhold.

Selve skjema kan kan være en del av XML-dokumentet eller i en seperat fil. Ved bruk av separat fil må lokasjonen oppgis i første elementet i XML-dokumtet. Anta at XML skjema som skal brukes for å validere XML-dokumente hentes fra web med følgende adresse http://registrar/dokumentasjon/klient/xml/regSkjema.xsd. I eksemplet nedenfor assosiorer man først prefikset xsi med standard navnerommet til XML Schema. Deretter tilordnet XML Schema atributtet noNamespaceChemaLocation adressen til XML Skjemaet for dokumentet.

<regSkjema1
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://registrar/dokumentasjon/klient/xml/regSkjema.xsd">

I XML Schema defineres ett element enten som simple eller complex. Simple elementer inneholder kun PCDATA verdi. De er ikke tommme, har ikke atributter og inneholder ikke andre elementer. Vi vil se på hvordan en setter opp regler for simple elementeri ved å bruke XML Schema. Nedenfor eksempler nedenfor er det satt opp regler for noen elementene i XML-dokumentet regSkjema1 som vi brukt tidligere som eksempel.

<?xml version="1.0"? ">
<xs:schema xmlns="http://www.w3.org/2001/XMLSchema">

<xs:annotation>
<xs:documentation>
Her kan en skrive en kommentar. Denne kommentaren blir parsert av validerings programmet.
</xs:documentation>
</xs:annotation>

<xs:element name="regSkjema1">
<xs:complexType>
<xs:sequence>

<xs:element name="advarsel" type="xs:string"/>
<xs:element name="overskrift" type="xs:string"/>
<xs:element name="tekstCelle" type="xs:string"/>

</xs:sequence>
</xs:complexType>
</xs:element name="regSkjema2">
</xs:schema>

Et XML skjema er også et XML-dokument, der navnrommet defineres. Innenfor "documentation" i "annotion"-elementet kan en skrive kommentarer. "annotation" kan plasseres hvor som helst. Det er også mulig å bruke vanlig HTML-kommentarer , men disse blir oversett av validerings-programmet. For alle de ulike taggene i XML-dokumentet må XML-skjemaet innholde minst et "xs:element" med matchende navn. "xsd:elementet" innholder informasjon om hvilke noder det har under seg. Alle element-noder kan ha under seg tekst-noder, element-noder og atributt-noder. Tekst- og atributt-noder innholder kun en tekststreng. Lovlig format til tekststrengen kan spesifseres ved hjelp av en rekke faste formater, se http://www.w3.org/TR/xmlschema-0/#CreatDt. Har xs:element kun en tekst-node under seg kalles xs:simpleType alle andre xs.element er xs:complexType. De simple elementene i eksemplet over er "advarsel", "overskrift" og "tekstCelle". Atributtet "type" definer hvilken datatype elementene kan innholde. I eksemplet over er det "string" altså tekst. Av standard standard datatyper kan nevnes xs.date krever format YYYY-MM-DD, xs.time krever format hh:mm:ss, xs.decimal krever desimaltall, xs.integer krever heltall, sx.positivInteger krever 1,2,3.... Det er også mulig definere sine egen typer.

"node"- og "type"-deklarasjoner kan benyttes omigjen i ved å bruke av henholdvis "ref"- og "type"-atributtet" i "xs.elementet". Dette er kun mulig å referer til elementer som er globalt definert. Elementer deklarett direkte i første node-element i treet er globale. I eksemplet over er node-elementene "advarsel" og "overskrift" samt type-elementene "regType1", "tabelType1!, "trType1" og "tdType1" globalt deklarert, mens node-elementene "tekstCelle", "boksCelle" og "knappCelle" er lokalt definert. Node-elementene "advarsel" og "overskrift" blir først innlemmet i tre-strukturen når de blir referert til.

xs:simpelType
Dette elementet benyttes til å definere en mengde med tekst-strenger. Det kan gjøres ved å trekke fra og gjøre tillegg til de forhåndsdefinerte mengdene. I eksemplene nedenfor benyttes regular expression og enumeration for å utrykke mengden en ønsker.
<xsd:simpelType navn="skandinavia">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="norge">
<xsd:enumeration value="sverige">
<xsd:enumeration value="danmark">
</xsd:restriction>
</xsd:simpelType>

<xsd:simpelType name="telefonummer">
<xsd:restriction base="xsd:string">
<xsd:pattern value="+47 \d{8}">
</xsd:restriction>
</xsd:simpelType>

Den første typen tillater tillater: norge, sverige, danmark. Den andre typen tillater 8 sifferet nummer prefikset med "+47 ". For utrykke dette er "regular expression" benyttet, for nærmere forklaring se f.eks. www.perldoc.com .

xsd:complexType
Dette elementet benyttes til å definere en mengde med noder. Har et node-element mer enn kun en tekst-node under seg må dette spesifisers i et complexType-element. I XML-schema for registreringsskjemaet over ser vi at elementet innholde "xsd:element"- og "xsd:attribute"-elementer. Ved å pakke "xsd:elementene inn i "xsd:sequensce"- eller "xsd:all"-element angir en om elementene skal kommer i en rekkefølge eller hvilkårlig rekkefølge. Pakkes elemenene inn i et "xsd:choice"-element skal kun eksistere i XML-dokumentet. Ved bruk av "minOccours" og "maxOccours" atributtene kan en bestemme hvor mange ganger elementene skal forekomme. Tilsvarende er mulig å sette "use='required'" atributtet i "xsd:attribute" for dermed å kreve at det skal eksistere i XML-dokumentet.

Ved å sette atributtet "mixed='true'" i "xs:complexType" er det lovlig med tekst i XML-dokementet mellom elementene som er spesifisert her.

For ytterligere informasjon se http://http://www.w3.org/XML/Schema

Tegnsett i XML
Det finnes to aksepterte standarder for å nummerere av alle verdens ulike språk-tegn: ISO/IEC 10646:1993 og Unicode 2.0. Begge standardene er heldigvis for alle praktiske formål identiske. Organisasjonen bak standardene er enige om lik nummering alle tegn i posisjon 0-1114111. Dette området er heretter kalt UCS (Universal Character Set). Det er ingen trivell oppgave å identifisere hva som er like og ulike tegn. Hvor mange ulike tegn er det f.eks. i følgende sekvens (ser bort fra blanke tegn): a A a a a a. Dagens programmerere er vant til at svaret er 2, og dette er heldigvis også tilfelle i UCS. Det er idag definert rundt 40 000 tegn i UCS. Alle tegnene er tilordnet nummer innenfor området 0-65535, dette kalles det Basic Multilingual Plane (BMP). BMP er videre oppdelt i bl.a. følgende områder: General Script, Symbols, CJK phonetics, CJK ideographs. General Script området går fra 000016 til 1FFF16 og innholder de mindere tegnsettene benyttet i spåkene: Latin, slavisk, cyrillic, arabisk, greek, hebraisk, tyrkisk etc. Symbols området går fra 200016 til 2FFF16 og innholder bl.a. spesielle mattematiske og tekniske symboler. CJK phonetics benytes til kinesiske-, japanske- og koreanske-tegn.

UCS er kompatibel med US-ASCII, ISO 6429 og ISO 8859-1 (Latin-1). US-ASCII er mange vant til å bruke og standarden nummerer tegn i området fra og med posisjon 32 til og med 126. Kontrolltegnene i posisjon 0-31 og 127 er definert i standarden ISO 6429. ISO 8859 er i området 0-127 ekvivalent med US-ASCII, posisjonene 128-160 er udefinert og området 160-255 nummerer vanlige skriftegn i vest-europa.

Det er fem standard metoder å kode UCS til bit mønster.

  • UCS-4 benytter 4 byte til å lagre den binære representasjonen av posisjon-nummeret.
  • UCS-2 benytter 2 byte til lagre den binære representasjonenen av posisjon-nummeret. UCS-2 kan kun representere BMP (65.536 første tegn i UCS). 2048 tall i området D80016 til DFFF16 er reservert.
  • UTF-16 (Universal character set Transformation Format 16 bits) er ekvivalent med UCS-2 for alle tegn i BMP, men kan også representere posisjonene 65.536 til 1.114.111. For posisjoner over 65.536 blir det blir representasjon i et par byte (2 byte) erstattet av to par av byte. Hvert par kalles henholdvis høyt og lav erstatnings par. Høyt og lavt erstatningspar inneholder en av 2046 reserver verdiene. Det reserverte området på 2048 tall er delt i to soner på hver 1024 tegn. Høyt erstatninspar innholder verdier fra D80016 til DBFF16 og de neste 1024 verdiene fra DC0016 til DCFF16 benyttes av lavt erstatningspar. Selve utregning av posisjonnummer ut fra erstatningsparet er som følger der H=er heksidesimal verdi til høyt erstatningpar og L er heksadesimalverdi til lavt erstatningspar:
    N=(H-D80016)*40016+(L-DC0016)+1000016
  • UTF-8 benytter fra 1 til 4 byte for å lagre posisjonnummerene i UCS. Antall byte er avhengig av hvilke posisjon som representeres. UTF-8 er kompatibel med ISO 8859-1 (Latin 1).
  • UTF-7 benytter også variablet antall byte for å lagre posisjonsnummerene i UCS, men her benyttes kun 7 minst signifikante posisjonen i hver byte.
Karakter settet til XML-dokumenter er UCS, men alle kontroll-tegn i posisjon 0-32 er forbudt, med untak av 9 (tab), 10 (linjeskift), 13 (vognretur). Det reserverte området som benyttes av erstatningsparene er forbudt. I XML-dokumentet kan en refere til alle UCS-karakter ved bruk referanser på formen &#233; for desimal referanse til tegnet é. Tilsvarende referanse i heksadesimal er &#xE9;.

Mottager av XML-dokumenter må informers om hvordan tegnsettet er kodet. Detter kan gjøres av webserver ved å benytte "charset" parameter i MIME spesifiskasjon i content-type hode-feltet:

  • Content-type: text/xml; charset=UTF8
Mange server sender dessverre ikke karaktersett informasjon og derfør bør XML dokumenter innholde følgende deklarasjon
  • <?xml encoding='UTF8' ?>
I HTML-dokumenter kan en legge karaktersett til Contet-type hodefeltet ved hjelp av meta-taggen:
  • <meta http-equiv="Content-type" content="text/html"; charset="ISO-8859-1">
XSL-FO
XSL-FO prosessor kan lese XSL-FO dokumenter å skrive de ut i mange forskjellige utskriftsformater som pdf, postscript, pcl, afp. XSL-FO standarden er definert av W3C. Java basert XSL-FO prosessor kan lastes ned fra http://xmlgraphics.apache.org/fop/1.0/. Etter utpakking av zip-filen kan en starte programmet fob.bat i Microsoft kommando-vindu. Husk stå i samme katalog som fob.bat.

XSL-FO dokumentet innholder selve teksten som skal skrives ut og informasjon om hvordan denne teksten skal se ut. XSL-FO språket er kraftig nok til at det kan beskrive layout til artikler og bøker. XSL-FO dokumentet starterb med definisjon av de fysiske målene til sidene som skal skrive ut/på samt bredder og høyde på marger og footer og header etc. En definerer gjerne flere forskjellige typer sider med hensynt til første side, siste side, odde eller likt sidenummer. Deretter kommer selve det tekstlige innholdet som en lang rekke av blokker. Hvert kapittel er en blokk, hver overskrift er en blokk, hvert avsnitt er blokk, hvert linjeskift er en blokk. Til hver blokk er det mulig å spesifisere en lang rekke parametere, som avstand til neste blokk, skriftstørrelse, skrifttype, bakgrunnsfarge, rammer etc. Selve XSL-FO prosessoren legger da blokken inn i de forhåndsefinerte siden og prøver ta hensyn til alle kravene som er angitt i blokkene.

<xml version="1.0" encoding="UTF-8">
<fo:root xmlns:xlink="http://www.w3.org/1999/XSL/Format" >

<fo:layout-master-set>

<!-- SIDE MED ODDETALL SIDENUMMER -->
<fo:simple-page-master
master-name="odd"
page-height="29.7cm"
page-width=#21.0cm"
margin-top="2cm"
margin-bottom="2cm"
margin-left="3.5cm"
margin-right="1.5cm">

<fo:region-body
margin-top="2cm"
margin-bottom="2cm"/>

<fo:region-before
region-name="odd-before"
extent="2cm"/>

<fo:region-after
region-name="odd-after"
extent="2cm"/>

<fo:region-start
region-name="odd-start"
extent="2cm"/>

<fo:region-end
region-name="odd-end"
extent="1cm"/> </fo:simple-page-master

<!-- SIDE MED PARTALL SIDENUMMER -->
<fo:simple-page-master
master-name="even"
page-height="29.7cm"
page-width=#21.0cm"
margin-top="2cm"
margin-bottom="2cm"
margin-left="1.5cm"
margin-right="3.5cm">

<fo:region-body
margin-top="2cm"
margin-bottom="2cm"/>

<fo:region-before
region-name="odd-before"

extent="2cm"/>

<fo:region-after
region-name="odd-after"

extent="2cm"/>

<fo:region-start
region-name="odd-start"

extent="1cm"/>

<fo:region-end
region-name="odd-end"
extent="2cm"/>

</fo:simple-page-master/>

<!--DETTE ELEMENTET VELGER KORREKT SIDEMAL -->
<fo:page-sequence-master
master-name="kapittel">
<fo:repeatable-page-master-alternatives>

<fo:conditional-page-master-reference
master-reference="odd"
page-postion="rest"
odd-or-even="odd" />

<fo:conditional-page-master-reference
master-reference="even"
page-postion="rest"
odd-or-even="even" />

</fo:page-sequence-master>

</fo:layout-master-set>

<!--SLUTT PÅ DEFINISJON AV SIDENE -->

<fo:page-sequence
master-reference="kapittel"
force-page-count="even"
initial-page-number="1">

<fo:flow flow-name="xsl-region-body">
<fo:block>
Her skulle det ha vært flere sider med tekst
</fo:block>

<fo:block break-before="page"/>
</fo:flow>

</fo:page-sequence>

XSL-FO dokumentet over begynner med deklaring av XML standard og navnrommer. Første/ytterste elementet i XSL-FO dokumentet skal alltid hete "root". Elementene "simpel-page-master" med "master-name" lik "odd" og "even" definere henholdvis side opp for oddetall sider og partall sider. I hver element definer størrelsen på siden, bredde på margene. Elementet har 5 element-barn. Hvert element tilsvarer et områ på siden. Førstge barne elementet "region-body" er omr&arign;det innenfor margene oppgitt til siden. "region-body" områ kan også ha marger. De neste 4 elementen er områder langs de fire sidene til "body-region". De 4 områ er innenfor "body-region" uten hensyn til dens marger. Øverst og nederst er henholdvis "region-befor" og "region-after". Langs venstre og &hoslash;yre kant er henholdvis "region-start" og "region-end". Atributtet "extent" angir bredden på området. topp og bunn områ gå langs hele topp- og bunn-linjen.

Det er fo:flow som skriver ut selve teksten. Elementet hvilket område på side det skriver til. I dette tilfelle "region-body". Dette elementet er definert innenfor fo:page-sequence som referer til sidemalen som skal benyttes. I dette tilfelle referer den til page-sequence-master elementet som innholder en switch. Switchen returner korrekt sidemal i hensyn til om sidenummeret er oddetall eller partall. Selve teksten som skrives er innenfor en blokk-element.

Det finnes fire typer blokk elementer

  • fo:block
  • fo:block-container
  • fo:list
  • fo:table
Nedenfor følger eksempler på blokk elemente. Et fo:block element kan innholde fo:block og andre blokk elementer og visa versa.

<!-- DETTE ER ET fo:block ELEMENT -->
<fo:block font-size="12pt"
font-family="sans-serif"
font-weight="bold"
line-height="15pt"
space-after.optimum="13pt"
text-align="justify">
Dette er et avsnitt som avsluttes med linjeskift
</fo:block>

<!-- DETTE ER ET fo:table ELEMENT -->
<fo:table border-collapse="separate">
<fo:table-column column-width="5cm"/>
<fo:table-column column-width="3cm"/>

<fo:table-body>

<fo:table-row>
<fo:table-cell border-bottom-color="black" border-bottom-width="0.1pt" border-bottom-style="solid">
<fo:block text-align="start">
Dette er rute 1. Bredden er fast. Cellen vokser nedover ved mye tekstelig innhold
</fo:block>
</fo:table-cell>

<fo:table-cell border-bottom-color="black" border-bottom-width="0.1pt" border-bottom-style="solid">
<fo:block text-align="end">
Dette er rute 2
</fo:block>
</fo:table-cell>
</fo:table-row>

</fo:table-body>
</fo:table>

<!-- DETTE ER ET fo:list ELEMENT -->
<fo:list-block>
<fo:list-item>
<fo:list-item-label>
<fo:block>&#2022;</fo:block>
<fo:list-body>
<fo:block>Dette er første liste element</fo:block>
</fo:list-body>
</fo:list-item>
</fo:list-block>

Elementet "fo:block" over vil skrive ut teksten "Dette er et avsnitt som avsluttes med linjeskift". Det vil bruke fonten sans-serif bold i 12p størrelse. Etter blokken vil det lages et mellomrom på 13 pt. Elementet fo:table vil skrive ut en tabell med to ruter. Hver rute har en sort linje langs nederste kant. Første rute vil inneholde teksten "Dette er rute 1. Bredden er fast. Cellen vokser nedover ved mye tekstelig innhold". Teksten i første rute vil være venstre justert og i andre ruten vil den være høyere justert. Det er ikke angitt font-type, dermed vil elementet arve disse egenskapene av sine forfedre. Listen innholde kun ett element. Elementet er prefikset med "bullet" tegnet. Blokk elementene har mange atributter og muligheter.

SVG (Scalable Vector Graphics)
W3C rekomandasjonen (standarden) for SVG 1.1 er http://www.w3.org/TR/SVG/Overview.html.

w3schools.com har laget en meget bra oversikt med gode eksempler over de ulike elementene i standarden og hvilken grafiske former de tegner se http://www.w3schools.com/svg/

XLink
XLink (XML Linking Language) definerer hvordan en kan linke XML-dokumenter til andre ressurser (identifisert av url) på webben. På "øverste nivå" definerer XLink to typer linke-elementer: simple-link-element og extended-link-element.


I figuren ser vi at simple-link-element definerer en relasjon mellom lokal og ekstern ressurs. Denne relasjonen er enveis fra lokal til ekstern ressurs. Ressurs er noder på weben identifisert av url. Simpel-link-elementet er en del av den lokale ressursen. Den lokale ressursen må dermed være et XML-dokument. Det er også mulig å spesifisere linker internt i den lokale-ressursen. <IMG> og <A> elementet i HTML kan erstattes av simple-link-element.

Extended-link-element definerer relasjoner mellom flere ressurser. Alle ressurs en ønsker å definer linker til/fra definert i et locator-element inne i extended-link-elementet. Deretter kan en ved arc-elementer definer linker mellom ressursene. Det er mulig å definer linker mellom du eksterne ressursene eller mellom lokal og ekstern ressurser. Selve extended-link-elementet kan være i et eget xml-dokument eller del av et annet xml-dokument. Hvordan dette blir implimentert i nettleseren blir spennende å se, men det ligger til rette for å erstatte bokmerk-lister og mulighet for å publiser disse. Systemet gir også betydelig enklere vedlikehold av linker. Det er kun nødvendig å endre url til ressursen og alle linkene er oppdatert.

Et vilkårlig element kan gjøres om til link-element. Krav til elementet er at det må inneholder atributtet "type" med en av verdien: simple, extended, locator, arc, resource, title, none. For at "type" skal bli tolket å tilhøre XLink standarden må det prefikset med et navn som er knyttet til XLink-navnerommet. Navnerommet til XLink er http://www.w3.org/1999/xlink. Se over for omtale av navnerom. Nedenfor følger eksempler på bruk av to simple-link-elementer til samme bilde:

<regSkjema1 xmlns:xlink="http://www.w3.org/1999/xlink" >

<xlink:simple xlink:href="bilde.gif" xlink:role="image" xlink:title"test bilde" xlink:show="embeddded" xlink:actuate="onload" />
<bilde xlink:type=simple xlink:href="bilde.gif" xlink:role="image" xlink:title"test bilde" xlink:show:embeddded" xlink:actuate="onload" />

</regSkjema1 >

Link-elementene over er litt forskjellig. Det første er et mer rent link-element. Det andre elementet er blitt tilordnet linke egenskaper ved at det innholder atributtet xlink:type. Videre ser vi at link-elementer kan ha en rekke atributter. Totalt definert standarden 10 atributter. Her følge omtale av noe i av de som er brukt over:

  • xlink:href tilordnes på vanlig måte url til noden som det sett opp en lenke til.
  • link:show kan tilordnes følgende verdier: replace, embedded og new. Replace erstatter dokumentet vist i nettleseren. Embedded inkluderer noden i websiden. New viser noden i nytt nettleser-vindu.
  • xlink:acuate bestemmer når ekstern node skal hentes og kan tilordnes verdiene: onRequest og onLoad.
  • link:role og link:title er kun semantiske atributter og kan fritt tilordnes verdier.

Nedenfor følger eksempel på bruk av extended-link-element

<regSkjema1 xmlns:xlink="http://www.w3.org/1999/xlink">

<xlink:extended>
<xlink:locator xlink:href="http://registrar.no/a.html" xlink:label="A" />
<xlink:locator xlink:href="http://registrar.no/b.html" xlink:label="B" />
<xlink:locator xlink:href="http://registrar.no/c.html" xlink:label="C" />
<xlink:locator xlink:href="http://registrar.no/d.html" xlink:label="D" />
<xlink:resource xlink:label="L" />

<xlink:arc xlink:from="A" xlink:to="D" xlink:show="replace" xlink:actuate="onRequest" />
<xlink:arc xlink:from="D" xlink:to="A" xlink:show="replace" xlink:actuate="onRequest" />
<xlink:arc xlink:from="D" xlink:to="C" xlink:show="replace" xlink:actuate="user" />
<xlink:arc xlink:from="C" xlink:to="B" xlink:show="replace" xlink:actuate="onRequest" />
<xlink:arc xlink:from="L" xlink:to="D" xlink:show="replace" xlink:actuate="onRequest"/>
</xlink:extended xlink:show="replace" xlink:actuate="onRequest" />
</xlink:extended>

</regSkjema1 >

extended-elementet innholder locator-, arc- og resource-elementer som er kort beskevet nedenfor.

  • xlink:locator benyttes til å identifisere eksterne ressurser. Elementet inneholde minimum atributtet href som tilordnes url til en ekstern ressurs og atributtet label som tilordnes et vilkårlig navn på dette elementet.
  • link:arc beskriver linker mellom locatorer. Elementet innholder minimum traverserings-atributtene "to" og "from" som tilordnes label-navn på locator-elementer.
  • xlink:resource benyttes for gi navn til den lokale ressursen.
For videre fordypning anbefales standarden, se her XLink 1.0

XPointer
XPointer kan i samspill med XLink lage lenker til deler at dokument. Url angitt i XLink atributtet xlink:href blir tillagt følgende: #xpointer(XPath-Expression). Eksemplet nedenfor er en lenke til celle 2 på side1.xml på http://registrar.no/dokumentasjon/klient/xml/side1.xml

<xlink:simple
xlink:href="http://registrar.no/dokumentasjon/klient/xml/side1.xml#xpointer(id('celle2'))"
xlink:show="replace" xlink:actuate="onload" />

For to spesialtilfeller er det definer forkortete skrivemåter som går utover XPath-standarden. Tilfellende kalles henholdvis "kun navn" og "sekvens av barn". I det første tilfelle må elemente ha atributtet id. Eksemplet over kan forkortes som følger (legge merke til href-verdien har tilsvarende tolkning i HTML):

<xlink:simple
xlink:href="http://registrar.no/side1.xml#celle2"
xlink:show="replace" xlink:actuate="onload" />

Tilfellet kalt "sekvens av barn" gir mulighet for oppgi en sti til elementet. På hvert nivå i nodetreet angir en nummer til noden i stedet for navnet. Vi benytter igjen samme eksempel og stien blir som følger:

<xlink:simple
xlink:href="http://registrar.no/dokumentasjon/klient/xml/side1.xml#/1/2/1/2"
xlink:show="replace" xlink:actuate="onload" />

XPointer kan selvsagt også benyttes i samspill med andre standarder. For vider fordyping se her XPoint 1.0.

XForm
W3C har pt. siste interne gjennomgang av XForm spesifikasjonene før de skal på ekstern høring. Standardiseringsarbeidet med XForms 1.0 vil trolig pågå i 2-3 år til. XFroms er, som navnet indikerer, XML versjonen av HTML-forms.