INNEHÅLLSFÖRTECKNING
1.1.4. Documemt type declaration
En Document Type Declaration är en deklaration i xml-dokumentet vars syfte är att det finns en Document Type Definition (DTD) samt var den finns. Det gäller här att hålla isär begreppen Document Type Declaration samt Document Type Definition. Den sistnämnda är en samling regler för hur xml-dokumentet får byggas upp och den förstnämnda är en deklaration som talar om vilken DTD som skall användas.
I DTDn deklarerar man alltså struktur och element (och relationen dessa emellan) för ett giltigt xml-dokument. Detta innebär att man kan ange vilka element som är tillåtna i xml-dokumentet och hur relationen mellan dem måste vara. Ett exempel att beskriva detta på skulle kunna vara följande: Man tänker sig att man har ett brev vars struktur och innehåll skall beskrivas med hjälp av xml.
Brevet är (enkelt sett) uppbyggt på följande vis:
Man skulle självklart kunna gjort en mer detaljerad uppdelning – men denna kommer ändå kunna exemplifiera det vi vill. Brevet består således av tre stycken huvududelar; Adressat, Avsändare och Text. Adressat består av Namn, Gatuadress och Postadress. Avsändare består av Namn och Text består av Hälsningsfras, Innehåll och Avslutningsfras. En hierarkisk avbildning av detta ser ut som följer:
Brev Adressat Namn Gatuadress Postadress Avsändare Namn Text Hälsningsfras Innehåll Avslutningsfras
Figur XX: Exempel på strukturering av ett brev
Brev
______________________________________________________________________________
(Adressat), Sender (Avsändare) samt Text (Text). Inga andra element får ligga direkt under elementet Letter. Likadant skulle vi ange reglerna för de element som är underordnade de tre element vi just beskrivit osv. På detta sätt kan man således försäkra sig om att xml-dokumentet är giltigt (valid) – dvs. det följer de regler som beskrivs i DTDn. Man kan även inkludera DTDn direkt i xml-dokumentet om man vill – men detta kan vara opraktiskt om man skulle behöva ändra något i DTDn och man har samma DTD för ett antal olika xml-dokument eftersom man då måste in och ändra i allihopa istället för att endast ändra i DTD-filen.
Ett prolog-exempel samt en schematisk bild av prologen ges nedan:
XML-deklaration: <?xml version=”1.0” encoding=”UTF-8”?> Kommentar: <!-- XML-dokument skapat 2001-02-30 --> PIs (även xml-deklarationen är en PI): <?cb .epd?> DTDeklaration: <!DOCTYPE SYSTEM ”external_file.dtd”>
Prolog Processing Instructions (PIs)
Kommentarer DTDeclaration eller DTDefinition
1.2. Root
De huvudsakliga byggstenarna i rooten är element, entiteter, kommentarer, PIs samt PCData och CDATA. Rooten i sig är ett element som innesluter alla tidigare nämnda delar. I följande exempel är <exempel> root – men det vanligaste är att man namnger rooten just ”root” eller ”document”.
<?xml version=”1.0” encoding=”UTF-8” standalone=”yes”?> <exempel>
Detta är ett enkelt exempel. </exempel>
1.2.1. Element
Nedan följer ett exempel på vad ett element är för något då vi beskriver en skiva:
<album>
<artist>Foo Fighters</artist>
<titel>The color and the shape</titel> <format typ=”CD”/>
<antal_låtar>13<antal_låtar/> </album>
Här är ”titel” en så kallad tag. Området från start-tag till slut-tag – <titel>The color and the shape</titel> - är ett element och texten ”The color and the shape” är elementets innehåll. Man kan själv välja vad elementet skall heta så länge som man ser till att ha en start-tag och slut-tag som är riktiga och det namn man väljer har endast semantisk betydelse för en själv (och de andra som eventuellt skall läsa koden). Man måste dock se till att man inte har några mellanslag i namnet. Således skulle inte följande element-namn vara godkänd:
<titel på skivan>
medan
<titel_på_skivan>
samt
<titel.på.skivan>
går bra. Dock kan man ju diskutera lämpligheten med att ha svenska tecken med. I dagsläget är det endast svenska försvaret som har å, ä och ö med i sina elementnamn i sina SGML-dokument.
______________________________________________________________________________ artist ”child”. Det finns dock inget som hindrar att ett element är både parent och child om man har en hierarki med tre eller fler led. Beroende på vilka element som relateras till varandra blir de således antingen parent eller child vilket visualiseras i figur XX.
Element A parent
Element B
parent/child Element C child
Element D
child El. B child till El. A parent till El. D
1.2.2. Attribut
Vi behandlade attribut i exemplet med skivan ovan men skall nu komplettera detta lite grand. Attribut har ett värde och angavs alltså inom starttagen – exempelvis
<album typ=”CD”>
Restriktioner för värden som attribut får ha anger man i DTDn där man också kan ange om ett attribut skall ha något default -värde – dvs. ett värde som antas om inget annat anges.
Det finns idag två fördefinierade attribut enligt XML-specifikationen vilka kan användas till vilka element som helst, var som helst utan att det specificeras i DTDn. Dessa är:
xml:space
samt
xml:lang
där namnet xml: är reserverat för framtida inbyggda attribut.
I XML bevaras mellanslag automatiskt men ibland ignoreras detta av applikationen som hanterar dokumentet. Vill man således tala om för exempelvis en webbläsare att den skall bevara alla ”mellanslag” när den visar innehållet i ett xml-dokument kan man göra detta genom att inkludera attributet xml:space samt tilldela det värdet
”preserve”. Detta kan vara en bra idé att göra om man exempelvis vill bevara läsbarheten i programkod. Jämför hur de två programsnuttarna skulle visas om
xml:space=”preserve” inkluderas eller ej:
<prog.kod xml:space=”preserve”> for(i=0; i<=12; i++) {
write(Ord(i)); }
</prog.kod>
xml:space=”preserve” inkluderas: for(i=0; i<=12; i++) {
write(Ord(i)); }
______________________________________________________________________________
1.2.3. Entiteter
Entiteter är innehåll, till skillnad mot bland annat element. Detta innehåll är vanligtvis text, men det kan även vara binär data som exempelvis bilder och ljud. Man kan säga att deras huvudsakliga användning är när man vill förenkla inmatning i ett dokument. Exempelvis vill man kanske föra in strängen ”Institutionen för Informatik” på ett antal ställen i ett dokument men kan då deklarera följande i DTDn:
<!ENTITY ifi ”Institutionen för Informatik”>
Vill man sedan införa strängen ”Institutionen för Informatik” någonstans i rooten på dokumentet behöver man endast skriva &ifi; (&entitetens_namn;) så ersätts detta med entitetens deklarerade innehåll.
1.2.4. Kommentarer
Liksom i prologen kan man lägga in kommentarer för att förklara eller förtydliga information i ett dokument. Läs mer om hur kommentarer fungerar under Prolog-avsnittet.
1.2.5. Processing Instructions (PIs)
Processing Instructions kan liksom kommentarer inkluderas både i prologen och rooten. Läs mer om hur PIs fungerar under Prolog-avsnittet.
1.2.6. PCDATA
PCDATA står för Parsed Character Data och är default-typen för all text i ett XML-dokument. Man kan säga att all text i rooten som exkluderat den inom vinkelparenteserna (< och >) är PCDATA (och det övriga är så kallad Markup).
1.2.7. CDATA
CDATA står för Character Data och används när man vill innefatta text i ett XML-dokument som skulle kunna tolkas som markup – men som inte är det. Om man exempelvis skulle vilja ha med vinkelparenteser (< eller >), som vanligtvis tolkas som det som inleder eller avslutar en tag, skulle man vara tvungen att ange deras entitetsreferenser (< samt >) istället. Att sitta och ändra all ställen i ett XML-dokument kan vara ganska arbetsamt och istället för att ha en kod som ser ut så här:
<?xml version=”1.0” encoding=”UTF-8” standalone=”yes”?> <exempel>
Så här kan ett XML-dokument inledas:
<?xml version="1.0" encoding="UTF-8" standalone="yes">
</exempel>
kan man istället ange att en sektion som följer inte skall tolkas som annat än text vilket skulle ge ovanstående kod följande utseende;
<?xml version=”1.0” encoding=”UTF-8” standalone=”yes”?> <exempel>
<!CDATA[
Så här kan ett XML-dokument inledas:
<?xml version=”1.0” encoding=”UTF-8” standalone=”yes”?> ]]>
</exempel>
1.2.8. Notationer
En XML-parser kan bara förstå och hantera text. Vill man inkludera annan typ av innehåll som exemeplvis bilder eller ljudfiler måste dessa refereras till genom notationer. Markup innehåller ju inte bilder eller ljud i sig självt utan talar bara om för exempelvis webbläsaren var bilden finns. Genom att använda notationer kan man specificera vilket program som skall ta hand om viss data. Notationer deklareras också i DTDn.
______________________________________________________________________________
1.3. Epilog
Epilogen kan inte sägas fylla någon egentlig funktion eftersom man faktiskt kan skriva allt det som skulle kunna ha stått i epilogen i prologen. Termen epilog är inte heller direkt använd i XML-specifikationen där det endast står att viss markup får förekomma efter rooten. Av dess skäl rekommenderas egentligen inte att man skriver någon epilog, även om det är tillåtet enligt specifikationen. Det som får stå i epilogen, dvs. efter rooten, är Processing Instructions och kommentarer.
Epilog
Kommentarer Processing
Instructions