<node>

   Innhold i elementet, kan både være tekst og nye noder

</node>

Eksemple på en enkel xml:

<bokListe>

   <bok isbn=”9780747591054” utgave=”1”>

      <tittel>Harry Potter</tittel>

      <forfatter>J. K. Rowling</forfatter>

      <utgitt>2004</utgitt>

      <forlag>Bloomsbury</forlag>

  </bok>

  <bok isbn=”9788249505234” utgave=”1”>

     <tittel>Ligg I grønne enger</tittel>

     <forfatter>Anne Birkefeldt Ragde</forfatter>

     <utgitt>2007</utgitt>

     <forlag>Oktober</forlag>

  </bok>

</bokListe>

Denne XML’en består av følgende noder:

• bokListe (rotnode)
• bok
• tittel
• forfatter
• utgitt
• forlag

Ved å skrive utlistigen av noder litt mer strukturert ser man også hvilket noder som er barn av andre noder:

• bokListe
  • bok
    • tittel
    • forfatter
    • utgitt
    • forlag
  • bok
    • tittel
    • forfatter
    • utgitt
    • forlag

Ved å gå gjennom ett XML dokument å skrive ned alle nodene på denne måten vil man enkelt kunne se strukturen i XML’en , noe som vil gjøre det enklere å lage f.eks. en DTD (som egentlig er en en gammel måte å skrive definisjoner på).

Noder kan også inneholde attributter, dette er verdier knyttet direkte opp mot en spesifikk node. Ved å se på XML’en over så vil man se at noden bok har to attributter isbn og utgave.

<bok isbn=”9780747591054” utgave=”1”>…</bok>

Ved å utvide måten vi noterte ned alle nodene på ovenfor, til å inkludere attributter, så kan vi få en enkel oversikt over alle elementer og attributter i XML’en:

• bokListe
  • bok (isbn, utgave)
    • tittel
    • forfatter
    • utgitt
    • forlag
  • bok (isbn, utgave)
    • tittel
    • forfatter
    • utgitt
    • forlag

Listen ovenfor gir nå en god oversikt over alle noder og hva disse nodene inneholder. Den viser også hvilke attributter som er definert for de forskjellige nodene. Når du har fått på plass en slik liste vil det være enkelt å lage en DTD.

DTD – Document Type Definition

DTD’er er ikke noe annet enn en definisjon på hva en XML fil kan inneholde. Det finnes også en annen måte å definere XML filer på som heter Schema. Schema er en bedre måte å definere muligheter med en XML fil på, men det er også mer komplekst å sette opp. Erfaringsmessig er det enklere å forholde seg til DTD, noe som også er grunne til at jeg skriver om dette istedenfor Schema.

Hvorfor trenger man en DTD tilknyttet XML filen? Grunnen til dette er å gi XML dokumenter en global struktur slik at hvem som helst kan lage systemer som baserer seg på visse XML filer.

Standard måte å definere en node på i DTD’er er:

<!ELEMENT nodeNavn innholdstype>

Eksempel på en DTD basert på XML’en ovenfor:

<!ELEMENT bokListe (bok)>

<!ELEMENT bok (tittel, forfatter, utgitt, forlag)>

