Introduktion til XML Schema

DTD'er, Document Type Definition, har indtil videre været måden at definere XML-data på. I maj måned færdiggjorde World Wide Web-konsortiet den færdige specifikation for XML Schema, som vi gennemgår i denne artikel.

XML-følgeteknologier

XML har en mængde følgeteknologier, som standardiserer løsninger på ofte forekommende problemer i forbindelse med anvendelsen af XML. De vigtigste af disse teknologier er XSLT, der definerer transformering af XML-dokumenter til nye XML-dokumenter, og teknologierne XPath, som beskriver hvorledes man kan navigere rundt i XML-dokumentets træ, XPointer og XLink som beskriver hyperreferencer i XML-dokumenter, og XML Namespaces som beskriver, hvorledes forskellige XML-vokabularier kan indlejres imellem hinanden i samme dokument.

Fælles for alle disse teknologier er, at de er defineret som XML, hvilket jo er ret oplagt. Men når man skal definere et XML-dokuments syntaks og semantik har man indtil i sommers været henvist til DTD'er - Document Type Definitions. DTD'er benytter en ganske anden formulering end XML, og derfor har der naturligt nok været efterspurgt en XML-teknologi, der kan definere XML-sprog.

Hvorfor DTD
Der er to krav til XML-dokumenter: De skal være velformede (well-formed), og de skal være gyldige (valid). Ved velformethed forstås, at syntaksen opfylder reglerne for XML. Det er regler som følgende: XML-mærker må ikke overlappe, XML-mærkernes navne er case-sensitive (store og små bogstaver er signifikante), enkelt-stående mærker skal afsluttes med en skråstreg sidst i mærket. Disse regler gælder for alle XML-dokumenter, uanset hvilket vokabularium de benytter.

Derudover skal et XML-dokument også være gyldigt: Det skal overholde de regler, som det konkrete vokabularium kræver. Det er ting som mærkernes navne, hvor mange gange de kan optræde, i hvilken sammenhæng de kan optræde med mere.

Formålet med DTD'er

Formålet med DTD'er og XML Schemas er oplagt. De definerer, hvorledes et XML-sprog er opbygget, og dermed kan man sikre sig, at data er repræsenteret på den rigtige facon. På den måde ved man, at XML-data passer ind i en underliggende applikation. Mere konkret specificerer DTD'er og XML Schema to ting: Dokumentets struktur og elementernes datatype.

En meget simpel DTD-definition kan for eksempel se sådan ud:

