Integritet och långsiktig användbarhet hos textdokument En avvägningsproblematik vid digitalt bevarande
Karl Pettersson
Institutionen för ABM Uppsatser inom arkivvetenskap ISSN 1651-6087 Masteruppsats, 30 högskolepoäng, 2015, nr 133 Författare/Author Karl Pettersson
Handledare/Supervisor Bertil Wergelius
Svensk titel Integritet och långsiktig användbarhet hos textdokument: En avvägningsproblematik vid digitalt bevarande
English Title Integrity and long-term Usability in Text Documents: Trade-offs in the Context of Digital Preservation
Abstract This thesis is about a potential trade-off between integrity and long-term usability in the choice of file formats for preser- vation of text documents. Five common formats are discussed: plain text, PDF/A, Office Open XML Document, Open Document Text, and Markdown. The formats are compared with respect to four criteria related to integrity and usability and to the records continuum model: support by widely used software, stability, rendering of contents and reusability. It is concluded that no single format is optimal with respect to all four criteria, when it comes to preserving typical documents in a modern environment, with more or less complex formatting and document structure. Therefore, the feasi- blity of using two or more formats for preservation of a single document (e.g. PDF/A combined with Markdown and/or Office Open XML) is discussed. It is necessary to weigh the importance of integrity and long-term usability against the costs of preserving documents in multiple formats. This is a two years master’s thesis in Archival Science, Library and Museum studies.
Ämnesord integritet, användbarhet, textdokument, märkspråk, records continuum
Keywords Integrity, Usability, Text documents, Markup languages, Records continuum Innehållsförteckning
1 Inledning ...... 5 1.1 Introduktion och upplägg ...... 5 1.2 Källmaterial och annan använd litteratur ...... 6 1.3 Utgångspunkter ...... 6 1.4 Tidigare forskning ...... 7 1.5 Frågeställning ...... 9 1.6 Metod...... 11 2 Undersökning ...... 12 2.1 Text...... 12 2.1.1 Beskrivning av formatet ...... 12 2.1.2 Utbrett mjukvarustöd ...... 15 2.1.3 Stabilitet ...... 15 2.1.4 Återgivning ...... 16 2.1.5 Återanvändbarhet ...... 17 2.1.6 Diskussion...... 17 2.2 PDF/A ...... 18 2.2.1 Beskrivning av formatet ...... 18 2.2.2 Utbrett mjukvarustöd ...... 19 2.2.3 Stabilitet ...... 20 2.2.4 Återgivning ...... 20 2.2.5 Återanvändbarhet ...... 21 2.2.6 Diskussion...... 21 2.3 Mellanspel om XML...... 22 2.4 Office Open XML Document ...... 24 2.4.1 Beskrivning av formatet ...... 24 2.4.2 Utbrett mjukvarustöd ...... 28 2.4.3 Stabilitet ...... 29 2.4.4 Återgivning ...... 30 2.4.5 Återanvändbarhet ...... 30 2.4.6 Diskussion...... 30
3 2.5 OpenDocument Text ...... 30 2.5.1 Beskrivning av formatet ...... 30 2.5.2 Utbrett mjukvarustöd ...... 34 2.5.3 Stabilitet ...... 34 2.5.4 Återgivning ...... 34 2.5.5 Återanvändbarhet ...... 34 2.5.6 Diskussion...... 34 2.6 Markdown ...... 35 2.6.1 Beskrivning av formatet ...... 35 2.6.2 Utbrett mjukvarustöd ...... 39 2.6.3 Stabilitet ...... 40 2.6.4 Återgivning ...... 40 2.6.5 Återanvändbarhet ...... 40 2.6.6 Diskussion...... 42 2.7 Övergripande jämförelse ...... 42 2.7.1 Enformatskombinationer (1–5) ...... 43 2.7.2 Tvåformatskombinationer (6–15) ...... 45 2.7.3 Treformatskombinationer (16–25) ...... 47 2.7.4 Jämförelsen i relation till continuummodellen...... 48 3 Slutdiskussion ...... 49 4 Sammanfattning ...... 53 Käll- och litteraturförteckning ...... 55 Förkortningar i text ...... 60
4 1 Inledning
1.1 Introduktion och upplägg Digitalt bevarande får allt större betydelse i dagens samhälle. Ett viktigt problem i samband med detta handlar om vilka filformat som är lämpliga för långtidsbevarande av textdokument. Internationella standarder, som ISO 15489-1, definierar generella krav på arkivhandlingar som skall fungera som evidens: autenticitet, tillförlitlighet, (”reliability”), integritet och användbarhet (”usability”). De två sista av de nämnda kraven, integritet och långsiktig användbarhet ligger i fokus för denna uppsats. International Council on Archives (ICA) definierar integri- tet som att en handling är ”complete and unaltered”, medan användbarhet handlar om ”the ability to locate, retrieve, present, and interpret a record” (ICA 2005, s. 12). Ett frekvent hinder för långsiktig användbarhet är att nyare programvaror inte korrekt kan återge dokument som skapats i filformat som används i äldre program. Ett sätt att minimera detta problem, och maximera den långsiktiga användbarheten, skulle vara att överföra alla textdokument till ren ASCII-text, men detta skulle få ne- gativa konsekvenser för dokumentens integritet: struktur, formatering, icke-engelska tecken m.m. skulle gå förlorade. Denna uppsats handlar om vad denna avvägnings- problematik får för konsekvenser när det gäller vilka filformat som är lämpliga för långtidsbevarande av textdokument. Det har gjort en hel del för att hantera problematiken. Genom användning av öppna standarder (PDF/A, Office Open XML) är det möjligt att minska beroendet av en specifik mjukvaruleverantör, men det krävs ändå att någon ser till att det finns pro- gram som kan hantera dessa format, som är anpassade till moderna datormiljöer. Ett intressant alternativ skulle kunna vara s.k. lättviktiga märkspråk av den typ som be- skrivs av MacFarlane (2013b), där källdokumenten (till skillnad från t.ex. PDF-filer eller komplexa XML-filer) är lätta att läsa för en människa i vilket program som helst som kan hantera textfiler, samtidigt som de ändå innehåller instruktioner som gör det möjligt att med lämplig programvara producera formaterade, strukturerade dokument i t.ex. PDF-format. Uppsatsen är upplagd på följande sätt. I detta inledningskapitel görs en översikt över tidigare forskning som rör långtidsbevarande av textdokument, och ett teore- tiskt ramverk i form av den s.k. records continuum-modellen definieras. Dessutom presenteras använd litteratur, precisa frågeställningar och metod. Därefter följer det
5 utredningskapitel som utgör huvuddelen av uppsatsen. Det tredje och avslutande ka- pitlet utgörs av en sammanfattande diskussion. Något bör här sägas om de centrala begreppen textdokument och filformat. Ett textdokument är ett elektroniskt dokument avsett att primärt återges som i huvudsak löpande text; det är den typ av dokument som normalt skapas i ordbehandlingspro- gram. Textdokument skiljer sig från t.ex. rena tabelldokument avsedda för bearbet- ning i databassystem eller statistikprogram, även om de kan innehålla strukturerad information, som tabeller. Ett filformat är en viss specifikation för hur data repre- senteras i en fil, sådan att programvaror som skall återge filer på det sätt som avsetts måste ta hänsyn till formatet. I moderna datorsystem anges filformat ofta med fil- namnstillägg (t.ex. .pdf för PDF-filer och .docx för Office Open XML Document), även om ett och samma filnamnstillägg ibland kan användas av olika filformat el- ler delvis inkompatibla versioner av samma filformat, och det omvänt gäller att filer med likartat format kan ha samma filnamnstillägg (t.ex. .htm och .html).
1.2 Källmaterial och annan använd litteratur Det primära källmaterial som används för undersökningen i denna uppsats är doku- mentation av de filformat, teckenkodningar och mjukvaror som diskuteras, exem- pelvis MacFarlane (2013b), ECMA (2012), OASIS (2013), Acrobat Engineering Team (2012) och Unicode Consortorium (2014). Undersökningsdelen är centrerad kring detta. Annan använd litteratur kan delas in i följande kategorier:
1. Diskussioner om de grundläggande ISO-kraven på digitala dokument (ICA 2005), som gåtts igenom under avsnitt 1.1. 2. Officiella standarder och andra dokument från myndigheter, som definierar tek- niska krav på digitala dokument, speciellt filformat för textdokument (RA-FS 2009:2; National Archives 2009; C. R. Arms, Fleischhauer och Murray 2013). Kriterierna under avsnitt 1.5 nedan anknyter till dessa. 3. Arkivteoretiska diskussioner om records continuum-modellen (Upward 1996; McKemmish 2001), och mer specifikt sådana som sätter den i relation till digitalt bevarande (Svärd 2013; Cunningham 2008; Borglund 2008). Detta gås igenom under avsnitt 1.3 och 1.4 nedan. 4. Tidigare forskning som specifikt berör filformat och digitalt bevarande för text- dokument (Ovadia 2014). Detta gås igenom under avsnitt 1.4 nedan och tas upp i undersökningsdelen.
1.3 Utgångspunkter För att studera relationen mellan arkivhandlingarnas integritet och användbarhet och de olika textformaten används records continuum-modellen. Denna modell utveck- lades i Australien och beskrevs av Upward (1996). Jag skall i det följande beskriva
6 de element i modellen som är av central betydelse för denna uppsats frågeställning. Records continuum-modellen kan kontrasteras mot tidigare modeller för förvaltning av arkivhandlingar, som den amerikanska life cycle-modellen, där handlingar tänks ingå i olika faser sekventiellt. I stället definieras fyra ”dimensioner”, där en hand- ling vid en given tidpunkt kan göras till föremål för åtgärder relaterade till flera olika dimensioner. De fyra dimensionerna karakteriseras på följande sätt av McKemmish (2001), s. 352.
1. Skapande av dokumenten (”create”). 2. Fångst av handlingar som evidens (”capture”), där dokumenten kopplas ihop med t.ex. de transaktioner de dokumenterar, relaterade handlingar och deras omedel- bara affärs- eller samhällskontext. 3. Organisation av handlingar (”organise”), där de placeras i en arkivkontext. 4. Mångfaldigande av handlingar (”pluralise”), där de placeras i ett ramverk som gör att de fungerar som tillgängligt kollektivt minne.
Vidare finns det fyra axlar – identitet, transaktion, evidens och förvaltning (”record- keeping”) – som skär över de olika dimensionerna, som visas i figur 1.1. Axlarna har dock ingen direkt relevans för denna uppsats. Det som gör records continuum-modellen attraktiv för en undersökning som denna är framför allt att den är anpassad för en kontext där arkivhandlingarna inte blir ”färdiga”, utan så länge de bevaras kan behöva göras föremål för åtgärder som migrering, konvertering och tillförande av metadata, och där det är viktigt med ett ”proaktivt” förhållningssätt, som innebär att det redan när handlingarna initialt ska- pas vidtas åtgärder som syftar till att underlätta t.ex. deras framtida bevarande och tillgängliggörande (jämför Borglund (2008)). ISO-modellen för ett OAIS är en annan typ av modell som ofta används i sam- band med digital arkivering. En begränsning hos modellen är dock att den är anpas- sad för en situation där ett SIP, som skall skickas in i arkivet från arkivbildaren, kan tas för givet (Cunningham 2008, s. 534). Detta kan göra den mindre lämplig i ett sammanhang där det är viktigt att se till att handlingarna förbereds för långtidsbe- varande redan när de skapas.
1.4 Tidigare forskning Uppsatsens övergripande frågeställning, om relationen mellan integritet och använd- barhet hos textdokument, har inte specifikt behandlats i tidigare forskning. Däremot finns det forskare som tillämpat records continuum-modellen på problem relatera- de till digitalt bevarande av arkivhandlingar. Svärd (2013) bygger på fallstudier av svenska kommunförvaltningar och handlar om hur records continuum-modellen till- sammans med s.k. Enterprise Content Management kan användas för att hantera pro- blem med långtidsbevarande. En slutsats i artikeln är att kommunerna brottas med
7 Evidens Skapande Fångst
Identitet Transaktion
Mångfaldigande Organisation Förvaltning
Figur 1.1: Records continuum-modellen. Efter McKemmish 2001, s. 350. problem som avsaknad av långsiktiga planer för informationshantering och olikar- tade system som är dåligt integrerade med varandra. Handlingar hanteras fortfaran- de utifrån en livscykelmodell, trots att continuummodellen, som inte skiljer mellan nutida och arkiverade handlingar, skulle vara mer passande för ett system där all- mänheten skall ges snabb åtkomst till elektroniska handlingar. Borglund (2008) är en sammanläggningsavhandling som behandlar design av informationssystem för skapande och hantering av arkivinformation. Artiklarna i avhandlingen innefattar fallstudier av svenska myndigheter och företag. Ett ”proak- tivt” förhållningssätt, som går ut på att det är nödvändigt att se till att information redan när den skapas uppfyller krav för arkivering, modelleras med hjälp av records continuum-modellen, och en Recordkeeping Quality Assesment Model (RQAM) definieras. Varken Svärd (2013) eller Borglund (2008) har som syfte att diskutera detaljer kring specifika filformat för långtidsbevarande. National Archives (2009) och C. R. Arms, Fleischhauer och Murray (2013) har definierat adekvanskriterier för filformat, vilka kommer att behandlas närmare i re- lation till de fyra kriterier som används i denna uppsats frågeställning och definieras i nästa avsnitt. National Archives (2009) definierar tolv adekvanskriterier för filformat. Två av kriterierna, Ubiquity och Support, motsvarar mitt mjukvarustödskriterium. Kriteriet Stability motsvarar mitt stabilitetskriterium. I kriteriet Complexity ingår att ”[f]or- mats should be selected for use on the basis that they support the full range of featu- res and functionality required for their designated purpose”. Detta reflekteras i mitt återgivningskriterium. Två kriterier, Interoperability och Reusability, är relaterade
8 till mitt återgivningskriterium. Dessutom definierar National Archives (2009) ett an- tal kriterier som inte har någon direkt relation till frågeställningen i denna uppsats. Dessa handlar om att formatet skall vara öppet och ha tillgänglig dokumentation (vil- ket är uppfyllt för alla de format som tas upp här) och om sådant som metadatastöd och verifikation. C. R. Arms, Fleischhauer och Murray (2013) definierar sju stycken ”sustaina- bility factors”, som också delvis överlappar mina kriterier. Faktorn Adoption hänger ihop med mjukvarustödskriteriet, även om det fokuserar på i vilken mån formatet används av arkivbildare och andra användare snarare än i vilken mån det stöds av program med utbredd användning, vilket är vad mitt kriterium går ut på. Faktorn Transparency handlar om i vilken mån formatet kan analyseras med enkla verktyg, som en textredigerare. Dessa frågor diskuteras i relation till mjukvarustödskriteriet och återanvändbarhetskriteriet. Faktorn External Dependencies handlar om i vilken mån ett format är beroende av viss hårdvara, operativsystemmiljö eller mjukvara för återgivning eller återanvändning och den förväntade komplexiteten i att hantera dessa beroenden i framtida miljöer. Aspekter av detta överlappar kriterierna mjuk- varustöd, återgivning och återanvändbarhet. C. R. Arms, Fleischhauer och Murray (2013) tar, förutom adekvanskriterierna, översiktligt upp två av de diskuterade for- maten, nämligen PDF/A och Office Open XML Document. Ovadia (2014) är en artikel som diskuterar Markdown, ett av de format som diskuteras i uppsatsen, med fokus på formatets användbarhet för bibliotekarier och akademiker. Teman som tas upp i artikeln är bl.a. formatets enkelhet jämfört med andra populära märkspråk som HTML och LaTeX, möjligheten att konvertera mel- lan Markdown och andra textformat med verktyg som Pandoc och avsaknaden av etablerad standardisering av Markdown. Dessa saker kommer att diskuteras närma- re i avsnitt 2.6.
1.5 Frågeställning I detta avsnitt konkretiseras generella frågeställningen i denna uppsats till att hand- la om hur väl olika filformat för textdokument uppfyller följande adekvanskriterier, som kan relateras till begreppen integritet och användbarhet och till de olika dimen- sionerna i records continuum-modellen:
Utbrett mjukvarustöd En förutsättning för att ett filformat skall vara användbart är att det kan hanteras av de program som används för att skapa textdokument hos arkivbildarna, antingen direkt eller via annan tillgänglig mjukvara, som kan konvertera till och från arkivformaten. Detta relaterar framför allt till skapande- dimensionen i records continuum. Stabilitet Ett filformat för bevarande uppfyller detta kriterium i den mån det inte genomgår stora förändringar över tid, som bryter kompatibilitet med tidigare
9 versioner. Detta är ett användbarhetskriterium som kan relateras till organisa- tionsdimensionen i records continuum, då det handlar om hur dokumenten för- blir tillgängliga över tid. Återgivning av dokument Ett filformat för bevarande uppfyller detta kriterium i den mån det återger dokument så att de har det utseende och den struktur som de hade när de skapades. Detta är ett integritetskriterium som kan relateras till organisationsdimensionen i records continuum. Återanvändbarhet Ett filformat uppfyller detta kriterium i den mån det gör det möjligt att extrahera information ur dokument och överföra den till andra sy- stem för bearbetning. Detta är ett användbarhetskriterium som kan relateras till mångfaldigandedimensionen i records continuum. De format som jämförs är följande: Text Oformaterad text. PDF/A PDF anpassad för digitalt bevarande. Office Open XML Document Det XML-baserade format som används som stan- dard i nyare versioner av Microsoft Word. OpenDocument Text Det XML-baserade format som används som standardformat i bl.a. Libre Office Writer. Markdown Ett s.k. lättviktigt märkspråk. Det bör med en gång varnas för att de båda XML-baserade ordbehandlingsformaten kan vara lätta att förväxla med varandra, speciellt med tanke på att OpenDocument Text utvecklats ur det med Wordformatet än mer namnlika OpenOffice.org XML, som användes i OpenOffice.org, föregångaren till LibreOffice. Vad gäller valet av format kan sägas att oformaterade text och PDF/A är rimli- ga utgångspunkter för en diskussion om bevarande av textdokument. Det är t.ex. de format som Riksarkivet direkt föreskriver för ”kontorsdokument” (RA-FS 2009:2, 3 kap. 4§). Office Open XML och OpenDocument är standardformat i vanliga kon- torsprogramvaror för textproduktion, och genom att de är öppna, XML-baserade for- mat kan de inordnas under Riksarkivets föreskrifter för ”strukturerade dokument” (RA-FS 2009:2, 3 kap. 3§). Markdown är ett relativt nytt format, som inte finns upptaget i officiella standarder hos t.ex. Riksarkivet, men som ter sig som ett in- tressant alternativ därför att det kombinerar flera av fördelarna hos oformaterad text med mer komplexa format, på det sätt som antytts i avsnitt 1.1 ovan. Det existerar för närvarande ingen ISO-standardisering eller motsvarande av Markdown, och det har med åren utvecklats en del olika versioner av formatet. Pandoc är en mjukvara för konvertering till och från olika textformat, som är centrerat kring en version av Markdown (MacFarlane 2013b). I denna framställning ligger fokus på denna ver- sion av Markdown, eftersom Pandoc kan konvertera till och från en lång rad andra textformat och innehåller funktioner för hantering av metadata (MacFarlane 2013b). Andra versioner av Markdown och andra lättviktiga märkspråk tenderar att vara mer specialinriktade på generering av HTML.
10 1.6 Metod Uppsatsens centrala metod består i ett teoretiskt resonemang kring de adekvanskri- terier som definierats i föregående avsnitt, med utgångspunkt från den litteratur som beskrivits i avsnitt 1.2 ovan. För vart och ett formaten ges först en allmän beskrivning av formatet, varefter det görs en mer specifik översikt över de egenskaper hos formatet som är relaterade till de fyra adekvanskriterierna och, mot bakgrund av detta, en sammanfattande diskus- sion kring vilka för- och nackdelar som finns med formatet i relation till integritets- och användbarhetsaspekten. Exempel på kod används för att visa på grundläggande funktionalitet hos formaten (utom för ren text, som inte innehåller någon kod utom själva texten, och PDF/A, som inte producerar kod som är läsbar för en människa utan speciella program). Avsnitten om de XML-baserade ordbehandlingsformaten föregås av en mer allmän redogörelse för XML. I slutet av undersökningsdelen görs så en övergripande jämförelse, där det redo- visas vilka kombinationer av olika format som är möjliga, och vilka för- och nackde- lar dessa har när det gäller integritet och användbarhet. Det existerar ingen enskild lösning som är bäst för alla behov hos olika typer av arkivbildare, men vissa kom- binationer ter sig långsökta, därför att de inte medför några signifikanta fördelar jämfört med enklare kombinationer, vare sig ur integritets- eller användbarhetssyn- punkt. För de kombinationer som ter sig som seriösa alternativ för bevarande av textdokument i olika sammanhang ges mer konkreta exempel, i form av hypotetis- ka arkivbildare, där det översiktligt diskuteras hur de skulle kunna implementeras. Valet av format relateras också till dimensionerna i continuummodellen.
11 2 Undersökning
2.1 Text 2.1.1 Beskrivning av formatet Med text avses här det som på engelska betecknas som ”plain text”. Det är lämpligt att precisera begreppet på följande sätt:
Text En sekvens av teckenkoder som inte innehåller komplexa instruktioner som bestämmer hur tecknen skall återges.
Preciseringen är i linje med det som sägs av Unicode Consortorium (2014), s. 19, att ”[p]lain text represents character content only, not its appearance”. Om en och samma sekvens av text återges med olika renderingsprocesser – t.ex. i olika datorpro- gram, eller på bildskärm och skrivare – kan vi inte vänta oss att dessa skall rendera texten med ett likartat utseende. Text måste innehålla tillräckligt med information för att återges så att den kan läsas som avsett men inget utöver detta. Begreppet ”teckenkoder” i preciseringen måste förklaras närmare. Datorer ar- betar internt med bit som grundläggande enhet för information. En bit är en binär enhet som antar ett av två värden, som brukar representeras av talen 0 och 1. Det är nödvändigt att specificera hur tecken skall mappas till bitsekvenser, vilket görs i en teckenkodning. En teckenkod är en sekvens som representerar ett givet tecken, relativt en teckenkodning. Exempelvis representeras bokstaven O i flera av de van- ligaste kodningarna av bitsekvensen 1001111. Detta motsvarar talet 79 i det vanliga decimala talsystemet, och 4F i det i datatekniska sammanhang ofta använda hexa- decimala systemet, som har 16 som bas och där bokstäverna A–F betecknar de de- cimala talen 10–15. Hexadecimala tal anges ofta med prefixet 0x, t.ex. 0x4F, för att undvika förväxling med andra talsystem. Det som vållar problem när det gäller återanvändning av information lagrad som ren text är i stor utsträckning inkompatibla teckenkodningar. Därför kommer diskus- sionen i detta avsnitt i stor utsträckning att centreras kring dessa. Det finns en uppsjö av olika teckenkodningar. I detta avsnitt begränsas diskussionen till sådana som kan förväntas uppträda i textdokument från svenskspråkiga arkivbildare. Formellt kan en teckenkodning 퐴 betecknas som en funktion som tilldelar varje tecken i en viss mängd, 퐷퐴 en kod (mer precist är 퐴 en bijektion eftersom varje kod endast representerar ett tecken). Kodningen i sig kan betecknas som en mängd
12 ordnade par av tecken och teckenkoder. För exemplet ovan skulle (O, 79) vara ett sådant par. För den följande diskussionen är det till hjälp att skilja mellan följande två sätt på vilka en kodning kan sägas inkludera en annan:
Starkt inkluderande En kodning 퐴 är starkt inkluderad i en kodning 퐵 ifall 퐴 är en delmängd av 퐵 (퐴 ⊆ 퐵 med matematisk notation).
Svagt inkluderande En kodning 퐴 är svagt inkluderad i en kodning 퐵 ifall 퐷퐴 är en delmängd av 퐷퐵.
Om 퐴 är svagt inkluderad i 퐵 innebär det att t.ex. en textfil kodad i 퐴 kan översättas till 퐵 utan förlust av data. Om 퐴 är starkt inkluderad i 퐵, innebär det att en teckense- kvens kodad i 퐵, som innehåller enbart tecken som ingår i 퐴, är identisk med samma teckensekvens kodad i 퐴. En av de mest använda teckenkodningarna har under lång tid varit American Standard Code for Information Interchange (ASCII), beskriven av ECMA (1991). ASCII-teckenkoderna är sekvenser om 7 bitar, vilket innebär att det finns plats för 27 = 128 kodpositioner. Av dessa upptas 33 av kontrolltecken för radmatning etc., vilket ger plats för 95 positioner för utskrivbara tecken. Dessa används bl.a. för sto- ra och små bokstäver, A–Z, a–z, siffror, vanliga skiljetecken och vissa tecken som används inom matematik och programmering (t.ex. #*+/<=>@[\]{|}). ASCII-kodningen är uppenbart otillräcklig när det gäller att representera sådant som svenska tecken eller tecken för mer avancerad typografi. ISO/IEC 646 defini- erar olika nationella varianter av 7-bitars ASCII, där den amerikanska varianten, US-ASCII, är identisk med den ursprungliga ASCII, men där de övriga varianterna byter ut vissa av de ovannämnda matematiska symbolerna mot nationella tecken. Koderna för strängen [\]{|} i US-ASCII representerar t.ex. i de svenska varianterna SE och SE2 (Simonsen 1992) i stället ÄÖÅäöå. SE2 skiljer sig från SE genom att den inkluderar ÉéÜü. Med tiden har det blivit vanligare att använda kodningar med sekvenser om 8 bitar, vilket ger plats för 28 = 256 tecken. Sedan länge har datorerna använt 8-bitarssekvenser, byte, som grundläggande enhet för lagring av information, så det- ta innebär i praktiken inga ökade utrymmeskrav för okomprimerad text (i filer ko- dade enligt ASCII är den inledande biten i varje byte 0). Persondatorer har normalt använt sig av olika varianter av vad som ofta kallas utökad ASCII, som inkluderar ASCII i den starka meningen definierad ovan. DOS har använt sig av en rad olika ”code pages”, t.ex. CP850 för västeuropeiska språk, som är 8-bitars utökningar av ASCII och innehåller bl.a. svenska tecken (Simonsen 1992). Standarden ISO/IEC 8859 anger en rad olika 8-bitarskodningar, som alla är ut- ökningar av ASCII. De 32 första teckenpositionerna i den utökade delen (alltså posi- tionerna mellan 128 och 159 eller 0x80 och 0x9F) är odefinierade; ISO/IEC 8859-1 (beskriven av ECMA (1986)) definierar alltså koder för 96 tecken utöver de som ingår i ASCII. Den ”västeuropeiska” kodningen ISO/IEC 8859-1, känd som ”Latin 1”, har en särställning eftersom Riksarkivet anger den som ett av de tillåtna formaten
13 för databaser och register som skall bevaras som textfiler (RA-FS 2009:2, 3 kap. 2§) och för kontorsdokument (RA-FS 2009:2, 3 kap. 4§). Windows har emellertid an- vänt sig av en egen kodning, Windows-1252 (Microsoft 2015b), för västeurope- iska språk. Denna kodning, som inte nämns i Riksarkivets föreskrifter, inkluderar starkt ISO/IEC 8859-1, och skiljer sig från denna genom att de 32 oanvända po- sitionerna har fyllts upp. Exempel på tecken som ingår i Windows-1252 men inte ISO/IEC 8859-1 är Eurosymbolen € och ”, som används för citattecken i t.ex. Sve- rige. Det finns även 8-bitarskodningar som inte är utökningar av ASCII. Ett exem- pel är Extended Binary Coded Decimal Interchange Code (EBCDIC), som är en grupp 8-bitarskodningar som använts på stordatorer från IBM, och där koderna för de tecken som även ingår i ASCII generellt inte överensstämmer med dessa teckens ASCII-koder. EBCDIC 278 (Simonsen 1992) är en variant som används i Sverige och svagt inkluderar ISO/IEC 8859-1 men innehåller ytterligare kontrolltecken. Även teckenkodningar om 8 bitar är otillräckliga för att t.ex. representera tec- ken i många icke västerländska skriftsystem. Unicode är en standard som utarbetats för att hantera moderna behov av teckenrepresentation i datorer. Version 1.0.0 av standarden, som publicerades 1991, definierar en kodrymd om 216 = 65 536 tec- ken. Detta kom emellertid också att bedömas som otillräckligt, och versioner från och med 2.0, som publicerades 1996, definierar en kodrymd indelad i 17 plan, num- rerade 0–16, med 216 = 65 536 tecken vardera, vilket ger utrymme för 1114 112 tecken (Unicode Consortorium 2014, s. 44–52). Plan 0, Basic Multilingual Plane (BMP), är det mest använda. De första 256 positionerna i BMP överensstämmer med ISO/IEC 8859-1. Därutöver innehåller planet ytterliga diakritiska tecken, tec- ken från icke-latinska alfabet, matematiska och typografiska symboler, tecken från österländska skriftsystem m.m. Plan 1–2 används bl.a. för historiska skriftsystem och mindre vanliga österländska tecken. Plan 3–13 är för närvarande odefinierade, plan 14 används för kontrolltecken och plan 15–16 är reserverade för ”privat an- vändning”, alltså att utomstående skall kunna definiera egna tecken som inte ingår i Unicode. Unicode är en abstrakt standard som inte i sig föreskriver någon teckenkodning. Olika varianter av Unicode Transformation Format (UTF) används som kodning för Unicode (Unicode Consortorium 2014, s. 35–37). Den enklaste varianten, UTF-32, använder 32 bitar för varje tecken: teckenkoden är varje teckens kodposition i Uni- code (med inledande nollor). UTF-16 använder 16 bitar för tecknen i BMP och 32 bitar för tecken i de övre planen. UTF-8 använder 8 bitar för ASCII-tecken (upp till position 0x7F), 16 bitar för tecken mellan 0x80 och 0x7FF (t.ex. de utökade tecknen i ISO/IEC 8859-1), 24 bitar för övriga tecken i BMP (t.ex. österländska tecken och typografiska symboler) och 32 bitar för tecken i de övre planen. Åtminstone vid an- vändning av västerländska skriftsystem är UTF-8 i regel mer utrymmeseffektiv än UTF-16, och den har blivit dominerande på webben (Q-Success 2015). UTF-16 och UTF-32 kompliceras också av endianness, alltså om den mest signifikanta byten lig-
14 ger först (som i vårt vanliga talsystem), s.k. big endianness (BE), eller sist, little endi- anness (LE), vilket kan anges med en Byte Order Mark (BOM) i början av filen. Detta gäller inte UTF-8, eftersom koderna är uppdelade i byte som inleds med speciella bitsekvenser. Dessutom är ASCII starkt inkluderad i UTF-8, så att en fil med enbart ASCII-tecken kodad i UTF-8 utan vidare är ASCII-kompatibel. ISO/IEC 8859-1 och Windows-1252 är emellertid endast svagt inkluderade i UTF-8, då UTF-8 använder 16 eller 24 bitar för de tecken utöver ASCII där ovannämnda kodningar använder 8 bitar. ISO/IEC 10646, Universal Character Set (UCS), är en standardiserad tecken- mängd som överensstämmer med Unicode med avseende på vilka tecken som in- kluderas och deras kodposition (Unicode Consortorium 2014, s. 861–863). Riksar- kivet hänvisar inte till någon variant av Unicode eller UCS när det gäller beva- randeformat för kontorsdokument. För bevarande av databaser i textformat anges ISO/IEC 10646:2003 (motsvarar Unicode 5.0), dock med tillåten teckenmängd be- gränsad till de utskrivbara ASCII-tecknen, andra latinska bokstäver med diakritiska tecken och ett fåtal andra tecken (§´·) (RA-FS 2009:2, bilaga 1).
2.1.2 Utbrett mjukvarustöd Alla standardprogramvaror som används för textproduktion kan läsa och spara filer i ASCII-format. Tolkningen av kontrolltecken i ASCII kan dock skilja sig mellan olika system. Ett exempel är tecknen 0x0D (”carriage return”, CR) och 0x0A (”li- ne feed”, LF), där olika system använder CR, LF eller kombinationen CRLF för att representera radmatning (Unicode Consortorium 2014, s. 258). Det kan också hända att äldre, interna system hos olika arkivbildare är uppbyggda kring delvis in- kompatibla standarder, som någon variant av EBCDIC eller SE-ASCII. De nämnda varianterna av ISO/IEC 8859 och UTF stöds också i moderna programvaror för text- produktion. Även om program kan läsa textfiler med en given kodning kan det variera i vilken mån de känner igen kodningen automatiskt, vilket kan vålla användbarhetsproblem. Ett exempel är att Vim, en populär textredigerare, som finns tillgänglig för de fles- ta systemmiljöer, kan ha problem att automatiskt känna igen textfiler sparade som UTF-16 utan BOM. För att filen skall visas korrekt kan det vara nödvändigt att ange kodningen manuellt (se Super User (2013) för diskussion kring detta)1.
2.1.3 Stabilitet En viktig aspekt av stabilitetskriteriet är bakåtkompatibilitet hos nya versioner av en standard. Det ovan diskuterade kriteriet för starkt inkluderande är relevant i detta sammanhang. Ett exempel är att ASCII-tecken i text kodad enligt UTF-8 också kan hanteras av alla program som kan hantera ASCII-text, eftersom ASCII, som nämnts
1Jag råkade ut för ett liknande problem vid uttag av textfiler från Socialstyrelsens statistikdatabas våren 2014. Filerna sparades som UTF-16LE, men mitt påpekade av problemet fick Socialstyrelsen att ändra kodning till UTF-8 (Socialstyrelsen 2014).
15 SE-ASCII (US-)ASCII 퐴 → 퐵 ∶ 퐷퐴 ⊆ 퐷퐵, 퐴 ⇒ 퐵 ∶ 퐴 ⊆ 퐵
CP850
ISO/IEC 8859-1 Windows-1252
EBCDIC 278
UTF-8 UTF-16 UTF-32
Figur 2.1: Relationer mellan de olika teckenkodningar som behandlas i avsnittet. Enkel linje från 퐴 till 퐵 betyder att 퐴 är svagt inkluderad i 퐵; dubbel linje betyder att 퐴 är starkt inkluderad. ovan, är starkt inkluderad i UTF-8. Om en viss mjukvara inte har stöd för en tecken- kodning finns ofta möjlighet att konvertera filen till en teckenkodning som stöds. Om man konverterar från en kodning 퐴 till en annan kodning 퐵 och 퐴 är svagt in- kluderad i 퐵 skall det gå att genomföra konverteringen utan informationsförluster. Figur 2.1 visar hur de i avsnitt 2.1.1 diskuterade teckenkodningarna är relaterade med avseende på svagt och starkt inkluderande. Ett program och API (alltså en spe- cifikation för funktioner som kan anropas via andra program) som kan användas för konvertering mellan teckenkodningar och som finns tillgängligt i fria versioner för olika systemmiljöer är iconv (Free Software Foundation 2011). Som framhållits är kodrymden i Unicode fortfarande till största delen outnyttjad. Denna fylls successivt ut i nya versioner, men standarden innehåller också policyspe- cifikationer för stabilitet, som syftar till bakåtkompatibilitet hos de nya versionerna. Dessa innebär bl.a., för alla versioner från Unicode 2.0 och framåt, att när ett tecken väl tilldelats en viss kodposition kommer det inte att tas bort eller flyttas till en annan position (Unicode Consortorium 2015).
2.1.4 Återgivning Konsistent återgivning är, som antyddes redan i introduktionsavsnittet, en uppen- bart svag punkt när det gäller ren text. Det finns inget sätt att bevara formatering, som teckensnitt, teckenstorlek eller kursivering, eller styckeinställningar, som mar- ginaljustering och centrering, om ett textdokument skapat i t.ex. ett XML-baserat ordbehandlingsformat överförs till ren text. Om ett dokument å andra sidan skapats som ren text från början kan sådana funktioner inte sägas vara en del av ursprungs- dokumentet, och i så fall uppstår inte problemet. När det gäller dokument sparade som text med någon av de ovannämnda 7- el- ler 8-bitarskodningarna skall det alltid gå att återge dokumentet i läsbart skick i en programmiljö som har stöd för den aktuella kodningen. När det gäller Unicode är saken mer komplicerad. Det är nödvändigt att skilja mellan tecken och glyfer i rela- tion till denna standard: en glyf är den form som används för att rendera ett tecken på skärm eller i utskrift, och en uppsättning glyfer utgör ett teckensnitt (Unicode Con-
16 sortorium 2014, s. 15–16). En glyf kan representera flera tecken, och ett tecken kan representeras av flera olika glyfer i ett teckensnitt: vilken som visas kan då bero på inställningar för formatering etc. Enskilda Unicodeteckensnitt innehåller inte heller glyfer för alla tecken som är definierade i Unicode. Därmed finns risk att ett textdo- kument inte kan återges läsbart hos en mottagare om det innehåller tecken som inte representeras av glyfer i något teckensnitt mottagaren har installerat. Ett sätt att hantera detta är att begränsa sig till tecken som finns representera- de i teckensnitt som kan förväntas vara lätt tillgängliga för mottagaren. Riksarki- vet tillåter t.ex., som nämnts i avsnitt 2.1.1, bara en kraftigt begränsad uppsättning Unicodetecken för bevarande av databaser i textformat. Dock bör inte detta problem överdrivas. Det finns idag teckensnitt som är fritt tillgängliga i TrueType-format, vil- ket stöds i moderna datormiljöer, som innehåller glyfer för alla BMP-tecken (Hardy 2014). Google Inc. (2014) avser att inkludera glyfer för alla skriftsystem i Unico- de i OpenType-format, men uppsättningen är i dagsläget inte fullständig. Om ett textdokument innehåller mindre vanliga Unicodetecken, kan det ur användbarhets- synpunkt vara lämpligt att bifoga instruktioner för installation av ett fritt tillgängligt teckensnitt som innehåller de glyfer som behövs för att återge dokumentet.
2.1.5 Återanvändbarhet Genom textformatets enkelhet är det lätt att skapa rutiner för att extrahera infor- mation ur dokument sparade som ren text. Det finns gott om programmeringsspråk inriktade på automatiserad behandling av text, såsom Sed, AWK och Perl (Dougher- ty och Robbins 1997; Perl.org 2015). Strukturerad information i tabeller kan sparas i fält med fast bredd eller med ett separatortecken. Riksarkivet anger båda dessa format som tillåtna för bevarande av databaser (RA-FS 2009:2, 3 kap. 1§).
2.1.6 Diskussion Utifrån ovanstående beskrivning kan textformatet relateras till de olika dimensio- nerna i records continuum. Sett till skapandedimensionen kan användning av for- matet innebära att arkivbildare sparar dokument som ren text, vilket kan göras i en textredigerare, som är gjord för att primärt hantera dokument i detta format, i ett ordbehandlingsprogram som kan spara filer som text eller i något mer specialiserat system för att hantera dokument. Det kan också innebära att dokument sparas i ett format som sedan kan överföras till text, t.ex. något av de XML-baserade ordbe- handlingsformat som diskuteras i kommande avsnitt. I många fall är kanske det sista sättet det mest realistiska. I dagsläget är de flesta som producerar textdokument i olika organisationer vana att använda ordbehandlare som Microsoft Word, och även om det är möjligt att spara dokument som ren text i dessa kan det vara omständligt att göra det i dagliga arbetet, och den som gör det kan inte utnyttja den funktionalitet sådana ordbehandlingsprogram erbjuder utöver textredigerare (t.ex. formatering av text).
17 Sett till organisationsdimensionen kan användning av textformatet innebära att befintliga dokument i ett ordbehandlingsformat överförs till text innan de skickas till en arkivinstitution för bevarande. Det går också att tänka sig att arkivbildare använ- der rutiner som automatiskt sparar kopior av ordbehandlingsdokument i textformat i samband med att de sparas i ordbehandlingsformat. Detta kommer, som framhål- lits ovan, att innebära att eventuell formatering går förlorad. Det kan också innebära att dokument i textformat i en äldre kodning, t.ex. ISO/IEC 8859-1, konverteras till en nyare kodning, t.ex. UTF-8. Alla vanliga äldre kodningar kan konverteras till en UTF-kodning utan förlust av information. När det gäller mångfaldigandedimensionen kan det vara så att dokumentet lad- das ned i sin helhet eller att innehåll extraheras ur textdokument för överföring till exempelvis databaser eller andra dokument i textformat eller annat format. Vad innebär detta för textformatet i förhållande till uppsatsens övergripande frå- geställning, om avvägningen mellan integritet och användbarhet? Integriteten är en uppenbar nackdel i de fall där något annat, mer komplext, format använts i skapan- dedimensionen, genom att exempelvis formatering går förlorad. Om dokumenten däremot skapats i textformat är det tvärtom bevarande i detta format som innebär att integriteten bevaras. Sett till användbarheten har textformatet en tydlig styrka. Textdokument kan återges i alla datormiljöer, och formatets enkelhet gör det lätt att extrahera och åter- använda innehåll. Det kan emellertid vara nödvändigt att konvertera dokument till andra kodningar för att hålla dem användbara, och att tillhandahålla teckensnitt som behövs för att återge glyfer i dokumenten. Med tanke på att de flesta arkivbildare i dagsläget i stor utsträckning använder sig av ordbehandlingsprogram och skapar dokument med ofta komplex formatering är textformatet knappast någon attraktiv generell lösning för digitalt bevarande av textdokument.
2.2 PDF/A 2.2.1 Beskrivning av formatet Portable Document Format (PDF) från Adobe har funnits tillgängligt sedan 1993 och har uppnått ställning som dominerande format för utbyte av dokument med kom- plex formatering som skall kunna återges på ett enhetligt sätt i olika datormiljöer. PDF version 1.7 är standardiserad som ISO 32000-1. PDF/A-standarden definierar en uppsättning restriktioner2 av PDF-formatet för att göra dokumenten bättre anpas- sade för digitalt bevarande. Det finns olika versioner av PDF/A-formatet, som beskrivs i varsitt avsnitt i PDF/A-standarden. ISO 19005-1 beskriver PDF/A-1, som är baserad på PDF ver-
2”Restriktion” innebär här att kraven för PDF/A är strängare än för PDF: alla PDF/A-filer är giltiga PDF-filer, men det omvända gäller inte.
18 sion 1.4 (PDF Association 2011). Denna version anges av Riksarkivet som tillåtet bevarandeformat för kontorsdokument (RA-FS 2009:2, 3 kap. 4§). PDF/A-1 innebär följande krav:
1. En rad funktioner som är potentiellt problematiska när det gäller långtidsbeva- rande är förbjudna. Detta inkluderar ljud- och videoinnehåll, JavaScript, anrop av externa program, inbäddade filer, kryptering, transparenta objekt och lager, bilder och andra element som är lagrade i externa filer (även om hyperlänkar till externa dokument är tillåtna) och vissa typer av bildkomprimering (LZW och JPEG2000). 2. De teckensnitt som används måste vara inbäddade i dokumentet. Enhetsobero- ende färgrymder och metadata måste också inkluderas.
ISO 19005-2 och ISO 19005-3 beskriver PDF/A-2 och PDF/A-3, som båda är ba- serade på PDF version 1.7. Jämfört med version 1.4 innebär version 1.7 bl.a. stöd för OpenType-teckensnitt. Restriktionerna i PDF/A-2 liknar annars de i PDF/A-1, men det finns stöd för transparens, JPEG2000 och inbäddade PDF/A-filer (Drümmer 2010). PDF/A-3 liknar PDF/A-2 men har mindre stränga restriktioner i det avseen- det att den tillåter inbäddning av godtyckliga filtyper i PDF/A-dokumenten (C. Arms m. fl. 2014, s. 2). Dessutom gäller för var och en av de olika versionerna av formatet att ett do- kument kan överensstämma med respektive version på olika nivåer. För PDF/A-1 finns nivå A och B, där filer som överensstämmer med respektive nivå betecknas PDF-1a och PDF-1b. Nivå B är den mest grundläggande och innebär att de ovan- nämnda grundkraven uppfylls så att dokumentet kan återges korrekt visuellt. Nivå A kräver dels att all text skall mappas till Unicode, dels användning av s.k. taggad PDF, som innebär att information om dokumentets struktur sparas, något som un- derlättar extrahering av innehåll och återgivning i t.ex. skärmläsare som används av personer med nedsatt syn (PDF Association 2011). PDF/A-2 har också nivå A och B och dessutom nivå U, som innefattar mappning till Unicode men inte de övriga funktionerna på nivå A (Drümmer 2010).
2.2.2 Utbrett mjukvarustöd Dokument som överensstämmer med någon av PDF/A-versionerna är inget annat än PDF-dokument med vissa restriktioner, och det innebär att alla program som kan återge en viss version av PDF-dokument också kan återge PDF/A-dokument som svarar mot den versionen (1.4 för PDF/A-1 och 1.7 för PDF/A-2 och PDF/A-3). Adobe Reader, som är proprietär men gratis att använda, är i praktiken standard för att läsa PDF-filer i bl.a. Windowsmiljö. Det finns även alternativa PDF-läsare, som de fria programmen Xpdf (Foo Labs 2014) och Evince (The Gnome Project 2014). Det är dock inte så att ett program som kan skapa PDF-dokument utan vidare också kan skapa PDF/A-dokument, utan det krävs speciellt stöd för att program- met skall se till att dokumentet inte bryter mot restriktionerna i PDF/A-standarden.
19 LibreOffice Writer och Windowsversionen av Microsoft Word ger båda möjlighet att ange överensstämmelse med PDF/A-1 vid export av ordbehandlingsdokument till PDF. Microsoft Word för Mac har dock för närvarande inte stöd för export till PDF/A. Adobe Acrobat och det fria programmet Ghostscript kan båda skapa filer i enlighet med PDF/A-1 eller PDF/A-2 utifrån PDF- eller Postscriptfiler. En tredje aspekt av mjukvarustöd för PDF/A rör validering. Om ett PDF/A- format anges i filhuvudet i en PDF-fil kommer t.ex. Adobe Reader normalt att visa information om att filen är PDF/A-kompatibel och öppna den skrivskyddad. Vem som helst kan emellertid modifiera huvudet, så detta utgör ingen garanti för att filen verkligen är PDF/A-kompatibel. Det behövs därför en validator, som kan kontrollera om en fil uppfyller de krav som gäller för en given PDF/A-version. Ett program med sådan funktionalitet är verktyget Preflight, som ingår i Acrobat Pro (Adobe Com- munity Help 2015). Apache PDFBox är ett fritt Javabibliotek som innehåller mot- svarande funktion, som också bär namnet Preflight (Apache Software Foundation 2014b), och det finns även system för validering av PDF/A online (PDF Tools AG 2015). Ett problem i sammanhanget är att tillgängliga validatorer inte är perfekta: de kan ge upphov till både falskt positiva resultat, att de hittar icke-existerande fel, och falskt negativa resultat, att de inte hittar existerande fel (Koo och Chou 2013).
2.2.3 Stabilitet PDF/A-formatet har som nämnts ISO-standardiserats. När det gäller PDF-formatet, där PDF/A utgör en delmängd, är detta väl etablerat sedan 1990-talet, och PDF 1.7 inkluderar äldre versioner. PDF/A ter sig därför inte speciellt problematiskt med avseende på stabilitetsaspekten.
2.2.4 Återgivning En grundläggande idé med PDF-formatet är att dokument skall kunna återges kon- sistent på olika plattformar. De grundläggande restriktioner som krävs för Nivå B- kompatibilitet i de olika PDF/A-versionerna syftar till att säkra detta vid långtidsbe- varande. Den föreskrivna inbäddningen av teckensnitt och förbudet mot inbäddning av godtyckliga filer och länkat innehåll i PDF/A-1 och PDF/A-2 innebär att använ- daren inte skall behöva installera någon särskild programvara utöver PDF-läsaren för att återge dokumentet korrekt. PDF/A-3 skiljer sig från de tidigare varianterna genom att inbäddning av godtyckliga filer tillåts. Det har påtalats att den nämnda avsaknaden av restriktioner för inbäddade filer i PDF/A-3 kan medföra problem: eftersom det inte finns något krav att de inbäddade filerna skall kunna återges i en PDF-läsare kan det hända att arkivinstitutioner får PDF/A-3-filer med inbäddade dokument som de saknar möjlighet att återge (Koo och Chou 2013, s. 19). Farhågan är att arkivbildare kommer att använda PDF/A-3 som ”a cover-note for a garbage bag full of who-knows-what” (Johnson 2014). Koo och Chou (2013), s.8 förespråkar med hänsyn till detta bestämt att arkivinstitutioner
20 som tar emot PDF/A-3-filer ser till att ha riktlinjer för arkivbildarna t.ex. beträffande vilka typer av inbäddade filer som är acceptabla. Initialt syftade PDF till att göra det möjligt att återge dokument ”som utskriv- na”. Det finns emellertid sammanhang där andra typer av återgivning är önskvärd, t.ex. vid användning av mobila enheter med låg skärmupplösning eller skärmläsare för användare med synnedsättning. Taggad PDF, som ingår i kraven för överens- stämmelse med PDF/A på nivå A, är ett system som utarbetats för att möjliggöra detta. Detta innebär att information om dokumentets semantiska struktur byggs in i PDF-filen. Exempelvis representeras element som rubriker, stycken och tabeller med HTML-liknande taggar, och ord i texten skall avgränsas på ett otvetydigt sätt.
2.2.5 Återanvändbarhet Komplexiteten i PDF-formatet gör att innehåll inte kan extraheras lika lätt som ur ett rent textdokument. Taggad PDF kan användas för att underlätta återanvändbarhet av information i en PDF-filen, genom att taggarna kan användas för att extrahera sådant som rubriker och tabelldata. Möjligheten att bädda in godtyckliga filer i PDF/A-3-dokument kan utnyttjas för att bädda in material i format som gör det lätt att extrahera innehåll. Ett exempel på detta skulle kunna vara en vetenskaplig artikel i PDF/A-3-format, där data som ligger till grund för tabeller och diagram bäddats in så att t.ex. andra forskare kan extrahera det för egna analyser (Koo och Chou 2013, s. 11). Det går också att bäd- da in källfiler till en längre, strukturerad text i exempelvis något av de format som kommer att behandlas i följande avsnitt (Office Open XML, OpenDocument Text eller Markdown) eller ett format som LaTeX. Om en sådan lösning skall användas vid långtidsbevarande förutsätter det dock genomarbetade riktlinjer för t.ex. vilka källformat som får bäddas in.
2.2.6 Diskussion PDF/A är ett format som normalt inte kommer till användning direkt i skapandet av dokument för bevarande. I stället kan dokument skapas i ordbehandlingsformat, t.ex. Office Open XML eller OpenDocument Text, för att överföras till PDF/A. Vissa system för framställning av dokument, som LaTeX, producerar normalt allmänna PDF-filer, som också kan överföras till PDF/A. På organisationsdimensionen går det dels att genomföra ovannämnda konver- tering av filer i andra dokumentformat eller PDF till PDF/A för långtidsbevarande, dels att verifiera PDF/A-filer så att de verkligen överensstämmer med standarden. När det gäller mångfaldigandedimensionen går det att på olika sätt extrahera och bearbeta innehåll i PDF/A-dokument, antingen huvuddokument eller inbäddade filer, när det gäller PDF/A-2 och PDF/A-3. PDF/A-formatet är i grunden konstruerat för att bevara dokumentens integritet, och det är förmodligen det i dagsläget tillgängliga format som är bäst lämpat för
21 detta ändamål. När det gäller den långsiktiga användbarheten är förutsättningarna goda för att bevara PDF/A-dokument i läsbart skick, eftersom det finns gott om pro- gram för att läsa denna typ av filer. Däremot kan formatet vara mer problematiskt när det gäller extrahering och bearbetning av innehåll. PDF/A-kompatibilitet på nivå A kräver att dokumentet inkluderar taggar, som kan användas för att bevara informa- tion om dokumentets struktur och extrahera innehåll. PDF/A-3 innebär möjlighet att bädda in t.ex. källdokument i ordbehandlingsformat i en PDF/A-fil, vilket kan vara en fördel när det gäller framtida återanvändning av innehållet. Det kräver dock en genomtänkt praxis för att inte inbäddningen skall missbrukas på ett sätt som även- tyrar dokumentens långsiktiga användbarhet, och det innebär en ökad komplexitet i PDF/A-filerna, som bör vägas mot för- och nackdelar med andra lösningar, som att spara källdokumenten separat.
2.3 Mellanspel om XML Extensible Markup Language (XML) ligger till grund för formaten Office Open XML Document och OpenDocument Text, som kommer att behandlas i följande avsnitt. XML är ett märkspråk som standardiseras genom rekommendationer från World Wide Web Consortorium (W3C). Det finns två versioner som utvecklas pa- rallellt, XML 1.0 och XML 1.1. XML 1.0 är den mest använda versionen, där den första W3C-rekommendationen (W3C 1998) publicerades 1998 och den femte och senaste (W3C 2008) publicerades 2008. XML utgör en delmängd av Standardized Generalized Markup Language (SGML). Generella syntaxregler definierar vad som är ett välformat XML-dokument, men XML är en generell specifikation avsedd att användas som utgångspunkt för mer specifika format. Det går därför att använda oli- ka typer av scheman som definierar t.ex. vilka attribut och element som är tillåtna i ett XML-dokument som är giltigt relativt schemat. Det finns olika schemaspråk för XML, som Document Type Definition (DTD), XML Schema [Definition] (XS[D]) och RELAX NG (W3C 2015). Nedanstående exempel visar ett kort XML-dokument3.
1 2 3
3Bygger på en övning av mig vid kursen i digital dokumenthantering höstterminen 2013.
22 8
23 butet xsi:schemaLocation hör hemma i denna namnrymd och kopplar dokumen- tet till schemat lvir.xsd. Namnrymd specificeras även för detta.
2.4 Office Open XML Document 2.4.1 Beskrivning av formatet Microsoft Word ingår som ett delprogram i Microsoft Office och har sedan tidigt 1990-tal haft en dominerande ställning som ordbehandlingsprogram bland använ- dare av Windows och Mac OS/OS X. Under lång tid sparade programmet doku- ment i det proprietära Microsoft Word Binary File Format, där filerna fick ändelsen .doc (Microsoft 2014). Microsoft Excel 2002, som ingick i Microsoft Office XP, var det första av Office-programmen som inkluderade ett XML-baserat filformat. Office 2003 inkluderade XML-baserade format för både Word och Excel (Jones 2007). Do- kument i dessa tidiga XML-format är fristående okomprimerade XML-filer (Micro- soft 2007). Office Open XML standardiserades först 2006 som ECMA-376 (ECMA 2012) och inkluderades som standardformat i Microsoft Office 2007 (Jones 2007). Senare ISO-standardiserades formatet som ISO/IEC 29500:2008. ISO-standarden defini- erar två nivåer av överensstämmelse, ”strict” och ”transitional”, där den senare är till för bakåtkompatibilitet med den ursprungliga ECMA-376. WordprocessingML är den specifika del av standarden som behandlar ordbehandlingsdokument i över- ensstämmelse med standarden, vilka har tillägget .docx. Det finns även Spreadshe- etML för kalkylblad, PresentationML för presentationer och DrawingML för grafik. Office Math Markup Language (OMML) används för att återge matematiska formler inbäddade i dokument. Detta introducerades i Microsoft Office 2007, och medförde initialt kompatibilitetsproblem med vissa vetenskapliga tidskrifter (Sargent 2007). En Office Open XML-fil är ett ZIP-arkiv med katalogstruktur i överensstäm- melse med Open Packaging Conventions (OPC). ZIP-komprimeringen innebär en utrymmesbesparing jämfört med de äldre okomprimerade XML-formaten. Filstruk- turen i ett sådant arkiv kan vara relativt komplex. Nedan listas strukturen i ett enkelt dokument. Figur 2.2 visar hur det aktuella dokumentet återges i Word $ unzip -l fluvir.docx Archive: fluvir.docx Length Date Time Name ------1572 03-15-2015 07:50 [Content_Types].xml 575 03-15-2015 07:50 _rels/.rels 2745 03-15-2015 07:50 word/document.xml 1263 03-15-2015 07:50 word/_rels/document.xml.rels 330 03-15-2015 07:50 word/_rels/footnotes.xml.rels 3350 03-15-2015 07:50 word/numbering.xml 15738 03-15-2015 07:50 word/styles.xml 627 03-15-2015 07:50 word/footnotes.xml 438 03-15-2015 07:50 docProps/core.xml 724 06-02-2014 03:37 docProps/app.xml
24 7674 06-02-2014 03:37 word/theme/theme1.xml 2494 06-02-2014 03:37 word/fontTable.xml 2034 06-02-2014 03:37 word/settings.xml 199 06-02-2014 03:37 word/webSettings.xml ------39763 14files
Filen [Content_Types].xml i roten innehåller en förteckning över de filer som ingår i arkivet och deras mediatyp. Filen _rels/.rels definierar övergripande rela- tioner som används när program läser filen. Denna fil innehåller i sin tur en hänvis- ning till word/document.xml, som innehåller själva texten och strukturen i doku- mentet. Den största filen i paketet är word/styles.xml, där formatmallar definieras. Filen word/document.xml omfattar 117 rader XML och ser ut på följande sätt: 1 2
25 21
26 59
27 96
Taggarna inleds med w, vilket är prefixet för den namnrymd som är defini- erad för WordprocessingML. Dokumentet innesluts i en
2.4.2 Utbrett mjukvarustöd Microsoft Word har som nämnts haft stöd för Office Open XML sedan Word 2007. Den ISO-standardiserade versionen kom först 2008, och stöd för denna hade inte
28 Figur 2.2: Listad Office Open XML-kod som den återges i Microsoft Word 2010. implementerats fullständigt i Microsoft Office 2010, vilket gav upphov till en del debatt (Brown 2010a). Först Word 2013 kan skriva dokument som överensstämmer med standarden på strict-nivån (C. R. Arms, Fleischhauer och Murray 2015). En rad andra program har åtminstone grundläggande stöd för att läsa och skriva filer i enlighet med olika versioner av Office Open XML Document. Detta inkluderar vanliga ordbehandlingssystem såsom LibreOffice Writer (The Document Founda- tion 2014), ordbehandlingsfunktionen i Google Docs (Google Inc. 2015) och Ap- ples Pages (Apple Inc. 2015). Pandoc, som kommer att behandlas mer detaljerat i avsnittet om Markdown, kan konvertera mellan Office Open XML Document och ett stort antal andra textformat (MacFarlane 2013b). Eftersom formatet är XML-baserat går det också att inspektera och redigera do- kument i en generisk textredigerare. Att dokumenten är komprimerade är relativt oproblematiskt i sammanhanget eftersom det finns utbrett stöd för ZIP-formatet. I praktiken kan det emellertid vara svårt att på detta sätt få en överblick över strukturen och innehållet i ett dokument enligt Office Open XML. Som ovanstående kodexem- pel visar tenderar document.xml-filerna, där texten lagras, att bli icke-transparenta, bl.a. genom att XML-taggar och attribut upptar stor plats i förhållande till själva texten, jämfört med t.ex. ett format som HTML.
2.4.3 Stabilitet Det har rapporterats vissa kompatibilitetsproblem mellan versioner av Office Open XML, så att t.ex. Word 2007 inte producerar dokument som är fullt kompatibla med ISO/IEC 29500 ens på transitional-nivån (Brown 2010b).
29 2.4.4 Återgivning Office Open XML Document är standardformat i program som Microsoft Word, och formatet skall därför stödja de funktioner för t.ex. formatering och struktur av dokument som finns i Word. Formatet är emellertid inte, som PDF/A, gjort för att garantera konsistent återgivning på olika enheter. Det är möjligt, men inte obligato- riskt, att bädda in teckensnitt. Byte av skrivardrivrutin kan påverka sidlayouten i ett dokument.
2.4.5 Återanvändbarhet Eftersom Office Open XML Document är ursprungsformat för filer som skapas i Microsoft Word går det att använda t.ex. Word för att extrahera innehåll ur doku- ment. Det går också att utveckla fristående rutiner för att extrahera information ur dokumenten. Formatets komplexitet innebär emellertid att detta kan vara komplice- rat i jämförelse med exempelvis textdokument.
2.4.6 Diskussion Office Open XML-dokument skapas normalt i Word, även om det också går att kon- vertera dokument i andra format till Office Open XML. När det sedan gäller över- föring av dokument för långtidsbevarande är det inte sannolikt att det finns skäl att konvertera textdokument i andra format till Office Open XML. Däremot kan det fö- rekomma att Office Open XML-dokument konverteras till andra format anpassade för bevarande, t.ex. PDF/A eller oformaterad text. En fördel med att bevara dokument i ett originalformat som Office Open XML är att innehållet lätt kan extraheras och återanvändas med hjälp av Word eller annat ordbehandlingsprogram som är kompatibelt med formatet. Samtidigt kan det vara problematiskt att konsistent återgivning av dokument, med avseende på t.ex. sidlay- out, är svår att garantera. Trots ISO-standardiseringen finns det också vissa frågetec- ken när det gäller stabiliteten hos Office Open XML. Med hänsyn till dessa faktorer är det tveksamt om Office Open XML lämpar sig som enda format för långtidsbe- varande av text i speciellt många fall.
2.5 OpenDocument Text 2.5.1 Beskrivning av formatet OpenOffice.org lanserades av Sun Microsystems 2002 som en fri kontorssvit (Sun Microsystems 2002). Programmet hade utvecklats ur den äldre proprietära sviten StarOffice. StarOffice använde, i likhet med äldre versioner av programmen i Micro- soft Office, binära filformat. OpenOffice.org använde sig däremot initialt av ett for- mat som, liksom det senare Office Open XML, baserades på komprimerad XML och fick namnet OpenOffice.org XML. År 2010 köptes Sun av Oracle, som året efter
30 överlät OpenOffice.org till Apache Software Foundation, vilka fortsatt att utveckla det som Apache OpenOffice (Apache Software Foundation 2014a). Strax dessförin- nan hade det emellertid bildats en s.k. fork (en avknoppning av ett mjukvaruprojekt) med namnet LibreOffice (The Document Foundation 2015). Många av de utveckla- re som arbetat med OpenOffice.org hade gått över till LibreOffice, och programmet hade snabbt blivit standardval i många Linuxdistributioner. Sedan OpenOffice.org 2.0 år 2005 har programmet (inklusive de nämnda här- ledda projekten) använt sig av OpenDocument, ett XML-baserat format som bygger på OpenOffice.org XML. Formatet har definierats av Organization for the Advance- ment of Structured Information Standards (OASIS), som tillhandahåller specifika- tioner (OASIS 2013). Sedan 2006 har det även ISO-standardiserats som ISO/IEC 26300. Ordbehandlingsdokument använder sig av OpenDocument Text, och dessa filer får tillägget .odt. En OpenDocument-fil kan vara en fristående XML-fil eller ett ZIP-arkiv. Nedan- stående listning visar filstrukturen i ett dokument med samma innehåll som Office Open XML-exemplet men sparat som ett OpenDocument Text-arkiv. $ unzip -l fluvir.odt Archive: fluvir.odt Length Date Time Name ------39 03-15-2015 07:50 mimetype 494 03-15-2015 07:50 meta.xml 1158 03-15-2015 07:50 META-INF/manifest.xml 3042 03-15-2015 07:50 content.xml 9866 08-11-2013 23:21 settings.xml 785 08-11-2013 23:21 Thumbnails/thumbnail.png 899 08-11-2013 23:21 manifest.rdf 0 08-11-2013 23:21 Configurations2/images/Bitmaps/ 0 08-11-2013 23:21 Configurations2/popupmenu/ 0 08-11-2013 23:21 Configurations2/toolpanel/ 0 08-11-2013 23:21 Configurations2/statusbar/ 0 08-11-2013 23:21 Configurations2/progressbar/ 0 08-11-2013 23:21 Configurations2/toolbar/ 0 08-11-2013 23:21 Configurations2/menubar/ 0 08-11-2013 23:21 Configurations2/accelerator/current. xml 0 08-11-2013 23:21 Configurations2/floater/ 54587 01-02-2014 21:54 styles.xml ------70870 17files Filen content.xml, som innehåller dokumentens text och struktur, omfattar 23 rader XML och listas nedan. 1 2
31 xmlns:table=" urn:oasis:names:tc:opendocument:xmlns:table:1.0" xmlns:draw=" urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl- fo-compatible:1.0" xmlns:xlink="http://www.w3.org /1999/xlink" xmlns:dc="http://purl.org/dc/elements /1.1/" xmlns:meta=" urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:number=" urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" xmlns:svg=" urn:oasis:names:tc:opendocument:xmlns:svg- compatible:1.0" xmlns:chart=" urn:oasis:names:tc:opendocument:xmlns:chart:1.0" xmlns:dr3d=" urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" xmlns:math="http://www.w3.org/1998/Math/MathML" xmlns:form=" urn:oasis:names:tc:opendocument:xmlns:form:1.0" xmlns:script=" urn:oasis:names:tc:opendocument:xmlns:script:1.0" xmlns:ooo="http://openoffice.org/2004/office" xmlns:ooow="http://openoffice.org/2004/writer" xmlns:oooc="http://openoffice.org/2004/calc" xmlns:dom="http://www.w3.org/2001/xml-events" xmlns:xforms="http://www.w3.org/2002/xforms" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance " office:version="1.2"> 3
32 11
33 Open XML-format, som exemplifierats ovan. Den ligger närmare ett format som HTML.
2.5.2 Utbrett mjukvarustöd Som nämnts är OpenDocument Text standardformat för dokument i några olika ord- behandlingsprogram härledda från OpenOffice.org, såsom LibreOffice Writer och Apache OpenOffice Writer. Detta är fria program som finns tillgängliga för Windows och olika Unixliknande operativsystem, som Mac OS X och GNU/Linux. Microsoft Word 2007 och senare har också stöd för OpenDocument Text (Microsoft 2015a). Pandoc kan skriva OpenDocument Text men i dagsläget inte läsa formatet.
2.5.3 Stabilitet Formatet är ISO-standardiserat, och de senaste versionerna av Apache OpenOffice och LibreOffice är kapabla att öppna filer som följer äldre versioner av specifikatio- nen för OpenDocument.
2.5.4 Återgivning På samma sätt som med Office Open XML Document är inte OpenDocument Text gjort för att garantera konsistent återgivning av dokument oberoende av plattform. Det går att bädda in teckensnitt, men konsistent återgivning av t.ex. sidlayout kan inte garanteras.
2.5.5 Återanvändbarhet OpenDocument Text har i grova drag egenskaper liknande Office Open XML Docu- ment när det gäller att möjliggöra återanvändning av innehåll. Formatets uppbygg- nad, med en tendens till ”renare” text, som visas i listningen, kan dock innebära att det är enklare att extrahera eller manipulera text.
2.5.6 Diskussion Dokument i enlighet med OpenDocument Text skapas normalt i LibreOffice eller Apache OpenOffice. De kan sedan användas för långtidsbevarande eller överföras till annat format, som PDF/A, på samma sätt som med Office Open XML. I stora drag är för- och nackdelarna med OpenDocument Text för långtidsbevarande desamma som med Office Open XML. Program som LibreOffice har i dagsläget mindre an- vändarbas än Microsoft Office, samtidigt som det, som nämnts i föregående avsnitt, finns vissa fördelar med OpenDocument Text ur ett återanvändbarhetsperspektiv. Det finns också mindre rapporterade problem när det gäller stabilitetsaspekten.
34 2.6 Markdown 2.6.1 Beskrivning av formatet Den första versionen av Markdown definierades 2004 av John Gruber, med hjälp av bl.a. Aaron Swartz (Gruber 2004). Det ursprungliga syftet var att kunna generera enkla HTML-dokument med hjälp av en minimal syntax som skulle vara lätt att lära sig och där källdokumenten skulle vara lätta att läsa i en vanlig textredigerare, utan att uppmärkningen blev alltför iögonfallande. Enligt Gruber var det vanlig e-post i oformaterad text (där det utvecklats informella konventioner för att t.ex. framhäva text med asterisker) som var den främsta inspirationskällan för syntaxen, även om tidigare filter för överföring av text till HTML, som Textile och reStructuredText, också haft betydelse i sammanhanget. Som nämnts i inledningen existerar det för närvarande ingen standardisering från ISO eller motsvarande av Markdown, och det har med åren utvecklats en del olika versioner av formatet. I detta avsnitt ligger fokus på den version av Markdown som stöds av mjukvaran Pandoc (MacFarlane 2013b), som är ett bibliotek och kom- mandoradsverktyg utvecklat av filosofen John MacFarlane i Haskell, ett s.k. funk- tionellt programmeringsspråk. Den första versionen av Pandoc kom 2006. Om inte annat anges kommer ”Markdown” i fortsättningen att referera till Pandocversionen av märkspråket. Önskvärdheten av en standardisering av Markdown har påtalas av Ovadia (2014). En specifikation med namnet CommonMark är för närvarande un- der arbete (MacFarlane 2015). Denna specifikation har inte uppnått officiell status, och John Gruber har inte accepterat att ordet ”Markdown” förekommer i specifika- tionens namn (Atwood 2014). Följande listning visar en Markdowntext, som använts för att generera exemplen på Office Open XML och Open Document Text i ovanstående avsnitt. 1 --- 2 title: Influensavirus -- en taxonomi 3 author: Karl Pettersson 4 --- 5 6 ##Subtypsindelningen för influensa A 7 Det finns tre arter av influensavirus -- A, B och C. Influensa A-virus indelas i sin tur i *subtyper* efter typen av glykoproteinerna hemagluttinin och neuraminidas. A/H3N2 har alltså hemagluttinin typ 3 och neuraminidas typ 2. 8 9 Någon sådan indelning används inte för influensa B och C. 10 11 ##Influensa A
35 12 13 ###A/H1N1 14 Olika varianter av A/H1N1 har orsakat bl.a. spanska sjukan 1918 och pandemin 2009 ([Wikipedia](http://en .wikipedia.org/wiki/Influenza_pandemic)).
Om denna text sparas som fluvir.md kan den överföras till HTML med nedan- stående kommandorad. $ pandoc -o fluvir.html fluvir.md --smart -s
Detta skapar en fil med namnet fluvir.html med följande innehåll. 1 2 3
4 5 6 7 8Influensavirus – en taxonomi
14Karl Pettersson
15Subtypsindelningen för influensa A
17Det finns tre arter av influensavirus – A, B och C. Influensa A-virus indelas i sin tur i subtyper efter typen av glykoproteinerna hemagluttinin och neuraminidas. A/H3N2 har alltså hemagluttinin typ 3 och neuraminidas typ 2.
18Någon sådan indelning används inte för influensa B och C.
19Influensa A
20A/H1N1
21Olika varianter av A/H1N1 har orsakat bl.a. spanska
36 Figur 2.3: Listad XHTML-kod som den återges i Mozilla Firefox.
sjukan 1918 och pandemin 2009 (Wikipedia ).
22 23Format för utdata antas vara HTML (närmare bestämt XHTML 1.0, en imple- mentering av HTML i XML) när filnamnstillägget .html anges. Figur 2.3 visar Firefox med den listade XHTML-koden. Om .docx eller .odt angetts hade i stället Office Open XML- och OpenDocument-exemplen i föregående avsnitt genererats. Växeln --smart innebär att t.ex. dubbla bindestreck, som i huvudrubriken, konver- teras till tankstreck (Unicode 0x2013). Växlen -s gör att det generas ett fristående dokument med huvud. Utan denna hade enbart bodyinnehållet genererats. Mark- downkoden är relativt självförklarande. Stycken avgränsas med dubbla radbrytning- ar. Rubriker på nivå 푛 kan anges i s.k. ATX-stil genom att rubrikraden inleds med 푛 #-tecken. Emfas anges med att text omges med asterisker. Hyperlänkar anges på formatet [länk](mål). Pandoc har stöd för metadatablock i enlighet med formatet YAML, även om så- dant stöd inte specificeras av MacFarlane (2015). Dessa block omges av tre binde- streck. I det aktuella exemplet har ett sådant block med fältet title och author defi- nierats. Dessa används dels för metadata i HTML-dokumentet, dels för dokumenthu- vudet i det inledande
37 mandoraden, hade Pandoc i stället genererat ett
• De i tidigare avsnitt diskuterade XML-baserade ordbehandlingsformaten Office Open XML Document och OpenDocument Text. • TeX-baserade format, som LaTeX och ConTeXt, som används för typsättning av bl.a. tekniska och naturvetenskapliga dokument. Det går också att generera PDF-filer från Pandoc via LaTeX. • Andra format inriktade på teknisk dokumentation, som DocBook, TexInfo, groff man (används för systemdokumentation i Unixliknande system) och Haddock (används för dokumentation i Haskell). • EPUB och FictionBook (används för e-böcker). • Andra lättviktiga märkspråk, som reStructuredText, MediaWiki (används exem- pelvis på Wikipedia) och Org Mode (används av textredigeraren Emacs). • Oformaterad text.
De flesta av de ovannämnda formaten kan även användas som indataformat, även om stöd för alla funktioner i formaten inte garanteras. Ett format som för närvarande inte stöds som indataformat är dock OpenDocument Text. Dokument i detta format kan överföras till Markdown indirekt genom att de först konverteras till t.ex. HTML i LibreOffice eller till ett annat lättviktigt märkspråk, som reStructuredText, med hjälp av programvara från tredje part (Ciampa 2014). För att skapa fristående måldokument i ett givet format använder sig Pandoc av mallar, där det bl.a. anges vilka element som skall placeras i dokumenthuvudet. Det är möjligt att använda en anpassad mall genom att ange växeln --template=FIL. Med hjälp av växlarna --reference-odt=FIL och --reference-docx=FIL går det ange referensdokument för OpenDocument eller Office Open XML med anpas- sade formatmallar och dokumentegenskaper. En annan viktig funktion i Pandoc är automatisk generering av källhänvisningar. Källor kan definieras i YAML Ain’t Markup Language (YAML)-block eller anges i externa filer, men det finns även stöd för flera vanliga bibliografiformat, som MODS, RIS, EndNote och BibTeX. Följande Markdowndata innehåller en källhänvisning, som anges med nyckeln [@kucharski15].
1 Nya rön tyder på att frekvensen av infektion med influensavirus minskar med stigande ålder upp till 30-årsåldern men därefter förblir konstant genom livet [@kucharski15]. 2 3 ##Referenser
38 Om detta fragment har sparats som filen flufreq.md och det vidare finns en BibTeX-fil flu.bib där referensen kucharski15 definierats, kan en HTML-fil med namnet flufreq.html genereras med följande kommando. $ pandoc -o flufreq.html flufreq.md --bibliography=flu.bib Den genererade HTML-filen har följande innehåll (utan huvud). 1
Nya rön tyder på att frekvensen av infektion med influensavirus minskar med stigande ålder upp till 30-årsåldern men därefter förblir konstant genom livet (Kucharski et al. 2015) .
2Referenser
4Kucharski, Adam J., Justin Lessler, Jonathan M. Read , Huachen Zhu, Chao Qiang Jiang, Yi Guan, Derek A. T . Cummings, and Steven Riley. 2015. “Estimating the Life Course of Influenza a(H3N2) Antibody Responses from Cross-Sectional Data”. PLoS Biol 13 (3). Public Library of Science: e1002082. doi:10.1371/journal.pbio.1002082.
52.6.2 Utbrett mjukvarustöd Pandoc i sig är fri mjukvara och tillhandahålls för närvarande i färdigkompilera- de paket för Windows, Mac OS X, flera av de vanligaste Linuxdistributionerna, NetBSD och FreeBSD (MacFarlane 2013a). Om det inte finns uppdaterade paket
39 för den plattform som används, går det att bygga och installera Pandoc från källko- den med hjälp av verktyget cabal, vilket ingår i Haskell Platform, som också är fritt tillgänglig för de flesta systemmiljöer. Som exemplen ovan visar är Markdownkodade filer lätta att läsa och ändra i en ordinär textredigerare. Pandoc använder sig av kodningen UTF-8, för vilken det finns utbrett stöd, som diskuterats under avsnitt 2.1 ovan. Dessutom tillhandahåller flera textredigerare, bl.a. Emacs (Blevins 2015) och Vim (Sanson och Morales 2015), stöd för syntaxmärkning och andra funktioner för Markdown.
2.6.3 Stabilitet Markdown och Pandoc har funnits relativt kort tid, och det existerar, som nämnts, inga standardiseringar av formatet, även om arbete med detta pågår. Det kan hända att framtida versioner av program som Pandoc bryter kompatibilitet med de versioner av Markdown som stötts av tidigare versioner. Även i avsaknad av standardisering innebär emellertid Markdownformatets närhet till oformaterad text att rimligt god läsbarhet med hjälp av textredigerare kan bevaras även om Markdownfilerna inte kan överföras till andra format.
2.6.4 Återgivning Markdownformatet kan i sig inte återge någon formatering, på samma sätt som med oformaterad text. Däremot kan Markdownfiler konverteras till och från format med stöd för formatering, t.ex. Office Open XML Document. Om en fil lagrad i Mark- down konverteras till eller från ett sådant format, eventuellt med hjälp av ett egen- definierat referensdokument, ärvs de problem med att bevara konsistent formatering som finns med dessa format. Så länge dokument primärt skapas i format som Office Open XML eller Open Document kan inte Markdownformatet komma runt de begränsningar som finns i Microsoft Word och LibreOffice Writer när det gäller konsistent återgivning. Där- emot kan det ge en fördelaktig lösning för detta om arkivbildarna använder Mark- down för att generera PDF-dokument, som sedan kan överföras till PDF/A. PDF kan anropas som utdataformat i Pandoc. Detta innebär att en PDF-fil genereras med ett kommando genom att det skapas ett tillfälligt LaTeX-dokument och LaTeX anropas för att överföra det till PDF (det finns, som nämnts, även möjlighet att skapa per- manenta LaTeX-dokument utifrån Markdown, vilket bl.a. gör att det går att använda mer avancerade funktioner för bibliografier). Figur 2.4 visar ett dokument genererat med pandoc -o fluvir.pdf fluvir.md som det återges i Evince.
2.6.5 Återanvändbarhet Filer lagrade som Markdown har egenskaper liknande rena textfiler när det gäller återanvändbarhet. Det är möjligt att återanvändningen i viss mån kompliceras om t.ex. rå HTML-kod används, som beskrivits ovan. Om Markdown används för att
40 Figur 2.4: Pandoc-genererad PDF i Evince.
41 generera PDF via LaTeX på det sätt som beskrivits ovan går det även att återskapa dokument med konsistent utseende. Detta förutsätter att användaren förutom Pandoc har tillgång till de malldokument och teckensnitt som använts för dokumentet och en LaTeX-distribution med nödvändiga paket. Det existerar fria LaTeX-distributioner för de flesta datorplattformar, även om de tenderar att vara tämligen utrymmeskrä- vande. Det har framförts önskemål om att ge möjlighet att generera PDF även via groff, ett mindre och enklare program som typiskt är förinstallerat på olika Linux- system och Mac OS X och även finns tillgängligt för Windows (Bolaños 2014).
2.6.6 Diskussion Sett till skapandedimensionen kan Markdowndokument framställas på samma sätt som rena textdokument, alltså med en textredigerare, eventuellt utökad med funk- tioner för sådant som färgmarkering av kod. När det gäller långtidsbevarande finns sedan flera alternativ. Markdownfiler kan i sig användas för långtidsbevarande, eller de kan överföras till ett annat format, som PDF/A. Det är också möjligt att överföra dokument sparade i ett annat format, t.ex. Office Open XML, till Markdown. Omvänt kan Markdowndokument överföras till komplexa ordbehandlingsformat. Sett till användbarheten har Markdown genom sin enkelhet fördelar liknande text. Ur ett integritetsperspektiv är för- och nackdelarna med Markdown mycket be- roende av skapandedimensionen. Om dokument framställs i Markdown och används för att t.ex. generera PDF direkt via Pandoc är formatet mycket fördelaktigt när det gäller integritet, även om det ändå kan vara rekommendabelt att bevara PDF/A om konsistent återgivning tillmäts stor betydelse. Om t.ex. Office Open XML-dokument skapade i Word överförs till Markdown kan det innebära problem med integriteten, om inte de ursprungliga dokumenten sparas parallellt för att bibehålla formatmallar och layout, och i vilket fall ärvs de problem med integriteten som finns hos Office Open XML-formatet.
2.7 Övergripande jämförelse Vid bevarande av textdokument är det möjligt att använda ett eller flera av de fem format som diskuterats i ovanstående avsnitt. Uppenbara fördelar med att använda mer än ett format är att det går att dra nytta av styrkorna hos olika format och att beroendet av specifik mjukvara som krävs för ett format kan minska. Nackdelen är att det kan bli kostsamt att använda flera format. Om flera kopior av en fil skall lagras parallellt kräver det både mer lagringsutrymme och medför mer komplex administ- ration. Givet att ett dokument skall bevaras i åtminstone ett av de fem diskuterade fil- formaten finns det teoretiskt 25 −1 = 31 kombinationer av filformat att välja mellan. Dessa kombinationer visas i tabell 2.1, och detta avsnitt syftar till en jämförelse av
42 deras för- och nackdelar i ljuset av diskussionen i föregående avsnitt. Observera att fokus ligger på användning av en kombination för ett och samma dokument, och inte att en arkivbildare använder sig av olika format för olika dokument, t.ex. från olika delar av verksamheten. När det gäller vissa av kombinationerna ter det sig inte troligt att de skulle vara av något större intresse för en bevarandelösning som tar hänsyn till både integritet och användbarhet. Detta gäller framför allt de kombinationer som inkluderar båda de XML-baserade ordbehandlingsformaten eller både Markdown och ren text. De båda ordbehandlingsformaten är så pass likartade med avseende på för- och nackdelar att det är svårt att se någon större poäng med att bevara ett och samma dokument i båda formaten. På motsvarande sätt gäller att Markdown erbjuder liknande fördelar som ren text med avseende på återanvändbarhet och uppenbart är överlägset när det gäller att bevara formatering, varför det är svårt att se något skäl till att ett dokument som lagrats som Markdown även skulle behöva lagras som ren text utan Markdownkod- ning. De kombinationer som ter sig irrelevanta utifrån detta är alla kombinationer med fyra eller fem format, tvåformatskombinationerna 9 och 13 och treformatskom- binationerna 18–22 och 25. Det återstår alltså 17 kombinationer, som kommer att diskuteras närmare i det följande.
2.7.1 Enformatskombinationer (1–5) Kombination 1 innebär att dokument för bevarande sparas enbart som ren text. Detta är fördelaktigt när det gäller användbarhetsaspekten, under förutsättning att doku- menten sparas i en kodning med utbrett stöd, som UTF-8, men ofördelaktigt när det gäller integritetsaspekten, utom i de fall där dokumenten skapats som ren text. Om dokumenten däremot skapas som ren text kommer denna kombination troligen att vara ett givet val genom sin enkelhet. Kombination 2 innebär att spara dokumenten som enbart PDF/A. Detta bevarar deras integritet väl. Samtidigt kan det vara problematiskt när det gäller vissa aspekter av återanvändbarhet, och överensstämmelse på nivå A kan vara att föredra framför enbart överensstämmelse på nivå B ur denna synpunkt. Om PDF/A-3 används och källdokument i något av de andra behandlade filformaten bäddas in är det att betrakta som en variant av aktuell flerformatskombination. En tänkbar användare av denna kombination skulle kunna vara arkivbildare 퐴2, som använder Microsoft Word och LibreOffice för att producera formaterade do- kument. Det finns inget behov att modifiera dokumenten efter att de skickats till bevarande, och dokumenten som skall bevaras utgörs mestadels av brev och liknan- de utan speciellt komplex struktur, men det bedöms som viktigt att dessa kan bevaras i det skick de hade då de expedierades till sin ursprungliga mottagare. Användarna instrueras därför att konvertera dokument till PDF/A innan de skickas för bevarande. Kombination 3 innebär att dokumenten sparas som enbart Office Open XML. Detta är fördelaktigt ur användbarhetssynpunkt när det gäller att möjliggöra framtida bearbetning i ett program som Word, men formatets komplexitet kan innebära pro-
43 Text PDF/A OOXML ODT Markdown 1* 1 0 0 0 0 2* 0 1 0 0 0 3* 0 0 1 0 0 4* 0 0 0 1 0 5* 0 0 0 0 1 6* 1 1 0 0 0 7* 1 0 1 0 0 8* 1 0 0 1 0 9 1 0 0 0 1 10* 0 1 1 0 0 11* 0 1 0 1 0 12* 0 1 0 0 1 13 0 0 1 1 0 14* 0 0 1 0 1 15* 0 0 0 1 1 16* 1 1 1 0 0 17* 1 1 0 1 0 18 1 1 0 0 1 19 1 0 1 1 0 20 1 0 1 0 1 21 1 0 0 1 1 22 0 1 1 1 0 23* 0 1 1 0 1 24* 0 1 0 1 1 25 0 0 1 1 1 26 1 1 1 1 0 27 1 1 1 0 1 28 1 1 0 1 1 29 1 0 1 1 1 30 0 1 1 1 1 31 1 1 1 1 1
Tabell 2.1: Alla logiskt möjliga kombinationer med åtminstone ett av de fem diskuterade filforma- ten: ren text, PDF/A, Office Open XML (OOXML), OpenDocument Text (ODT) och Markdown. De kombinationer som är märkta med asterisk diskuteras i texten som tänkbara alternativ för bevarande.
44 blem när det gäller andra typer av återanvändning. Det kan också vara problematiskt ur integritetssynpunkt, när det gäller bevarande av teckensnitt, sidlayout etc. Kom- bination 4, som innebär sparande som enbart OpenDocument Text, har egenskaper liknande kombination 3, men formatet är mindre komplext, vilket kan innebära en användbarhetsfördel, och det kan också vara mindre problematiskt ur stabilitetssyn- punkt. Exempel på användare av dessa kombinationer skulle kunna vara arkivbildarna 퐴3 och 퐴4, som använder Microsoft Word respektive LibreOffice för att framställa dokument. Dokumenten som skall bevaras utgörs av forskningsmaterial, där det är viktigt att textinnehållet bevaras och hålls sökbart, men det inte finns något behov att bevara exakt formatering. Arkivenheten tar därför emot dokument i respektive ordbehandlingsformat. Kombination 5 innebär att dokumenten sparas som enbart Markdown. Ur an- vändbarhetssynpunkt medför det nästan samma fördelar som kombination 1, ef- tersom formatet är föga mer komplext än ren text. Ur integritetssynpunkt bevarar formatet dokumentets struktur och gör det möjligt att återskapa formaterade doku- ment i olika format. Om inga mallar eller referensdokument i andra format finns tillgängliga går det emellertid inte att i detalj styra måldokumentens formatering. Detta innebär att om dokument skapade i komplexa ordbehandlingsformat bevaras som Markdown kommer inte integriteten att bevaras fullständigt. Användning av kombination 5 exemplifieras av arkivbildare 퐴5, som använder textredigerare för att skapa dokument i Markdownformat. Dessa överförs sedan till olika målformat, som HTML och PDF. Det finns dock inget behov att bevara doku- menten som de återges i dessa format. Precis som när det gäller 퐴3 och 퐴4 är det väsentliga att själva textinnehållet och strukturen bevaras. Därför tar arkivenheten emot Markdownfiler för bevarade.
2.7.2 Tvåformatskombinationer (6–15) Kombination 6 innebär att dokumenten sparas dels som ren text, dels som PDF/A. På så vis är det möjligt att kombinera fördelarna med PDF/A ur integritetssynpunkt med fördelarna med ren text ur användbarhetssynpunkt. Textkopian kommer dock inte att kunna användas för att återskapa funktioner relaterade till dokumentens struktur och formatering. En användare av denna kombination skulle kunna vara arkivbildare 퐴6, som an- vänder program som Microsoft Word och LibreOffice för att producera dokument. Det bedöms som viktigt att dokumenten bevaras så att de kan återges med konsistent utseende och att det är enkelt att extrahera information. Därför bevaras de som både PDF/A och oformaterad text kodad enligt UTF-8. Makron utarbetas i Visual Basic och LibreOffice Basic för att automatiskt spara kopior av dokument i ordbehand- lingsformat i båda dessa format innan dokumenten sänds för bevarande. Kombinationerna 7 och 8 innebär att dokumenten sparas som dels ren text, dels i ett komplext ordbehandlingsformat. Textformatet är överlägset de XML-baserade
45 ordbehandlingsformaten när det gäller användbarhetsaspekten, men inget format är optimalt när det gäller integritetsaspekten (det kan förutsättas att det rör sig om do- kument som skapats i ett ordbehandlingsformat, då det är svårt att se någon poäng alls med att överföra oformaterade textdokument till ordbehandlingsformat för be- varande). Arkivbildare 퐴7 och 퐴8 använder Microsoft Word respektive LibreOffice för att framställa dokument. Det finns inget behov att bevara exakt formatering hos doku- menten. Däremot bedöms det som viktigt att textinnehållet kan återges utan tillgång till specialiserad programvara. Därför konverteras dokumenten till text kodad enligt UTF-8, som lagras parallellt med det ursprungliga ordbehandlingsformatet. Kombinationerna 10 och 11 innebär att dokumenten sparas som dels PDF/A, dels i ett komplext XML-baserat ordbehandlingsformat. Detta kan vara lämpligt när det gäller dokument skapade i de aktuella ordbehandlingsprogrammen: ordbe- handlingsformaten är överlägsna PDF/A ur användbarhetssynpunkt, samtidigt som PDF/A är överlägset ur integritetssynpunkt. Arkivbildare 퐴10 och 퐴11 använder Microsoft Word respektive LibreOffice för att framställa dokument. Det bedöms som viktigt att bevara dokumenten dels så att de kan återges konsistent dels så att innehållet kan återanvändas med bibehållen do- kumentstruktur. Dokumenten konverteras därför till PDF/A på samma sätt som hos 퐴3 och 퐴4 samtidigt som de också bevaras i sitt ursprungliga ordbehandlingsformat. Kombination 12 innebär att dokumenten sparas dels som PDF/A, dels som Mark- down. Det innebär liknande fördelar som kombination 6 plus de fördelar Markdown medför när det gäller att bevara dokumentens struktur. Om de ursprungliga doku- menten är lagrade som PDF-filer som genererats utifrån Markdownfiler via Pan- doc innebär det att LaTeX använts för att generera dem, och då går det att återska- pa PDF-dokument med konsistent utseende utifrån Markdownfilerna, under förut- sättning att användarna har tillgång till Pandoc och en LaTeX-distribution tillsam- mans med de malldokument och teckensnitt som används för dokumentet. Under dessa förutsättningar är detta förmodligen den kombination som ger bäst förutsätt- ningar att bevara både integritet och användbarhet för formaterade dokument. Dess användning begränsas emellertid av den dominerande ställning ordbehandlingspro- gram som Microsoft Word och LibreOffice Writer har hos många arkivbildare. Arkivbildare 퐴12 använder textredigerare för att skapa dokument i Markdown- format, som i sin tur används för att generera PDF-dokument med hjälp av Pandoc. Det bedöms som viktigt att dokumenten kan återges konsistent och att innehållet kan återanvändas med bibehållen struktur. Dokumenten konverteras därför till PDF/A samtidigt som de också bevaras i Markdownformat. Även de LaTeX-mallar som används för att skapa PDF-filer med hjälp av Pandoc bevaras. På så sätt möjlig- görs återskapande av modifierade versioner av dokumenten med samma utseende som de ursprungliga. Detta kräver dock att användaren har tillgång till en LaTeX- distribution, förutom Pandoc. Kombinationerna 14 och 15 innebär att dokumenten sparas dels i något av de
46 XML-baserade ordbehandlingsformaten, dels i Markdown. Detta innebär samma fördelar som kombinationerna 7 och 8 tillsammans med fördelarna med Markdown jämfört med ren text. En variant på dessa kombinationer är att spara det specifika do- kumentet i Markdown samtidigt som referens- eller malldokument med komponen- ter som behövs för att återskapa specifik formatering eller dokumenthuvuden sparas i ordbehandlingsformatet. Ett referens- eller malldokument kan användas. Detta kan vara användbart t.ex. för myndigheter som arbetar med ett enhetligt utseende på de dokument som produceras inom verksamheten. Arkivbildare 퐴14 och 퐴15 använder Microsoft Word respektive LibreOffice för skapande av dokument. Det finns inget behov att bevara dokumenten så att forma- tering kan återges exakt, men det är viktigt att kunna återanvända dokumenten på ett sätt som bevarar deras struktur. Hos 퐴14 konverteras dokument i enlighet med Office Open XML till Markdown med hjälp av Pandoc. Hos 퐴15 sparas dokument i enlighet med OpenDocument som HTML i LibreOffice. De på detta sätt skapa- de HTML-dokumenten överförs sedan till Markdown med Pandoc. I båda fallen kan Markdowndokumenten redigeras och sedan användas för att återskapa doku- ment i Office Open XML eller OpenDocument med de ursprungliga dokumenten som referensdokument, så att formatmallar och andra dokumentegenskaper bibe- hålls, även om det inte går att garantera samma konsistenta återgivning som när det gäller PDF/A-dokument. Detta kräver att användaren har tillgång till Pandoc – och, om formatmallarna skall återges korrekt, de teckensnitt som används i dokumenten – men det är inte nödvändigt med tillgång till Word eller LibreOffice.
2.7.3 Treformatskombinationer (16–25) Kombination 16 och 17 innebär att dokumenten sparas dels i ett XML-baserat ord- behandlingsformat, dels som text och PDF/A. Detta skulle kunna vara användbart i en kontext där det ställs höga krav på både återanvändbarhet och integritet. Arkivbildare 퐴16 och 퐴17 använder Microsoft Word respektive LibreOffice för skapande av dokument. Det finns behov att dels bevara dokumenten så att de kan återges med konsistent utseende, dels bevara dem så att så att de kan återanvändas med formatering och struktur och så att innehållet kan återges utan specialiserad programvara. På samma sätt som hos arkivbildare 퐴8 och 퐴9 används makron för att automatiskt spara kopior av dokument i ordbehandlingsformat dels som PDF/A, dels som text kodad enligt UTF-8 innan dokumenten sänds för bevarande. Utöver detta bevaras dokumenten också i de ursprungliga ordbehandlingsformaten. Kombinationerna 23 och 24 motsvarar 16 och 17, förutom att Markdown an- vänds i stället för text. Det ger fördelarna med Markdown ur integritetssynpunkt. Arkivbildare 퐴23 och 퐴24 skapar dokument med hjälp av Microsoft Word respek- tive LibreOffice. Det bedöms hos båda arkivbildarna som viktigt att dokumenten bevaras så att de kan återges med konsistent utseende men också så att de kan åter- användas med formatering och struktur och återges innehållsligt utan specialiserad programvara. Hos 퐴23 konverteras dokumenten dels till PDF/A, dels till Markdown
47 med Pandoc. Hos 퐴24 sparas dokumenten först som HTML i LibreOffice. Dessa HTML-dokument konverteras sedan till Markdown i Pandoc. Om Markdownfilerna sedan modifieras kan de ursprungliga ordbehandlingsdokumenten sedan användas som referensdokument för att återskapa nya dokument i respektive ordbehandlings- format, på samma sätt som hos 퐴14 och 퐴15.
2.7.4 Jämförelsen i relation till continuummodellen Det finns, som framgått av ovanstående genomgång, ingen enskild kombination som ger en rimlig avvägning av integritets- och användbarhetsaspekterna för alla behov av lagring av textdokument. De faktorer som styr vilka kombinationer som är lämp- liga kan relateras till de olika dimensionerna i records continuum. Sett till skapandedimensionen är det för det första väsentligt vad för typ av do- kument som skapas hos arkivbildaren (t.ex. i vilken mån de innehåller formatering och komplex struktur). Om dokumenten skapas som ren text finns ingen anledning att överföra dem till ett mer komplext format. Det har också betydelse vilka program- varor som används för att skapa dokument. Arkivarier och andra som är ansvariga för bevarandefrågor kanske i viss mån kan styra över detta, men ofta är deras möj- ligheter i detta avseende högst begränsade. Sett till organisationsdimensionen har det betydelse i vilken mån de filformat som skall användas vid bevarande är stabila och medger konvertering från de filfor- mat som används vid skapande. Den betydelse som tillmäts integritetsaspekter, som konsistent återgivning, är också av vikt. När det gäller mångfaldigandedimensionen är det viktigt att se till vilka som kan förväntas använda sig av de lagrade dokumenten, vad de kommer att göra för slags extraheringar och bearbetningar av innehållet och vad de kommer att ha tillgång till för mjukvara i samband med detta.
48 3 Slutdiskussion
Denna uppsats har diskuterat filformat för bevarande av textdokument med avseen- de på formatens för- och nackdelar när det gäller aspekterna integritet och använd- barhet. De båda aspekterna har undersökts med avseende på egenskaperna utbrett mjukvarustöd, stabilitet, dokumentåtergivning och återanvändbarhet. De har även kopplats till dimensionerna i records continuum-modellen. Faktorer relaterade till skapandedimensionen (t.ex. vilka program som används för att skapa dokument) är av betydelse för hur dokumenten kan lagras i en arkivkontext på ett sätt som be- varar deras integritet, vilket hör till organisationsdimensionen. Förväntade framtida användningar av de lagrade dokumenten, vilket är en faktor relaterad till mångfal- digandedimensionen, har betydelse för vilka användbarhetsaspekter som är viktiga. De format som diskuterats är: oformaterad text, PDF/A, Office Open XML, Open Document Text och Markdown. Textformatet kännetecknas av att enbart de teckenkoder som är nödvändiga för att representera själva textinnehållet lagras. Formatet är dock inte enhetligt, utan text- filer kan använda sig av olika teckenkodningar, som skiljer sig åt med avseende på de numeriska koder som används för att representera olika tecken i datorns minne, och ett program som kan hantera text sparad i en kodning behöver inte nödvändigtvis kunna hantera text sparad i en annan kodning. Exempel på vanligt förekomman- de teckenkodningar, som alla är ISO-standardiserade, och som kan förekomma hos svenska arkivbildare, är ASCII, ISO/IEC 8859-1 och Unicode. ASCII-kodningen inkluderar 128 tecken – i huvudsak det engelska alfabetet, siffror och vanliga skiljetecken. ISO/IEC 8859-1 (”Latin 1”) definierar 96 tecken- koder utöver de som ingår i ASCII, bl.a. de svenska tecknen åäö. Unicode är en standard som i sina senaste versioner definierar en kodrymd med utrymme för över en miljon tecken, som kan kodas i enlighet med en s.k. UTF-kodning. De vanligas- te UTF-kodningarna är UTF-8 och UTF-16. Alla tecken som finns representerade i Latin 1 (och därmed även ASCII) finns också representerade i Unicode. Därutö- ver inkluderar UTF-8 ASCII också i den starkare meningen att de teckenkoder som används i ASCII också används för motsvarande tecken i UTF-8, vilket innebär att program som har stöd för ASCII också kan läsa ASCII-tecken i en fil sparad som UTF-8. Textformatets stora svaghet ligger i integritetsaspekten, bortsett från de fall där dokumenten från början sparats som oformaterad text. Om t.ex. ett dokument ska-
49 pat i Microsoft Word eller LibreOffice Writer konverteras till ren text försvinner all textformatering, sidlayout, inbäddad grafik etc. Formatets styrka ligger i bevaran- de av användbarheten. Även om den nämnda inkompatibiliteten mellan kodningar ibland kan ställa till problem vid återanvändning av textdokument, gäller ändå att textdokument sparade som t.ex. ASCII eller UTF-8 kan hanteras med hjälp av enkla program som finns tillgängliga på i stort sett alla moderna datorplattformar. När det gäller Unicodedokument som innehåller ovanliga tecken kan det dock krävas till- gång till speciella teckensnitt för att de skall återges korrekt. Formatets enkelhet gör att det också är förhållandevis lätt att utveckla anpassade rutiner som på olika sätt återanvänder information i textdokument. PDF/A är en ISO-standardiserad uppsättning restriktioner av PDF-formatet, som syftar till att anpassa dokumenten för långtidsbevarande. Det finns tre olika versioner av formatet: PDF/A-1, PDF/A-2 och PDF/A-3. Gemensamt för de olika versioner- na är bl.a. att teckensnitt som används måste vara inbäddade, så att dokument kan återges korrekt utan att användaren behöver installera dessa i sitt system, och att vis- sa typer av innehåll, som ljud, video och JavaScript inte får förekomma. PDF/A-2 skiljer sig från A-1 bl.a. genom att den är baserad på PDF 1.7 i stället för 1.4 och att den har stöd för inbäddning av PDF/A-filer. PDF/A-3 har stöd för inbäddning av godtyckliga filer. Det finns också olika nivåer av överensstämmelse med PDF/A, där nivå B är den mest grundläggande och nivåerna U och A innefattar utökade krav på mappning av text till Unicode och s.k. taggad PDF, vilket innebär att information om dokumentstrukturen lagras. PDF-formatet har sedan lång tid tillbaka varit mycket populärt för utbyte av formaterade dokument, och eftersom PDF/A-dokument som sagt bara är normala PDF-dokument som uppfyller vissa restriktioner kan de läsas av alla program som kan läsa dokument i PDF-format. Det finns även gott om program som kan ska- pa PDF/A-dokument, som Microsoft Word (dock inte Mac-versionen), LibreOffice Writer, Adobe Acrobat och Ghostscript. Den grundläggande idén med PDF/A är att bevara centrala aspekter av integri- teten hos formaterade dokument, som konsistent återgivning, och det är förmodligen det format som är bäst anpassat för detta. En problematisk aspekt är dock att det för närvarande inte finns något standardiserat sätt att verifiera om ett givet dokument verkligen uppfyller en viss variant av PDF/A-standarden: de validatorer som finns kan ge olika resultat för ett och samma dokument. Vad gäller återanvändbarheten kan PDF/A vara mer problematiskt: dokument lagrade som PDF/A kan ofta inte öppnas och redigeras i det program där de ur- sprungligen skapades, och formatets komplexitet gör att det kan vara komplicerat att utveckla rutiner för att extrahera information ur dokument. PDF/A-3 ger möjlig- het att bädda in dokument i originalformat, men dessa inbäddningsmöjligheter kan samtidigt skapa problem både för integritet och användbarhet om de inte hanteras varsamt. Populära ordbehandlingsprogram, som Microsoft Word, har traditionellt använt
50 sig av slutna, binära format för lagring av dokument. På senare år har det emellertid blivit mer vanligt med öppna format, baserade på XML. Två sådana format, som bå- da är ISO-standardiserade, är Office Open XML Document, som är standardformat i Microsoft Word, och OpenDocument Text, som är standardformat i LibreOffice Writer och andra ordbehandlingsprogram som bygger på OpenOffice.org. De båda formaten är tekniskt sett relativt likartade: dokumenten lagras i ett ZIP- arkiv där texten, tillsammans med taggar för sådant som styckeindelning och forma- tering, lagras separat från annan information, t.ex. formatmallar. De XML-filer som lagrar texten tenderar att bli mer lättlästa i OpenDocument jämfört med Office Open XML genom att formateringstaggarna tar upp mindre utrymme. Båda ordbehandlingsformaten har utbrett mjukvarustöd, åtminstone med avse- ende på grundläggande funktionalitet. Microsoft Word har i dagsläget klart större användarbas än LibreOffice Writer, vilket innebär en viss fördel för Office Open XML. Program som kan dekomprimera ZIP-filer är också lätt tillgängliga för de flesta system, vilket möjliggör direkt bearbetning av XML-filer i ett arkiv med hjälp av t.ex. en textredigerare. När det gäller användbarhetsaspekten har de XML-baserade formaten den up- penbara fördelen att dokument normalt kan öppnas och redigeras i det program där de skapades. Samtidigt är formaten, speciellt Office Open XML, klart mer kom- plexa än oformaterad text, vilket kan komplicera skapandet av anpassade rutiner för återanvändning av innehåll och skapa ett beroende av tillgång till tunga ordbehand- lingsprogram. Med avseende på integritetsaspekten bevarar formaten dokumentstruktur och textformatering (det senare förutsätter dock i många fall inbäddning av teckensnitt). Bevarande av t.ex. sidlayout kan emellertid inte garanteras, vilket är en nackdel i jämförelse med t.ex. PDF/A. Markdown är ett format som från början utvecklats som ett enkelt sätt att gene- rera HTML. Numera finns program som Pandoc, som kan konvertera mellan Mark- down och en rad andra textformat, bl.a. de ovannämnda XML-baserade ordbehand- lingsformaten. Markdowndokument är textdokument utökade med märkning för ru- briker, emfas o.s.v. Pandoc har även stöd för metadata i YAML. Pandoc är fritt tillgängligt för de flesta vanliga system, och den minimalistiska uppmärkningen gör att Markdowndokument är lätta att läsa och redigera i en vanlig textredigerare. Det finns emellertid ingen ISO-standardisering, eller annan standar- disering erkänd av någon större organisation, av formatet, även om det finns initiativ från enskilda individer att utarbeta rigorösa specifikationer. Sett till integritetsaspekten ger Markdownformatet stöd för att återskapa sådant som rubriker och textformatering. Det går dock av uppenbara skäl inte att t.ex. bädda in teckensnitt i Markdownfiler, och för exakta specifikationer av sådant som format- mallar krävs malldokument i ett annat format. När det gäller användbarhetsaspekten har Markdown en fördel genom att det är nästan lika enkelt som oformaterad text. Dock väcker avsaknaden av standardisering
51 viss oro beträffande långsiktig återanvändning av de funktioner hos formatet som går utöver ren text, t.ex. för rubriker och metadata. Inget av de diskuterade formaten är alltså perfekt med avseende på både integri- tet och användbarhet (med undantag av det fall där dokumentet skapas som oforma- terad text och det inte finns någon utökad funktionalitet att bevara), och för att säkra båda aspekterna kan det bli nödvändigt att använda en kombination av två eller fle- ra format. Valet av format måste avgöras genom en vägning av betydelsen av dessa båda aspekter mot kostnader av att bevara dokument i mer än ett format. Vissa kombinationer av filformat ter sig föga intressanta ur bevarandesynpunkt, som de där dokument lagras i mer än ett ordbehandlingsformat eller som både ofor- materad text och Markdown. Alla kombinationer med fyra eller fem format hör till åtminstone en av dessa kategorier, och därför är det i praktiken bara kombinationer med högst tre format som är värda närmare diskussion. En typ av tvåformatskombination som kan vara användbar är att kombinera nå- got av ordbehandlingsformaten med PDF/A. Bevarandet i PDF/A säkrar integritets- aspekten, och bevarandet i ordbehandlingsformat gör att dokumenten kan återanvän- das i det program där de skapades. En annan variant är att kombinera ordbehand- lingsformat med text eller Markdown, för att möjliggöra återanvändning av doku- menten utan tillgång till komplexa ordbehandlingsprogram. Kombinationen av Markdown med PDF/A kan vara lämplig i de fall där arkivbil- darna producerar dokumenten med hjälp av en textredigerare. Pandoc kan generera PDF-filer från Markdown genom anrop av LaTeX. På så vis kan Pandoc användas för att utifrån Markdownfilerna återskapa PDF-dokument med ett utseende som väl överensstämmer med ursprungsdokumenten, under förutsättning att användarna har tillgång till LaTeX, relevanta teckensnitt och de LaTeX-mallar som använts för att generera PDF-dokumenten. I vissa fall kan det även vara motiverat att kombinera tre format. Ett exempel på detta är lagring i ordbehandlingsformat parallellt med PDF/A och Markdown. På så vis kan konsistent återgivning säkras med hjälp av PDF/A, och dokumenten kan dessutom återanvändas och redigeras med bibehållen formatering och struktur. Detta kan göras genom användning av det ordbehandlingsprogram där de skapades eller genom att Pandoc används för att generera dokument utifrån Markdownfilerna med dokumenten i ordbehandlingsformat som referensdokument. Givetvis finns det filformat för text som inte diskuteras i denna uppsats, och nya format kommer otvivelaktigt att definieras i framtiden. Men det ramverk som definierats i uppsatsen, med de fyra kriterierna mjukvarustöd, stabilitet, återgivning och återanvändbarhet, kan vara en hjälp även i bedömningen av andra format än de diskuterade, med avseende på vilka för- och nackdelar dessa har när det gäller integritets- och användbarhetsaspekterna.
52 4 Sammanfattning
Uppsatsens övergripande frågeställning handlar om valet av filformat för textdoku- ment med hänsyn till egenskaperna integritet, alltså att en handling skall bevaras i fullständigt och oförändrat skick, och långsiktig användbarhet. Frågeställningen konkretiserades till följande fyra kriterier: 1. Utbrett mjukvarustöd för filformaten: ett filformat är inte användbart om det inte kan läsas eller skrivas med den mjukvara som brukas hos arkivbildare och and- ra användare som behöver tillgång till dokumenten. Kriteriet kan relateras till skapandedimensionen i records continuum-modellen. 2. Stabilitet hos filformaten, alltså att de inte skall genomgå ändringar som bryter kompatibilitet med tidigare versioner. Kriteriet kan relateras till organisationsdi- mensionen i records continuum. 3. Att filformaten skall kunna återge dokument med det utseende och den struktur de hade när de skapades. Kriteriet kan relateras till organisationsdimensionen i records continuum. 4. Att filformaten skall tillåta nödvändig återanvändning av information i filerna. Kriteriet kan relateras till mångfaldigandedimensionen i records continuum. Följande fem filformat jämfördes med avseende på de fyra kriterierna: 1. Oformaterad text, som inte innehåller någon kodning utöver vad som är nödvän- digt för att återge textinnehållet i ett dokument. 2. PDF/A, alltså PDF-format med vissa restriktioner som syftar till att anpassa do- kument för långtidsbevarande (t.ex. krav på inbäddade teckensnitt och förbud mot vissa funktioner som kan vara problematiska ur bevarandesynpunkt). 3. Office Open XML Document, ett XML-baserat ordbehandlingsformat som är standardformat i moderna versioner av Microsoft Word. 4. OpenDocument Text, ett XML-baserat ordbehandlingsformat som är standard- format i bl.a. LibreOffice Writer. 5. Markdown, ett s.k. lättviktigt märkspråk, som liknar oformaterad text men in- nefattar minimala instruktioner för formatering och struktur. Markdownfiler kan konverteras till och från andra format med program som Pandoc. När det gäller dokument som skapats med komplex formatering är inget av filfor- maten idealiskt med avseende på alla fyra kriterierna. Oformaterad text har utbrett
53 mjukvarustöd samt god användbarhet och stabilitet (under förutsättning att en stan- dardiserad teckenkodning, som UTF-8, används), men brister när det gäller åter- givningen. PDF/A har utbrett mjukvarustöd, är stabilt och optimalt när det gäller återgivningen men har begränsade möjligheter till smidig återanvändning. Office Open XML och OpenDocument Text har utbrett mjukvarustöd och ger möjlighet till återanvändning, men inte i samma utsträckning som oformaterad text, och trots ISO-standardisering finns frågetecken när det gäller stabiliteten, framför allt för Office Open XML. När det gäller återgivningen är dessa format också underlägsna PDF/A. Markdown är jämförbart med oformaterad text när det gäller mjukvarustöd för läsning och redigering och enkel återanvändning av innehåll, men avsaknaden av standardisering väcker frågetecken med avseende på stabiliteten, och det kan inte säkra återgivningen av formaterade dokument på samma sätt som PDF/A. Om både användbarhets- och integritetsaspekterna är viktiga kan det bli nödvän- digt att lagra textdokument i mer än ett format, vilket t.ex. kan innebära att PDF/A används tillsammans med Markdown och/eller ett av ordbehandlingsformaten.
54 Käll- och litteraturförteckning
Förkortningar i källhänvisningar RA-FS 2009:2 Riksarkivet (2009). Riksarkivets föreskrifter och allmänna råd om tekniska krav för elektroniska handlingar. Riksarkivet.
Otryckt material I uppsatsförfattarens ägo Socialstyrelsen (2014). E-postkorrespondens med uppsatsförfattaren.
Tryckt material Acrobat Engineering Team (2012). Adobe Acrobat Engineering. URL: http://acroeng. adobe.com/wp/ (hämtad 2014-11-13). Adobe Community Help (2015). Analysera dokument med preflight-verktyget (Ac- robat Pro). URL: https : / / helpx . adobe . com / se / acrobat / using / analyzing - documents-preflight-tool-acrobat.html (hämtad 2015-01-03). Apache Software Foundation (2014a). Apache OpenOffice. URL: http : / / www . openoffice.org/ (hämtad 2015-03-13). — (2014b). Apache PDFBox. URL: https://pdfbox.apache.org/index.html (hämtad 2015-01-03). Apple Inc. (2015). Compatiblity. URL: http : / / www . apple . com / mac / pages / compatibility/ (hämtad 2015-03-15). Arms, Caroline R., Carl Fleischhauer och Kate Murray (2013). Sustainability of Digital Formats: Planning for Library of Congress Collections. URL: http:// www.digitalpreservation.gov/formats/index.shtml (hämtad 2014-11-13). — (2015). DOCX Transitional (Office Open XML), ISO 29500:2008-2012, ECMA- 376, Editions 1-4. URL: http : / / www . digitalpreservation . gov / formats / fdd / fdd000397.shtml (hämtad 2015-05-03). Arms, Caroline m. fl. (2014). The Benefits and Risks of the PDF/A-3 File Format for Archival Institutions. Tekn. rapport. NDSA Standards och Practices Wor-
55 king Group. URL: http://www.digitalpreservation.gov/ndsa/working_groups/ documents/NDSA_PDF_A3_report_final022014.pdf. Atwood, Jeff (2014). Standard Markdown is now Common Markdown. URL: http: //blog.codinghorror.com/standard- markdown- is- now- common- markdown/ (hämtad 2015-04-19). Blevins, Jason (2015). Emacs Markdown Mode. URL: http://jblevins.org/projects/ markdown-mode/ (hämtad 2015-03-13). Bolaños, Marduk (2014). Why use LaTeX for PDF output instead of groff? #1839. URL: https://github.com/jgm/pandoc/issues/1839 (hämtad 2015-05-03). Borglund, Erik (2008). Design for recordkeeping : areas of improvement. Diss. Sundsvall : Mittuniversitetet, 2008. Sundsvall: Department of Natural Sciences, Mid Sweden University. ISBN: 978-91-85317-95-0. Brown, Alex (2010a). Microsoft Fails the Standards Test. URL: http://www.adjb. net/post/Microsoft-Fails-the-Standards-Test.aspx (hämtad 2015-03-19). — (2010b). OOXML and Microsoft Office 2007 Conformance: a Smoke Test. URL: http://www.adjb.net/post/OOXML-and-Office-2007-Conformance-a-Smoke- Test.aspx (hämtad 2015-03-18). Ciampa, Marco (2014). Request: ODT reader #1768. URL: https://github.com/ jgm/pandoc/issues/1768 (hämtad 2015-04-19). Cunningham, Adrian (2008). ”Digital Curation/Digital Archiving: A View from the National Archives of Australia”. I: The American Archivist 71, s. 530–543. Dougherty, Dale och Arnold Robbins (1997). Sed & awk. Cambridge: O’Reilly. ISBN: 9781449301880. Drümmer, Olaf (2010). PDF/A-2 – Technical Overview. URL: http://www.pdfa. org/2010/10/pdfa-2-%E2%80%93-technical-overview/ (hämtad 2015-02-15). ECMA (1986). ECMA-94: 8-Bit Single-Byte Coded Graphic Character Sets — La- tin Alphabets No. 1 to No. 4. Second. URL: http : / / www . ecma . ch / ecma1 / STAND/ECMA-094.HTM. — (1991). ECMA-6: 7-Bit Coded Character Set. Sixth. URL: http://www.ecma. ch/ecma1/STAND/ECMA-006.HTM. — (2012). Standard ECMA-376. URL: http : / / www . ecma - international . org / publications/standards/Ecma-376.htm (hämtad 2013-11-26). Foo Labs (2014). Xpdf. URL: http://www.foolabs.com/xpdf/index.html (hämtad 2015-02-16). Free Software Foundation (2011). libiconv. URL: http://www.gnu.org/software/ libiconv/ (hämtad 2015-02-03). Google Inc. (2014). Google Noto Fonts. URL: http://www.google.com/get/noto/ (hämtad 2015-02-12). — (2015). Save Office files to Google Docs, Sheets, and Slides. URL: https : / / support.google.com/docs/answer/6055139 (hämtad 2015-03-15). Gruber, John (2004). Markdown. URL: http://daringfireball.net/projects/markdown/ (hämtad 2015-03-13).
56 Hardy, Paul (2014). GNU Unifont Glyphs. URL: http://unifoundry.com/unifont.html (hämtad 2015-02-12). ICA (2005). Electronic records: a workbook for archivists. ICA. Johnson, Duff (2014). Archivists: No flowers for PDF/A-3. URL: http : / / duff - johnson.com/2014/02/28/archivists-no-flowers-for-pdfa-3/ (hämtad 2015-02-18). Jones, Brian (2007). History of office XML formats (1998-2006). URL: http : / / blogs.msdn.com/b/brian_jones/archive/2007/01/25/office-xml-formats-1998- 2006.aspx (hämtad 2015-03-13). Koo, Jamin och Carol C. H. Chou (2013). ”PDF to PDF/A: Evaluation of Converter Software for Implementation in Digital Repository Workflow”. I: New Review of Information Networking 18.1, s. 1–15. DOI: doi:10.1080/13614576.2013. 771989. MacFarlane, John (2013a). Pandoc - Installing. URL: http://johnmacfarlane.net/ pandoc/installing.html (hämtad 2015-03-13). — (2013b). Pandoc User’s Guide. URL: http://johnmacfarlane.net/pandoc/README. html (hämtad 2014-12-28). — (2015). CommonMark Spec. URL: http://spec.commonmark.org/0.18/ (hämtad 2015-04-19). McKemmish, Sue (2001). ”Placing Records Continuum Theory and Practice”. I: Archival Science 1, s. 333–359. Microsoft (2007). Office 2003: XML Reference Schemas. URL: http://www.microsoft. com/en-us/download/details.aspx?id=101 (hämtad 2015-03-13). — (2014). [MS-DOC]: Word (.doc) Binary File Format. URL: https://msdn.microsoft. com/en-us/library/cc313153(v=office.12) (hämtad 2015-03-13). — (2015a). File format reference for Word 2013, PowerPoint 2013, and Excel 2013. URL: https://technet.microsoft.com/en-us/library/dd797428(v=office. 15).aspx (hämtad 2015-03-15). — (2015b). Windows 1252. URL: https://msdn.microsoft.com/en-us/goglobal/ cc305145 (hämtad 2015-02-03). National Archives (2009). Selecting File Formats for Long-Term Preservation. Tekn. rapport. National Archives. URL: https://www.nationalarchives.gov.uk/documents/ selecting-file-formats.pdf. OASIS (2013). OASIS Open Document Format for Office Applications (OpenDocu- ment) TC. URL: https://www.oasis-open.org/committees/tc_home.php?wg_ abbrev=office (hämtad 2013-11-26). Ovadia, Steven (2014). ”Markdown for Librarians and Academics”. I: Behavioral & Social Sciences Librarian 33. DOI: doi:10.1080/01639269.2014.904696. PDF Association (2011). PDF/A – A Look at the Technical Side. URL: http://www. pdfa.org/2011/08/pdfa-%E2%80%93-a-look-at-the-technical-side/ (hämtad 2015-02-15). PDF Tools AG (2015). Online Validator. URL: http://www.pdf-tools.com/pdf/ validate-pdfa-online.aspx (hämtad 2015-01-03).
57 Perl.org (2015). The Perl Programming Language. URL: https://www.perl.org/ (hämtad 2015-02-13). Q-Success (2015). Historical yearly trends in the usage of character encodings for websites. URL: http://w3techs.com/technologies/history_overview/character_ encoding/ms/y (hämtad 2015-02-03). Riksarkivet (2009). Riksarkivets föreskrifter och allmänna råd om tekniska krav för elektroniska handlingar. Riksarkivet. Sanson, David och Felipe Morales (2015). vim-pandoc. URL: https://github.com/ vim-pandoc (hämtad 2015-03-13). Sargent, Murray (2007). Science and Nature have difficulties with Word 2007 mat- hematics. URL: http://blogs.msdn.com/b/murrays/archive/2007/06/05/science- and - nature - have - difficulties - with - word - 2007 - mathematics . aspx (hämtad 2015-03-15). Simonsen, K. (1992). Character Mnemonics and Character Sets. Internet Engi- neering Task Force. URL: http : / / www . ietf . org / rfc / rfc1345 . txt (hämtad 2015-02-03). Sun Microsystems (2002). OPENOFFICE.ORG COMMUNITY ANNOUNCES OPE- NOFFICE.ORG 1.O: FREE OFFICE PRODUCTIVITY SOFTWARE. URL: http: //www.openoffice.org/about_us/ooo_release.html (hämtad 2015-03-13). Super User (2013). How to remove this symbol “ˆ@” with vim? URL: http : / / superuser.com/questions/75130/how-to-remove-this-symbol-with-vim (häm- tad 2015-02-11). Svärd, Proscovia (2013). ”Enterprise Content Management and the Records Conti- nuum Model as strategies for long-term preservation of digital information”. I: Records Management Journal 23. DOI: doi:10.1108/RMJ-12-2012-0035. The Document Foundation (2014). LibreOffice 4.2 Writer Guide. URL: https://wiki. documentfoundation . org / images / e / e6 / WG42 - WriterGuideLO . pdf (hämtad 2015-03-15). — (2015). LibreOffice. URL: http://www.libreoffice.org/ (hämtad 2015-03-13). The Gnome Project (2014). Apps/Evince. URL: https : / / wiki . gnome . org / Apps / Evince (hämtad 2015-02-16). Unicode Consortorium (2014). The Unicode Standard Version 7.0 – Core Specifica- tion. URL: http://www.unicode.org/versions/Unicode7.0.0/UnicodeStandard- 7.0.pdf (hämtad 2015-02-03). — (2015). Unicode Character Encoding Stability Policy. URL: http://www.unicode. org/policies/stability_policy.html (hämtad 2015-02-11). Upward, Frank (1996). ”Structuring the Records Continuum - Part One: Postcusto- dial principles and properties”. I: Archives and Manuscripts 24, s. 268–285. W3C (1998). Extensible Markup Language (XML) 1.0. URL: http://www.w3.org/ TR/199%C2%A7/REC-xml-19980210/ (hämtad 2015-03-13). — (2008). Extensible Markup Language (XML) 1.0 (Fifth Edition). URL: http : //www.w3.org/TR/2008/REC-xml-20081126/ (hämtad 2015-03-13).
58 — (2015). Schema. URL: http://www.w3.org/standards/xml/schema (hämtad 2015-03-13).
59 Förkortningar i text
ASCII American Standard Code for Information Interchange. 5, 13–16, 49, 50
BMP Basic Multilingual Plane. 14, 17 BOM Byte Order Mark. 15
CSL Citation Style Language. 39
DTD Document Type Definition. 22
EBCDIC Extended Binary Coded Decimal Interchange Code. 14–16
HTML Hypertext Markup Language. 8, 10, 21, 23, 29, 33, 35–40, 45, 47, 48, 51
ICA International Council on Archives. 5 ISO International Organization for Standardization. 5–7, 10, 13–16, 18–20, 24, 28–31, 34, 35, 49–51, 54
OAIS Open Archival Information System. 7 OASIS Organization for the Advancement of Structured Information Standards. 31 OMML Office Math Markup Language. 24, 39 OPC Open Packaging Conventions. 24
PDF Portable Document Format. 2, 5, 6, 8, 10, 11, 18–22, 29, 30, 34, 38, 40–47, 49–54
RQAM Recordkeeping Quality Assesment Model. 8
SGML Standardized Generalized Markup Language. 22 SIP Submission Information Package. 7
UCS Universal Character Set. 15 URL Uniform Resource Locator. 23 UTF Unicode Transformation Format. 14–16, 18, 40, 43, 45–47, 49, 50, 54
W3C World Wide Web Consortorium. 22
60 XML Extensible Markup Language. 2, 3, 5, 6, 8, 10, 11, 16, 17, 21–25, 28–31, 33–35, 37–40, 42–47, 49, 51, 53, 54 XS[D] XML Schema [Definition]. 22
YAML YAML Ain’t Markup Language. 37, 38, 51
61