<!ELEMENT tittel (#PCDATA)>

<!ELEMENT forfatter (#PCDATA)>

<!ELEMENT utgitt (#PCDATA)>

<!ELEMENT forlag (#PCDATA)>

<!ATTLIST bok
   isbn CDATA #REQUIRED
   utgave (1|2|3|4|5|6) ”1”>

Nodenavn

Nodenavn kan være hva som helst. Dette er navnet på noden i XML filen, som f.eks. i XML’en overnfor så er bok ett nodeNavn. Nodenavn kan ikke innholde særnorske og andre spesial tegn som f.eks. Æ, Ø, Å o.s.v.

Innholdstype

Disse definerer hva en node kan inneholde. Følgende innholdstyper er mest vanlig; andre noder, PCDATA, ANY og EMPTY.

Andre noder

<!ELEMENT nodeNavn (node1, node2, node3+)>

Ved å definere noder på denne måten i DTD’en så begrenser vi en node til å kun inneholde barnenodene definert mellom parantesene; node1, node2, node3. Plusstegnet (+) etter node3 tilsier at man kan ha så mange ”node3” barnenoder man vil innenfor noden, mens node1 og node2 kun kan opptre 1 gang.

PCDATA

<!ELEMENT nodeNavn (#PCDATA)>

Dette tilsier at noden kun kan inneholde vanlig tekst og tall. Dersom en node definert med en innholdstype PCDATA inneholder andre noder vil XML’filen feile

ANY

<!ELEMENT nodeNavn ANY>

ANY betyr at noden kan inneholde både tekst (som definert i PCDATA) og hvilken som helst andre noder.

EMPTY

<!ELEMENT nodeNavn EMPTY>

EMPTY betyr at noden ikke kan inneholde noen ting. Med dette menes at en node i XML’en ikke kan ha noe innhold mellom start tag og slutt tag. Følgende XML vil feile hvis innnholdstypen er definert som EMPTY:

<nodeNavn>Innhold i noden</nodeNavn>

Riktig syntax vil være

<nodeNavn></nodeNavn> eller <nodeNavn/>

Atributter

I tillegg til <!ELEMENT> taggen for å definere noder benyttes også <!ATTLIST> taggen ofte for å definere attributter knyttet til noder.

Standard måte for å definere attributter på i en DTD er:

<!ATTLIST nodeNavn

  attributtNavn1 innholdstype standard

  attributtNavn1 innholdstype standard>

Nodenavn er navnet på den noden man ønsker å knytte attributtene mot. Dette navnet må være det samme som er definert i <!ELEMENT nodeNavn>.

Attributtnavnet kan være hva som helst så lenge det ikke inneholder særnorske eller andre spesialtegn. I XML’en ovenfor så er isbn en attributt til noden bok.

Innholdstypen definerer hva slags data en attributt kan inneholde. Følgende innholdstyper er mest vanlig; CDATA, liste av mulige verdier, ID, IDREF, NMTOKEN.

Når det gjelder innholdstyper så er det ikke så mye jeg kan forklare. Jeg vet kun hvordan men benytter CDATA og lister. ID blir som regel benyttet til unike ID’er for ett element, men jeg har aldri benyttet dette, så jeg er litt usikker på hvordan det funkgerer.

CDATA

<!ATTLIST nodeNavn

attributt1 CDATA standard>

CDATA sier at inneholdet i attributten kan være en hvilken som helst tekststreng. Stort sett så vil de fleste attributter benytte seg av CDATA dersom det ikke er attributter som benyttes til id eller lignende.

Lister

<!ATTLIST nodeNavn

   attributt1 (tekst1 | tekst2 | tekst3) standard>

Dersom man definerer en attributt som en liste vil definerer man hvilke verdier en attributt kan ha. Ved f.eks. attributtet over vil man i XML filen kun kunne sette inn verdiene; tekst1, tekst2 eller tekst3 som verdier til attributtet. Alle andre verdier vil medføre at XML’filen ikke er gyldig.

Standard definerer kun hvilken verdi vi ønsker skal være standard for en attributt. Dette benyttes ofte i sammenheng med ”lister”. I eksempelet over kan vi f.eks. si at tekst2 skal være standardverdi for attributt1:

<!ATTLIST nodeNavn

   attributt1 (tekst1 | tekst2 | tekst3) ”tekst1”>

Dette gjør så attributtet aldri vil være tom. Dersom man oppretter en XML basert på DTD’en vil alle attributt1 være ferdigutfylt med verdien ”tekst1”.

Det er også mulig å bytte ut standard verdien med såkalte ”Actions”. Dette er variabler som definerer om attributtet er påkrevd eller ikke. Jeg tror ikke det er mulig å benytte actions i attributter som er definert som lister.

Syntaxen for å benytte actions er:

<!ATTLIST nodeNavn

  attributt1 CDATA #REQUIRED>

Følgende actions er tilgjengelig:

#REQUIRED

Betyr at attributtet må inneholde en verdi, d.v.s. at attributtet må være med på alle noder som er definert til å ha dette attributtet.

#IMPLIED

Betyr at attributtet kan være tomt, d.v.s. at det ikke behøver å være definert i noder som er definert til å ha med dette attributtet.

#FIXED

Er jeg litt usikker på hva betyr, så her må du nok søke på internettet

Vel, nå er mitt nye hjertebarn (langt fra) ferdig og jeg har litt tid til overs, så jeg tenkte jeg skulle skrive litt om det siste året. Kort oppsummert har det siste året stort sett dreid seg om å komme fra A (figur 1) til B (figur 2).

Figur 1: Canal Digital Norge (parabol) sine gamle nettsider

Figur 2: Canal Digital Norge (parabol) sine nye nettsider

Som jeg har nevnt på Om meg sidene så har Canal Digital en litt komplisert struktur. Siden jeg jobber parabol har jeg derfor kun fokusert på parabol sine nettsider, noe som også er årsaken til at Figur 1 faktisk viser dagens www.canaldigital.no og ikke den oppdaterte versjonen vi har på parabol.canaldigital.no, men frykt ikke, vår felles forside kommer også snart i ny drakt. Illustrativt viser det uansett hvor vi var og hvor vi har kommet.

Smak og behag

Liker du vårt nye design? Vel, smaken er som baken så noen vil vel synes det er mørkt og trist, mens andre vil like det. Jeg er i den andre kategorien (overraskende nok) og liker det nye designet. Men design er, etter min mening, bare en liten del av en nettside. Det viktigste er innholdet og muligheten til å finne innholdet. For å få dette til er man avhengig av gode verktøy som gjør det mulig å både publisere innhold og knytte alt innholdet sammen. Dette har også vært fokuset når vi utviklet de nye nettsidene.

Når har vi ikke gjort alt alene. Det er konsulentselskapet Making Waves som har stått for konsept, desing og utvikling av nettsidene. For min del så har dette vært en helt ny opplevelse. For første gang har jeg vært kunde og kravstiller på ett webprosjekt. Som en gammel front-end utvikler, med fokus på detaljer og ett kritisk blikk, har det vært utfordrende og ha fokus på “the big picture”. Selv om alle gener i kroppen min sier at vi må flytte streken noen pixler til siden, eller justere fonten opp noen hakk, så har dette ingen ting å si for “the big picture”. Vi vil verken vinne eller tape kunder på denne type pixel pushing. Uansett har det vært utfordrende. Det er som når du pusser opp hjemme. Den lille glippen mellom listene irriterer deg noe grenseløst, og den er like synlig som 55″ flatskjermen som står midt i stua. Fakta er at det mest sannsynlig bare vil være deg som legger merke til den (og sannsyligvis kona).

Det har også vært lærerikt. Som konsulent kan du ofte skjule deg bak dårlig kravspesifikasjoner, uklare behov og idiotiske beslutninger når ikke alt går på skinner. Vel, nå har jeg vært ansvarlig for de dårlige kravspesifikasjonene, uklare behovene og de idiotiske beslutningene. Som tidligere konsulent og utvikler så var jeg klar på at jeg ikke skulle gå i denne fellen, men det skjedde.

Kjernen i problemstillingen er innsikt. For leverandøren, innsikt i kundens forretninger og behov. For kunden, innsikt i konsulenten sin tankegang og forståelse. Vi ønsket å gi leverandøren så mye frihet som mulig når de skulle utvikle våre nettsider, slik at de kunne utnytte det det er best på nemlig å lage gode nettløsninger. Mye frihet gir ofte i dårlige kravspesifikasjoner.

“Veien blir til mens du går” sa Ferdinand Finne en gang, dette var også litt av tankene våre. Vi hadde noen grunnleggende krav og behov, resten skulle vi finne ut av på veien. TV-distribusjon er en kompleks greie. For kunden er det ganske enkelt. De vil ha tilgang til de kanalene og programmene de er interessert i. Hvor vanskelig kan det være?

Canal Digital eier ingen TV-kanaler. De har avtaler med de største TV-selskapene, rundt omkring i verden, slik at de kan distribuere diverse TV-kanaler til de 1000 hjem. Slike avtaler legger føringer for hvordan kanaler skal pakketeres og distribueres, og hvordan penger skal fordeles. Det er ingen hemmlighet at alle skal tjene penger. Rettigheter og produksjoner koster penger. Ønsker man å opprettholde kvaliteten på TV-programmer og kanaler må man forvente å betale for det. Ønsker man kvalitet må man betale.

Uansett, alt dette er kompliserende faktorer man må ta i betrakning når nettsider skal utvikles. Feilen jeg gjorde var å forvente at leverandøren hadde like stor innsikt i vårt univers som jeg selv har. Kanskje kravspesifikasjonene burde vært mer detaljerte, men det er en tynn line å balansere på. Hvor ligger grensen der designere, informasjonsarkitekter og utviklere har frihet til å utnytte kompetansen sin, og ikke føler de er bundet av sterke restriksjoner? Jeg mener at når alt blir så detaljert og styrt at konsulenter føler de blir sekretærer, så er vi langt over grensen. I mitt tilfelle var jeg kanskje litt under grensen.

Alt i alt er både jeg og mine kolleger veldig fornøyd med de nye nettsidene. Som alltid er det noen hick-up’s, men visuelt har vi tatt noen kvantesprang fremover. Viktigst av alt er at vi har fått på plass ett rammeverk vi kan vidreutvikle. Det er nå jobben begynner.

Ta en titt selv på parabol.canaldigital.no og si hva du mener i kommentarfeltet nedenfor.

Kort om meg. Jeg heter Marius og jobber hos Canal Digital med ansvar for nettsidene til parabol delen av Canal Digital. Disse sidene er ikke så mye å skryte av for øyeblikket, men vi jobber med saken.

Før jeg begynte i Canal Digital har jeg jobbet som utvikler i forskjellige konsulentselskaper, med fokus på brukergrensesnitt, men det er ikke det som er viktig nå. Ønsker du å vite mer om meg så finner du det her.

Hva kommer så bloggen min til å inneholde? Vel, det vet jeg ikke spesielt mye om, men siden jeg for tiden jobber mye med TV-innhold så vil jeg sikkert ha mine meninger om hva som går på TV og hvorfor folk har så mange meninger om dette. Bortsett fra det så vet jeg ikke.

Uansett så kommer nok bloggen min til å inneholde meninger, synspunkter, furstrasjoner og annet crap jeg måtte føle for å skrive om.

/mb