<!DOCTYPE  [
  <!ELEMENT Bogliste (Bog)+>
  <!ELEMENT Bog (Titel, Forfatter, ISBN)>
  <!ELEMENT Titel (#PCDATA)>
  <!ELEMENT Forfatter (#PCDATA)>
  <!ELEMENT ISBN (#PCDATA)>
]>

Ovenstående DTD definerer et XML-sprog, hvis rod-element er Bogliste, som består af en eller flere Bog-elementer. Hver enkelt Bog-mærke består så af et Titel-mærke, et Forfatter-mærke og et ISBN-mærke. De enkelte mærker består af #PCDATA, som betyder Parsed Character Data, hvilket blot betyder tekststrenge. Et XML-dokument defineret ved ovenstående DTD kunne for eksempel se sådan ud:

<Bogliste>
  <Bog>
    <Titel>Homepage Usability</Titel>
    <Forfatter>Jakob Nielsen</Forfatter>
    <ISBN>0-7357-1102-X</ISBN>
  </Bog>
  <Bog>
    <Titel>XML i praksis</Titel>
    <Forfatter>Jakob Kristiansen</Forfatter>
    <ISBN>87-7843-424-6</ISBN>
  </Bog>
</Bogliste>

XML Schema: Derfor
DTD'er har nogle svagheder. For det første er der ikke nogen grund til at benytte et selvstændigt sprog med egne regler til at definere XML-sprog. XML er mindst lige så velegnet til formålet, og så behøver man ikke to sprog.

Derudover mangler DTD'er en god understøttelse af datatyper. Man kan for eksempel ikke definere, at et givet element må indeholde heltal mellem 1 og 10. I XML Schemas er der 44 datatyper som udgangspunkt, og derudover kan man definere sine egne datatyper.

XML namespaces

XML namespaces
En anden fordel ved XML Schemas er, at de sammenkobler dokumenterne med deres definition. Et XML Schema definerer ikke bare hvorledes XML-dokumentet skal se ud, men definerer også et navnerum, XML namespace. Det kan benyttes til at blande forskellige forskellige vokabularier. Herunder er et eksempel, hvor navnerummet RDF, som specificerer metadata, er blandet med navnerummet dc, som definerer enkelte, kontekst-specifikke metadata.

<rdf:RDF
  xmlns:rdf="http://www.w3.org/TR/WD-rdf-syntax#"
  xmlns:dc="http://purl.org/dc/elements/1.0/">
  <rdf:Description
  about="http://www.pcworld.dk/Default.asp
  ?ArtikelID=2705">
   <dc:Title>Metadata giver
   masser af mening</dc:Title>
   <dc:Creator>Tania Andersen</dc:Creator>
  </rdf:Description>
</rdf:RDF>

I rod-mærket defineres de to navnerum med en URI, en generaliseret webadresse, som peger på det sted på nettet, som definerer navnerummet. Navnerum er en særdeles stærk funktion i XML, da man ellers skulle definere et nyt Schema eller DTD, hver gang man ønsker at blande mærker fra forskellige sprog. Det lægger også op til genbrug af andres løsninger, så hjulet ikke skal genopfindes hver gang, behovet opstår.

Ved hjælp af XML Schemas kan man skabe en formel sammenhæng i mellem navnerum og dokument.

Fra DTD til Schema

Fra DTD til Schema
De flere muligheder i XML Schema betyder også, at definitionerne bliver lidt mere fyldige. Vores simple Bogliste-DTD fra før kunne repræsenteres således i XML Schema:

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               targetNamespace="http://www.boglister.dk"
               xmlns="http://www.boglister.dk"
               elementFormDefault="qualified">
   <xsd:element name="Bogliste">
      <xsd:complexType>
        <xsd:sequence>
           <xsd:element ref="Bog" minOccurs="1"
           maxOccurs="unbounded"/>
        </xsd:sequence>
      </xsd:complexType>
   </xsd:element>
   <xsd:element name="Bog">
      <xsd:complexType>
        <xsd:sequence>
           <xsd:element ref="Titel" minOccurs="1"
           maxOccurs="1"/>
           <xsd:element ref="Forfatter" minOccurs="1"
           maxOccurs="1"/>
           <xsd:element ref="ISBN" minOccurs="1"
           maxOccurs="1"/>
        </xsd:sequence>
      </xsd:complexType>
   </xsd:element>
   <xsd:element name="Titel" type="xsd:string"/>
   <xsd:element name="Forfatter" type="xsd:string"/>
   <xsd:element name="ISBN" type="xsd:string"/>
</xsd:schema>

Schemaet er væsentligt mere omfangsrigt end DTD'en, men også mærkbart mere læsevenligt. Det første mærke, der defineres, er bogliste. Det er af typen complexType, som er mærker, der indeholder indlejrede børne-mærker. Af definitionen læses, at mærket <Bogliste> består af mindst et <Bog>-mærke. Dette angives med attributterne minOccurs og maxOccurs. Ved at læse videre ses, at et <Bog>-mærke også er af typen complexType, altså indeholder børne-mærker. Det ses af et <Bog>-mærke består af de tre mærker <Titel>, <Forfatter> og <ISBN>, der hver skal optræde netop én gang inden i et <Bog>-mærke.

De tre vigtigste mærker i XML Schema er <element>, som definerer et enkeltstående mærke. Dernæst er der mærket <complexType> som angiver et mærke med indlejrede børne-mærker. Det tredie mærke <simpleType>, som ikke optræder i eksemplet herover, definerer en type ud fra en af de indbyggede typer, som XML Schema tilbyder. I eksemplet herover benyttes string-typen nederst i schema-definitionen, hvor de tre mærker Titel, Forfatter og ISBN defineres.

Læs videre
Websitet Xfront.com har en glimrende, omfangsrig PowerPoint-introduktion med masser af eksempler, og den kan i parentes bemærket også læses i StarOffice.

XML Schema hører hjemme hos World Wide Web-konsortiet, og der kan man finde specifikationen og mange links til ressourcer vedrørende XML Schema.

Annonce

Vallensbæk Kommune

NIS2-konsulent til Digital sikkerhed

Københavnsområdet

Statens IT

Erfaren Omada-specialist til Statens IT

Københavnsområdet

Forsvarsministeriets Materiel- og Indkøbsstyrelse

DevOps Engineer (AI) til Forsvarets nye IT-platform

Midtjylland

Capgemini Danmark A/S

Java Engineer

Københavnsområdet

Annonceindlæg fra Barco

De vigtigste samarbejdstrends, som enhver IT-leder bør holde øje med

I lang tid har samarbejdsbranchen fokuseret på at forbedre enhedsfunktioner – bedre kameraer, klarere lyd og smartere software. Men den virkelige forvandling handler ikke om funktioner.

Navnenyt fra it-Danmark

IFS Danmark A/S har pr. 1. september 2026 ansat Gustav Olsen som Business Development Representative. Gustav skal især beskæftige sig med forretningsudvikling & identificering af muligheder med fokus på AI, automatisering og optimering af forretningsprocesser. Gustav kommer fra en stilling som Business Development Specialist hos SAP Danmark A/S. Gustav er uddannet Cand.merc Sales Management. Gustav har tidligere beskæftiget sig med forretningsudvikling og salgsstrategi inden for ERP-teknologi. Nyt job

Gustav Olsen

IFS Danmark A/S

Netip A/S har pr. 11. august 2026 ansat Emil Kristoffersen som IT-Supporterelev ved netIP's kontor i Thisted. Han er uddannet Fisker, - Emil har dermed valgt et karriereskifte. Nyt job

Emil Kristoffersen

Netip A/S

Norriq Danmark A/S har pr. 1. januar 2026 ansat Allan Kimmer Jensen som Lead Solution Architect. Han skal især beskæftige sig med at sikre vores kunder får en verdensklasse brugeroplevelse gennem stærk frontend-arkitektur og kodekvalitet. Han kommer fra en stilling som Freelance Consultant hos Remmik. Han er uddannet hos Center for Medie og Kommunikation, Roskilde. Nyt job

Allan Kimmer Jensen

Norriq Danmark A/S

Netip A/S har pr. 1. august 2026 ansat Thomas B. Steffensen som Seniorkonsulent ved netIP's kontor i Thisted. Han kommer fra en stilling som Senior IT/OT Network Consultant hos Frontmatec. Nyt job