EKSPERTUDVALGET OM ÅBNE STANDARDER

Transkript

1 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilagssamling Side Bilag A: Beslutningsforslag B 103, juni Bilag B: UVT Betænkning over B 103, juni Bilag C: Konklusionspapir, juni Bilag D: Aftale om anvendelse af åbne standarder for software i det offentlige, oktober Bilag E: Folketingsvedtagelse, V45, om åbne standarder, april Bilag F: Vejledning om anvendelse af åbne standarder, IT- og Telestyrelsen, oktober Bilag G: Testrapport fra laboratorietest, Sogeti, november Bilag H: Research about OpenXML, ODF & PDF, Ovitas, Bilag I: Implementering af åbne dokumentformater hos offentlige myndigheder, IT- og Telestyrelsens anbefalinger på grundlag af pilotforsøg og laboratorietest, nov Bilag J: Vejledning i anvendelse af åbne standarder for dokumentudveksling, ITog Telestyrelsen, december 2007, v Bilag K: Converterkortlægning, Devoteam Consulting, juni Bilag L: Konsulentundersøgelse af åbne dokumentformater, Devoteam Consulting, oktober Bilag M: Endelig rapport til IT- og Telestyrelsen vedrørende monitorering af konverterkvalitet ODF-OOXML, Magenta, oktober Bilag N: Indholdsfortegnelse til bilagsmappen til Folketingets it-ordførere...377

2 Bilagssamling Side 2 af 379

3 Bilagssamling Side 3 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag A

4 Bilagssamling Side 4 af 379 B 103 (som vedtaget): Forslag til folketingsbeslutning om anvendelse af åbne standarder for software i det offentlige. Vedtaget af Folketinget ved 2. (sidste) behandling den 2. juni 2006 Folketingsbeslutning om anvendelse af åbne standarder for software i det offentlige Folketinget pålægger regeringen at sikre, at det offentliges brug af informationsteknologi, herunder brug af software, er baseret på åbne standarder. Regeringen bør senest den 1. januar 2008, eller så snart det er teknisk muligt, indføre og vedligeholde et sæt af åbne standarder, der kan tjene til inspiration for øvrige offentlige myndigheder. Åbne standarder bør herefter være en del af grundlaget for det offentliges udvikling og indkøb af it-software med henblik på at fremme konkurrencen. Regeringen bør sikre, at alle digitale informationer og data, som det offentlige udveksler med borgere, virksomheder og institutioner, findes i formater, der er baseret på åbne standarder.

5 Bilagssamling Side 5 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag B

6 Udvalget for Videnskab og Teknologi Bilagssamling Side 6 af 379 B Bilag 9 Offentligt Til beslutningsforslag nr. B 103 Folketinget Betænkning afgivet af Udvalget for Videnskab og Teknologi den 1. juni 2006 Betænkning over Forslag til folketingsbeslutning om anvendelse af åbne standarder for software i det offentlige [af Morten Helveg Petersen (RV) m.fl.] 1. Ændringsforslag Dansk Folkepartis medlemmer af udvalget har stillet 1 ændringsforslag til beslutningsforslaget. 2. Udvalgsarbejdet Beslutningsforslaget blev fremsat den 30. marts 2006 og var til 1. behandling den 3. maj Beslutningsforslaget blev efter 1. behandling henvist til behandling i Udvalget for Videnskab og Teknologi. Dispensation fra 8 a, stk. 2, i Folketingets forretningsorden Udvalget anmoder om, at Folketinget dispenserer fra reglen i forretningsordenen om, at der skal gå mindst 2 dage fra omdeling af betænkning til 2. (sidste) behandling. Møder Udvalget har behandlet beslutningsforslaget i 4 møder. Skriftlige henvendelser Udvalget har i forbindelse med udvalgsarbejdet modtaget 1 skriftlig henvendelse fra Microsoft Danmark. Videnskabsministeren har over for udvalget kommenteret den skriftlige henvendelse til udvalget. Deputationer Endvidere har Microsoft Danmark mundtligt over for udvalget redegjort for sin holdning til beslutningsforslaget. Samråd Udvalget har stillet 1 spørgsmål til videnskabsministeren til mundtlig besvarelse, som denne har besvaret i et åbent samråd med udvalget den 23. maj Ministeren har efterfølgende sendt udvalget det talepapir, der lå til grund for ministerens besvarelse af spørgsmålet. Spørgsmål Udvalget har stillet 15 spørgsmål til videnskabsministeren til skriftlig besvarelse, som denne har besvaret.

7 2 Bilagssamling Side 7 af Indstillinger og politiske bemærkninger Et flertal i udvalget (udvalget med undtagelse af V og KF) indstiller beslutningsforslaget til vedtagelse med det stillede ændringsforslag. Socialdemokratiets, Dansk Folkepartis, Det Radikale Venstres, Socialistisk Folkepartis og Enhedslistens medlemmer af udvalget lægger til grund, at regeringen ikke har kunnet dokumentere, at der skulle være nævneværdige økonomiske konsekvenser som følge af beslutningsforslaget. Partierne lægger til grund, at beslutningsforslaget ikke må medføre øgede udgifter for det offentlige. Videnskabsministeren har i et åbent samråd sagt:»for så vidt angår de økonomiske konsekvenser af beslutningsforslaget for Videnskabsministeriet, så pålægger forslaget ikke i sig selv Videnskabsministeriet særlige omkostninger i det kommende finansår.«partierne konstaterer, at beslutningsforslaget udelukkende forpligter Videnskabsministeriet til at tilvejebringe de åbne standarder, som derefter kan være med i grundlaget for nye investeringer, men at der ikke som følge af beslutningsforslaget er et krav om, at ældre systemer omlægges til åbne standarder. Partierne lægger endvidere til grund, at der kan være undtagelser fra den generelle regel om, at grundlaget skal være åbne standarder, og at disse undtagelser i så fald skal begrundes. Derfor medfører beslutningsforslaget ikke økonomiske konsekvenser for kommuner og amter. Et mindretal i udvalget (V) vil redegøre for sin stilling til beslutningsforslaget og det stillede ændringsforslag ved 2. (sidste) behandling. Et andet mindretal i udvalget (KF) vil redegøre for sin stilling til beslutningsforslaget og det stillede ændringsforslag ved 2. (sidste) behandling. Venstres og Det Konservative Folkepartis medlemmer af udvalget støtter beslutningsforslagets intentioner om at skabe øget åbenhed, konkurrence og sammenhæng. Dog er der usikkerhed om, hvorvidt beslutningsforslaget i sin nuværende form vil være tilstrækkeligt til at understøtte målene for den digitale forvaltning bl.a. i forhold til at sikre adgang til data til brug for digital forvaltning. Disse spørgsmål vil blive belyst i rapporten fra udvalget om bedre interoperabilitet, som videnskabsministeren har indbudt udvalget til en drøftelse af den 15. august Venstre og Det Konservative Folkeparti noterer med tilfredshed, at regeringen allerede er i gang med udbredelsen af åbne standarder. Videnskabsministeriet udvikler og vedligeholder allerede i dag et katalog med et sæt af fælles standarder for hele den offentlige sektor. Disse standarder bliver i vidt omfang allerede brugt som en del af grundlaget for indkøb af software i den offentlige sektor. Regeringen arbejder på at øge anvendelsen af de anbefalede standarder, bl.a. ved at de indgår i den fremtidige statslige standardkontrakt for it-indkøb K02. De to partier noterer sig endvidere, at Videnskabsministeriet fremover skal begrunde eventuelle afvigelser fra den generelle regel om, at grundlaget skal være åbne standarder. Desuden vil Videnskabsministeriet fra den 1. september 2006 tilbyde publikationer og anden relevant skriftlig kommunikation i et åbent dokumentformat i det konkrete tilfælde Open Document Format (ODF) når de offentliggøres. Finansministeriet vil ligeledes fra den 1. september 2006 lægge sine nye publikationer ud i ODFformat, medmindre særlige kontraktmæssige eller indholdsmæssige forhold gør sig gældende. Venstre og Det Konservative Folkeparti er desuden bekendt med, at regeringen vil sikre, at tre til fire ministerier fra den 1. september 2006 deltager i forsøget med at tilbyde publikationer og anden

8 3 Bilagssamling Side 8 af 379 relevant skriftlig kommunikation i et åbent dokumentformat, og håber, at flere ministerier vil deltage. Efter en prøveperiode frem til årsskiftet 2006/07 vil erfaringerne fra forsøgene blive samlet op med henblik på at igangsætte eventuelle yderligere tiltag i forhold til borgere og virksomheder. Der fremsendes en afrapportering fra udvalget vedrørende interoperabilitet om åbne standarder inden sommerferien 2006, og videnskabsministeren har allerede inviteret partiernes ordførere til en drøftelse om udvalgets arbejde i august måned Siumut, Tjóðveldisflokkurin, Fólkaflokkurin og Inuit Ataqatigiit var på tidspunktet for betænkningens afgivelse ikke repræsenteret med medlemmer i udvalget og havde dermed ikke adgang til at komme med indstillinger eller politiske udtalelser i betænkningen. En oversigt over Folketingets sammensætning er optrykt i betænkningen. 4. Ændringsforslag med bemærkninger Æ n d r i n g s f o r s l a g Af et mindretal (DF), tiltrådt af et mindretal (S, RV, SF og EL): Til teksten 1) I 2. afsnit indsættes efter»2008«:», eller så snart det er teknisk muligt,«. [Ændring af frist for at indføre og vedligeholde et sæt af åbne standarder] Til nr. 1 Hvis det ikke er teknisk muligt at indføre og vedligeholde et sæt af åbne standarder senest den 1. januar 2008, bør det ske, så snart det er teknisk muligt.

9 4 Bilagssamling Side 9 af 379 Troels Lund Poulsen (V) Britta Schall Holberg (V) Tina Nedergaard (V) Torsten Schack Pedersen (V) Henrik Fruergaard (V) Jesper Langballe (DF) Jørn Dohrmann (DF) Per Ørum Jørgensen (KF) Carina Christensen (KF) Rasmus Prehn (S) Magnus Heunicke (S) nfmd. Christine Antorini (S) Pia Gjellerup (S) Margrethe Vestager (RV) Morten Helveg Petersen (RV) Anne Grete Holmsgaard (SF) Per Clausen (EL) Siumut, Tjóðveldisflokkurin, Fólkaflokkurin og Inuit Ataqatigiit havde ikke medlemmer i udvalget. Folketingets sammensætning Venstre, Danmarks Liberale Parti (V) 52 Enhedslisten (EL) 6 Socialdemokratiet (S) 47 Siumut (SIU) 1 Dansk Folkeparti (DF) 24 Tjóðveldisflokkurin (TF) 1 Det Konservative Folkeparti (KF) 18 Fólkaflokkurin (FF) 1 Det Radikale Venstre (RV) 17 Inuit Ataqatigiit (IA) 1 Socialistisk Folkeparti (SF) 11

10 5 Bilagssamling Side 10 af 379 Bilag 1 Oversigt over bilag vedrørende B 103 Bilagsnr. Titel 1 Pressemeddelelse om åbent samråd den 23. maj Henvendelse af 17/5-06 fra Microsoft Danmark 3 Forstudiet»Forstudie: Obligatorisk anvendelse af åbne standarder«, fra videnskabsministeren 4 IT- og Telestyrelsens notat»udenlandske initiativer vedrørende åbne standarder«, fra videnskabsministeren 5 Notaterne»Pilotforsøg med software gennemført i 2004«og»Økonomiske konsekvenser vedr. åbne standarder for kommunerne«, fra videnskabsministeren 6 Talepapir fra samråd 23/5-06, fra videnskabsministeren 7 1. udkast til betænkning 8 2. udkast til betænkning Oversigt over spørgsmål og svar vedrørende B 103 Spm.nr. Titel 1 Spm. om at beregne de økonomiske konsekvenser af beslutningsforslaget med de angivne forudsætninger og herunder holde disse op imod de årlige udgifter forbundet med opgradering til ny software baseret på proprietære standarder i den offentlige sektor, til videnskabsministeren, og ministerens svar herpå 2 Spm. om, hvad de økonomiske og teknologiske konsekvenser af beslutningsforslaget er med de i beslutningsforslaget angivne forudsætninger opdelt på finansårene 2006, 2007 og 2008, til videnskabsministeren, og ministerens svar herpå 3 Spm. om, hvad de økonomiske og teknologiske konsekvenser af beslutningsforslaget er for Videnskabsministeriet, og hvilket beregningsgrundlag der i den forbindelse er lagt til grund, til videnskabsministeren, og ministerens svar herpå 4 Spm., om ministeren kan bekræfte, at beslutningsforslaget er udgiftsneutralt for kommunerne, til videnskabsministeren, og ministerens svar herpå 5 Spm., om ministeren kan bekræfte, at der er årsværk i den statslige sektor, der arbejder med udvikling og vedligeholdelse af åbne standarder, til videnskabsministeren, og ministerens svar herpå 6 Spm. om, hvornår ministeren forventer at beslutningsforslagets forudsætninger om et fuldt sæt åbne standarder vil være tilvejebragt med den nuværende teknologiske udvikling, til videnskabsministeren, og ministerens svar herpå 7 Spm. om redegørelse for de direkte afledte omkostninger som følge af

11 6 Bilagssamling Side 11 af 379 beslutningsforslaget eksklusive omkostninger forbundet med indkøb af ny software i den offentlige sektor, til videnskabsministeren, og ministerens svar herpå 8 Spm. om redegørelse for de teknologiske og økonomiske omkostninger i Videnskabsministeriet som følge af beslutningsforslaget, til videnskabsministeren, og ministerens svar herpå 9 Spm., om ministeren kan bekræfte, at det er omkostningsneutralt for kommunerne, hvis man fra centralt hold indfører og vedligeholder et sæt åbne standarder, til videnskabsministeren, og ministerens svar herpå 10 Spm. om kommentar til henvendelse af 17/5-06 fra Microsoft Danmark, til videnskabsministeren, og ministerens svar herpå 11 Spm., om pdf-formatet efter ministerens opfattelse er en åben standard eller ej, til videnskabsministeren, og ministerens svar herpå 12 Spm. om, hvilke åbne standarder på dokumentsiden der i dag honorerer internationale krav om handicaptilgængelighed, til videnskabsministeren, og ministerens svar herpå 13 Spm., om ministeriet anvender andre åbne formater end odf-formatet på sin hjemmeside, til videnskabsministeren, og ministerens svar herpå 14 Spm. om fremsendelse af kommissorium m.v. for det tværministerielle udvalg, som ministeren omtalte i sin besvarelse af samrådsspørgsmål A, til videnskabsministeren, og ministerens svar herpå 15 Spm. om, hvad de økonomiske konsekvenser af beslutningsforslaget er for kommunerne, og hvilke ændringsforslag ministeren forestiller sig, der kan stilles for at afhjælpe eventuelle negative økonomiske konsekvenser, til videnskabsministeren, og ministerens svar herpå Samrådsspm.nr. A Titel Oversigt over samrådsspørgsmål vedrørende B 103 Samrådsspm. om, hvad de økonomiske konsekvenser efter ministerens vurdering er af beslutningsforslaget for Videnskabsministeriet i det kommende finansår, til videnskabsministeren

12 Bilagssamling Side 12 af 379

13 Bilagssamling Side 13 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag C

14 Bilagssamling Side 14 af 379 Bilag 32 Konklusionspapir, juni 2007 Konklusionspapir Indførelsen af åbne standarder skal, uden at det medfører øgede udgifter for det offentlige, fremme et konkurrencepræget marked for software og medvirke til, at offentlige it-systemer uanset valg af software kan udveksle informationer på tværs. For hvert potentielt set obligatoriske sæt af åbne standarder gennemføres en økonomisk konsekvensvurdering. Vurderingen sikrer, at indførelsen af den enkelte standard er samfundsøkonomisk hensigtsmæssig. For alle de foreslåede standarder gælder, at den enkelte myndighed ved eventuelle merudgifter eller for den pågældende myndighed it-sikkerhedsmæssige hensyn kan undlade at anvende de obligatoriske standarder. De nærmere retningslinier, herunder hvordan en undladelse skal begrundes, fastsættes i de generelle vejledninger, der udarbejdes på baggrund af implementeringen af B103. At en standard er åben indebærer, at: standarden skal være fuldstændigt dokumenteret og offentligt tilgængelig, standarden skal være frit implementérbar uden økonomiske, politiske eller juridiske begrænsninger på implementering og anvendelse, hverken nu eller i fremtiden, og standarden skal være standardiseret og vedligeholdt i et åbent forum via en åben proces (standardiseringsorganisation). De første syv sæt af obligatoriske, åbne standarder træder i kraft fra den 1. januar Det drejer det sig om følgende sæt af standarder: Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) Standarder til elektronisk sags- og dokumenthåndtering (FESD) Standarder til elektroniske indkøb i det offentlige (OIOUBL) Standarder for digital signatur (OCES) Standarder for offentlige netsteder / hjemmesider og tilgængelighed Standarder for it-sikkerhed (DS484 - er indført og gælder kun for staten) Standarder for dokumentudveksling (ODF/OOXML) Vedrørende standarder for dokumentudveksling eksisterer der i dag to åbne væsentlige standarder for disse formater på markedet: ODF og OOXML. Begge standarder er dog stadig relativt umodne, og der mangler konkrete erfaringer med deres anvendelse i praksis. Derfor er de økonomiske konsekvenser ved at indføre dem vanskelige at estimere og baseret på et stort skønselement. Samme erkendelse er man ligeledes nået frem til i andre europæiske lande, der står over for lignende beslutninger. 1

15 Bilagssamling Side 15 af 379 Bilag 32 Konklusionspapir, juni 2007 Derfor igangsættes følgende implementering: Den 1. januar 2008 skal alle offentlige myndigheder kunne modtage tekstbehandlingsdokumenter fra borgere, virksomheder og andre myndigheder i to formater: OOXML og ODF. Pr. 1. januar 2008 bliver OOXML og ODF obligatoriske standarder for offentlige myndigheder. Løsninger, der indkøbes efter 1. januar 2008, skal understøtte mindst en af disse åbne standarder og kunne modtage tekstbehandlingsdokumenter i begge formater, evt. ved brug af tilføjelsesprogrammer (plug-ins). Om ODF og /eller OOXML skal være obligatoriske efter 1. juli 2009 afgøres efter en vurdering af en uafhængig tredjepart. Initiativet vil for staten blive underbygget af, at krav om anvendelse af åbne standarder vil indgå i Finansministeriets kommende aftaler om indkøb af software. Vurderingen af om ODF og/eller OOXML skal være obligatoriske efter 1. juli 2009 skal ske inden for rammerne af folketingsbeslutning B103. Som led i vurderingen indgår blandt andet: Softwareleverandørernes evne til at sikre interoperabilitet mellem de to standarder i deres produkter i forhold til det offentliges udvekslingsbehov (funktionalitetsloft). De reelle muligheder for og de praktiske erfaringer med at implementere standarderne uafhængigt af leverandør og platform. En konkret vurdering fra Konkurrencestyrelsen om effekten af anvendelse af obligatoriske åbne standarder for dokumentudveksling på konkurrencesituationen. De nærmere kriterier for vurderingen, anvendelse af eksterne eksperter og udvælgelse af uafhængig tredjepart drøftes med Folketingets it-ordførere inden udgangen af Videnskabsministeren vil løbende drøfte implementeringen af åbne standarder for software i det offentlige med Folketingets it-ordførere. I disse drøftelser kan indgå forslag til relevante tiltag, der understøtter konkurrencen. Implementeringen af ovenstående konklusioner kræver regeringsbeslutning samt en aftale med kommuner og regioner om anvendelse af standarderne, herunder at der ikke er økonomiske krav forbundet med implementeringen. 2

16 Bilagssamling Side 16 af 379

17 Bilagssamling Side 17 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag D

18 Bilagssamling Side 18 af 379 Aftale om anvendelse af åbne standarder for software i det offentlige, oktober 2007 Indførelsen af de obligatoriske, åbne standarder er obligatorisk for staten. Med denne aftale erklærer Danske Regioner og KL sig enige i, at regioner og kommuner ligeledes indfører standarderne som beskrevet i teksten nedenfor. Regioner og kommunerne tilslutter sig indførelsen af obligatoriske åbne standarder, da udbredelsen af de åbne standarder vil fremme konkurrence og interoperabilitet. Baggrund Den 2. juni 2006 vedtog et enigt Folketing folketingsbeslutning B 103 om anvendelse af åbne standarder for software i det offentlige. B 103 pålægger regeringen at sikre, at det offentliges brug af informationsteknologi, herunder brug af software, er baseret på åbne standarder. Et flertal af partierne har lagt til grund, at B 103 ikke må medføre øgede udgifter for det offentlige. 11. august 2006 offentliggjordes rapporten Virkemidler til fremme af interoperabilitet gennem fælles, åbne standarder. Bag rapporten stod Videnskabsministeriet, Finansministeriet, KL og Danske Regioner. Rapporten lagde en fællesoffentlig basis for hvordan udmøntningen af B103 kunne gennemføres. Herunder blev det foreslået, at man gennemførte udmøntningen af B103 ved en regeringsbeslutning og en aftale med de kommunale parter. På baggrund af Folketingets folketingsbeslutning B 103 fra sommeren 2006, og rapporten Virkemidler til fremme af interoperabilitet gennem fælles, åbne standarder, sendte Videnskabsministeriet i februar 2007 rapporten Anvendelse af åbne standarder for software i det offentlige i høring. Denne rapport anbefaler, at syv software-standarder gøres obligatoriske pr. 1. januar Høringssvarene var overvejende positive, og videnskabsministeren opnåede efterfølgende en politisk enighed om en køreplan for implementering af anvendelse af obligatoriske, åbne standarder for software i det offentlige. Obligatoriske, åbne standarder Indførelsen af åbne standarder skal, uden at det medfører øgede udgifter for det offentlige, fremme et konkurrencepræget marked for software og medvirke til, at offentlige it-systemer uanset valg af software kan udveksle informationer på tværs. For hvert potentielt set obligatoriske sæt af åbne standarder gennemføres en økonomisk konsekvensvurdering. Vurderingen sikrer, at indførelsen af den enkelte standard er samfundsøkonomisk hensigtsmæssig. De første syv sæt af obligatoriske, åbne standarder træder i kraft fra den 1. januar Det drejer det sig om følgende sæt af standarder: Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) Standarder til elektronisk sags- og dokumenthåndtering (FESD) Standarder til elektroniske indkøb i det offentlige (OIOUBL)

19 Bilagssamling Side 19 af 379 Standarder for digital signatur (OCES) Standarder for offentlige netsteder / hjemmesider og tilgængelighed Standarder for it-sikkerhed (DS484 - kun for staten) Standarder for dokumentudveksling (ODF/OOXML) Vedrørende standarder for dokumentudveksling eksisterer der i dag to åbne væsentlige standarder for disse formater på markedet: ODF og OOXML. Begge standarder er dog stadig relativt umodne, og der mangler konkrete erfaringer med deres anvendelse i praksis. Derfor er de økonomiske konsekvenser ved at indføre dem vanskelige at estimere og baseret på et stort skønselement. Samme erkendelse er man ligeledes nået frem til i andre europæiske lande, der står over for lignende beslutninger. Derfor igangsættes følgende implementering: Den 1. januar 2008 skal alle offentlige myndigheder kunne modtage tekstbehandlingsdokumenter fra borgere, virksomheder og andre myndigheder i to formater: OOXML og ODF. Pr. 1. januar 2008 bliver OOXML og ODF obligatoriske standarder for offentlige myndigheder. Løsninger, der indkøbes efter 1. januar 2008, skal understøtte mindst en af disse åbne standarder og kunne modtage tekstbehandlingsdokumenter i begge formater, evt. ved brug af tilføjelsesprogrammer (plug-ins). Om ODF og /eller OOXML skal være obligatoriske efter 1. juli 2009 afgøres efter en vurdering af en uafhængig tredjepart. At en standard er åben indebærer, at: standarden skal være fuldstændigt dokumenteret og offentligt tilgængelig, standarden skal være frit implementérbar uden økonomiske, politiske eller juridiske begrænsninger på implementering og anvendelse, hverken nu eller i fremtiden, og standarden skal være standardiseret og vedligeholdt i et åbent forum via en åben proces (standardiseringsorganisation). Anvendelse af obligatoriske, åbne standarder Kravet om anvendelse af obligatoriske, åbne standarder gælder alene for nye it-løsninger. For anvendelsen af obligatoriske, åbne standarder gælder, at den enkelte myndighed ved eventuelle merudgifter eller andre uhensigtsmæssigheder, herunder i forhold til den pågældende myndigheds itsikkerhedsmæssige hensyn, kan undlade at anvende de obligatoriske standarder. På baggrund heraf kan der således ikke gøres økonomiske krav gældende over for staten fra kommuner og regioner vedrørende anvendelse af obligatoriske, åbne standarder for software. De nærmere retningslinier, herunder hvordan myndigheder kan undtages fra den ellers obligatoriske indførelse af en åben standard, fastsættes i de generelle vejledninger, der udarbejdes på baggrund af implementeringen af B103. Disse generelle vejledninger vil være til myndighedernes disposition inden denne aftale træder i kraft.

20 Bilagssamling Side 20 af 379 Efter Europa-Parlamentets og Rådets direktiv 98/34/EF af 22. juni 1998 om en informationsprocedure med hensyn til tekniske standarder og forskrifter, som ændret ved Europa- Parlamentets og Rådets direktiv 98/48/EF af 20. juli 1998, skal Kommissionen underrettes forinden aftalen træder i kraft. Aftalens tre parter erklærer sig enige i den beskrevne proces. Aftalen om anvendelse af åbne standarder for software i det offentlige understreger, at de tre myndighedsniveauer samarbejder om væsentlige digitaliseringsinitiativer.

21 Bilagssamling Side 21 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag E

22 Bilagssamling Side 22 af 379 Vedtagelse 45 fra forespørgsel F 24 den 25. april i Folketinget Folketinget opfordrer regeringen til at sikre, at den uafhængige 3. part, der nedsættes ved valg af dokumentformater, sammensættes, så den dækker forvaltningsmæssige, tekniske og konkurrencemæssige aspekter. Regeringen sikrer, at 3. parten undersøger softwareleverandørernes evne til at sikre interoperabilitet og praktiske erfaringer med at implementere standarderne uafhængigt af platform, herunder spørgsmålet om dokumentformaternes konkurrencemæssige neutralitet, ved at analysere: 1. Om der i de to dokumentformater er tekniske bindinger, eksempelvis begrænsninger i muligheden for implementering på flere platforme. 2. Om der knyttet til de to dokumentformater findes juridiske barrierer, der hindrer implementering af formaterne i flere leverandørers it-løsninger. Regeringen bedes undersøge de konkurrencemæssige konsekvenser ved manglende interoperabilitet og vurdere konkurrencen inden for kontorsoftware baseret på ODF og/eller OOXML, herunder tekniske og juridiske bindinger knyttet til kontorsoftware, samt foreslå, hvordan konkurrencen i givet fald øges inden for rammerne af B 103 fra Folketinget tilkendegiver, at konkurrencemyndighederne bør inddrages i denne proces.

23 Bilagssamling Side 23 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag F

24 Bilagssamling Side 24 af 379

25 Bilagssamling Side 25 af 379 > Vejledning om anvendelse af obligatoriske, åbne standarder for software i det offentlige Udgivet af: Videnskabsministeriet Ministeriet for Videnskab, Teknologi og Udvikling Bredgade København K Telefon: Fax: Publikationen udleveres gratis Så længe lager haves, ved henvendelse til: IT- og Telestyrelsen. Publikationen kan også hentes på Videnskabsministeriets Hjemmeside: ISBN (internet): Tryk: Oplag: ISBN:

26 Bilagssamling Side 26 af 379 > Vejledning om anvendelse af obligatoriske, åbne standarder for software i det offentlige Ministeriet for Videnskab, Teknologi og Udvikling Oktober 2007

27 Bilagssamling Side 27 af 379 Indhold > Obligatoriske, åbne standarder 6 Regeringsbeslutning og aftale om anvendelse af åbne standarder for software i det offentlige 6 Obligatoriske, åbne standarder 7 Anvendelse af obligatoriske, åbne standarder 8 Anvendelse af obligatoriske, åbne standarder 9 Hvilke standarder er relevante? 10 Egenudvikling 10 Indkøb og udbud 10 Begrundelse for anvendelse af undtagelsesbestemmelser 11 Offentliggørelse af anvendelse af undtagelsesbestemmelserne 12 Sæt af obligatoriske, åbne standarder 13 Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) 14 Hovedprincip for OIOXML 14 Primære virkefelt for OIOXML 14 Obligatoriske, åbne OIOXML standarder 14 Anvendelseskrav for OIOXML 14 Standarder til elektronisk sags- og dokumenthåndtering (FESD) 16 Hovedprincip for FESD standarder 16 Primære virkefelt for FESD standardne 16 Obligatoriske, åbne FESD standarder 16 Krav om anvendelse af FESD standarderne 16 Vedligeholdelse af kravet om anvendelse af FESD standarder 17 Standarder til elektroniske indkøb i det offentlige (OIOUBL) 18 Hovedprincip for elektroniske indkøb 18 Primære virkefelt for OIOUBL 18 Obligatoriske, åbne OIOUBL standarder 18 Anvendelseskrav for OIOUBL 19 Standarder for digital signatur 20 Hovedprincip for OCES digital signatur 20 Primære virkefelt for OCES digital signatur 20 Obligatoriske, åbne OCES standarder 20 Anvendelseskrav for OCES digital signatur 21 Vedligeholdelse af kravet om anvendelse af OCES digital signatur 21 Standarder for offentlige netsteder og tilgængelighed 22 Hovedprincip for offentlige netsteder 22

28 Bilagssamling Side 28 af 379 Primære virkefelt for standarder for offentlige netsteder 22 Obligatoriske, åbne standarder for offentlige netsteder 22 Anvendelseskrav standarder for offentlige netsteder 22 Standarder for it-sikkerhed (DS484) 23 Hovedprincip for informationssikkerhed 23 Primære virkefelt for DS Kun gældende for staten 23 Obligatoriske, åbne standarder for informationssikkerhed 23 Anvendelseskrav for DS Standarder for dokumentudveksling (ODF/OOXML) 25 Hovedprincip for dokumentstandarder 25 Primære virkefelt for dokumentstandarder 25 Obligatoriske, åbne dokumentstandarder 25 Vedligeholdelse af kravet om dokumentstandarder 25 OIO-kataloget 27 International forankring af OIO-kataloget 27 Justeringer af OIO-kataloget 27 OIO-katalogets struktur 28 Nye obligatoriske, åbne standarder 29

29 Bilagssamling Side 29 af 379 Obligatoriske, åbne standarder > Den 1. januar 2008 vil en række åbne standarder blive obligatoriske at anvende for offentlige myndigheder ved fremtidige indkøb af software og it-løsninger. For offentlige myndigheder betyder det, at man skal sikre sig, at fremtidige itløsninger er baseret på, eller understøtter, disse obligatoriske, åbne standarder, hvis standarderne er relevante for it-løsningen. For alle de obligatoriske, åbne standarder gælder, at den enkelte myndighed ved eventuelle merudgifter eller for den pågældende myndighed it-sikkerhedsmæssige hensyn kan undlade at anvende de obligatoriske standarder Anvendelse af obligatoriske, åbne standarder medfører ikke et forbud mod anvendelse af andre standarder end de obligatoriske, åbne standarder. It-løsninger må således gerne kunne anvende andre standarder end de obligatoriske, åbne standarder, så længe løsningerne også understøtter anvendelsen af de relevante obligatoriske, åbne standarder. Der er ingen krav om at anvende bestemte typer eller fabrikater af software, og der er ingen krav om, at de pågældende formater anvendes som det interne format i software. Ved offentlige myndigheder forstås kommunale og regionale forvaltninger, statslige departementer, styrelser og direktorater. Ved obligatoriske, åbne standarder forstås udvalgte og navngivne standarder, som er vurderet hensigtsmæssige for anvendelse i den offentlige sektor. Denne vejledning baserer sig på nedenstående aftale, der er indgået mellem regeringen, KL og Danske Regioner Regeringsbeslutning og aftale om anvendelse af åbne standarder for software i det offentlige Den 2. juni 2006 vedtog et enigt Folketing folketingsbeslutning B 103 om anvendelse af åbne standarder for software i det offentlige. Folketingsbeslutningen pålægger regeringen at sikre, at det offentliges brug af informationsteknologi, herunder brug af software, er baseret på åbne standarder. Et flertal af partierne har lagt til grund, at anvendelsen af åbne, obligatoriske standarder ikke må medføre øgede udgifter for det offentlige. 11. august 2006 offentliggjordes rapporten Virkemidler til fremme af interoperabilitet gennem fælles, åbne standarder. Bag rapporten stod Videnskabsministeriet, Finansministeriet, KL og Danske Regioner. Rapporten lagde en fællesoffentlig basis for hvordan anvendelsen af obligatoriske, åbne standarder kunne gennemføres. Herunder at anvendelsen blev gennemført ved en regeringsbeslutning og en aftale med de kommunale parter. I februar 2007 sendte IT- og Telestyrelsen rapporten Anvendelse af åbne standarder for software i det offentlige i høring. Denne rapport anbefaler, at syv softwarestandarder gøres obligatoriske pr. 1. januar

30 Bilagssamling Side 30 af 379 > Høringssvarene var overvejende positive, og videnskabsministeren opnåede efterfølgende en politisk enighed om en køreplan for implementering af anvendelse af obligatoriske, åbne standarder for software i det offentlige. Obligatoriske, åbne standarder Indførelsen af åbne standarder skal, uden at det medfører øgede udgifter for det offentlige, fremme et konkurrencepræget marked for software og medvirke til, at offentlige it-systemer uanset valg af software kan udveksle informationer på tværs. For hvert potentielt set obligatoriske sæt af åbne standarder gennemføres en økonomisk konsekvensvurdering. Vurderingen sikrer, at indførelsen af den enkelte standard er samfundsøkonomisk hensigtsmæssig. At en standard er åben indebærer, at: standarden skal være fuldstændigt dokumenteret og offentligt tilgængelig, standarden skal være frit implementérbar uden økonomiske, politiske eller juridiske begrænsninger på implementering og anvendelse, hverken nu eller i fremtiden, og standarden skal være standardiseret og vedligeholdt i et åbent forum via en åben proces (standardiseringsorganisation). De første syv sæt af obligatoriske, åbne standarder træder i kraft fra den 1. januar Det drejer det sig om følgende sæt af standarder: Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) Standarder til elektronisk sags- og dokumenthåndtering (FESD) Standarder til elektroniske indkøb i det offentlige (OIOUBL) Standarder for digital signatur (OCES) Standarder for offentlige netsteder / hjemmesider og tilgængelighed Standarder for it-sikkerhed (DS484 - kun for staten) Standarder for dokumentudveksling (ODF/OOXML) Vedrørende standarder for dokumentudveksling eksisterer der i dag to åbne væsentlige standarder for disse formater på markedet: ODF og OOXML. Begge standarder er dog stadig relativt umodne, og der mangler konkrete erfaringer med deres anvendelse i praksis. Derfor er de økonomiske konsekvenser ved at indføre dem vanskelige at estimere og baseret på et stort skønselement. Samme erkendelse er man ligeledes nået frem til i andre europæiske lande, der står over for lignende beslutninger. Derfor igangsættes følgende implementering: Den 1. januar 2008 skal alle offentlige myndigheder kunne modtage tekstbehandlingsdokumenter fra borgere, virksomheder og andre myndigheder i to formater: OOXML og ODF. Pr. 1. januar 2008 bliver OOXML og ODF obligatoriske standarder for offentlige myndigheder. Løsninger, der indkøbes efter 1. januar 2008, skal understøtte mindst en af disse åbne standarder og kunne modtage tekstbehandlingsdokumenter i begge formater, evt. ved brug af tilføjelsesprogrammer (plug-ins). 7

31 Bilagssamling Side 31 af 379 > Om ODF og /eller OOXML skal være obligatoriske efter 1. juli 2009 afgøres efter en vurdering af en uafhængig tredjepart. Anvendelse af obligatoriske, åbne standarder Kravet om anvendelse af obligatoriske, åbne standarder gælder alene for nye itløsninger. For anvendelsen af obligatoriske, åbne standarder gælder, at den enkelte myndighed ved eventuelle merudgifter eller andre uhensigtsmæssigheder, herunder i forhold til den pågældende myndigheds it-sikkerhedsmæssige hensyn, kan undlade at anvende de obligatoriske standarder. De nærmere retningslinjer, herunder hvordan en undladelse kan begrundes, fastsættes i de generelle vejledninger, der udarbejdes på baggrund af implementeringen af obligatoriske, åbne standarder. 8

32 Bilagssamling Side 32 af 379 Anvendelse af obligatoriske, åbne standarder > Det er i anvendelsen af standarder, at deres værdi realiseres. Det er samtidigt vigtigt at undgå, at den enkelte myndighed tvinges til at foretage uhensigtsmæssige valg og fremskynde indkøb og udvikling i forhold til det administrative behov, eller at de afstår fra at etablere en it-løsning, fordi det bliver for dyrt eller besværligt. Af denne grund fastsættes en række undtagelsesbestemmelser for kravet om anvendelse af obligatoriske, åbne standarder. Fra 1. januar 2008 forudsættes det, at al offentlig nyudvikling udarbejdes med obligatoriske, åbne standarder som en del af grundlaget. Det vil sige, at myndigheder, der gennemfører udbud og udviklingsprojekter inden for de områder, hvor der er defineret obligatoriske åbne standarder, inddrager disse som en del af grundlaget for projektet. Ved nye løsninger forstås nyindkøb og nyudvikling, samt videreudvikling og opgradering af software, med mindre dette foregår som en del af en allerede indgået aftale. Myndigheder kan i forbindelse med udbud og udviklingsprojekter undtage sig selv fra reglerne om at anvende obligatoriske, åbne standarder, hvis myndigheden dermed tvinges til en løsning, der enten: > er væsentligt fordyrende i forhold til anvendelse af andre standarder, > svækker sikkerhedsniveauet væsentligt i forhold til anvendelse af andre standarder, > medfører væsentlig funktionel forringelse, der er direkte forårsaget af, at den er baseret på de obligatoriske, åbne standarder, > øger implementeringstiden markant, > medfører konflikt med standarder, der på grund af internationale forpligtelser er gældende inden for enkeltområder. Såfremt et eller flere af ovenstående punkter gør sig gældende, kan den givne myndighed vælge at fravige konkrete obligatoriske, åbne standarder i den givne løsning. Vurderes det, at kravet skal fraviges, giver det anledning til en såkaldt forklaring. Med dette skal forstås, at der skal udarbejdes en forklaring fra den givne myndighed, der redegør nærmere for de omstændigheder, der i situationen ligger bag en fravigelse af kravet om overholdelse af det obligatoriske sæt af åbne standarder. Krav og forudsætninger for fravigelse herfra udgør tilsammen en følg eller forklarmodel. 9

33 Bilagssamling Side 33 af 379 > Hvilke standarder er relevante? Den enkelte myndighed bør indlede vurderingen af spørgsmålet om anvendelse af obligatoriske standarder i forbindelse med foranalysefasen i et givent it-projekt. Vurderingen består i en identifikation af, hvilke af de obligatoriske, åbne standarder, der har relevans inden for det område, som systemløsningen dækker. Egenudvikling Hvor myndigheden besidder størstedelen af projektledelseskompetencen, bør vurderingen af eventuelle negative konsekvenser ved anvendelse af obligatoriske, åbne standarder være gennemført inden projektets igangsættelse endeligt godkendes. Indkøb og udbud Ved indkøb med eller uden et udbud, bør vurderingen indgå i eller som bilag til kravspecifikationen, idet den offentlige myndighed samtidig adresserer en entydig forventning om, at leverandørens løsningsbeskrivelse tager afsæt i et sæt obligatoriske åbne standarder, såfremt disse er relevante at anvende inden for det givne løsningsområde. I forbindelse med opstilling af disse krav om anvendelse af standarder skal leverandøren gøres opmærksom på baggrunden herfor, det vil sige de hovedprincipper, der ligger bag følg eller forklar. Leverandøren bør tilsvarende informeres om, hvilke standarder der på et givent tidspunkt er obligatoriske. Endelig skal leverandøren gøres opmærksom på, at kravet kan afviges på baggrund af de opstillede undtagelsesbestemmelser. Såfremt en eller flere af årsagerne til fravigelse gør sig gældende, og leverandøren vurderer, at det bør have indflydelse på løsningsbeskrivelsen, skal der udarbejdes en nærmere begrundelse herfor. Myndigheden præsenteres således for en løsningsbeskrivelse fra leverandøren, der forholder sig til, hvorvidt åbne obligatoriske standarder er relevante at anvende i den givne kontekst, og om disse i så fald kan overholdes eller falder ind under undtagelsesbestemmelserne. I tilfælde af, at den obligatoriske standard anvendes, angives dette af leverandøren. I tilfælde af, at der undtages fra anvendelsen, vil de nærmere omstændigheder og dokumentationen herfor skulle angives. Hvordan ordregivende myndigheder inddrager obligatoriske, åbne standarder i sit udbudsmateriale For at sikre at ordregivende myndigheder inddrager obligatoriske, åbne standarder ved køb af it-løsninger foreslås det, at udbudsmaterialer udformes på følgende måde: 1. Giv mulighed for, at tilbudsgiver kan afgive alternative tilbud, hvis tilbudsgiver vurderer, at det ikke er hensigtsmæssigt for ordregivende myndighed at basere sig på de obligatoriske, åbne standarder i den konkrete sammenhæng. Hermed gives tilbudsgiverne mulighed for at afgive to typer tilbud: o et tilbud der baseres på/understøtter obligatoriske, åbne standarder o et tilbud der ikke baseres på/understøtter obligatoriske, åbne standarder. 2. Muligheden for at afgive alternative tilbud skal være angivet i 10

34 Bilagssamling Side 34 af 379 > udbudsbekendtgørelsen. Det er et krav at tildelingen af kontrakten sker på grundlag af tildelingskriteriet det økonomisk mest fordelagtige tilbud. 3. Opstil krav til it-løsningen i udbudsgrundlaget. 4. Angiv hvilke hvilke af disse krav der er minimumskrav d.v.s. krav som alle tilbud skal opfylde for at være konditionsmæssige. Disse minimumskrav kan vedrøre sikkerhed, tidsrammer og funktionalitet. Også internationale forpligtelser som it-løsningen skal overholde angives som minimumskrav Når den ordregivende myndighed modtager tilbud, kan myndigheden vælge det økonomisk mest fordelagtige tilbud blandt både de tilbud der opfylder alle krav i udbudsgrundlaget eller de tilbud der har kommet med alternative løsningsforslag. I dette valg indgår også en vurdering af, eventuelle negative konsekvenser der kan følge af at vælge en it-løsning, der baseres på/understøtter obligatoriske, åbne standarder. Disse negative konsekvenser gennemgås nærmere nedenfor. Begrundelse for anvendelse af undtagelsesbestemmelser Der er opstillet en række kriterier for, hvornår en myndighed kan undtages fra reglerne om at anvende obligatoriske åbne standarder på et konkret område. I disse tilfælde skal der foretages en uddybende begrundelse for behovet for denne undtagelse. Uanset om redegørelsen udarbejdes af den offentlige myndighed, af den private leverandør eller hvis det sker i fællesskab, bør begrundelsen så vidt muligt indeholde følgende oplysninger. Øgede udviklingsomkostninger: > Skønnede meromkostninger, både absolut i forhold til den samlede anskaffelsessum. > Der angives eventuelle negative konsekvenser for anden myndighed ved, at løsning ikke anvender obligatoriske standarder. Svækket sikkerhedsniveau: > Det angives, hvorfor det vurderes, at sikkerhedsniveauet svækkes væsentligt. Funktionel forringelse: > Det begrundes, hvorfor der forventes en funktionel forringelse som følge af anvendelse af obligatoriske åbne standarder, herunder hvorvidt det skyldes et eller flere af følgende forhold: - Manglende mulighed for integration - Konflikt med andre allerede anvendte standarder, der ikke kan fraviges 11

35 Bilagssamling Side 35 af 379 > Væsentlig forsinkelse: > Vurdering af hvor meget projektet forsinkes, og evt. hvilke afledte konsekvenser det giver. Konflikt med sektorfastsatte standarder: > Hvis undtagelsen begrundes med henvisning til konflikt med standarder, der på grund af internationale forpligtelser er gældende inden for enkeltområder, vedlægges henvisning til sektorbeslutning. Offentliggørelse af anvendelse af undtagelsesbestemmelserne Ved nye løsninger, hvor den tekniske anskaffelse har samlede omkostninger, der overstiger EU s udbudsgrænse, skal de udarbejdede begrundelser for anvendelse af undtagelsesbestemmelserne offentliggøres. Dette kan ske ved at myndigheden sender begrundelserne til IT- og Telestyrelsen i forbindelse med underskrivelse af kontrakten, hvorefter IT- og Telestyrelsen vil sørge for offentliggørelse, at offentliggøre begrundelserne på myndighedens egen hjemmeside eller at offentliggøre begrundelserne i forbindelse med regnskabsaflæggelse. Nye løsninger, hvis samlede omkostninger ligger under denne grænse, skal ligeledes anvende obligatoriske åbne standarder, medmindre de falder ind under undtagelsesbestemmelserne. Disse løsninger er dog ikke underlagt kravet om offentliggørelse af eventuelle undtagelsesbestemmelser. Dog opfordres myndighederne også at offentliggøre disse Krav om offentliggørelse bringes ikke i anvendelse for systemer, der er omfattet af Statsministeriets sikkerhedscirkulære. 12

36 Bilagssamling Side 36 af 379 Sæt af obligatoriske, åbne standarder > Det er først, når en standard anvendes, og ofte når den anvendes i tilknytning til andre standarder, at dens potentielle værdi i forhold til at sikre interoperabilitet for alvor kan realiseres. Standarder skal derfor betragtes i en anvendelseskontekst. En anvendelseskontekst kan for eksempel være dataudveksling mellem systemer, tværgående brugerstyring eller borgeres adgang til offentlig information via internettet. For hver af sådanne anvendelseskontekster vil der typisk være mere end én relevant standard. Man kan derfor tale om, at der vil være et sæt af standarder knyttet til hver kontekst. Videnskabsministeren og Folketingets it-ordførere er blevet enige om en køreplan for anvendelsen af obligatoriske åbne standarder, hvor syv sæt af standarder bliver obligatoriske fra 1. januar 2008 De syv sæt af standarder er: > Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) > Standarder til elektronisk sags- og dokumenthåndtering (FESD) > Standarder til elektroniske indkøb i det offentlige (OIOUBL) > Standarder for digital signatur (OCES) > Standarder for offentlige netsteder / hjemmesider og tilgængelighed (HTML/XHTML, CSS og WCAG) > Standarder for it-sikkerhed (DS-484) > Standarder for dokumentudveksling (ODF/OOXML) De følgende sider beskriver hvert enkelt sæt af standarder nærmere. 13

37 Bilagssamling Side 37 af 379 Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) > En forudsætning for en effektiv digital forvaltning er, at dataudveksling mellem systemer foregår så korrekt og gnidningsfrit som muligt - eller med andre ord, at interoperabilitet mellem systemer er mulig. For at interoperabilitet er muligt, er det nødvendigt at standardisere; og i Danmark er der i det offentlige siden 2001 arbejdet målrettet på en sådan standardisering. Med et fælles sæt af standarder til dataudveksling mellem myndighedernes it-systemer kan den offentlige sektor udvikle it-systemer, hvor informationer er defineret ensartet og kan genbruges på tværs af it-systemerne, så it-systemerne kan anvendes til at skabe sammenhængende services til borgere, virksomheder og andre myndigheder på tværs af forvaltninger og myndigheder. Hovedprincip for OIOXML OIOXML er et sprog, der danner grundlaget for at skabe sammenhængende dataudveksling mellem myndighedernes it-systemer, idet OIOXML sikrer, at information udveksles på en ensartet og forståelig måde. OIOXML er helt konkret en fællesbetegnelse for hele sættet af alle OIOdatastandarder, som samlet udgør det fællesoffentlige udvekslingssprog i XMLformat. Primære virkefelt for OIOXML Det primære virkefelt for OIOXML er udveksling af information mellem alle offentlige it-systemer udviklet af myndigheder, som er dækket af aftalen om anvendelse af åbne standarder for software i det offentlige. Obligatoriske, åbne OIOXML standarder De obligatoriske, åbne standarder er: OIO-datastandarder enten adopteret fra internationale bidrag eller udviklet i henhold til den til enhver tid gældende version af det fællesoffentlige regelsæt OIO-NDR (= OIO Navngivnings- og Design Regler). XML Schema 1.0 vedligeholdt af W3C ( OIO- NDR en er en profil (en nedskåren version) af XML Schema 1.0 anbefalingen, hvor bl.a. (for OIOXML) uhensigtsmæssige konstruktioner er fjernet. Extensible Markup Language (XML) 1.0 (Third Edition) vedligeholdt af W3C ( Anvendelseskrav for OIOXML At anvende OIOXML vil sige, at al dataudveksling følger specifikationer i eksisterende OIO-datastandarder, herunder at der så vidt muligt (jf. principperne om følg eller forklar) udvikles nye OIO-datastandarder til at tilfredsstille eventuelle udækkede behov. Retningslinierne for anvendelse og udvikling er, som følger: for information, som allerede er udtrykt i OIOXML, genbruges eksisterende OIO-datastandarder på den af OIO foreskrevne måde i relevante OIOretningslinier. for information, som endnu ikke er dækket af OIOXML, tilføjes nye OIOdatastandarder efter følgende prioriterede trin: 1. eksisterer der internationale datastandarder, som dækker det relevante udvekslingsbehov, adopteres disse som OIO-datastandarder, som 14

38 Bilagssamling Side 38 af 379 > angivet i relevante OIO-retningslinier (evt. etableres nationale versioner af disse). 2. kun hvor ingen internationale bidrag findes, udvikles nye nationale OIO-datastandarder på den af OIO foreskrevne måde i OIO-NDR en og andre relevante OIO-retningslinier. for nye og bedre versioner af eksisterende OIO-datastandarder, gælder princippet igen, at internationale bidrag til de nye versioner skal prioriteres over nationale. 15

39 Bilagssamling Side 39 af 379 Standarder til elektronisk sags- og dokumenthåndtering (FESD) > Den offentlige sektors it-systemer på statsligt, kommunalt og regionalt niveau skal kunne spille sikkert og effektivt sammen. Til dækning af det behov, er der udarbejdet fælles standarder for elektronisk sags- og dokumenthåndtering - de såkaldte FESDstandarder. Målet med dette standardiseringsarbejde er at fremme digital forvaltning i den offentlige sektor, og midlet er at sikre, at de forskellige elektroniske sags- og dokumenthåndteringssystemer (ESDH) får en fælles kerne, og at det samtidig sikres, at denne kerne videreudvikles ensartet. En fælles kerne skal sikre at: at der kan foretages sagsbehandling på tværs af flere organisationer at myndigheder, der arbejder med åbne sager, kan lægges sammen at der kan flyttes opgaver mellem forskellige myndigheder Hovedprincip for FESD standarder ESDH systemer (Elektronisk Sags- og Dokumenthåndtering) i det offentlige skal baseres på en række standarder med henblik på så vidt muligt at sikre interoperabilitet mellem forskellige ESDH systemer samt mellem ESDH systemer og andre systemer (fagsystemer). Den overordnede hensigt er således, at alt så vidt muligt hænger sammen på ESDH-området med henblik på højere kvalitet og bedre effektivitet i sagsbehandlingen. Primære virkefelt for FESD standardne Det primære virkefelt for obligatoriske, åbne standarder på ESDH området, er ESDHsystemer, som anskaffes i det offentlige. Obligatoriske, åbne FESD standarder De obligatoriske, åbne standarder er: FESD Sager og dokumenter FESD Adressemodel FESD Udvekslingspakke FESD Skanningsmodul FESD LIS (Ledelsesinformation) FESD indeholder yderligere syv standarder, der endnu ikke kan gøres obligatoriske, da de endnu ikke er færdigbehandlet. Disse er: FESD Udvalgsbehandling FESD Brugeradministration FESD Arkivstruktur FESD Emnesystematik FESD Sikker epostløsning FESD Generisk Integrationsmodel FESD GIS-Integrationsmodel Krav om anvendelse af FESD standarderne At anvende de obligatoriske, åbne standarder for offentlige hjemmesider vil sige, at man Implementerer FESD standarderne på den i standarderne foreskrevne måde. 16

40 Bilagssamling Side 40 af 379 > Vedligeholdelse af kravet om anvendelse af FESD standarder OIO-kataloget beskriver løbende hvilke FESD standarder og versioner af disse, der er gældende. Alle FESD-standarder gennemløber en proces, hvor offentlig høring er et centralt element. Igangsættelse af den enkelte standard sker efter beslutning i den fælles offentlige FESD styregruppe. Det enkelte forslag til standard udarbejdes herefter i fællesskab af de såkaldte FESD-leverandører, hvorefter dette forslag til standard er i offentlig høring i én måned. Efter tilretning på baggrund af den offentlige høring, forelægges forslaget til standard til godkendelse. 17

41 Bilagssamling Side 41 af 379 Standarder til elektroniske indkøb i det offentlige (OIOUBL) > Det er målet, at handel mellem den offentlige og private sektor i 2012 skal være fuldt gennemført ved brug af it og åbne standarder. Til indfrielse af det mål, er standarden OIOUBL udviklet. Udviklingen er sket med følgende tre forretningsmæssige krav for øje: Små og store virksomheder og offentlige myndigheder skal med færrest mulige teknologiske, administrative og økonomiske barrierer kunne håndtere de basale elektroniske handelsdokumenter i standarden. Handelsdokumenterne skal udvælges med henblik på at være netop det nødvendige og tilstrækkelige sæt af meddelelser, som understøtter den basale indkøbsproces i den offentlige og private sektor. Den danske standard skal basere sig på åbne internationale standarder, således at handel over grænser er mulig. Hovedprincip for elektroniske indkøb E-handelsdokumenter i den offentlige sektor bør baseres på en række standarder, med henblik på at sikre en nem udveksling af dokumenter mellem den offentlige og den private sektor. Derved sikres, at alle leverandører til den offentlige sektor på forhånd ved hvilket format, de skal understøtte og kan nøjes med at understøtte et frem for mange forskellige formater i deres it-systemer. De offentlige myndigheder får til gengæld mere ensartede og strukturerede data, som giver mulighed for yderligere effektivisering af arbejdsgange og bedre indkøbsstatistikker. Primære virkefelt for OIOUBL Det primære virkefelt for obligatoriske, åbne standarder for elektroniske indkøb, er alle offentlige økonomi- og indkøbssystemer anskaffet af myndigheder, som er dækket af aftalen om anvendelse af åbne standarder for software i det offentlige. Obligatoriske, åbne OIOUBL standarder De obligatoriske, åbne standarder er: OIOUBL version 2.01 vedligeholdt af IT- og Telestyrelsen. UN/SPSC version vedligeholdt af GS1. OIOUBL er en dansk tilpasning af den internationale standard UBL 2.0 fra standardiseringsorganet OASIS (Organization for the Advancement of Structured Information Standards) til danske forretningskrav. OIOUBL indeholder standarder for alle væsentlige forretningsdokumenter til understøttelse af handelsprocessen fra katalog til faktura. De dokumenter, der er medtaget i OIOUBL, og som udgør en delmængde af UBL 2.0 dokumenterne, er udvalgt i samråd med Sektorstandardiseringsudvalget for e-handel. UN/SPSC UNSPSC (United Nations Standard Product and Services Code) er et internationalt klassifikationssystem for varer og tjenester. Det bruges til at skabe overblik over virksomheders forbrug og foretage systematiske søgninger i forbindelse med elektronisk varekataloger. Det er UNDP (United Nations Development Programme), som ejer rettighederne til UN/SPSC klassifikationssystemet. Systemet administreres i det daglige af GS1 US. GS1 Denmark administrerer i samarbejde med IT- og Telestyrelsen den danske oversættelse af UN/SPSC

42 Bilagssamling Side 42 af 379 > Anvendelseskrav for OIOUBL At anvende de obligatoriske, åbne standarder for elektronisk ordreafgivelse vil sige, at man efterlever OIOUBL specifikationerne som beskrevet i IT- og Telestyrelsens vejledninger på (dansk version) og (engelsk version) efterlever UN/SPSC klassifikationerne som beskrevet af GS1 på 19

43 Bilagssamling Side 43 af 379 Standarder for digital signatur > Med den digitale signatur har den offentlige sektor etableret en solid infrastruktur for sikker elektronisk identifikation og kommunikation, der er fundamentet for den digitale forvaltning og for etablering af en ny generation af serviceorienterede offentlige og private internettjenester. Den offentlige sektor vil via etablering af e-services og brug af digital signatur kunne forbedre servicen til borgere og virksomheder samtidig med, at effektiviteten i administrationen øges. OCES standarden for digital signatur er udviklet for at nedbryde en række barrierer identificeret, efter et tidligere forsøg i 2001 på at stimulere markedet til øget anvendelse af digitale signaturer baseret på kvalificerede signaturer jf. EU-direktiv 1999/93 om en fællesskabsramme for elektroniske signaturer.. Det viste sig i 2001, at markedets forretningsmodeller ikke fungerede, især fordi man som borger selv skulle betale for sin digitale signatur. Hertil kom manglende standardisering og ringe interoperabilitet på tværs af markedets tilbud. Hovedprincip for OCES digital signatur Offentlige myndigheder skal som udgangspunkt basere sin digitale forvaltning på anvendelsen af OCES digital signatur i forbindelse med implementering af sikker e- mail og selvbetjeningsløsninger der kræver identifikation og autenticitet. OCES standarden er fastlagt i OCES certifikatpolitikker, som administreres og reguleres af IT- og Telestyrelsen. Certfikatpolitikkerne, der har været sendt i offentlig høring, definerer således et standardiseret og offentligt kontrolleret sikkerhedsniveau for udstedelse og anvendelse af den digitale signatur. Primære virkefelt for OCES digital signatur Det primære anvendelsesområde for OCES digital signatur, er kommunikationen mellem borgere, virksomheder og den offentlige sektor, særligt i forbindelse med implementering af sikre - og selvbetjeningsløsninger. Obligatoriske, åbne OCES standarder De obligatoriske, åbne standarder er: OCES-personcertifikatpolitik. OCES-medarbejdercertifikatpolitik. OCES-virksomhedscertifikatpolitik. OCES-funktionscertifikatpolitik. OCES-certifikatpolitikkerne er baseret på nedennævnte internationale standarder, men er tilrettet i forhold til lovmæssige og forvaltningsmæssige krav i den danske digitale forvaltning. CEN Workshop Agreement :2002: Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures part 2: Cryptographic Module for CSP Signing Operations Protection Profile (MCSO-PP) ETSI TS v ( ): Electronic signatures and infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates 20

44 Bilagssamling Side 44 af 379 > ETSI SR v ( ): Algorithms and Parameters for Secure Electronic Signatures FIPS PUB 140-1: Security Requirements for Cryptographic Modules ISO/IEC (del 1 til 3): Information technology - Security techniques - Evaluation criteria for IT security" ISO/IEC /ITU-T Recommendation X.509: Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks Anvendelseskrav for OCES digital signatur At anvende den obligatoriske, OCES standard for digital signatur vil sige, at man Implementerer sikre løsninger med anvendelse af OCES digital signatur. Implementerer selvbetjeningsløsninger, der anvender OCES digital signatur, hvor der er behov for autentifikation eller elektronisk signatur. Vedligeholdelse af kravet om anvendelse af OCES digital signatur De angivne OCES-certifikatpolitikker vedligeholdes og opdateres løbende af IT- og Telestyrelsen. Ved større revisioner gennemføres offentlig høring i forbindelse med revisionen. De til enhver tid gældende versioner af certifikatpolitikkerne er tilgængelige på 21

45 Bilagssamling Side 45 af 379 Standarder for offentlige netsteder og tilgængelighed > Principperne for forvaltningens digitale kommunikation med borgere og virksomheder bør følge almindelig forvaltningsskik om åbenhed, faglighed og saglighed i behandlingen af borgerne. Dette betyder, at forvaltningens digitale kommunikation med borgere og virksomheder for så vidt muligt skal sikre: at alle har lige adgang til at benytte digitale services, og at alle har lige adgang til at kommunikere digitalt med forvaltningen. God forvaltningsskik foreskriver, at regler og anbefalinger så vidt muligt skrives og udvikles teknologineutralt og produktneutralt. Tilsvarende bør den offentlige forvaltning basere sin borger- og virksomhedsvendte digitale forvaltning på kendte og tilgængelige datastandarder, der understøttes af en lang række producenter. Forvaltningen bør i sit teknologivalg søge at begrænse de tekniske udgifter og administrative byrder, som pålægges borgeren eller virksomheden, der ønsker at kommunikere digitalt med forvaltningen. Der skal ligeledes tænkes et særligt hensyn til tilgængelighed for blandt andre syns-, bevæge- og hørehæmmede borgere og medarbejdere. Derfor skal alle nye offentlige netsteder baseres på internationalt anerkendte åbne standarder. Hovedprincip for offentlige netsteder Offentlige hjemmesider baseres på en række standarder med henblik på at sikre, at de er tilgængelige for alle borgere og virksomheder. Ved at benytte de obligatoriske standarder sikres, at hjemmesiderne er så fremtidssikrede som muligt og kan bruges bredt på tværs af platforme og værktøjer. Ikke mindst sikres borgere med permament eller midlertidig funktionsnedsættelse digital adgang til det offentlige. Primære virkefelt for standarder for offentlige netsteder Det primære virkefelt for obligatoriske, åbne standarder for netsteder er alle offentlige hjemmesider udarbejdet af myndigheder, som er dækket af aftalen om anvendelse af åbne standarder for software i det offentlige. Obligatoriske, åbne standarder for offentlige netsteder De obligatoriske, åbne standarder er: HTML eller XHTML vedligeholdt af W3C (World Wide Web Consortium). CSS vedligeholdt af W3C. WCAG (Web Content Accessibility Guidelines), seneste version, level AA, vedligeholdt af WAI (Web Accessibility Initiative) under W3C. Anvendelseskrav standarder for offentlige netsteder At anvende de obligatoriske, åbne standarder for offentlige hjemmesider vil sige, at man Anvender den version af HTML, XHTML og CSS, man foretrækker på den af W3C foreskrevne måde. At man efterlever WCAG level AA. En praktisk vejledning til efterlevelse kan findes på 22

46 Bilagssamling Side 46 af 379 Standarder for it-sikkerhed (DS484) > For at styrke den generelle it-sikkerhed i staten skal alle statens institutioner følge en fælles statslig it-sikkerhedsstandard, med mindre særlige økonomiske eller juridiske forhold taler imod. Hovedprincip for informationssikkerhed Statslige myndigheder skal basere styringen af deres informationssikkerhed på DS484, Standard for informationssikkerhed. DS484 er en national standard, der tager sit udgangspunkt i den vejledende internationale standard ISO17799:2005 (ISO27002). DS484 indeholder en række basale og skærpede krav. Alle basale krav skal som minimum være etableret for at man kan påberåbe sig efterlevelse af standarden. DS484 er en metodestandard. Valg af konkrete udførelsesmåder og løsningsmodeller i forhold til standardens krav overlades i vidt omfang til den enkelte institution. Udgangspunktet for informationssikkerheden er risikobaseret tilgang hvor risici og løsningsmodeller afvejes. Det afgørende er, at ledelsen eksplicit tager stilling til en risikovurdering, som beskriver hvilken relevans og betydning de enkelte krav har for institutionen og institutionens samarbejdspartnere. Primære virkefelt for DS484 Det primære virkefelt for DS484 er hele organisationens informationsbehandling. Standardens organisatoriske fodspor er således ikke begrænset til it-afdelingen. Endvidere kan standarden, direkte eller indirekte, stille visse generiske krav til organisationens tekniske installationer og fysiske indretning. Kun gældende for staten Beslutningen er obligatorisk for alle institutioner, der er underlagt Bekendtgørelse om statens regnskabsvæsen mv. - i det følgende benævnt regnskabsbekendtgørelsen. Ifølge regnskabsbekendtgørelsens 2 omfatter dette alle: statsinstitutioner, dvs. departementer, underliggende institutioner, særlige fonde mv., samt selvejende institutioner, der er optaget på bevillingslovene på lige fod med de egentlige statsinstitutioner. Disse statslige institutioner er forpligtede til at følge den fælles standard for it-sikkerhedsprocesser. Selvejende institutioner, foreninger, fonde mv., hvis regnskaber omfattes af statsregnskabslovens 2, stk. 2 er ligeledes forpligtet til at følge den fælles standard for it-sikkerhedsprocesser i staten, såfremt de respektive ressortministerier har taget en sådan beslutning. De statslige aktieselskaber og selvstændige forvaltningssubjekter er som udgangspunkt ikke underlagt det statslige budget- og bevillingssystem og er dermed ikke omfattet af regeringsbeslutningen. Bemærk, at dette krav dækker flere statslige institutioner, end de i hovedaftalen beskrevne. Bemærk endvidere, at dette krav ikke dækker kommuner og regioner. Obligatoriske, åbne standarder for informationssikkerhed De obligatoriske, åbne standarder er: DS484:2005, vedligeholdt af Dansk Standard 23

47 Bilagssamling Side 47 af 379 > Anvendelseskrav for DS484 At anvende DS484 vil sige, at man Har forankret styringen af informationssikkerheden i topledelsen, bl.a. ved etablering af et formaliseret styringssystem et såkaldt Informations Security Management System (ISMS), f.eks. som beskrevet i ISO Har placeret et entydigt ansvar for informationssikkerhed hos ledelsen og, med udgangspunkt i en risikovurdering, formuleret og udmeldt retningslinier som mindst dækker de basale krav i DS484. Har omsat retningslinierne til konkrete løsninger og/eller forretningsgange, som efterleves og vedligeholdes løbende. Løbende følger op på udvalgte indikatorer for organisationens sikkerhedstilstand og herudfra genererer et passende niveau af ledelsesinformation. 24

48 Bilagssamling Side 48 af 379 Standarder for dokumentudveksling (ODF/OOXML) > Udveksling af tekstbehandlingsdokumenter mellem offentlige myndigheder foregår i dag oftest med formater, som er ejet af de respektive leverandører. Idet det i dag er muligt at basere udvekslingen af tekstbehandlingsdokumenter på åbne formater, bør det offentlige skifte til at udveksle tekstbehandlingsdokumenter ved brug af disse åbne formater. Dette giver mulighed for større konkurrence og mindre binding til enkeltleverandører. Hovedprincip for dokumentstandarder Offentlige myndigheder skal kunne modtage tekstbehandlingsdokumenter fra borgere, virksomheder og andre myndigheder i de åbne tekstbehandlingsdokumentformater OOXML og ODF. It-løsninger, der indkøbes efter 1. januar 2008, skal understøtte mindst en af de åbne tekstbehandlingsdokumentstandarder ODF og OOXML, og kunne modtage tekstbehandlingsdokumenter i begge formater, evt. ved brug af tilføjelsesprogrammer (convertere, plug-ins). Om ODF og /eller OOXML skal være obligatoriske efter 1. juli 2009 afgøres efter en vurdering af en uafhængig tredjepart. Primære virkefelt for dokumentstandarder De primære virkefelter er udveksling af redigerbare tekstbehandlingsdokumenter mellem offentlige myndigheder og modtagelse af redigerbare tekstbehandlingsdokumenter fra borgere, virksomheder og myndigheder. Obligatoriske, åbne dokumentstandarder De obligatoriske, åbne standarder er: ODF (Open Document Format) vedligeholdt af standardiseringsorganisationen OASIS. OOXML (Office Open-XML) vedligeholdt af ECMA. Anvendelseskrav for dokumentstandarder Fra den 1. januar 2008 skal alle myndigheder sikre, at de kan modtage dokumenter i de to formater. Ved anskaffelse af nye systemer efter 1. januar 2008 skal offentlige myndigheder sikre sig, at disse kan understøtte et eller begge de beskrevne formater. Vedligeholdelse af kravet om dokumentstandarder Om ODF og /eller OOXML skal være obligatoriske, åbne standarder efter 1. juli 2009 afgøres efter en vurdering af en uafhængig tredjepart. Som led i vurderingen indgår blandt andet: Softwareleverandørernes evne til at sikre interoperabilitet mellem de to standarder i deres produkter i forhold til det offentliges udvekslingsbehov (funktionalitetsloft). 25

49 Bilagssamling Side 49 af 379 > De reelle muligheder for og de praktiske erfaringer med at implementere standarderne uafhængigt af leverandør og platform. En konkret vurdering fra Konkurrencestyrelsen om effekten af anvendelse af obligatoriske åbne standarder for dokumentudveksling på konkurrencesituationen. 26

50 Bilagssamling Side 50 af 379 OIO-kataloget > OIO-kataloget er den fællesoffentlige ressource til brug ved planlægning og udvikling af offentlige it-projekter. OIO-kataloget indeholder beskrivelser og vurderinger af udvalgte standarder, teknologier og protokoller, som ønskes anvendt og understøttet i forbindelse med udbygningen af digital forvaltning i Danmark. OIO-kataloget bør være kendt af offentlige myndigheder, som udvikler it-strategier, - planer og -projekter, og af disses leverandører og rådgivere. Intentionen er at bidrage til at sikre bedre sammenhæng og teknisk konsistens ved anvendelse af etablerede teknologier i hele den danske offentlige sektor. International forankring af OIO-kataloget Standardisering giver ofte ikke mening i en snæver dansk sammenhæng. Dette skyldes dels, at der sker datasamspil over grænserne, dels at standardiseringen i praksis i mange tilfælde skal udføres af leverandører, som retter sig imod det internationale marked. Derfor skal standardiseringen i Danmark gennemføres i forlængelse af det internationale arbejde på området. I EU-regi kaldes OIO-kataloget en national interoperabilitetsramme for digital forvaltning (e-government Interoperability Framework). En national interoperabilitetsramme tilbyder et sæt politikker, tekniske standarder og retningslinjer (anbefalet praksis), som skitserer forvaltningens politik med hensyn til, hvordan interoperabilitet skal opnås. Den nationale interoperabilitetsramme er rettet mod alle myndigheder, som har behov for at interoperere med andre myndigheder og med deres øvrige omverden, herunder EU og andre medlemslande. Inden for rammerne af det Europæiske samarbejde om digital forvaltning er udarbejdet en særlig pan-europæisk interoperabilitetsramme (European Interoperability Framework, EIF), der skal ses som et supplement til de nationale rammer. OIO-kataloget er udarbejdet i overensstemmelse med EIF. Der er fortsat behov for kontinuerligt at foretage justeringer for at sikre overensstemmelse med EIF. Justeringer af OIO-kataloget OIO-kataloget har under flere navne eksisteret siden Udviklingen gennem de seneste fire år og kravene i forbindelse med obligatoriske åbne standarder bevirker naturligt nok, at det er nødvendigt at revidere strukturen og indholdet af kataloget med henblik på, at dette bliver tilrettet de nye krav. Indførelsen af obligatoriske åbne standarder i det offentlige tager sit udgangspunkt i det eksisterende fællesoffentlige standardiseringsarbejde. Kontinuitet er nøgleordet, og udgangspunktet for indførelsen af obligatoriske åbne standarder ligger i forlængelse af det standardiseringsarbejde, der allerede har foregået i flere år i det fællesoffentlige samarbejde forankret i IT- og Telestyrelsen. Målet I forbindelse med indførelsen af obligatoriske åbne standarder tilvejebringes af en bedre anvendelse og værdi af det fremadrettede arbejde med eksisterende standarder. Denne tilpasning viser sig klarest på tre punkter. 27

51 Bilagssamling Side 51 af 379 > 1 Rådgivning. IT- og Telestyrelsen har hidtil rådgivet om, hvilke standarder der blev anset som de bedste. Nu bliver visse standarder obligatoriske at anvende, med mindre væsentlige argumenter taler imod. Introduktion af følg eller forklar-begrebet fordrer, at offentlige myndigheder skal begrunde, hvis de ikke lever op til OIO-katalogets krav om obligatoriske standarder. 2 Dokumentation. Der er et klart behov for, at beslutningerne om hvilke kriterier, der ligger til grund for godkendelsen af standarder, i højere grad bliver dokumenteret. 3 Vedligeholdelse. Med et sæt af obligatoriske åbne standarder, skal der løbende være fokus på udviklingen vedr. standardiseringsområdet, den tekniske/markedsmæssige udvikling og den forretningsmæssige udvikling OIO-katalogets struktur OIO-kataloget inddeler standarder i tre overordnede kategorier. Tekniske standarder, datastandarder og metodestandarder. Karakteristik af de tre typer standarder Tekniske standarder Det er karakteristisk for tekniske standarder, at de har fokus på it-systemers tekniske virkemåde. Hovedformålet med fastsættelse af tekniske standarder er at sikre tekniske løsninger, der understøtter den samlede arkitektur og dermed fremmer hvidbogens fem hovedprincipper, som beskrevet i afsnit 3.3 Principper for itarkitektur. Datastandarder Det er karakteristisk for datastandarder, at de har fokus på de data, der registreres, anvendes og udveksles i forskellige systemer og organisationer. Formålet med datastandarder er at skabe grundlag for mere integrerede løsninger og for genbrug af data. Metodestandarder Det er karakteristisk for metodestandarder, at de har fokus på måden, hvorpå der arbejdes i digitaliseringsprojekter og i forbindelse med udvikling og drift af itløsninger. Det er også et særtræk, at der er relativt få metodestandarder. Formålet med metodestandarder er at skabe løsninger af kvalitet, sammenhæng, interoperabilitet og tillid. 28

52 Bilagssamling Side 52 af 379 Nye obligatoriske, åbne standarder > Obligatoriske, åbne standarder er udvalgte og navngivne standarder, som er vurderet hensigtsmæssige for anvendelse i den offentlige sektor. Fastsættelse af obligatoriske, åbne standarder sker efter indstilling fra videnskabsministeren og kræver beslutning i regeringen samt aftale med de de kommunale og regionale parter. Til grund for beslutningen skal foreligge en faglig og økonomisk vurdering af det enkelte sæt af standarder. Den faglige vurdering skal blandt andet belyse, om der er tale om en åben standard, hvilken forretningsmæssig relevans standarden har for den offentlige sektor og om markedsmæssige forhold gør standarden klar til anvendelse. Den faglige vurdering skal gøres til genstand for en offentlig høring. Hvis den faglige vurdering viser, at der er tale om en potentiel obligatorisk, åben standard, skal der efterfølgende laves en økonomisk konsekvensvurdering, der blandt andet skal afdække, om det er uden meromkostninger for det offentlige, at gøre standarden til en obligatorisk, åben standard. 29

53 Bilagssamling Side 53 af 379 > 30

54 Bilagssamling Side 54 af 379

55 Bilagssamling Side 55 af 379 < Vejledning om anvendelse af obligatoriske, åbne standarder for software i det offentlige Fra den 1. januar 2008 bliver en række åbne standarder obligatoriske at anvende for alle offentlige myndigheder. Det betyder, at alle nye offentlige it-løsninger skal kunne anvende disse obligatoriske, åbne standarder. Den 1. januar 2008 vil en række åbne standarder blive obligatoriske at anvende for offentlige myndigheder ved fremtidige indkøb af software og it-løsninger. For offentlige myndigheder betyder det, at man skal sikre sig, at fremtidige itløsninger er baseret på eller understøtter, disse obligatoriske, åbne standarder, hvis standarderne er relevante for it-løsningen. For alle de obligatoriske, åbne standarder gælder, at den enkelte myndighed ved eventuelle merudgifter eller for den pågældende myndighed it-sikkerhedsmæssige hensyn kan undlade at anvende de obligatoriske standarder.

56 Bilagssamling Side 56 af 379

57 Bilagssamling Side 57 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag G

58 Bilagssamling Side 58 af 379 SOGETI Testrapport v1.3 TESTRAPPORT fra LABORATORIETEST FOR IT- OG TELESTYRELSENS PILOTPROJEKT FOR ÅBNE DOKUMENTFORMATER I DET OFFENTLIGE Version november 2007 Udarbejdet af SOGETI for IT- og Telestyrelsen Side 1 af 19

59 Bilagssamling Side 59 af 379 SOGETI Testrapport v1.3 Indhold 1 Indledning Opsummering Gennemførelsen af laboratorietesten Første testrunde Dag Dag Dag Dag Research perioden Anden runde Dag Dag Dag Dag Planlægningsprocessen Testmiljø Testdokumentation Detaljeret dokumentation fra testgennemførelsen Første testrunde Anden testrunde Strukturen i undermapperne for findings og tests Sammenfattende dokumentation Leverancer Side 2 af 19

60 Bilagssamling Side 60 af 379 SOGETI Testrapport v1.3 Dokumenthistorik Dato Version Ændring Ændret af Nyt dokument Ove Nielsen Opdateret med resumé af dag 8 (testens sidste dag) Ove Nielsen Gennemgået, rettet op og suppleret med manglende beskrivelser Lars Christiansen Tine Borlund Ove Nielsen Manglende dokumentreferencer tilføjet Ove Nielsen Indsat opsummering fra sidste dag i lab ITST workshopdeltagere, Rettelser på basis af høringssvar. ITST/Jens Jakob Andersen Mindre korrekturændringer ITST/Jens Jakob Andersen Side 3 af 19

61 Bilagssamling Side 61 af 379 SOGETI Testrapport v1.3 1 Indledning Dette dokument er udarbejdet af SOGETI for IT- og Telestyrelsen som dokumentation af laboratorietesten i pilotprojektet med åbne dokumentformater. For en beskrivelse af baggrund, formål, scope mv. henvises til [1], Testplan for laboratorietest for IT- og Telestyrelsens pilotprojekt for åbne dokumentformater i det offentlige. For at tilvejebringe et solidt og veldokumenteret vejledningsgrundlag gennemførte IT- og Telestyrelsen sammen med en række centrale aktører en laboratorietest, som tog afsæt i resultaterne fra de allerede gennemførte pilotforsøg og paralleltest. Sidstnævnte blev gennemført på prioriterede observationer fra pilotforsøgene, for at belyse disse nærmere, men stadig i pilotens miljø. Brug af begreber Finding En finding er en konstateret afvigelse mellem originaldokument og resultatdokument efter konvertering, begge visualiseret ved hjælp af det valgte visualiseringsværktøj. Hypotese En hypotese er et sæt af faktorer, som tænkes at kunne påvirke om en afvigelse opstår, og som derfor er kandidat til at indgå i testen, jfr. kap. 6.3, Testdesign i [1], Testplan for laboratorietest for IT- og Telestyrelsens pilotprojekt for åbne dokumentformater i det offentlige. Konsistent Hvis alle gennemførte tests af en finding viser samme afvigelse, kaldes findingen konsistent. finding Scenarie Der blev til brug i pilot, defineret to scenarier: 1. Simpel konvertering 2. Samarbejde (korrektur, bemærkninger, vis ændringer) I laboratorietesten tages der udgangspunkt i findings fra pilot uafhængig af, hvilket scenarie de stammer fra. Dette betyder, at begrebet scenarie ikke vil blive benyttet i forbindelse med laboratorietesten. Visuel validering Visuel sammenligning af dokumenter, enten på skærm eller papir Refererede dokumenter [1] Testplan for laboratorietest for IT- og Telestyrelsens pilotprojekt for åbne dokumentformater i det offentlige (Testplan v doc) Dette dokument omtales i det følgende som Testplanen) [2] Faktisk gennemført fase 1 (Faktisk gennemførte tests i fase xls) [3] Faktisk gennemført fase 2 (Faktisk gennemførte tests i fase xls) [4] Oversigt over findings (Oversigt over findings v xls) [5] Specificeret plan for første runde (Specifiseret køreplan - fase xls) [6] Specificeret plan for anen runde (Specifiseret køreplan - fase xls) Alle de refererede dokumenter ligger i hovedmappen Complete LAB_TEST. Her ligger også testrapporten (dette dokument) Side 4 af 19

62 Bilagssamling Side 62 af 379 SOGETI Testrapport v1.3 2 Opsummering Planen for gennemførelsen af laboratorietesten er omtalt i kap. 6.4 i [1], Testplanen. Ifølge denne plan skulle der gennemføres to runder laboratorietest med en research periode imellem. De to testrunder blev gennemført i henholdsvis uge 41 ( oktober 2007) og uge 43 ( oktober 2007), med den mellemliggende tid som research periode. Laboratorietesten var en del af den stringente metode, som lå til grund for dokumentformatprojektets arbejde. Arbejdet blev ledet af ITog Telestyrelsen, bistået af Devoteam. Sogeti levererede en neutral testplatform. Forudsætninger for gennemførelse af laboratorietesten var: Neutral grund Apolitisk sigte Forum, hvor der kunne skabes konsensus omkring resultater Mulighed for åbenhed og fortrolighed De deltagende leverandører har blandt andet set laboratorietesten som en mulighed for at hjælpe deres kunder, men leverandørernes deltagelse i forsøget var ikke nødvendigvis et udtryk for deres holdning til det politiske valg af de to standarder. De øvrige samarbejdspartnere omkring laboratorietesten, herunder leverandørerne, bragte kritisk merværdi til arbejdet via deres store tekniske ekspertise og netværk. Figur: Om organisation og roller i laboratorietesten Testen blev afviklet i Sogetis Center of Test Excellence med konsulenter fra Sogeti til at sikre udførelse, koordination og rapportering, IT- og Telestyrelsens samarbejdspartnere som testere samt ITog Telestyrelsen til at overvåge testforløbet. Testen blev udført med en explorativ tilgang. Dvs. at der i planen var mulighed for at tilføje yderligere tests og undersøgelser, når det viste sig hensigtsmæssigt i testforløbet. Testen blev løbende dokumenteret, og den blev gennemgået i plenum, hvor der blev opnået enighed om testresultater. Forløb og resultater blev ligeledes dagligt gennemgået i plenum Side 5 af 19

63 Bilagssamling Side 63 af 379 SOGETI Testrapport v1.3 3 Gennemførelsen af laboratorietesten 3.1 Første testrunde Dag 1 Deltagere Jens Jakob Andersen, ITST Finn Gruwier Larsen, Magenta Jesper Lund Stocholm, Ciber Jens Mikael Jensen, IBM, fra ca. kl. 14:00 Ove Nielsen og Lars Christiansen fra Sogeti Testgennemførelse Der var på forhånd lagt en tentativ plan som basis for en struktureret gennemførelse af testen; men det var også forudsat, at planen skulle kunne justeres undervejs på grundlag af: Research, som var blevet gennemført på forhånd inden for nogle af områderne, og som via en bedre forståelse af området, gav anledning til mere målrettede tests end dem som var formuleret i planen Erfaringer undervejs i testen, som gav ny forståelse og dermed grund til at justere det videre forløb. Testen på dag 1 blev startet i henhold til den på forhånd fastlagte plan. I overensstemmelse med ovennævnte principper blev planen justeret i løbet af dagen, dels på grundlag af erfaringer fra de gennemførte tests, og dels på grundlag af på forhånd gennemført research. I denne forbindelse blev der, som noget nyt i forhold til planen, indført research breakouts, hvor hypoteser blev analyseret nærmere, før nye test blev formuleret. Overordnet betragtet blev testen på dag 1 holdt inden for de oprindelig planlagte temaer og findings. På den sidste del af dagen blev der testet parallelt, da det viste sig at være mere ressourceeffektivt. Der blev gennemført følgende tests på dag 1, grupperet efter tema og finding: Billeder der bliver væk, finding fra RMAAK, Scenarie 1, trin 1.11 (Dokument: RM Kursmateriale ) o Konvertering vha. CleverAge 1.1 o Undersøgelse af om billedet fandtes i docx-filen o Undersøgelse af z-index for billedet i ODT filen. Ændring af z-index fra 9 til 1, og konvertering med CleverAge 1.1 o Undersøgelse af z-index i docx-filen (VML). Ændring af z-index til 1 og kontrol af, om billedet nu blev vist i visuel validering o Ændring af drawing ML attribut, behinddoc, fra 1 til 0 OLE-objekter bliver væk, finding fra RMAAK, Scenarie 1, trin 1.11 (Dokument: RM Kursmateriale ) o Åbning af kildedokument med XML-editor for kontrol af objekttype Side 6 af 19

64 Bilagssamling Side 64 af 379 SOGETI Testrapport v1.3 o Konvertering vha. CleverAge 1.1 o Konvertering vha. Sun ODF-plugin o Test af 2 nye blanke dokumenter med OLE-objekter Status på slutningen af dag 1 De temaer som var blevet testet på dag 1, var: Tema nr. 1, Billeder bliver væk, blev testet færdig Tema nr. 2, OLE-objekter bliver væk, blev testet med undtagelse af én test, som blev udsat til dag to. Lessons learned Der må for den videre test planlægges med tid til research breakouts, hvor der bl.a. foretages en grundig vurdering af nye hypoteser, da dette viste sig at være formålstjenligt i forhold til at målrette den videre testning Der kan med fordel testes parallelt, hvis dette kombineres med, at den enkelte tester dokumenterer undervejs Dag 2 Deltagere Jens Jakob Andersen, ITST Finn Gruwier Larsen, Magenta Jesper Lund Stocholm, Ciber Jens Mikael Jensen, IBM, fra ca. kl. 13:00 Ove Nielsen og Lars Christiansen fra Sogeti Testgennemførelse På dag 2 blev der testet videre efter den justerede plan på den måde, at testen blev tilrettelagt i henhold til de erfaringer, som var gjort på dag 1, med tid for research breakouts og paralleltest Der blev gennemført følgende tests på dag 2, grupperet efter tema og finding: OLE-objekter bliver væk, finding fra RMAAK, Scenarie 1, trin 1.11 (Dokument: RM Kursmateriale ). Den test som blev udsat fra dag 1. o Validering af kildedokumentet ved hjælp af en ODF-validator Tegninger bliver væk, finding fra RMAAK, Scenarie 1, trin 1.18 (Dokument: RM Personalehåndbog ) o Genskabelse af test fra pilotforsøget o Indsættelse af yderligere stregtegninger i dokumentkilden o Indsættelse af tilsvarende stregtegninger i et nyt dokument Tegninger bliver væk, finding fra RMAAK, Scenarie 2, trin (Dokument: RM Personalehåndbog ) Side 7 af 19

65 Bilagssamling Side 65 af 379 SOGETI Testrapport v1.3 o Lagring af fil som DOC fra Lotus Notes 8 o Inspektion af XML-kode Tegninger bliver væk, finding fra RMAAK, Scenarie 2, trin (Dokument: RM Kursusmateriale) o Lagring af fil som DOC fra Lotus Notes 8 o Test af forskellige forankringer af tegninger Tekstbokse bliver væk, finding fra RMAAK, Scenarie 1, trin 5.11 (Dokument: Standardbrev på 2 sider ) o Test på dokument med tilsvarende tekstbokse, genereret på anden vis o Inspektion af XML-kode o Åbning af dokumentet i OpenOffice o Åbning af dokumentet i Lotus Notes 8 Forankringer flytter sig, finding fra RMAAK, Scenarie 1, trin 1.18 (Dokument: RM Kursmateriale ) o Genskabelse af test fra pilotforsøget o Ændring af forankring o Inspektion af XML-kode o Åbning af dokumentet i Lotus Notes 8 og lagring i DOC-format Status på slutningen af dag 2 Følgende var færdigtestet på slutningen af dag 2: Sidste del af tema nr. 2, OLE-objekter bliver væk. Dvs. den test under dette tema, som var blevet udsat fra dag 1 Tema nr. 3, Tegninger bliver væk Tema nr. 4, Tekstbokse forsvinder Tema nr. 6, Forankringer flytter sig. Lessons learned Erfaringerne fra dag 2 bekræftede, at det var hensigtsmæssigt at afsætte tid til research breakouts Dag 3 Deltagere Jens Jakob Andersen, ITST Finn Gruwier Larsen, Magenta Jesper Lund Stocholm, Ciber Jens Arnt, IBM Ove Nielsen og Lars Christiansen fra Sogeti Side 8 af 19

66 Bilagssamling Side 66 af 379 SOGETI Testrapport v1.3 Testgennemførelse Dag 3 var på forhånd afsat til en grundigere analyse af findings fra konverteringer fra ODT til EOOXML og fra EOOXML til ODT. Dagen startede med en planlægningsrunde på grundlag af dokumentet Opsummering af dokumentanalyse af scenario 2. Det blev her besluttet at analysere begge typer konverteringer ved hjælp af tre metoder: Skrælle løg metoden Byg fra bund XML-analyse Som grundlag for dette, blev det valgt at bruge dokumenterne RM Standardbrev 2s og RM Kursusmateriale. Der blev gennemført følgende tests på dag 3: Konverteringer fra ODT til EOOXML o Undersøgelse af beskæring afbilleder o Test af overførsel af streger o Undersøgelse af XML-kode Konverteringer fra EOOXML til ODT o Test af luft mellem linjer o Bottom-up konstruktion af tekstbokse o Undersøgelse af XML-kode Status på slutningen af dag 3 På slutningen af dagen havde man gennemført de tests som var blevet formuleret og sat på planen for dagen, med undtagelse af to tests angående konvertering af testbokse. Det blev besluttet at gennemføre disse to tests på starten af dag Dag 4 Deltagere Jens Jakob Andersen, ITST Finn Gruwier Larsen, Magenta Jesper Lund Stocholm, Ciber Jens Arnt, IBM Ove Nielsen og Lars Christiansen fra Sogeti Testgennemførelse Det som blev testet på dag 4 var: To tests angående tekstbokse, som blev formuleret på dag 3, men som af tidsmæssige årsager var blevet udsat til dag 4 o Test af tekstbokse fra ODT til EOOXML i dokumenter, som blev bygget fra bunden Side 9 af 19

67 Bilagssamling Side 67 af 379 SOGETI Testrapport v1.3 o Test af tekstbokse fra EOOXML til ODT ved hjælp af bottom-up konstruktion af tekstbokse Konverteringer af samme dokument ved hjælp af forskellige konvertere, bl.a. Beta CleverAge 1.1 (Se efterfølgende kommentar) Med udgangspunkt i en undersøgelse, som var foretaget på forhånd, og som er dokumenteret i sin egen mappe under dag 4 ( BetaCA.1.1.1/JBMS.test ), blev der gennemført en række konverteringer af dokumentet RM Standardbrev 2s fra EOOXML til ODF og fra ODF til EOOXML. Konverteringerne blev gennemført med forskellige konvertere, herunder Beta CleverAge 1.1 og Novel ODF converter for Linux, med det formål at undersøge om resultaterne blev forskellige. Status på slutningen af dagen Dag 4 var sidste dag i testrunde 1. Lessons learned De justeringer i arbejdsform og rutiner for dokumentationsudarbejdelse, som blev gjort i starten af testperioden, havde vist sig at fungere godt, og planlægges videreført i næste testrunde. 3.2 Research perioden Den vigtigste aktivitet i research perioden var at få defineret de tests som planlægningen af anden testrunde skulle baseres på. Som et led i dette arbejde blev der afholdt en workshop hos ITST onsdag den , hvor der blev gennemgået findings fra pilotforsøg i Gribskov og fra pilotforsøg hos Direktoratet for Fødevareerhverv. Gennemgangen gav anledning til en række tests baseret på disse findings, og i tillæg blev der defineret ekstra tests til anden testrunde baseret på materiale fra Århus kommune og Region Midtjylland. 3.3 Anden runde Dag 5 Deltagere Jens Jakob Andersen, ITST Finn Gruwier Larsen, Magenta Jesper Lund Stocholm, Ciber Jens Arnt, IBM Jens Mikael Jensen, IBM, til ca. kl. 12:00 Ove Nielsen og Lars Christiansen fra Sogeti Testgennemførelse Dagen blev indledet med en gennemgang af planlagt arbejdsform og rutiner for dokumentationsudarbejdelse, sådan som disse var blevet indarbejdet i første testrunde. Det som blev testet på dag 5 var: Logo bliver væk ved konvertering fra DOCX til ODT, finding og fra Gribskov, Scenarie 1, trin 1.8 (Dokument: Erindring1-2kvt07 samlet funktionalitet fra dokument 1-2 og 9.docx ) Side 10 af 19

68 Bilagssamling Side 68 af 379 SOGETI Testrapport v1.3 Overskrift (tekst på hyperlink) mangler, finding Gribskov, Scenarie 1, trin 1.8 (Dokument: Udkast til Forslag til Lokalplan.docx ) Ekstra tests af finding fra paralleltest i RMAAK om tekstbokse og logo som bliver væk (Test Ekstra , dokument: RM Standardbrev 2s.odt ) Ekstra tests vedrørende tekstbokse for at undersøge specifikke elementer, der kan påvirke konvertering af disse (Test Ekstra ) Indlejrede objekter forsvinder, finding fra DFFE, Scenarie 1, trin 2.11, og finding fra DFFE, Scenarie 2, trin 20.9 (Dokument: Afgået svar til Jane Doe vedr. et areal, som De ønsker at købe af naboen [DOK311622].odt ) Kolofon forskydes og afskæres, og kommentarer forsvinder, finding og fra DFFE, Scenarie 2, trin (Dokument: SJ_(1) Foreløbig Høring om forslag til æ.odt ) Status på slutningen af dagen Testen var blevet gennemført i henhold til planen, uden at der havde vist sig væsentlige behov for justeringer undervejs. Lessons learned Både de indarbejdede rutiner for dokumentationsudarbejdelse og arbejdsformen for øvrig, fungerede godt og ville blive videreført Dag 6 Deltagere Jens Jakob Andersen, ITST Finn Gruwier Larsen, Magenta Jens Arnt, IBM Ove Nielsen og Lars Christiansen fra Sogeti Testgennemførelse Dagen startede med, at der blev lagt sidste hånd på dokumentationen af et par af testene fra dagen før. Det som blev testet på dag 6 var: Tabeller som ændrer bredde, med udgangspunkt i finding fra DFFE (Dokument: Afgået svar til Jane Doe vedr. et areal, som De ønsker at købe af naboen [DOK311622].docx ) Striber (enkeltcellede tabeller) som ændrer højde, finding fra Gribskov, Scenarie 1, trin 1.8 (Dokument: bek-281(bs).docx ) Første bogstav i et ord, som blev adskilt fra resten af ordet, finding fra DFFE, Scenarie 1, trin 2.11 (Dokument: Afgået svar til Jane Doe vedr. et areal, som De ønsker at købe af naboen [DOK311622].odt ) Side 11 af 19

69 Bilagssamling Side 69 af 379 SOGETI Testrapport v1.3 Tabuleringer som forrykker sig, finding fra DFFE, Scenarie 2, trin 20.9 (Dokument: Afgået svar til Jane Doe vedr. et areal, som De ønsker at købe af naboen [DOK311622].odt ) Forskellige viewers for de åbne dokumentformater (Ekstratest 1.1) Status på slutningen af dagen Der blev defineret en enkel ny test i forhold til planen, men ellers testet i henhold til plan. Der blev, som planlagt, introduceret en ny testvariant i forhold til tidligere, nemlig afprøvning af forskellige viewerløsninger. Lessons learned Ikke noget specielt at bemærke til dette punkt Dag 7 Deltagere Jens Jakob Andersen, ITST Finn Gruwier Larsen, Magenta Jens Arnt, IBM Jesper Lund Stocholm, Ciber Ove Nielsen og Lars Christiansen fra Sogeti Testgennemførelse Dagen startede med: en gennemgang af arbejdet på dag 6 for at sikre konsensus, specielt som følge af, at én af testdeltagerne ikke var til stede på dag 6 færdiggørelse af dokumentationen for én af testene fra dagen før Det som blev testet på dag 7 var: Håndtering af felter ved konvertering mellem DOC/DOCX og ODT med udgangspunkt i finding fra Gribskov, Scenarie 4, trin (Dokument: Standardbrev ifm ITST pilotprojekt ) Forkert/manglende nummerering af punktlister og overskrifter med udgangspunkt i finding fra Gribskov, Scenarie 1, trin 1.8 (Dokument: Udkast til Forslag til Lokalplan..docx ) I tillæg blev der startet på test af, om commandline-versioner af konverterne konverterer anderledes end plugin-versionerne - ud fra teori om, at konvertering ved commandline fungerer på en anden måde. Status på slutningen af dagen Testen på dag 7 var koncentreret om få emner, som til gengæld lidt mere i dybden. Der blev under gennemgangen af dagens resultater afdækket områder indenfor emnet håndtering af felter, som det var ønskelig at få testet yderligere på dag Side 12 af 19

70 Bilagssamling Side 70 af 379 SOGETI Testrapport v1.3 Lessons learned Det blev oplevet som positivt, at man havde fået anledning til at gå dybere i udvalgte emneområder Dag 8 Deltagere Jens Jakob Andersen, ITST Finn Gruwier Larsen, Magenta Jens Arnt, IBM Jesper Lund Stocholm, Ciber Ove Nielsen og Lars Christiansen fra Sogeti Testgennemførelse Det, som blev testet på dag 8, var: Ekstra tests vedrørende håndtering af felter ved konvertering mellem DOC/DOCX og ODT med udgangspunkt i finding fra Gribskov, Scenarie 4, trin (Dokument: Standardbrev ifm. ITST pilotprojekt ) Test af om commandline-versioner af konverterne konverterer anderledes end pluginversionerne - ud fra teori om, at konvertering ved commandline fungerer på en anden måde. Test af konverteringer ved hjælp af Sun ODF-plugin for MS v.1.1. Status på slutningen af dagen Der blev på testens sidste dag gennemført tests med udgangspunkt i alternative konverterversioner. Selv om der også i disse tests blev testet findings fra pilot, var dette en anden indfaldsvinkel til testen, idet tidligere tests havde taget udgangspunkt i de enkelte findings. De konvertere, som blev afprøvet, var commandline-versioner af tidligere brugte konvertere samt Sun ODF-plugin for MS v.1.1. Tonen og samarbejdet under laboratorietesten havde været særdeles godt, og der blev rettet en tak til testerne for engageret og konstruktiv deltagelse. 4 Planlægningsprocessen Med udgangspunkt i findings fra gennemførte pilotforsøg blev der formuleret hypoteser om, hvad de enkelte findings kunne skyldes, og der blev defineret tests for at bekræfte eller afkræfte hypoteserne. En væsentlig del af dette arbejde blev gennemført på workshops hos ITST den og den En risikobaseret tilgang blev anvendt ved udarbejdelse af de detaljerede testplaner for laboratorietesten. De på forhånd definerede tests blev grupperet i temaer, som derefter blev prioriteret efter, hvor væsentlige de er for funktionaliteten. Det var imidlertid tanken, at disse planer ikke nødvendigvis skulle følges slavisk. For at sikre bedst mulig udnyttelse af de erfaringer og resultater som blev opnået undervejs, blev der lagt op til, at man undervejs skulle kunne ændre planen ved at: omdefinere tests ud fra ny indsigt i problemstillingen Side 13 af 19

71 Bilagssamling Side 71 af 379 SOGETI Testrapport v1.3 definere nye tests til test af nye eller justerede hypoteser droppe tests, som på grundlag af ny indsigt viste sig at være overflødige eller irrelevante. Denne åbning for at justere planen undervejs, viste sig under testen at være særdeles værdifuld. I et tilfælde som dette, hvor der ikke findes erfaringsmateriale, som kan bruges for at estimere tidsforbrug, og hvor der i tillæg er åbnet for at justere planen undervejs, er det vanskelig at forudsige hvor mange tests, det er realistisk at planlægge med. Det blev derfor defineret rigeligt med tests for at undgå, at der skulle opstå mangel på testcases mod slutningen af testen. Dvs. at det var en del af planen, at der til slut var tests tilbage, som ikke var blevet gennemført Side 14 af 19

72 Bilagssamling Side 72 af 379 SOGETI Testrapport v1.3 5 Testmiljø Testmiljøet bestod af seks PC er (en pc med Linux og fem pc er med Windows) plus en fælles disk. PC erne var konfigureret ud fra nedenstående krav: Krav til konfiguration af Linux-computeren SUSE Linux Enterprise Desktop 10 SP1 OpenOffice Novell Edition version 2.1 Lotus Notes 8 klient med productivity tools Novell Edition ODF-converter Krav til konfigurationer for XP-computere Generelt Sprog Danske versioner af Office og XP, men licenser til engelske versioner er tilgængelige. Hvis tiden tillader det, og hvis det vurderes, at der er behov for det, kan der etableres mulighed for også at teste på engelske versioner. Læsning af EOOXML- og ODF-filer Der skal være XML-spy tilgængelig for læsning af EOOXML-filer, og zip-program tilgængelig for læsning af ODF-filer. Dvs. mulighed for at udpakke ZIP filer (odt henholdsvis docx som omdøbes til.zip og udpakkes for analyse) Formatvalideringer For validering af ODF-filer benyttes online validator på For validering af EOOXML-filer benyttes den som ligger på PDF-writer Som PDF-writer bruges PDF995, som kan downloades fra Mulighed for at lave skærmdumps (Printscreen) Side 15 af 19

73 Bilagssamling Side 73 af 379 SOGETI Testrapport v1.3 Konfigurationer på XP- testmaskiner Styresystem XP XP XP Office pakke Word 2003 Word 2007 Open Office Novell Edition Rent image, kun med styresystem og office pakke Konvertere MS Compatibility Pack CleverAge 1 CleverAge 1 Novell Edition ODFconverter Nyt image med ovennævnte konvertere Alternative konvertere MS Compatibility Pack CleverAge 1.1 CleverAge 1.1 Nyt image med alternative konvertere Alternativ konverter Sun ODF-plugin for MS 1.0 Nyt image med alternativ Sun ODF-plugin Dvs. i alt 8 images: Fire med Word 2003 o Kun XP og Word 2003 o XP, Word 2003, MS Compatibility Pack og CleverAge 1 o XP, Word 2003, MS Compatibility Pack og CleverAge 1.1 o XP, Word 2003 og Sun ODF-plugin for MS 1.0 Tre med Word 2007 o Kun XP og Word 2007 o XP, Word 2007og CleverAge o XP, Word 2007og CleverAge 1.1 Én med XP og Open Office Novell Edition o OpenOffice Novell Edition og Novell Edition ODF-converter Ændringer af konfigurationer i forhold til ovenstående Der blev oprettet et nyt image med CleverAge build 3804 På et image blev der installeret OpenOffice Novell Edition build 3 (developer edition) Der blev oprettet et nyt image med XP og forskellige viewers, men uden kontorstøttepakker, jf. beskrivelsen af testen Ekstra Desuden blev der benyttet: o Command-line versioner af Novell ODF-converter under Linux, og af CleverAge under Windows, i henholdsvis test Ekstra og test Ekstra o Sun ODF-plugin for MS 1.1 i test Ekstra Sun1.1.1 Softwarekonfigurationer er valgt ud fra et udsnit af de tekstbehandlingsapplikationer som anvendes i det offentlige, og skal ikke ses som udtryk for hverken positiv eller negativ holdning til det pågældende software og de givne leverandører Side 16 af 19

74 Bilagssamling Side 74 af 379 SOGETI Testrapport v1.3 6 Testdokumentation 6.1 Detaljeret dokumentation fra testgennemførelsen Den detaljerede dokumentation fra testgennemførelsen ligger i mappen Complete LAB_TEST \ LAB_TEST, undermapperne: LAB_TEST_FASE1 \ Hypoteser til test LAB_TEST_FASE1-ny \ Hypoteser til test LAB_TEST_FASE2 \ Hypoteser til test Første testrunde Den dokumentation som blev produceret i under testen, ligger i mappen Complete LAB_TEST \ LAB_TEST \ LAB_TEST_FASE1 \ Hypoteser til test i undermapperne: Pilot, som indeholder den dokumentation, som blev produceret dag 1 og 2 Dag og Dag , som indeholder dokumentationen fra dag 3 og 4 I tillæg ligger der en mappe med betegnelsen Parallel, men denne blev ikke benyttet. Under disse undermapper ligger der en mappe for hver af de findings, som er blevet undersøgt under testen. Indholdet i disse er nærmere beskrevet i nedenstående afsnit Ikke alt af den detaljerede testdokumentation fra første testrunde blev gjort færdig under selve testen. Det gælder f.eks.: der blev ikke genereret PDF-filer af alle relevante output-filer, og ikke alle relevante output-filer blev printet filnavnene på testdokumentationsskemaerne blev ikke i alle tilfælde ændret til at indeholde en reference til den aktuelle test ikke alle relevante outputdokumentnavne var nævnt i testdokumentationsskemaerne Dette, samt andre mindre mangler i testdokumentationen, blev udbedret efter selve testgennemførelsen; men for at der ikke skal opstå tvivl om ægtheden af testdokumentationen fra selve testen, blev ændringerne udført i en kopi af den oprindelige dokumentation. Dvs. at den oprindelige dokumentation fortsat ligger urørt i LAB_TEST_FASE1 \ Hypoteser til test, mens den justerede dokumentation ligger i LAB_TEST_FASE1-ny \ Hypoteser til test Anden testrunde Dokumentationen fra enden testrunde ligger i mappen Complete LAB_TEST \ LAB_TEST \ LAB_TEST_FASE2 \ Hypoteser til test Direkte under denne ligger der en mappe for hver af de findings, som er blevet undersøgt under testen. Indholdet i disse er nærmere beskrevet i nedenstående afsnit I anden testrunde var rutinerne for udarbejdelse af dokumentation undervejs, blevet bedre indarbejdet. Det var derfor ikke, som i første runde, behov for at oprette en ny, egen mappe med opdateret dokumentation Side 17 af 19

75 Bilagssamling Side 75 af 379 SOGETI Testrapport v Strukturen i undermapperne for findings og tests Nederst i dokumentationsstrukturen ligger der mapper for hver af de findings, som er blevet undersøgt under testen. Understrukturen i disse mapper er: <Finding nr. f.eks > o Test1 INPUT_DOCS DFFE DOCS Gribskov RMAAK DATA INPUT_DOCS_DANNET_I_LAB OUTPUT_DOCS o Test2 osv. De inputdokumenter fra pilotforsøgene som er benyttet i de enkelte tests, ligger i undermapperne INPUT_DOCS \ DFFE, INPUT_DOCS \ Gribskov og INPUT_DOCS \ RMAAK DATA. I INPUT_DOCS \ DOCS ligger beskrivelse af den finding og den hypotese som skal undersøges, og tilhørende, planlagte test. I INPUT_DOCS_DANNET_I_LAB ligger eventuelle dokumenter, som er dannet i testlaboratoriet som input til testen. Dette kan være dokumenter som er dannet fra bunden, dvs. på grundlag af blanke dokumenter, eller f.eks. inputdokumenter fra pilotforsøg, som er blevet ændret til testformål. Output fra en test er lagt i undermappen OUTPUT_DOCS. Det vil typisk være: dokumenter dannet ved konvertering av inputdokumenter print af skærmbilleder testdokumentationsskema 6.2 Sammenfattende dokumentation Oversigt over de tests som blev gennemført i testfase 1 og 2, findes i henholdsvis [2], Faktisk gennemført - fase 1 og [3], Faktisk gennemført - fase 2. De to oversigter er udarbejdet på grundlag af planerne for de respektive testrunder, dels under selve testen, og dels efter testen. I overensstemmelse med de principper for justering af planerne undervejs, som er omtalt i kap. 4, Planlægningsprocessen, blev planen justeret under testen med kommentarer til ændringerne. I tillæg blev det markeret på hvilke dage, de enkelte tests var blevet gennemført. Ved slutningen af hver testrunde viste den opdaterede kopi af planen således, hvilke tests som faktisk var blevet gennemført, og de blev omdøbt til Faktisk gennemført - fase x. Efter hver testrunde blev skemaerne med oversigter over faktisk gennemførte tests, udvidet med følgende kolonner: Findings fra de enkelte tests, kopieret ind fra testdokumentationsskemaerne Side 18 af 19

76 Bilagssamling Side 76 af 379 SOGETI Testrapport v1.3 Forslag og kommentarer fra de enkelte tests, kopieret ind fra testdokumentationsskemaerne Oversigt over printet dokumentation fra de enkelte tests Oversigt over ikke-printede output-dokumenter fra testene Delvis på grundlag af disse oversigter over gennemførte tests, og delvis på grundlag af testdokumentationsskemaerne, blev der bagefter udarbejdet en oversigt over findings, jf. [4], Oversigt over findings. Princippet i oversigten over findings er, at hver finding skal være tilknyttet: Et hovedtema Et undertema Et værktøj for 1. visuelle validering Et værktøj for 2. visuelle validering (*) En konverter (*) *) I nogle tilfælde, f.eks. hvis findingen knytter sig til en XML-inspektion af input-filen, er disse ikke relevante. Da er det i skemaet angivet med NA. De fem nævnte nøgleoplysninger angives med standardiserede betegnelser i hver sin kolonne i regnearket. På denne måde kan findings sorteres og selekteres efter disse oplysninger. For hver finding er der i tillæg angivet en reference til den tilhørende test. Den kan bruges, hvis man ønsker at søge yderligere oplysninger i baggrundsmaterialet fra testen. Til nogen tests er der knyttet mere end én finding. I disse tilfælde vil samme test optræde i flere linjer i regnearket. Dette er angivet med.a,.b osv. i en egen kolonne efter testnummeret. 6.3 Leverancer Følgende indgår i den samlede leverance til IT-og Telestyrelsen Fil-mappen "LAB_TEST_FASE1" (originalmateriale fra runde 1) Fil-mappen "LAB_TEST_FASE1-Ny" med de PDF-dokumenter, som manglede i originalmaterialet, samt mindre justeringer i testdokumentationsskemaerne Fil-mappen "LAB_TEST_FASE2" (originalmateriale fra runde 2) To ringbind med print fra hhv. runde 1 og runde 2 Oversigt over faktisk gennemførte tests i runde 1 Oversigt over faktisk gennemførte tests i runde 2 Samlet oversigt over findings Testrapport Den harddisk, som blev brugt som fællesdisk under testen Side 19 af 19

77 Bilagssamling Side 77 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag H

78 Bilagssamling Side 78 af 379 Research about OpenXML, ODF & PDF February 2007 Ovitas AS, Norway

79 Bilagssamling Side 79 af 379 Research OpenXML, ODF & PDF Table of Contents 1 SCOPE AND SUMMARY STANDARD ODF OPENXML PDF ORGANIZATION ADMINISTRATION OASIS (ODF) Ecma (OpenXML) MEMBERSHIP OASIS (ODF) Ecma (OpenXML) DECISION PROCESS OASIS (ODF) ECMA (OpenXML) Adobe (PDF) OPENNESS OASIS (ODF) Ecma (OpenXML) ECONOMIC GROUND OASIS (ODF) Ecma (OpenXML) Adobe (PDF) INFLUENCE OPENNESS - THE TECHNICAL COMMITTEE Membership Decision process Transparency Availability Permissions PERFORMANCE MATURITY Functional dimension Testing - development period & successful implementation EXTENSIVENESS Market share current & previous version AGREEMENT ADEQUACY - NOT FUNCTIONAL QUALITY & LIMITATIONS - REFERENCE ARCHITECTURE CUSTOMIZATION ODF OpenXML PDF POTENTIAL Use Cases SPECIFICATION ON DOCUMENT FORMATS READABILITY, PRESENTATION, EDITING

80 Bilagssamling Side 80 af 379 Research OpenXML, ODF & PDF ODF OpenXML PDF EXCHANGE AND INTEGRATION ODF OpenXML PDF SUPPORT OF OTHER STANDARDS ODF OpenXML PDF HOW APPLICABLE IS THE STANDARD FOR OTHER STANDARDS? ODF OpenXML PDF DOCUMENT TYPES ODF OpenXML PDF SUPPORT USER ANNOTATION ODF OpenXML PDF DOCUMENTATION AND SPECIFICATION ODF OpenXML PDF TECHNICAL REFERENCES ODF OpenXML PDF ADOPTION AND/OR SUPPORT OF OTHER DOCUMENT FORMATS ODF OpenXML PDF APPLICATION SUPPORT ODF OpenXML PDF LAW AND RIGHTS WHAT LICENSE RELATED RIGHTS ARE AFFILIATED WITH THE STANDARD? ODF OpenXML PDF ARE RIGHTS OTHER THAN THOSE RELATED TO LICENSING AFFILIATED WITH THE STANDARD? WHICH? ODF OpenXML PDF REFERENCES

81 Bilagssamling Side 81 af 379 Research OpenXML, ODF & PDF 1 Scope and summary This report is the result of a preliminary research commissioned by the Danish National IT and Telecom Agency (ITST) and conducted by Ovitas AS Norway in The purpose of this preliminary research is to establish whether the three document formats, OpenXML, ODF and PDF meet the following criteria for qualifying as candidates for open standards for document formats. The criteria covered in this research include three main areas: 1. Openness (open documentation, rights, open interface, open meeting, consensus, due process) 2. Market issues (penetration, maturity, implementation) 3. Business potentials (functional and non-functional requirements, security, potentials and architecture) The structure of this report is divided in a somewhat different way - as the description of the criteria has developed over time, but the covered issues are unchanged. The main findings in the report are: 1. Openness: All three standards are open and accessible for the public free of charge. The standards can be implemented by anyone, without any discrimination as open- or closed source applications on any platform. OpenXML is originally developed by Microsoft and submitted to the Ecma standardization process. Only companies can join Ecma. OpenXML cannot be considered as entirely open, as it is considered that Ecma does not work in an entirely transparent manner. ODF is based on the document format developed by OpenOffice.org and the standard was developed by OASIS. OASIS is considered to work in a highly transparent manner. ODF became a published ISO standard on November 30, PDF is created and controlled by Adobe Systems. There is no public information available on their internal routines. (Here we do not consider specialized subsets of PDF like PDF/A that has been adopted as an ISO-standard). 2. Market issues: OpenXML is not supported by any products yet (December 2006), but the document format is expected to gain widespread use as Microsoft has announced to use the format as the native format for their future Office product line. Microsoft s current market share of the office suite market is estimated to 90-95%. ODF is currently supported by a number of products and more product support is anticipated in the future. OpenDocument Fellowship claims OpenDocument has more than 12 % market share. PDF has about 15 years history on the market and has become a de facto global standard for fixed-layout documents. Readers for many platforms are available and are generally free. 3. Business potentials: OpenXML is an editorial format which supports rich functionality of the Microsoft Office suite, as it is a development of the internal document formats used in Microsoft Office including spreadsheets, presentations and drawings. ODF is an editorial format, which supports rich functionality for office users including spreadsheets, presentations and drawings. PDF is not intended to be used as an editorial format. PDF is used for representing documents in a device independent and resolution independent fixed-layout document format. 4

82 Bilagssamling Side 82 af 379 Research OpenXML, ODF & PDF The conclusion of this preliminary research is that both OpenXML and ODF qualify as viable candidates for open standards for editorial document formats based on the criteria used in this research. PDF is currently controlled by Adobe Systems but has a unique worldwide take up. After this preliminary research was carried out, a number of interesting developments have taken place. These developments are not reflected in this report. Three of these noteworthy developments are: Ecma has on 7 December 2006 approved Office Open XML as an Ecma standard and voted to submit the new standards to ISO for consideration as an ISO standard through the fast-track process. Adobe Systems has on 31 January 2007 announced that it intends to release the full Portable Document Format (PDF) 1.7 specification to AIIM, the Enterprise Content Management Association, for the purpose of publication by ISO. Microsoft has released Office 2007, which uses OpenXML as the default document format. While it is too early to determine the results of these developments, this certainly accentuates the industry interest in support for open standards for document formats. 2 Standard First, here it s a short description of each standard: history, origin and actual stage. 2.1 ODF The ODF (OpenDocument) standard was developed by the OASIS industry consortium and based upon the XML format originally created by OpenOffice.org. More than 100 changes were made on the original schema, taking every participant s needs in account. ODF was approved as an OASIS standard on May 1, 2005 (by the whole full membership, which represents over 600 organizations). ODF became a published ISO and IEC International Standard referred to as ISO/IEC 26300:2006 on November 11, OpenXML OpenXML is an open standard, originally developed by Microsoft and has submitted it to the Ecma standardization process. The charter of the Ecma Technical Committee requires it to submit the completed standard to the ISO. Ecma announced on December 9, 2005 that it had accepted Microsoft's proposal to document the format as a proposed standard. It will be referred to as Ecma Office Open XML. The final draft of the Office Open XML standard has been submitted it to the Ecma Secretary General (October 6th, 2006) and the General Assembly of Ecma International will vote on this proposal during their meeting December 7-8, PDF PDF is an open file format created and controlled by Adobe Systems, for representing documents in a device independent and resolution independent fixed-layout document format. 5

83 Bilagssamling Side 83 af 379 Research OpenXML, ODF & PDF Version 1.0 of PDF was announced at Comdex Fall in Version 1.6 was made available on November Organization This chapter is about the internal workflow, rules and control of the organization, responsible for the development of the standard. Adobe is a private company. It s governed by rules and regulations related to private companies. There is no public information available on their internal routines. 3.1 Administration How the organization is governed OASIS (ODF) The ODF standard is based on the document format developed by OpenOffice.org. From OASIS who page 3 : OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 5,000 participants representing over 600 organizations and individual members in 100 countries. Members of the OASIS Board of Directors are nominated in an open election process by the Sponsors and Contributors of the Consortium. Each director serves a two-year term. Please read further details about the open election process here: Ecma (OpenXML) Ecma International is an industry association founded in 1961 and dedicated to the standardization of Information and Communication Technology (ICT) and Consumer Electronics (CE). The organizational structure of Ecma is a simple, flat one: the technical work is done by the Technical Committees, and the results of this work can be submitted twice a year to the General Assembly for approval for publication. 4 The General Assembly of the ordinary members is the highest authority of the Association. It controls the Association and appoints and controls its Management. The Ecma procedures consist of a set of By-laws 5, Rules 6 and a Code of Conduct in Patent Matters Membership Rules and criteria for joining the organization. 6

84 Bilagssamling Side 84 af 379 Research OpenXML, ODF & PDF OASIS (ODF) Anyone company, organization or individual can join to OASIS. Specialist, providers, implementers, users work on the standards. See membership FAQ for details: Members participated in the ODF standardization process, listed by Wikipedia 8 : The standardization process included the vendors of office suites or related document systems, including (in alphabetical order): Adobe (Framemaker, Distiller) Arbortext (Arbortext Enterprise Publishing System) Ars Aperta Corel (WordPerfect) IBM (Lotus 1-2-3, Workplace) KDE (KOffice) SpeedLegal (SmartPrecedent enterprise document assembly system); both product and company later changed names to Exari. Sun Microsystems / OpenOffice.org (StarOffice/OpenOffice.org) Document-using organizations who initiated or were involved in the standardization process included (alphabetically): Boeing CSW Informatics Drake Certivo Intel (they are developing sample documents as a test suite) (Bastian, 2005) National Archives of Australia New York State Office of the Attorney General Novell (Berlind, October 25, 2005) Society of Biblical Literature Sony Stellent Ecma (OpenXML) From How to join Ecma 9 : Companies which have interest and experience in matters related to one or more Technical Committees of the Association, and which wish to exert the right to vote at the General Assembly and to exert other exclusive rights defined in the By-laws and Rules can apply to become Ordinary members (full membership). Companies which have interest and experience in matters related to one or more of the Technical Committees of the Association but without the right to vote in the General Assembly can apply to become Associate members. 7

85 Bilagssamling Side 85 af 379 Research OpenXML, ODF & PDF Companies which have similar interests as an associate member and an annual, global turnover of less than one hundred million Swiss Francs can apply to become SME members (Small and Medium-sized Enterprise. The Ecma technical committee developing the (OpenXML) proposal includes representatives from Apple The British Library Canon Intel Microsoft NextPage Novell Pioneer Statoil ASA Toshiba The United States Library of Congress. 3.3 Decision process How the organization develops and adopts a new standard OASIS (ODF) The elected board of the organization is not directly involved in the technical process of the standard development. The technical work around the standard is driven by the technical committees, which can be freely formed in the organization. The board is responsible to supervise if the standard development goes according to OASIS regulations. They also maintain and can revise OASIS Open Bylaws: ECMA (OpenXML) ECMA TCs develop standards. Their work can be submitted twice a year to the General Assembly for approval for publication. Unless otherwise prescribed by these By-laws or the Rules of the Association, the vote of the majority of all the ordinary members shall decide any question Adobe (PDF) PDF is the intellectual property of Adobe. Adobe alone decides about the development direction and speed. New versions are released rapidly. These new versions provide more and more functionality, but at the same time they bring possible incompatibilities also. 8

86 Bilagssamling Side 86 af 379 Research OpenXML, ODF & PDF 3.4 Openness How open are the processes, documentation, meetings etc. in the organization OASIS (ODF) OASIS Policies and Procedures are publicly available on the web site of OASIS: OASIS hosts a wide variety of lists to enable and augment the work of Consortium members and encourage public input. Along with OASIS Standards and other approved documents, these lists represent a vital community asset, a unique knowledge base produced through collaborative effort. With the conviction that access to information is the foundation of the open standards process, all OASIS lists are archived online, and the vast majority are viewable by the public Ecma (OpenXML) Ecma does not operate in a transparent manner. They don t have publicly available mailing list or archive. Meeting minutes are not available for the public, neither the comments posted by the public. 3.5 Economic ground Ownership and other economic circumstances those are valid for the organization OASIS (ODF) OASIS is a non-profit organization, financed by sponsors. Time and travel expenses are the responsibility of individual experts and their employers. The costs of phone and face-to-face meetings are covered by the sponsors Ecma (OpenXML) Ecma is a non-profit-making organization. It devotes itself to no commercial activity. It s financed based on membership fees, decided by the General Assembly with a two thirds majority of all ordinary members. Ecma does not pay salary to TC members nor cover their expenses Adobe (PDF) Adobe is a private company, founded in Adobe Systems entered NASDAQ in Adobe's 2005 revenues were about $2.0 billion USD. Today it has about 5879 employees worldwide. 9

87 Bilagssamling Side 87 af 379 Research OpenXML, ODF & PDF 4 Influence Control fulfillment. 4.1 Openness - The technical committee A technical committee (TC) of an open community: Open standards are carefully monitored by a community that has the following characteristics. A TC is the group of all participants who are involved in the procreation and further development process of the standard. How the TC is founded and controlled has a major role in the standard creation process Membership All who are interested should be able to participate, without discrimination OASIS TC (ODF) The OASIS Technical Committees (TC) is self-organized. Three or more OASIS members can form a TC to standardize anything in the structured information field, without any formal approval by the board. The purpose of the OASIS OpenDocument Committee is to "create an open, XML-based file format specification for office applications." 11 This means, the file format is not specialized for a certain application, but it provides a formal standard for arbitrary office applications. This includes Microsoft Office, but is not limited to it Ecma TC (OpenXML) TCs will be formed by the Secretary General (SG) when so decided at a General Assembly. Any proposal for the setting up of a TC must give the suggested terms of reference, including the scope, and be sent to the SG. Any Ecma member may participate in any TC. The purpose of ECMA TC45 is "to produce a formal standard for office productivity applications that is fully compatible with the Office Open XML Formats, submitted by Microsoft" Adobe (PDF) There is no public information how working groups are formed at Adobe. Most likely it s driven by the company hierarchy Decision process Decisions are to be reached by consensus OASIS TC OASIS has developed a strictly controlled, neutral process for developing new standards, named OASIS Technical Committee Process: 10

88 Bilagssamling Side 88 af 379 Research OpenXML, ODF & PDF Decisions are made via voting of the TC s members. The voting details are available for the public: Ecma TC From the Ecma rules: Voting on any matter shall be by simple majority of TC members present at the meeting. It is recommended that in the course of its ordinary work the TC should not use voting unless it is impossible to make progress without a vote. Conclusion made by the TC can be submitted twice a year to the General Assembly for approval for publication Transparency Policies and practice, notes and decisions of the community should be publicly available OASIS TC The public can follow the work of the TC in great depth. They not only can access to this information, but also anyone can comment on this. The comments submitted by the public are also available for anyone to read. TCs actively use these public comments for their work. OASIS ODF TC has 3 lists: Office used by TC members. The public can access the archive. Office-comment a public mailing list for providing input to the TC members. Opendocument-users a public mailing list for developers implementing the standard. The OASIS TC also has an OpenDocument Wiki, which is a collaborative tool for the members. Only members can post to these pages, but anyone can read it. Permanent work and stable artifacts will be moved to the document repository, where the archival work product of the TC also can be viewed by the public Ecma TC The TC s work is not transparent towards the public. They publish a status report after each meeting, which are not very detailed and present the result, but don t say anything about the discussion itself: It s also possible to submit a feedback, however these feedback are not publicly visible: 11

89 Bilagssamling Side 89 af 379 Research OpenXML, ODF & PDF Adobe Adobe provides PDF Language and Specification forum 13 as part of their Adobe PDF Technology Center Availability Open standards are free for all to read and implement in a non-discriminating fashion. All of these three standards are open, accessible for the public for free of charge. These can be implemented by anyone, without any discrimination as open- or closed source applications on any platform Permissions The conditions of an open standard have to allow an extended or reduced implementation. In a given situation there might be a demand of communicating this clearly ODF ODF allows extensions. Documents conform to the ODF format, may contain foreign elements, elements not defined by the standard. These elements must use a foreign namespace. The standard states one condition: the document must validate against the ODF schema after the foreign elements (extensions) are removed. Conformance (regarding to reduced implementation) is not defined further. Applications can read and write the ODF format, may preserve the foreign elements, but it s not required. ODF can also contain custom metadata (<office:meta>), which must be preserved. For detailed information, please refer to section 1.5 (Document Processing and Conformance) in the standard OpenXML A document conforms to the OpenXML standard if it s validating against the schema (excluding the extensions). An application conforms to the schema if it accepts all documents conform to the standard and if it produces documents conform to the standard. Does it allow reduced implementation? Certainly. A conforming application must not reject any conforming documents, but it does not mean it has to do any meaningful with the content. It can be for example a simple validating parser. The standard also defines interoperability guidelines: The application need not implement operations on all elements defined in this Standard. However, if it does implement an operation on a given element, then that operation should use semantics for that element that are consistent with this Standard. Further readings: Conformance chapter in the Fundamentals. The standard defines also extensibility in part 5, Markup Compatibility and Extensibility. 12

90 Bilagssamling Side 90 af 379 Research OpenXML, ODF & PDF PDF PDF does allow reduced implementation or extensions (for example using custom dictionaries) of the format. The implementation has to make a reasonable effort to respect the access permissions defined by the document. 5 Performance Comply with a generic demand. 5.1 Maturity Judging the maturity of a standard is a hard nut. We have to admit, this is not an exact science. However looking into the history of the standard and the quality of the supporting application, we can draw quite an accurate picture Functional dimension To what extent does the standard cover its area of functionality (e.g. XML is 80% of SGML) ODF & OpenXML In functionality-wise both ODF and OpenXML formats satisfy the needs of sophisticated office applications. They express all commonly used office object types with advanced features. Beyond that they provide good accessibility and right management. OpenXML made the goal to keep all the functionality of its preceding Microsoft document format. ODF has strong roots also: it s the descendant of the proven OpenOffice.org format, which has been used on the market for at least 5 years. The first work for the ODF file format started as early as PDF PDF is derived from the very successful PostScript language. It has a long history, so it got long time to become mature... The first version came out in the early 1990s and the fifth edition was released about two years ago. Along these years PDF became the de-facto standard on the fixed-layout document format market, winning over competing formats like Envoy, Common Ground Digital Paper or DjVu. Today it s widely used by the big publisher companies, which is the best proof of its maturity Testing - development period & successful implementation Tested in a technical implementation and/or been through several improvements/life cycles. Successful implementation in a sector, multi sector, public- and/or non-public sector 13

91 Bilagssamling Side 91 af 379 Research OpenXML, ODF & PDF ODF OpenDocument Format is currently used as the native file format in several office suites and individual applications. Support for OpenDocument was implemented independently, first in the KOffice suite and later in OpenOffice.org. Office suites which natively support OpenDocument Format are available on Windows, Mac OS X, GNU/Linux, Solaris, and Symbian OS. The ODF Test Suite 15 is a publicly available interoperability test suite developed by Intel and the University of Central Florida. Automated results are available for interoperability testing of KOffice and OpenOffice.org. The results are discussed and published on the opendocument-sample 16 list. The test results of the test suite related to OpenOffice and KOffice are published here: OpenXML Microsoft Office 2007 will support the standard as its default format. This suite is not yet released, but expected about the end of this year (2006). The new Wordperfect (Corel software) will also support the OpenXML format, but its release date is unknown by now. No publicly available interoperability test suite exists for Microsoft Office Open XML format. Since no currently released office suites provide native support for the format, it is not known to what extent documents saved in the Microsoft Office Open XML format will be properly formatted in other office suites PDF Adobe has a test suite with reference documents here: The PDF specification also contains a few example documents. 5.2 Extensiveness Limited to developers/pilot projects and smaller/bigger groups or publicly available Market share current & previous version ODF OpenDocument Fellowship claims OpenDocument has more than 12% market share. They have even higher figure related to the small and medium business. When we sum different market share figures, we certainly end up with a number bigger than 100, which shows the reliability of the statistics. The market situation may improve for ODF quite soon, since there are more and more efforts to adopt this standard. Governments are the biggest among them. This market share analysis provides a long list: 14

92 Bilagssamling Side 92 af 379 Research OpenXML, ODF & PDF Major deployments: There is an excellent article about the adoption of OpenDocument at Wikipedia: OpenXML Microsoft owns about 90-95% of the office suite software market. Since Microsoft made OpenXML (docx) the default format of its new Office 2007, the format will spread very fast as soon as this suite is released. End users will meet some problems, since former versions are not able to open docx. It can be fixed quickly via adding a plugin which can read and save documents in this new format. The previous version of the format (Office 2003 XML) had about 8% market share. It was supported by MS Office 2003 only PDF PDF is the de-facto format, used basically everywhere. It s the default preview format on Macintosh, but there are free generators/viewers available for all the platforms. PDF is the almost the only widely used page oriented document format on the market. Beyond that PostScript 17 is used quite a lot (which is also an Adobe standard), but it has less and less importance. Important to note that Microsoft presented a similar fixed-layout document format named XML Paper Specification (XPS) in XPS is based on XAML, and is distributed along a royalty-free license. Microsoft is looking again at its license in order to make it compatible with open source licenses to make possible supporting this new format on other platforms also (like Linux or Mac OS). XPS support is scheduled to be included in Microsoft Windows Vista. XPS can gain a good part of market share against PDF. 6 Agreement Fulfillment of specific egovernment demands. 6.1 Adequacy - Not functional quality & limitations - Reference Architecture Customization In what scale the standard is in use/ is relevant in egovernment (different platforms, OS and hardware). In what scale can the standard be added and used in a reference architecture? A reference architecture describes an overall digital infrastructure ODF Applications and platforms There are sophisticated applications (both commercial and freeware) available for all the major platforms, including Windows, Linux, Mac OS, and Solaris... etc. We can say for all desktop hardwares. 15

93 Bilagssamling Side 93 af 379 Research OpenXML, ODF & PDF ODF office suites are also localized for a vast number of languages 20 and use excellent language tools (spell checker, thesaurus...). All parties, governments, companies or individuals can get the right level of support they depend on. A disadvantage can be the missing mature light-weight viewer applications. Migration of legacy documents Data migration is most likely a very important issue here. On demand conversion managed by the end user is not a commended way to address this issue, because any conversion on legacy formats will be lossy (at least on the layout). No doubt about that. However a do it once conversion, did by professionals, in a controlled way with review at the end can solve this problem. Data flow Light-weight viewer application can be used to read other formats. Modifying documents arrived in other formats is a bit more difficult. Import filters, conversion does preserve the original text on a fairy reliable level, but the layout will most likely be a bit different OpenXML Applications and platforms Microsoft will release Office 2007 by end of this year, which will be the only application supports OpenXML for a while. The Mac OS platform will be supported in about a half a year. Other operation systems are not covered. Corel promised to support the OpenXML format in the next release of WordPerfect. There is no viewer application available for the format right now. Data migration Presumably, as soon as Microsoft releases Office 2007, the OpenXML format will spread very fast. However since other governments, companies or individuals are using or will be soon using the ODF formats, just using OpenXML would not eliminate data migration issues. They would be just the same as it s described above under the ODF section PDF Applications and platforms PDF has about 15 years history on the market. There are mature, free readers available for all platforms (operating systems & hardware). PDF also has available plug-ins for browser which makes it well integrated with the web. The end user can fill out a form online and submit it without leaving the browser or using directly the file system. PDF authoring tools are very sophisticated, but also very expensive used mainly by publication companies. Freeware print drivers available to convert almost anything to PDF. Commercial PDF generators can make good quality, interactive PDF (table of content, indexes, links etc). 16

94 Bilagssamling Side 94 af 379 Research OpenXML, ODF & PDF Data migration Converting any editorial document format to PDF is fairly easy these days. As soon as Microsoft will spread the XPS format (available in the Vista operating system), the convertibility will be an issue between these two formats. The discussion about this point is beyond the domain of this report. 6.2 Potential Potential of growth, may be spread out to other sectors Use Cases Democracy Scenario It s so apparent that electronic documents will be increasingly used between individuals and governments and between companies and governments. Democratic systems cannot allow locking public documents into proprietary formats or being dependent on one specific software vendor. The government cannot push citizens to invest vendor specific applications by using a format with a single vendor. To make sure public information is equally accessible for everyone, the government should not use document format, which requires specific applications to read or use what citizens cannot afford to purchase. Open source or at least free of charge software availability is preferred Business Scenario By using document format which is not vendor locked, the government would be able to choose between open source and different commercial solutions freely. It would lead to good competition between different software vendors, which will reduce the price of the different office suites. This price will be significantly lower than the premium price the government pays today. By using open source technology, the government would be able to save huge amount of money in long term what was earlier spent on licenses, even changing the technical platform and train people is expensive Technology Scenario Only an open document format can ensure that a document will be readable after hundred years. Computer technology is changing lightning fast, in just a couple of years things can change dramatically. Contrarily with this speed, the government must keep public records in long term, in a readable form. Open Formats are specifications for data file formats based on an underlying open standard, developed by an open community, and affirmed by a standards body; or de facto format standards controlled by other entities that are fully documented and available for public use under perpetual, royalty-free, and nondiscriminatory terms

95 Bilagssamling Side 95 af 379 Research OpenXML, ODF & PDF 7 Specification on document formats 7.1 Readability, presentation, editing Is the format intended to be human readable? Is the format intended to use in editor tools by non-expert users? ODF ODF uses XML syntax. The source format is very complex, not intended for the end users. However experts can read it directly for debugging, developing purposes. Using editor tools, non-expert users can work with it in a convenient way OpenXML OpenXML documents are native XML documents also, like ODF. The OpenXML markup is not a mixed content markup (as for example ODF is), which makes human readability worse. The markup syntax is hidden from the end users. They get a user friendly WYSIWYG 22 editor PDF PDF s source format is not a human readable. It uses proprietary syntax, embedding other formats, like XML, RDF, JavaScript etc. PDF is not intended to be used as an editorial format. It does not recognize paragraphs, indentations, formatting, headers, and footers. Expert users can add links or do small text changes in PDF. For non-expert users it s recommended to use a (any) word processor and publish the content to PDF when it s done. 7.2 Exchange and integration Is the format intended to be used as an exchange format from machine to machine? We can generally say, all these three formats can be used as an exchange format, however all of them have different advantages, disadvantages. Let s check these out ODF Pros: Compact many content (XML) and multimedia files are packaged (by zip) into a single document Small document size zip compressed Editors are available on most platforms free, high quality editors Free viewers on most platforms Well-known syntax easy to transform 18

96 Bilagssamling Side 96 af 379 Research OpenXML, ODF & PDF Built-in right management Cons: Editors are not yet widely used Viewers are not yet mature OpenXML Pros: Compact packed using the Open Packaging Conventions Small zip archive Microsoft Office 2007 will most likely be widely used Well-known syntax easy to transform Built-in right management Cons: Editors are not available on most platforms (only Windows and Mac will follow it soon) Free viewers are not available Some features are only available on Windows platform (for example: embedded OLE, VBA) PDF Pros: Compact both text, multimedia and even fonts can be embedded Small documents can be compressed Free, sophisticated viewers are available on all platforms Faithfully preserves page layout Built-in right management Cons: Structure is not preserved, only layout Further editing is very limited Page optimized documents are difficult to render on smaller devices (like PDA) 7.3 Support of other standards Does the format support/use other standards? ODF ODF is built using of these standards: 19

97 Bilagssamling Side 97 af 379 Research OpenXML, ODF & PDF Standard organization Description XML W3C Extensible markup language RelaxNG OASIS, ISO REgular LAnguage for XML Next Generation XLink W3C Linking standard XSL, XSL-FO W3C extensible Stylesheet Language XForms W3C Web forms SVG W3C Scalable Vector Graphics SMIL 2.0 W3C Synchronized Multimedia Integration Language DublinCore NISO Metadata element set, uses RDF (Resource Description Framework) MathML W3C Mathematical Markup Language OpenXML standard organization description XML W3C Extensible markup language W3C XML Schema W3C XML Schema language RelaxNG OASIS, ISO REgular LAnguage for XML Next Generation an alternative way defining the structure DublinCore NISO Metadata element set, uses RDF (Resource Description Framework) OpenXML uses Vector Markup Language (VML) to produce vector graphics. VML was submitted as a proposed standard to the W3C in 1998 by Microsoft, Macromedia, and others. VML was rejected as a web standard because Adobe, Sun, and others submitted a competing proposal known as PGML. The two standards were joined and improved upon to create SVG PDF standard organization description XMP 24 Adobe PDF may contain metadata streams described as XMP. XMP is based on DublinCore 25 (RDF 26, XML, ) JPEG, JPEG2000 ISO, ITU-T Compression of color and grayscale images. JBIG2 ISO, ITU-T compression of monochrome images 20

98 Bilagssamling Side 98 af 379 Research OpenXML, ODF & PDF SVG W3C Scalable Vector Graphics 7.4 How applicable is the standard for other standards? Does the format/standard comply with the most widely known and accepted norms of quality when it is in use by other standards? I.e. XSLT is often used to transform XML based formats to other formats ODF ODF is built on using many well known standards. It makes possible to build applications which reuse existing modules, libraries implement these built-in standards. ODF is XML and XML Namespace aware, so it s possible to parse, validate and serialize with proven XML tools on any platform. XSLT suits well to transform the content. XSL-FO can be used to generate a PDF representation. ODF uses zip for packaging the XML fragments OpenXML OpenXML is an XML markup with namespace support. Because of this fact, it has the same processing benefits as described above related to ODF. The ODF Converter, which is a plugin (under development) for Microsoft Office 2007 is able to open and save ODF documents, implemented using XSLT technology. An OpenXML document can store information about an XSL Transformation which might be applied on save. OpenXML defines the Open Packaging Conventions. It s a set of XML files, packed as a zip document. Beyond XML, OpenXML does not use many other open standards, but instead implements features from scratch PDF PDF is built in a proprietary fashion from the bottom, using unique syntax and structure, so PDF processors has to be special also. However it can embed objects defined by other standards, like XML fragments Metadata descriptor RDF (XML) JavaScript Pictures Fonts 7.5 Document types Does the format support the most known document types? Which ones? (I.e. presentations, spread sheets etc.) 21

99 Bilagssamling Side 99 af 379 Research OpenXML, ODF & PDF ODF Yes, ODF covers all the most common document types. Defined ones: Text Drawing Presentation Spreadsheet Chart Image OpenXML OpenXML implements the same set of document types what ODF does (see above). It uses the next markup languages to implement these types: WordProcessingML SpreadsheetML PresentationML DrawingML VML PDF PDF does not define document types. It s not an editorial, but a page oriented representation format. Content elements: Text Vector graphics Raster graphics 7.6 Support user annotation Does the format allow a user to utilize its own annotation of the document structure? ODF The ODF standard defines annotation functionality. An annotation can contain text paragraphs, lists an it has metadata like creator, creation time etc. The user can also create notes, which are numbered annotations, like footnotes. ODF has review function, it can record and display changes. For technical details, read sections 12.1 & 5.3 of the standard. 22

100 Bilagssamling Side 100 af 379 Research OpenXML, ODF & PDF OpenXML OpenXML allows 3 different types of annotations: Inline: bound to a specific text location. Cross structure: they may span parts of multiple paragraphs. Property: annotation is stored as a property on an object, like paragraphs, table rows etc. Comments are cross structure annotations, which are anchored to a region of document content, but the text of the comments is stored in a separate comments part of the document package. Read the standard text, section PDF The PDF specification says: a PDF document can contain interactive elements that are possible only in an electronic representation. PDF supports annotations of many kinds for such things as text notes, hypertext links, markup, file attachments, sounds, and movies. A document can define its own user interface; keyboard and mouse input can trigger actions that are specified by PDF objects. The document can contain interactive form fields to be filled in by the user, and can export the values of these fields to or import them from other applications. If these functions have been rights-enabled by the PDF author, the user can annotate the document using the freeware Adobe Reader for example. 7.7 Documentation and specification Is the format well documented and the specification well structured and understandable? ODF OASIS ODF v1.0 standard: The specification is well structured, understandable and available for the public. A short description at Wikipedia: OpenXML Ecma Office Open XML File Formats Standard - Final draft - 9th of October 2006: The standard is modular, split to well defined parts as: 23

101 Bilagssamling Side 101 af 379 Research OpenXML, ODF & PDF 1. Fundamentals 2. Open packaging conventions 3. Primer 4. Markup language reference 5. Markup compatibility and extensibility All together it s about 6000 pages, complex, but well-constructed and understandable PDF The PDF specification is publicly available here: It s a huge document, more than 1200 pages. It requires quite a huge effort to study, but it s extremely well structured, clearly expressed and understandable. 7.8 Technical references Are there other technical references and articles available on the format? What and where? ODF This Wikipedia article can be used as a starting point: Online community site: Why ODF? - The Importance of OpenDocument Format for Governments: Open-standards solutions White Paper: Emerging business value of OpenDocument format v1.0, IBM, January 2006.: Is ODF an Open Standard?: OpenXML Again, Wikipedia is good to start with: Ecma Office Open XML Formats overview: 24

102 Bilagssamling Side 102 af 379 Research OpenXML, ODF & PDF Ecma International standardization of OpenXML file formats frequently asked questions: Technical forum: PDF An excellent introduction of PDF is given by the PDF primer white paper: Wikipedia has an article with many good references: Adoption and/or support of other document formats Does the format support other standards for document formats? Which ones? This section is about if the standards are maintaining interoperability with other standards, previous versions or ancestor of the standard. It s not about if the standard makes use of or built on top of other standards. That s already covered in section ODF The ODF standard is used the OpenOffice.org format as a starting point, but it had the primary aim to develop an application and platform independent document format. It targeted to cover all the functionality demanded by the whole community (including also Microsoft Office users). ODF does not support the OpenOffice.org format as standard. Of course end users get the application level support for this legacy format. OpenOffice users can load and save documents using this format, but ODF is the default format for the application OpenXML OpenXML is the direct descendant of the Office XML 2003 which was used in Microsoft Office 2003, however Microsoft decided not to support this previous format. OpenXML has the aim to be 100% compatible with the old proprietary binary document format, to enable lossless conversion between them. Certainly OpenXML is not backward compatible with the binary format, since for example they use different syntaxes, but on the functional level, yes it s backward compatible PDF PDF does not support other document formats, except it maintains a certain level of compatibility with its older versions. Please refer to appendix H.2 of the standard about feature compatibility between different versions. 25

103 Bilagssamling Side 103 af 379 Research OpenXML, ODF & PDF 7.10 Application support Status of the product: Work has started. Has important limitations. Generally works, but there are missing features. Works well even on complex documents. Perfect support ODF The web resource Application support for the OpenDocument format 27 is used from the OpenDocument Fellowship. Only applications using ODF as native format are listed Viewer Application Status Used in the public sector Export Platform Comments Fellowship ODF Viewer 28 TextMaker ODF viewer 29 No - Windows, Linux, Mac No - Windows Supports other formats as well: Microsoft Word, TextMaker, OpenOffice.org (sxw), RTF, Pocket Word, Pocket Word, HTML, text Firefox ODF - Windows, plugin 30 Linux, Mac Visioo - Windows, Linux Writer Editor Application Status Used in the public sector Import Export Platform Comments, advantages OpenOffice. org 32 Attracts more and more users PDF, LaTex Windows, Linux, Mac ODF is the native format since version 2.0. StarOffice 33 Yes 34 Windows, Linux Based on OpenOffice.org 26

104 Bilagssamling Side 104 af 379 Research OpenXML, ODF & PDF KOffice 35 Linux, Unix KOffice is not derived from the OpenOffice.org code base. Workplace 36 Mobile Office Windows, Linux Symbian Based on OpenOffice.org, OpenDocument support is developed independently. Writely 37 No Windows, Linux, Mac Web based editor. Files size is limited to 500KB. Does not support OpenDocument Text Template format Conversion tool Application Status Format Platform Comments ODF Tools 38 Ods, odt, xhtml Linux Reusable XSLTs. 3BOpenDoc 39 ODF, Microsoft Office (doc, xls, ppt), SWX, PDF, Secure PDF, RTF, Text, HTML, PNG and JPEG, FLASH Windows, Linux Server based solution, can be integrated into intranets. Docvert 40 MS Word, ODF, DocBook, HTML, WMF, SVG Windows, Linux Only converts text documents. Xena 41 Microsoft Office documents Any (Java) OpenXML Viewer As it s today, there is no OpenXML (docx) viewer available. Microsoft used to make freeware viewers 42 available for Word, Excel, PowerPoint and Visio. Word Viewer is not able to open docx files. 27

105 Bilagssamling Side 105 af 379 Research OpenXML, ODF & PDF Editor Application Status Used in the public sector Import/ Export Platform Comments, advantages Microsoft Yes Html, Rtf, Office WordPerfect, Works, PDF (via plugin), XPS 45 (via plugin) Windows, Mac version is expected around sept OpenXML is the native format. Gnumeric 46 Applix, DIF, Excel, Html, LaTex, Lotus 1-2-3, MultiPlan, GNU Oleo, OpenDocument, OpenOffice.org 1.x, Quattro Pro, SpreadsheetML, Xspread and Xbase Linux, Windows Spreadsheet application OpenOffice.org already supports the predecessor of the OpenXML word processing format namely WordProcessingML Corel has already indicated its Wordperfect Office suite will also support OpenXML Conversion tool Application Status Format Platform Comments 2007 Microsoft Office Add-in: Save as PDF or XPS PDF, XPS Windows Because of legal issues, Microsoft Office 2007 cannot publish natively to PDF 48. Microsoft Office 2007 compatibility pack Pre release docx Windows Open, edit, save, and create files in OpenXML (docx) file formats in Microsoft Office 2000, Office XP, and Office ODF ODF Windows Add-in to Microsoft Word 2007 to allow opening Converter 49 and saving OpenDocument format (ODF) files. Microsoft finances an open-source (BSD license) project on sourceforge.net to create a plugin for MS Office. The project plans to release the first version by end of 2006 for Microsoft Word. Support for Microsoft Excel and Microsoft PowerPoint will be added in Be aware! There are OpenXML features which are not supported by ODF and visa versa. The conversion can loose information. 28

106 Bilagssamling Side 106 af 379 Research OpenXML, ODF & PDF PDF Viewer PDF viewers are available for almost all operating system for free of charge. PDF interpreters are ported to many platforms. Many different GUIs are available using the same backend. The software list below is far not complete, but contains the most important applications. Application Status Used in the public sector Export Platform Comments Adobe Reader 50 Yes text Windows, Linux, Mac, Plam, Pocekt PC, Symbian Foxit Reader 51 text Windows, Windows Mobile, Windows CE, Embedded Linux Feature rich, many plugins. Very fast and small. Brava Jpeg Windows Views also TIFF & CSF. Reader 52 Only page thumbnails, but no table of content. Evince 53 Linux GNOME Fast, easy navigation, effective search. GSView 54 Windows, OS/2, Linux Based on GhostScript. No bookmarks available. GhostView 55 Unix/X11 Based on GhostScript Xpdf 56 PDF+ 57 Browser plugin Unix/Linux, BEOS, RISC OS, Palm OS Symbian OS Firefox, Internet Explorer... Weak graphical user interface Print drivers Using a PDF print driver is the easiest way to generate a PDF document from any document viewer/editor with print capability. 29

107 Bilagssamling Side 107 af 379 Research OpenXML, ODF & PDF Application Status Platform Comments Adobe Distiller 58 Windows, Unix, Sun Solaris Replaced by Adobe Lifecycle PDF Generator 59. PDFCreator 60 Windows Does not generate interactive PDF. PrimoPDF 61 Windows CUPS 62 Linux/Unix Common UNIX Print System Mac Preview 63 Mac OS Available from all document viewers. JAWS PDF Windows, Mac Creates interactive PDF (TOC, links ), creator 64 optimizes to print or web Editor PDF is not and editorial but rather a representation format. It does not have a concept for paragraph, formatting, headers, footers, indentations, line-breaks, etc. It cannot be authored via normal word processing. However it can be manipulated many ways, like merging, splitting documents, encrypt, decrypt, adding indexes, maintaining bookmarks etc. Application Status Used in the public sector Export Platform Comments, advantages Adobe Yes HTML, XML, Acrobat 65 text, EPS, MS Word Windows, Mac OS Adobe Acrobat is not an authoring application. 66 NITRO PDF 67 Yes MS Word Windows Fast document processing. JAWS PDF Yes Windows Editor 68 ScanSoft PDFConverter 69 MS Office, WordPerfect Windows Text-to-Speech Capability PDFFactory 70 Windows VeryPDF PDF Image file Windows Editor 71 PDFMeld 72 pdftk 73 Windows, Linux, FreeBSD, MAC, AIX, HP-UX, SCO SV, Sun Solaris Windows, Linux, Max, Solaris, FreeBSD Free software (GPL) 30

108 Bilagssamling Side 108 af 379 Research OpenXML, ODF & PDF Conversion tool As mentioned above PDF does not recognize paragraphs, headers, footers etc, which makes very difficult to turn a PDF document to a word processing format. Doing it so is not problem free. Application Status Format Platform Comments GhostScript 74 Windows, Mac, Linux, OS/2 Postscript & PDF interpreter. LIT PDF2everything 75 PowerPoint, PS, EPS, BMP, PNG, TIF, JPEG, PCX Windows Based on GhostScript. VeryPDF conversion tools 76 Word, text, HTML, Windows 8 Law and rights 8.1 What license related rights are affiliated with the standard? ODF From the OASIS ODF FAQ 77 : OpenDocument is royalty-free. It can be used without charge by anyone. The OpenDocument format is owned by OASIS, a non-profit consortium dedicated to the open development of public XML standards. The standard is maintained by the OASIS OpenDocument Technical Committee, which is made up of XML, document management, and office application experts OpenXML OpenXML is an open standard. No license is needed to use the OpenXML format. It can be freely implemented by multiple applications on multiple platforms. It also permits open source implementation. From the paper Ecma International standardization of OpenXML file formats frequently asked questions 78 : intellectual property in the OpenXML document formats would be available freely, now and forever We eliminated the license to patents language and are instead providing an irrevocable commitment to not sue anyone based on the patents we have in the formats. If any parties prefer, we will make available the existing open and royalty free license as an alternative. Anyone is free to work with a subset of the specifications, and anyone is free to create extensions to the specifications The key is that this is an assurance that no one will be sued for using intellectual property in the specifications as they are written. 31

109 Bilagssamling Side 109 af 379 Research OpenXML, ODF & PDF In other words, Microsoft applies the 'Covenant Not to Sue' (CNS) approach for the license. Further readings: Top open source lawyer blesses new terms on Microsoft s XML file format: Brian Jones blog about Open XML Formats: PDF Adobe has copyright on the PDF standard. Adobe gives permission to anyone to create PDF files, write print drivers, software which interprets the content. The author of such software must respect the access permissions described by the format and must include an appropriate copyright notice. See the section 1.5 of the standard for details. 8.2 Are rights other than those related to licensing affiliated with the standard? Which? We also have to check if the standards are bound to specific platforms or proprietary technologies ODF ODF is built on top of well known, widely used open standards. It does not re-invent the wheel, which makes it more transparent and easier to use for developers. It does not use proprietary technology and completely open OpenXML OpenXML uses Microsoft s technology, like ActiveX 79 (OLE) or Visual Basic for Applications 80 (VBA) which are bound to the Windows platform. VBA is proprietary to Microsoft and is not an open standard PDF PDF might refer to fonts which are not free of charge or not available on every platform. 32

110 Bilagssamling Side 110 af 379 Research OpenXML, ODF & PDF 9 References 1 ODF OpenXML OASIS who Ecma memento Ecma By laws Ecma Rules Ecma Code of Conduct in Patent Matters Participants in the ODF standardization How to join ECMA OASIS lists Purpose of the OASIS ODF TC The purpose of Ecma TC PDF Language and Specification forum Adobe PDF Technology Center ODF Test Suite Opendocument-sample list PostScript XPS XPS specification OpenOffice language support Open format comments WYSIWYG VML XMP DublinCore Resource Definition Framework Application support for the OpenDocument format ODF Viewer TextMaker ODF viewer Firefox ODF plugin Visioo Writer OpenOffice

111 Bilagssamling Side 111 af 379 Research OpenXML, ODF & PDF 33 StarOffice The Adoption of and Migration to, OpenDocument in the Public Sector 35 KOffice Workplace Writely ODF Tools BOpenDoc Docvert Xena Microsoft Office viewers Word Viewer d ab826e7b8fdf&DisplayLang=en 44 Microsoft Office XML Paper Specification (XPS) Gnumeric OpenXML market adoption MS Office & PDF legal issues ODF converter Adobe Reader Foxit Reader Brava Reader Evince GSView GhostView Xpdf PDF Adobe Distiller Adobe Lifecycle PDF Generatror PDFCreator PrimoPDF CUPS Mac Preview JAWS PDF creator Adobe Acrobat

112 Bilagssamling Side 112 af 379 Research OpenXML, ODF & PDF 66 Adobe Acrobat help What is the best way to create a PDF? A721.html 67 NITRO PDF JAWS PDF Editor ScanSoft PDFConverter PDFFactory VeryPDF PDF Editor PDFMeld pdftk GhostScript LIT PDF2everything VeryPDF conversion tools OASIS ODF FAQ Ecma OpenXMl FAQ: 79 ActiveX VBA

113 Bilagssamling Side 113 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag I

114 Notat Bilagssamling Side 114 af 379 Dette dokument indeholder: Notat om implementering af åbne dokumentformater Samt følgende bilag hertil: 1. Opsummerende rapport fra pilotforsøg 2. Opsummerende rapport fra labforsøg 3. Beskrivelse af funktionalitetsloftet Implementering af åbne dokumentformater hos offentlige myndigheder IT- og Telestyrelsens anbefalinger på grundlag af pilotforsøg og laboratorietest 1 Indledning Dette dokument giver et overblik over IT- og Telestyrelsens anbefalinger til offentlige myndigheders efterlevelse af Folketingets beslutning om åbne standarder for software 1 med fokus på de åbne dokumentformater, OOXML og ODF. 26. november 2007 IT- og Telestyrelsen Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Kravene pr. 1. januar 2008 for alle myndigheder er, at myndigheden skal kunne modtage dokumenter i begge åbne formater, men ikke nødvendigvis selv arbejde med sådanne formater 2. Idet der er begrænset erfaring med brug af de to formater, har IT- og Telestyrelsen i 2007 gennemført en omfattende vidensindsamling og pilotforsøg/ laboratorietest, herunder en omfattende afprøvning af mulighederne for at håndtere modtagne dokumenter i de to åbne dokumentformater. Resultaterne af dette arbejde har givet den erfaringsmæssige baggrund for styrelsens vejledning af myndighederne ift. de åbne dokumentformater. Dette notat opsummerer de væsentligste vejledningsrelevante konklusioner fra pilotforsøg og laboratorieforsøg../. Opsamlende afrapportering fra pilotforsøg og laboratorietest er vedlagt som bilag 1 og 2 til dette dokument. De vejledningsrelevante konklusioner vil være omdrejningspunktet for IT- og Telestyrelsens videre vejledning af offentlige myndigheder. Denne vejledning er i 1 Folketingets beslutning B103 om anvendelse af åbne standarder for software i det offentlige af 2. juni I tilfælde af, at der indkøbes løsninger af myndigheden efter 1. januar 2008 skal løsningen skal understøtte mindst en af disse.

115 Bilagssamling Side 115 af 379 produktion og forventes publiceret ultimo november på 2 Pilotforsøg og laboratorietest IT- og Telestyrelsen har i 2007 bistået af Devoteam Consulting gennemført en række pilotforsøg i samarbejde med myndigheder på tværs af stat, regioner og kommuner. Pilotforsøgene har omfattet: Direktoratet for FødevareErhverv, Gribskov Kommune, Region Midtjylland, Statens Arkiver, Århus Kommune. Pilotforsøgene har haft til formål at kortlægge de udfordringer, som myndighederne i en faktisk driftssituation kan møde ved at skulle håndtere de to standarder for åbne dokumentformater. Målet har endvidere været at skabe grundlag for praktisk vejledning af alle offentlige myndigheder i forhold til efterlevelse af beslutningen om de åbne dokumentformater. IT- og Telestyrelsen Side 2 af 6 Fokus har været på de formatrelevante funktionaliteter, der er de mest benyttede i en dansk forvaltningsmæssig kontekst. Dette sæt funktionaliteter er defineret som funktionalitetsloftet 3, jf. også bilag 3. Ud over pilotforsøgene er der gennemført en laboratorietest (strukturerede afprøvninger af konverteringer i kontrollerede testmiljøer) baseret på observationer fra pilotforsøgene. Laboratorietesten er udført i samarbejde med leverandørerne Ciber, IBM, Magenta, Microsoft og Novell. Laboratorietesten er udført hos Sogeti. Det har været af afgørende betydning, at myndigheder og leverandører har stillet sig til rådighed for og været engageret i pilotforsøg og laboratorietest. Leverandørernes villighed til i laboratoriet at arbejde videre med pilotforsøgenes resultater med henblik på at afhjælpe en række af de konstaterede problemstillinger har været meget positivt og tegner lovende for mulighederne for den fremtidige praktiske interoperabilitet mellem især de åbne dokumentformater. Der er i pilotforsøgene og laboratorietesten anvendt en række tekstbehandlingsapplikationer, som understøtter en af de to standarder for åbne dokumentformater, samt Microsoft Word Herudover er afprøvet en række convertere. 3 IT- og Telestyrelsen har til pilotforsøg og laboratorietests udarbejdet en bruttoliste over områder af anvendte formatrelevante funktionaliteter og herudfra defineret et funktionalitetsloft. Dette er et sæt formatrelevante funktionaliteter, som er indkredset i et samarbejde med offentlige myndigheder og leverandører, og er bl.a. drøftet i ITarkitekturkomitéen og Datastandardiseringskomitéen. Funktionalitetsloftet har defineret omfanget af, hvad der er væsentligt at se på, når samspillet mellem tekstbehandlingsdokumentformaterne er undersøgt i projektet.

116 Bilagssamling Side 116 af 379 Pilotforsøg og laboratorietest er begge gennemført efter en detaljeret og dokumenteret metode, og alle resultater er fuldt dokumenteret både i forhold til testresultat og anvendt konfiguration mv. Det betyder, at alle tests kan gentages på et senere tidspunkt. Det være sig med de originale konfigurationer eller med modificerede konfigurationer, f.eks. med nye versioner af convertere og programmer. Det vil således eksempelvis være muligt på et senere tidspunkt at undersøge om nye convertere og programmer skaber bedre mulighed for praktisk interoperabilitet mellem de åbne dokumentformater. 3 Vejledningsrelevante konklusioner På baggrund af vidensindsamling, pilotforsøg og laboratorietest har IT- og Telestyrelsen draget følgende vejledningsrelevante hovedkonklusioner: De eksisterende convertere er ikke altid tilstrækkelige til, at man som myndighed kan basere sig udelukkende på convertere IT- og Telestyrelsen Side 3 af 6 Pilotforsøgene viser, at myndighederne kan komme langt med anvendelsen af convertere. Konvertering ved hjælp af convertere foregår endvidere hurtigt og uden mærkbar ventetid for brugeren. Simple dokumenter konverteres uden væsentlige problemer på tværs af programmer, formater og operativsystemer. Men jo mere komplekse dokumenterne bliver, jo større udfordringer er der ved konverteringen. Generelt kan det konstateres, at der i forbindelse med konvertering er observeret varierende former for informations- og datatab alt efter de scenarier, der er gennemført. Inden for funktionalitetsloftet er der i varierende grad risiko for, at konverteringen gennemføres med et resultat, der visuelt afviger fra udgangspunktet på nedenstående punkter, Billeder forsvinder OLE-objekter forsvinder Tegninger forsvinder Tekstbokse forsvinder Problemer ved skifte mellem sprogversioner af værktøj Forankringer flytter sig Problemer med bl.a. indholdsfortegnelser i forbindelse med sektions- og kapitelopdelinger Problemer ved forskellig layout på første side hhv. efterfølgende sider Problemer vedrørende sidehoved og -fod Tekst forskubber sig (linjeafstand og tekstfonte) Punktopstillinger I laboratorietesten blev der iagttaget varierende grad af konverteringsmodenhed på tværs af convertere og dokumenter og det samlede billede af converterne er, at converterne generelt har potentiale for forbedring af modenheden.

117 Bilagssamling Side 117 af 379 Det er dog væsentligt at fremhæve, at konverteringens modenhed nøje hænger sammen med det enkelte converterscenarie 4, jf. nedenstående figur. IT- og Telestyrelsen Eksempelvis går konverteringer inden for funktionalitetsloftet i vid udstrækning godt indbyrdes mellem formaterne OOXML og DOC 5, og kan som oftest fungere fra DOC til ODF. Fra ODF til DOC er der generelt nogle udfordringer med konvertering. Endvidere vil en indbyrdes konvertering mellem formaterne ODF og OOXML rumme udfordringer. Side 4 af 6 Det giver umiddelbart det bedste resultat, såfremt myndigheden indlæser et modtaget dokument i et tekstbehandlingsprogram, som direkte understøtter dokumentets format. Derfor vil den af IT- og Telestyrelsen til myndighederne anbefalede tekniske løsningsmodel bestå af en converterløsning suppleret med en strategisk anvendelse/udrulning af en supplerende tekstbehandlingsapplikation. Denne anbefalede tekniske løsningsmodel skal så kombineres med en hensigtsmæssig og effektiv arbejdsproces. Særligt anbefales det, at myndigheden ikke alene baserer sig på konvertering af dokumenter ved hjælp af convertere, men altid sikrer sig muligheden for at kunne validere resultatet af en konvertering mod det originale dokument. Det er anbefales således, at myndigheden ikke mindst af hensyn til arkiv- og dokumentationspligten har en kvalitetssikringsprocedure ved konvertering. For nogle dokumenter, herunder dokumenter af juridisk gyldighed, er det afgørende, at det konverterede elektroniske dokument har den samme bevisværdi som det originale elektroniske dokument, og myndighederne skal derfor overveje at gemme originaldokumentet ved modtagelsen samt overveje, hvordan det 4 Der er naturligvis enkelte variationer i kvaliteten mellem de enkelte convertere, men billedet er ret konsistent på tværs af teknologierne. 5 DOC er ikke et åbent dokumentformat. Formatet er et proprietært format og anvendes i tidligere versioner af Microsoft Word (frem til og med Microsoft Word 2003). Formatet har frem til nu været en de facto-standard i det offentlige.

118 Bilagssamling Side 118 af 379 konverterede dokuments kvalitet sikres, eventuelt gennem en sammenligning med originalen. Mulighed for aflevering til Statens Arkiver er også undersøgt i forbindelse med projektet, og der er i den forbindelse ikke identificeret væsentlige udfordringer, som ligger ud over, hvad myndighederne kender i dag eksempelvis ved konvertering fra DOC-formatet til aflevering i TIF-formatet.. Convertermodenheden forbedres løbende IT- og Telestyrelsen vurderer på baggrund af laboratorietesten, at de konstaterede konverteringsudfordringer inden for funktionalitetsloftet ved konvertering vedrørende ODF, OOXML og DOC kan henføres til relativt få bagvedliggende tekniske udfordringer, jf. også ovenfor. Disse udfordringer vil med rimelig sandsynlighed i stort omfang kunne afhjælpes i takt med, at kvaliteten af convertersoftwaren forbedres. IT- og Telestyrelsen Side 5 af 6 Begge åbne dokumentformater er relativt nye, og interoperabilitet mellem de to formater er et helt nyt område. Udviklingen af convertere mellem formaterne har været i gang i cirka et år, og da de komplette specifikationer for hhv. OOXML og ODF er omfattende, er det forventeligt, at converterne på tidspunktet for pilot- og laboratorieforsøgene har udvist en begrænset evne til fuld konvertering af dokumenter. IT- og Telestyrelsen vurderer, at produkterne til konvertering fortsat har et stort udviklingspotentiale, og har allerede i perioden for analyse og forsøg konstateret en løbende og positiv udvikling af converterne. Situationen i dag er ikke ulig den situation, myndigheder tidligere har befundet sig i, når der er sket skift i dokumentformater, eller hvor myndighederne har set et behov for at kunne læse indkommende dokumenter i fremmede formater. Som i de tidligere tilfælde arbejder tiden for, at udfordringer reduceres i takt med den teknologiske udvikling. IT- og Telestyrelsen vil derfor anbefale, at myndigheden løbende følger converterudviklingen, idet der selv inden for en kort tidshorisont kan ske markante forbedringer i converternes kvalitet gennem frigivelsen af nye versioner. Erfaringerne fra projektets pilot- og laboratorieforsøg har været, at leverandørerne gerne vil løse de tekniske udfordringer for myndighederne. Derfor anbefales det, at offentlige myndigheder indrapporterer konstaterede fejl og uhensigtsmæssigheder ved de af myndigheden anvendte convertere til leverandørerne. IT- og Telestyrelsen har udarbejdet en converterkortlægning, som kan tilgås på Kortlægningen er foretaget i maj 2007 og vil blive opdateret ultimo november 2007.

119 Bilagssamling Side 119 af 379 Styrelsen vil i 2008 følge converterudviklingen nøje, herunder medio 2008 publicere en ajourført converterkortlægning til brug for myndighederne. IT- og Telestyrelsen vil endvidere i vejledningen til offentlige myndigheder formulere konkrete anbefalinger for, hvordan konverteringsproblemer ift. de eksisterende convertere reduceres mest muligt. Dette vil ske gennem en vejledning i, hvordan myndighederne bedst kan formatere udgående dokumenter, således at disse kan konverteres af modtageren med mindst muligt tab af indhold. Endelig vil IT- og Telestyrelsen løbende søge at inddrage relevante udenlandske erfaringer med praktisk håndtering af de åbne dokumentformater. Dette vil bl.a. ske i regi af EU-organet PEGSCOs igangsatte undersøgelse ODEF (Open Document Exchange Formats) af sameksistensen mellem de to dokumentformater ODF og OOXML. ODEF forventes at få stort overlap med de i Danmark gennemførte pilotforsøg og laboratorietest. IT- og Telestyrelsen ODEF forventes i 2008 bl.a. at tilvejebringe Retningslinjer for interoperabilitet Værktøj for kontrol af interoperabilitet Vejledninger for design af og indhold i oversættelsesbare dokumenter. Side 6 af 6 4 Egen parathed og leverandørparathed Myndighederne anbefales at undersøge deres egen organisatoriske og tekniske parathed. På baggrund af erfaringerne fra pilotforsøg og laboratorietest, har IT- og Telestyrelsen den 21. november 2007 publiceret en Test-selv-pakke. Pakken indeholder forskellige eksempeldokumenter i ODF og OOXML samt en vejledning i hvordan myndigheden tester modtagelsen af disse mv. Med pakken kan myndighederne teste konvertering og læsning af åbne dokumentformater i eget itmiljø. Myndighederne anbefales endvidere at undersøge deres leverandørers parathed til at håndtere de åbne dokumentformater. IT- og Telestyrelsen har indhentet leverandørers selvvurdering af deres parathed og har 22. november 2007 publiceret en oversigt over 14 leverandørers egen angivelse af parathed. Eksempelvis er der publiceret oplysninger om ESDHleverandørernes parathed og om centrale KMD-systemer på førnævnte hjemmeside ( rnes-parathed).

120 Bilagssamling Side 120 af 379 Bilag 1 Devoteam Consulting A/S Tuborg Parkvej 10 DK-2900 Hellerup Copenhagen, Denmark Tel Fax info@devoteam.dk Konsolideret testrapport for pilotforsøg om åbne dokumentstandarder -november 2007 Indhold Indledning Hovedkonklusioner og observationer Convertere er ikke altid tilstrækkelige Forskel på convertermodenhed Piloter og metode Testscenarier Metode Hvad går typisk godt? Udfordringer og mulige løsningsmodeller for myndigheder der benytter DOC som produktionsformat Modtagelse og læsning af ODF dokumenter Hvordan står I generelt ved modtagelse af ODF? Eksempler på udfordringer ved modtagelse af ODF Eksempler på løsninger og forudsætninger Modtagelse og læsning af OOXML dokumenter Hvordan står I generelt ved modtagelse af OOXML? Eksempler på udfordringer ved modtagelse af OOXML Eksempler på løsninger og forudsætninger ved modtagelse af OOXML Udfordringer og mulige løsningsmodeller for myndigheder der benytter ODF som produktionsformat Hvordan står I generelt ved modtagelse af OOXML? Eksempler på udfordringer ved modtagelse af OOXML Eksempler på løsninger og forudsætninger ved modtagelse af OOXML...12 CONNECTING BUSINESS & TECHNOLOGY #66221-v4-Konsolideret testrapport_pilotforsøg VAT N DK PBS: Bank: Danske Bank, Branch N 4260, Account N

121 Bilagssamling Side 121 af Udfordringer og mulige løsningsmodeller for myndigheder der benytter OOXML som produktionsformat Hvordan står I generelt ved modtagelse af ODF? Eksempler på udfordringer ved modtagelse af ODF Eksempler på løsninger og forudsætninger ved modtagelse af ODF Overvejelser ifm. nyanskaffelser Myndighed der overvejer løsning med ODF som produktionsformat Myndighed der overvejer løsning med OOXML som produktionsformat Opsummerende anbefalinger Beslut jer for et funktionalitetsloft Tilpasning af dokumentskabeloner med udgangspunkt i funktionalitetsloftet Undgå gentagne konverteringer Vælg PDF til udveksling af ikke redigerbare dokumenter Vurder hvilke dokumenter, I vil lave kvalitetscheck på efter konvertering Indfør tjekrutiner for udvalgte dokumenter Installere en kontorpakke eller viewer, som understøtter det pågældende format Overvej harmonisering af sprogversioner Følg med i udviklingen Indrapporter jeres tekniske udfordringer til leverandørerne...20 CONNECTING BUSINESS & TECHNOL

122 Bilagssamling Side 122 af Indledning Dette notat opsummerer de erfaringer der er opnået i forbindelse med afvikling af pilotforsøg vedr. åbne dokumentformater Pilotforsøgene er udført som et led i indsamlingen af praktiske erfaringer med åbne dokumentformater med henblik på udformning af en vejledning om, hvordan de åbne dokumentformater ODF og OOXML bedst kan implementeres i offentlige myndigheder fra Konsolideringen har fokus på at vejlede om anvendelse af de åbne dokumentstandarder. For nærmere dokumentation af forudsætninger, konfigurationer og observationer, henvises der til testrapporterne for de enkelte pilotforsøg. Den konsoliderede testrapport er inddelt i afsnit, der forholder sig til den brugssituation en myndighed kan stå i, når de skal kunne modtage og læse dokumenter i de åbne dokumentformater, ODF og OOXML, pr. 1. januar Hovedkonklusioner og observationer I pilotforsøgene er der identificeret en række udfordringer i forbindelse med dokumentkonvertering, som der vil redegøres for i det følgende Convertere er ikke altid tilstrækkelige Generelt kan det konstateres, at der i forbindelse med konvertering er observeret varierende former for informations- og datatab alt efter de scenarier, der er gennemført. Pilotforsøgene har vist eksempler på: - Billeder forsvinder - OLE-objekter forsvinder - Tegninger forsvinder - Tekstbokse forsvinder - Problemer ved skifte mellem sprogversioner af værktøj - Forankringer flytter sig - Problemer med bl.a. indholdsfortegnelser i forbindelse med sektions- og kapitelopdelinger - Problemer ved forskellig layout på første side hhv. efterfølgende sider - Problemer vedrørende sidehoved og -fod - Tekst forskubber sig (linjeafstand og tekstfonte) - Punktopstillinger Det er stor forskel på kvaliteten af konverteringerne alt efter, hvilket scenarie der undersøges, hvilke convertere der anvendes og hvilke formater der er tale om. Det skal understreges, at konvertering i de givne eksempler er ensbetydende med import af dokumenter i et fremmed format i et tekstbehandlingssystem. Konvertering som eksport, er CONNECTING BUSINESS & TECHNOL

123 Bilagssamling Side 123 af 379 dermed ikke undersøgt. Det hænger sammen med, at kravet om at kunne modtage i de åbne dokumentformater er med modtagerkrav, hvilket fordrer konvertering via import. I praksis har pilotforsøgene vist, at de eksisterende convertere ikke altid er tilstrækkelige til, at man som myndighed kan basere sig udelukkende på disse. Derfor vil en relevant teknisk løsningsmodel typisk bestå af en converterløsning, som efter behov kan suppleres med en strategisk anvendelse/udrulning af en supplerende tekstbehandlingsapplikation. Den tekniske løsningsmodel skal så kombineres med en hensigtsmæssig og effektiv arbejdsproces. I nogle scenarier fungerer konverteringerne imidlertid tilfredsstillende (se også 1.1.2). Også aflevering til Statens Arkiver med konvertering til TIFF, er i pilotforsøget sket uden udfordringer. Generelt kan det konstateres, at jo mere komplekse dokumenter jo større udfordringer. Men også simple dokumenter inden for funktionalitetsloftet kan give udfordringer. Den overordnede konklusion på baggrund af pilotforsøgene er derfor, at myndighederne bør vælge en løsningsmodel, som ikke kun er baseret på convertere Forskel på convertermodenhed Nedenfor har vi illustreret den modenhed, som generelt er observeret i brugen af convertere i de forskellige piloters situationer, hvor man som myndighed modtager forskellige dokumentformater 1 : Stigende modenhed Import af DOC til OOXML Import af OOXML til DOC Import af DOC til ODF Import af ODF til DOC Import af ODF til OOXML Import af OOXML til ODF Observationer inden for funktionalitetsloft Konvertering kan fungere med få udfordringer Konvertering kan som oftest fungere Generelt er der nogle udfordringer med konvertering Konvertering- og konverteringsmuligheder er mangelfulde 1 Der er naturligvis enkelte variationer i kvaliteten mellem de enkelte convertere, men billedet er ret konsistent på tværs af teknologierne. CONNECTING BUSINESS & TECHNOL

124 Bilagssamling Side 124 af 379 Som det fremgår af modellen, er der eksempelvis stor forskel på, om man som ODFmyndighed modtager OOXML, eller om man som OOXML-myndighed modtager DOC. Mulighederne for succesfuld konvertering, og dermed også de foranstaltninger og procedurer man som myndighed må definere, varierer derfor alt efter myndighedens teknologianvendelse og behov. 1.2 Piloter og metode 2 Den konsoliderede testrapport er resultatet af en række testforløb, som er gennemført i de følgende myndigheder i perioden juli november 2007: Pilotmyndighed Ansvarlig Direktoratet for FødevareErhverv Jari Bøg jabl@dffe.dk Gribskov Kommune Michel van der Linden mvdli@gribskov.dk Region Midtjylland Henrik Jordt henrik.jordt@stab.rm.dk Statens Arkiver Anders Bo Nielsen abn@ra.sa.dk Århus Kommune Peter Henriksen ph@mag1.aarhus.dk I de fem myndigheder er der gennemført forskellige tests baseret på en række scenarier. Fællesnævneren for de gennemførte testforløb har været at indhente praktiske erfaringer med de udfordringer, der kan opstå ved at konvertere mellem dokumentformaterne ODF og OOXML, jf. modellen nedenfor. Myndighed 1 Myndighed 2 Konvertering Dokument i myndighedens produktionsformat (DOC, ODF eller OOXML) Sendes til myndighed 2 Figur 1: Myndighederne kan anvende de tekstbehandlingsformater de ønsker internt, indtil de nyanskaffer løsning, men fra 1. januar 2008 skal de kunne modtage både OOXML- og ODFtekstbehandlingsdokumenter. 2 En detaljeret gennemgang af projektets metode kan findes her: CONNECTING BUSINESS & TECHNOL

125 Bilagssamling Side 125 af Testscenarier I forbindelse med pilotforsøgene er der opstillet fire scenarier, der tilsammen dækker de væsentligste anvendelsessituationer for udveksling af tekstbehandlingsdokumenter mellem offentlige myndigheder. - Pilotscenarie 1: Udveksling af tekstbehandlingsfiler mellem to myndigheder - Pilotscenarie 2: Samarbejde omkring en tekst på tværs af myndigheder - Pilotscenarie 3: Afleveringsformat til Statens Arkiver - Pilotscenarie 4: Integration mellem kontorpakker og fagsystemer, herunder ESDH Formatsammenspillet i alle ovenstående scenarier er blevet undersøgt via pilotforsøg hos fem pilotmyndigheder. Det har varieret, hvor mange scenarier, der er gennemført i hver pilot, så testforløbet var effektivt og dækkende i sin helhed. Formaterne der har indgået i pilotforsøgene, er: - DOC: binært format for Microsoft Word - ODF: obligatorisk åbent dokumentformat - OOXML: obligatorisk åbent dokumentformat Testforløbet er så vidt muligt sket i myndighedernes egne driftsmiljøer for at skabe en så virkelighedsnær test som muligt. Herudover er der gennemført enkelte paralleltest for at belyse særlige aspekter eksempelvis konvertering på platforme, som ikke har været i drift i pilotmyndighederne. Forskellene mellem de to testmetoder er beskrevet nedenfor Metode Nedenfor er den overordnede metode for gennemførelse af testforløbet gengivet. Pilotforsøg Formål Metode Formålet med pilotforsøg har været at indhente praktiske erfaringer med de udfordringer, der kan opstå ved at konvertere mellem dokumentformaterne Pilotmyndigheden har 1) udvalgt en række dokumenter fra deres forvaltning, der indeholdt de funktioner inden for funktionalitetsloftet, som de vurderede relevante 2) taget udgangspunkt i de(t) tekstbehandlingssystem(er) og de(n) driftsplatform(e), som pilotmyndighederne normalt anvender 3) givet input til de udvalgte testscenarier for at gøre disse så virkelighedsnære som muligt 4) valgt en (eller flere) converter(e), som kan konvertere til og/eller fra de formater, der er relevante for pilotmyndigheden 5) selv forestået arbejdet med konvertering af dokumenterne i forhold til de specificerede testscenarier Myndigheden har således gennemført en række veldefinerede testscenarier, som tilsammen har givet et billede af de udfordringer, der er forbundet med at modtage og læse dokumenter i ODF eller OOXML-format i et tekstbehandlingssystem, men også afledte udfordringer fx i forbindelse med efterfølgende at arbejde videre i dokumentet i tekstbehandlingssystemet, lagre dokumentet i et ESDH-system eller i forbindelse med CONNECTING BUSINESS & TECHNOL

126 Bilagssamling Side 126 af 379 publicering af dokumentet i et CMS-system. Efter konvertering af dokumentet var konverteret fra format A til format B, gennemføres en visuel kontrol af de konkrete funktionaliteter i dokumentet. Derudover gennemføres en generel vurdering. Ved fejl i konverteringen er det blevet afdækket, hvor i processen fejlen er opstået. Nærmere analyse er sket ved research eller gennem paralleltest og laboratorietest, se nedenfor. Paralleltest Formål Metode I de situationer, hvor gennemførelse af pilotforsøg med fordel kunne suppleres med yderligere test, er der gennemført paralleltest. Formålet har været at undersøge fejlkilder og om-teste scenariet med andre teknologier fx med andre convertere. Paralleltestene er gennemført i piloternes egne miljøer. En række parametre kan ændres, således at paralleltesten giver en værdimæssig tilførsel til testen: - Converteren - Testdokumentet - Redigering i testdokument for provokation af isolerede hændelser - Styresystem - Tekstbehandlingsapplikation Ændring af ovennævnte parametre er sket i tæt samarbejde med pilotmyndigheden, da ændringerne er foretaget i myndighedens testmiljø og testgrundlag. Det er pilotmyndigheden, der har taget beslutning om behovet for paralleltest ud fra de testresultater, der forelå efter pilotforsøget. Alle pilotforsøgene er blevet gennemført efter princippet om anvendelse af det funktionalitetsloft, som er udviklet i et bredt myndighedssamarbejde. Funktionalitetsloftet består af de funktioner, som myndighederne har peget på er de vigtigste at få testet, jf. funktionalitetsloftet. Hver pilotmyndighed har udvalgt de for dem mest betydningsfulde af disse funktioner fra funktionalitetsloftet. De observationer som ligger til grund for denne rapport, er derfor udelukkede baseret på disse udvalgte formatrelevante funktionaliteter for hver enkelt myndighed 3. 2 Hvad går typisk godt? De gennemførte pilotforsøg viser, at der er stor forskel på kvaliteten af konverteringerne, alt efter hvad der er testet. Der er imidlertid en række situationer, hvor konverteringerne fungerer tilfredsstillende. Overordnet går det godt, når et OOXML dokument bliver konverteret til DOC og omvendt. Her er Word 2007 bagudkompatibel, og converteren Microsoft Compatibility Pack fungerer tilfredsstillende til Word inden for funktionalitetsloftet. 3 På baggrund af bl.a. piloterne er der udarbejdet et konsolideret funktionalitetsloft, jf. CONNECTING BUSINESS & TECHNOL

127 Bilagssamling Side 127 af 379 Konvertering fra DOC til ODF går i hovedreglen også godt. Der er imidlertid ved denne konvertering nogle begrænsninger, som fremgår nedenfor. Pilotforsøgene viser også, at funktionaliteter som formatering, redigering og sideopsætning generelt konverteres korrekt, når man ser på tværs af de forskellige konverteringskombinationer. Også funktionalitetsområderne sidehoved/sidefod, fodnoter og slutnoter, nummererede lister og punktopstilling, og automatiske indholdsfortegnelser bliver generelt konverteret uden meningsforstyrrende informationstab på tværs af de forskellige konverteringskombinationer, men der kan forekomme visuelle afvigelser i forbindelse med konverteringerne. Med den konfiguration, som Statens Arkiver valgte, viste det sig endvidere, at der ikke er betydeligt flere eller færre problemer ved konvertering fra åbne tekstbehandlingsdokumentformater til afleveringsformat for tekstdokumenter (TIFF), end der er ved konvertering fra lukkede tekstbehandlingsdokumentformater til afleveringsformat for tekstdokumenter (TIFF).. 3 Udfordringer og mulige løsningsmodeller for myndigheder der benytter DOC som produktionsformat En myndighed, der benytter DOC-formatet som produktionsformat, skal pr. 1. januar 2008, både kunne modtage og læse ODF og OOXML dokumenter. 3.1 Modtagelse og læsning af ODF dokumenter På baggrund af erfaringerne i pilotforsøgene, behandler dette afsnit den del af modtagekravet, som omhandler ODF Hvordan står I generelt ved modtagelse af ODF? Generelt er der nogle udfordringer for myndigheder, som skal modtage ODF formaterede dokumenter. For at kunne modtage og læse ODF i tekstbehandlingssystemet, er det nødvendigt at installere en converter. I pilotforsøgene er to forskellige convertere til modtagelse af ODF på en DOC-baseret platform testet: 1. SourceForge CleverAge Odfconverter Add-in for Word 2. SUN ODF Plug-in for Microsoft Word Generelt kan det konstateres, at konverteringer i dette scenarie med disse convertere fungerer med nogle udfordringer. Der er ikke observeret væsentlige forskelle i konverteringskvaliteten mellem de to konvertere. For en detaljeret gennemgang af forskellene i brugen af de to konvertere, henvises til Converterkortlægningen på CONNECTING BUSINESS & TECHNOL

128 Bilagssamling Side 128 af 379 I løbet af pilotforsøgfasen er der lanceret forskellige versioner af disse convertere. Derfor er de to convertere også blevet testet i forskellige versioner 4. I det følgende generaliseres på tværs af disse. Generelt kan det dog konstateres, at de nyeste versioner af converterne fungerer bedst Eksempler på udfordringer ved modtagelse af ODF Sammenligninger af konverterede dokumenter, har på tværs af pilotforsøgene vist nogle udfordringer med at konvertere ODF dokumenter til DOC. Samtidig skal det dog understreges, at flere dokumenter er konverteret korrekt fra ODF til DOC. I de tilfælde, hvor der er observeret deciderede visuelle informationstab, er det typisk billeder, tegninger og OLE objekter, der er forsvundet. Derudover er der observeret visuelle forskelle ved konverteringerne, som imidlertid ikke har været direkte meningsforstyrrende. Disse observationer drejer sig om ændringer af tabuleringer og formatering af punktopstillinger i relation til skrifttyper og punkttegn. I de tilfælde, hvor der er tale om andengangskonvertering, altså konvertering af dokumenter, som i forvejen er konverteret fra et andet format til ODF, er der flere visuelle forskelle i dokumenterne. Her er der yderligere observeret ændringer i dokumenternes marginer, nummererede lister og punkttegn. Der er også eksempler på, at dokumenter med separat sidehoved på første side, ikke bliver konverteret korrekt Eksempler på løsninger og forudsætninger Observationerne fra pilotforsøgene indikerer, at myndighederne ikke kan basere deres løsning udelukkende på en converterinstallation. Derfor vil en relevant teknisk løsningsmodel typisk bestå af en converterløsning, som efter behov kan suppleres med en strategisk anvendelse/udrulning af ensupplerende tekstbehandlingsapplikation.. Den tekniske løsningsmodel skal så kombineres med en hensigtsmæssig og effektiv arbejdsproces. Pilotforsøgene viser dog også, at det i hovedreglen er muligt at modtage og læse ODF dokumenter succesfuldt med de ovennævnte convertere til Word, forudsat, a. at der ikke anvendes indsatte elementer i dokumentet af følgende typer: tegninger direkte i dokumentet, grafik og billeder, samt dynamiske objekter fra andre formater (OLE-objekter). b. at der ikke bliver foretaget flere på hinanden følgende konverteringer c. at udarbejdelsen af dokumenter hos samarbejdsmyndigheden, der sender ODFdokumenterne, er baseret på et funktionalitetsloft, hvor der ikke indgår avancerede 4 Jf. oversigt over anvendte konfigurationer fra pilot- og laboratorieforsøg på CONNECTING BUSINESS & TECHNOL

129 Bilagssamling Side 129 af 379 funktionaliteter. Eksempelvis kan man undgå dokumenter med afsnitsspecifik indholdsfortegnelse. For myndigheder der anvender DOC, og som modtager komplekse dokumenter i ODF format, eller har særlige behov og kvalitetskrav, kan det blive relevant at installere en tekstbehandlingsapplikation, som kan læse ODF enten til at læse eller kvalitetssikre dokumenterne. Alternativt kan denne funktion varetages af myndighedens Servicedesk. Nedenfor er én mulig løsningsmodel ift. modtagelse af ODF for myndigheder med DOC som produktionsformat angivet: Én mulig løsningsmodel ift. modtagelse af ODF for myndigheder med DOC som produktionsformat: Dokumenter i ODF kan modtages via en ODF-plugin eksempelvis Sun ODF Plugin 1.1 for Microsoft Office eller SourceForge OpenXML/ODF Translator Add-in for Office V1.1. Herudover tilbydes en manuel ODF til PDF-konverteringsservice via myndighedens service desk i tilfælde, hvor brugeren eksempelvis er i tvivl om konverteringens kvalitet. Servicedesken anvender her Open Office v2.3, som kan eksportere direkte til PDF. 3.2 Modtagelse og læsning af OOXML dokumenter På baggrund af erfaringerne i pilotforsøgene, behandler dette afsnit den del af modtagekravet, som omhandler OOXML Hvordan står I generelt ved modtagelse af OOXML? Erfaringerne fra pilotforsøgene er, at der generelt kun er få udfordringer for myndigheder, som skal modtage OOXML formaterede dokumenter, når de allerede anvender DOC. For at kunne modtage og læse OOXML i tekstbehandlingssystemet, er det nødvendigt at installere Microsoft Compatibility Pack. Det er muligt at hente denne gratis på Microsofts hjemmeside 5. Dette er pt. den eneste konverteringsløsning, som opfylder behovet for konvertering mellem DOC og OOXML. Løsningen fungererede tilfredsstillende i langt de fleste tilfælde i pilotforsøgene Eksempler på udfordringer ved modtagelse af OOXML Med denne converter installeret, er der ikke i pilotforløbet konstateret eksempler på markante konverteringsfejl inden for det anvendte funktionalitetsloft. Der har kun været tale om enkelte eksempler på, at rækkehøjde og kolonnebredde i tabeller bliver lidt større. I et enkelt tilfælde har en større kolonnebredde medført, at tekst i en kolonne faldt uden for højremarginen. 5 Jf. CONNECTING BUSINESS & TECHNOL

130 Bilagssamling Side 130 af Eksempler på løsninger og forudsætninger ved modtagelse af OOXML Det anbefales, at myndigheder, der benytter Word-versioner ældre end 2007 versionen, bruger Microsofts Compatibility Pack for konvertering af OOXML dokumenter. Hvis brugerne ikke har denne converter installeret, men har de seneste opdateringer fra Microsoft, vil der automatisk komme en dialogboks frem ved forsøg på at åbne et OOXML dokument. Via denne dialogboks, kan brugerne installere Compatibility Pack en. Nedenfor er én mulig løsningsmodel ift. modtagelse af OOXML for myndigheder med DOC som produktionsformat angivet: Én mulig løsningsmodel ift. modtagelse af OOXML for myndigheder med DOC som produktionsformat: Microsoft Office Compatibility Pack gør det muligt for myndigheden at modtage OOXMLdokumenter 4 Udfordringer og mulige løsningsmodeller for myndigheder der benytter ODF som produktionsformat En myndighed der benytter ODF formatet i sit tekstbehandlingssystem, skal pr. 1. januar 2008, kunne modtage og læse OOXML dokumenter. Myndigheder der allerede benytter ODF som format i deres tekstbehandlingssystem, vil typisk være vant til at skulle modtage DOC dokumenter som en del af deres dagligdag. Derfor vil dette afsnit primært behandle udfordringerne ved modtagelse af OOXML dokumenter, som vil være det nye krav for disse myndigheder Hvordan står I generelt ved modtagelse af OOXML? I pilotforsøgene var konverteringer og konverteringsmuligheder, hvor en myndighed vil importere OOXML til ODF, generelt mangelfulde. For at kunne modtage og læse OOXML i tekstbehandlingssystemet, er det nødvendigt at installere en converter, men udbuddet af relevante tekniske løsninger er her stadig begrænset. Den eneste converter på markedet da pilotforsøgene blev afviklet og ved udgangen af 2007, som understøtter direkte import af OOXML-dokumenter i ODF-baserede tekstbehandlingssystemer er Novells odf-converter, OpenOffice.org OpenXML Translator, der p.t. er udgivet i en version til MS Windows, og en version til Linux 6. Samtidig er det eneste tekstbehandlingsprogram converteren kan integreres til OpenOffice Novell Edition version og Platformen er den eneste forskel på de to versionsnumre. CONNECTING BUSINESS & TECHNOL

131 Bilagssamling Side 131 af 379 Generelt kan det i pilotforsøgene konstateres, at konverteringer i dette specifikke scenarie med anvendelse af Open Office Novell Edition som tekstbehandlingssystem er mangelfulde. For øvrige ODF-baserede kontorpakker er konvertering direkte via kontorpakken ikke en mulighed ultimo Her må der findes alternative løsninger, jf. afsnit 4.1.3, hvor eksempler på alternativer omtales Eksempler på udfordringer ved modtagelse af OOXML I pilotforsøgene har sammenligninger af dokumenter før og efter konvertering vist, at myndigheder ikke kan forvente en fejlfri konvertering af OOXML dokumenter til ODF. Der er også flere eksempler i pilotforsøgene på, at der opstår læsefejl, når et OOXML dokument bliver indlæst i OpenOffice for konvertering til ODF, hvilket betyder, at dokumentet ikke kan åbnes. Dette er observeret, når bogstaverne æ, ø eller å indgår i navnet på mappens sti eller i dokumentets filnavn. Paralleltest har vist, at denne fejl ikke opstår, hvis OpenOffice 2.1 Novell Edition inkl. Converter, er installeret på en Linux platform. Der er i pilotforsøgene observeret tab af data, i forbindelse med konvertering af visse billedtyper. Herudover er der observeret en successiv stigning i konverteringsfejl, når der er tale om flere på hinanden følgende konverteringer. Her har datatab eksempelvis resulteret i at hele og halve sider er forsvundet. Også feltdefinitioner i skabeloner er gået tabt i konverteringerne, hvilket betyder at dokumenter, der integrerer til fagsystemer, kan miste deres integrationsmuligheder. Ud over direkte tab af data, er der i pilotforsøgene observeret en række udfordringer, der får dokumenterne til at ændre udseende efter konvertering. Her er der udfordringer med overskrifter, der omdannes til sorte streger eller punktopstillinger, punktopstillinger der bliver til punkttegn, sideopsætninger med rammer/tekstbokse der konverteres forkert, samt tabeller der ændrer kanter og justeringer. Alt i alt er der altså en række udfordringer, hvilket pilotforsøgenes observationer indikerer kalder på andre løsninger, end rene konverterløsninger, jf. afsnit 4.1.3, hvor eksempler på alternativer omtales Eksempler på løsninger og forudsætninger ved modtagelse af OOXML Ud fra ovenstående erfaringer fra pilotforsøgene, er det ikke muligt, alene, at basere sin tekniske løsning på den eksisterende converter fra Novell. For de myndigheder, som arbejder med ODF, men ikke allerede har valgt OpenOffice Novell Edition, er det en løsning at overgå til denne, men for de fleste vil dette ikke være den mest nærliggende vej særligt ikke i det perspektiv, at pilotforsøgene viser at konverteringerne, som nævnt, er mangelfulde. Derfor må myndighederne søge komplementerende løsninger. En let tilgængelig løsning, som betyder, at myndigheden kan opfylde kravet om, at kunne modtage og læse dokumenter i OOXML er, at installere en decideret viewer. Dette betyder CONNECTING BUSINESS & TECHNOL

132 Bilagssamling Side 132 af /20 dog, at brugene ikke kan arbejde videre på dokumenterne. Herudover kan det blive relevant at installere en supplerende tekstbehandlingsapplikation, som kan håndtere OOXML enten til at læse, kvalitetssikre eller redigere dokumenterne. Hvis der blot er behov for at læse dokumenterne, kan myndighedens service desk eksempelvis også konvertere dokumenterne til pdf eller til et andet format, som brugeren kan læse. Myndighederne kan eksempelvis bruge de decentrale superbrugere til at hjælpe med anvendelsen af de implementerede løsninger, og service desken kan varetage flere roller i forbindelse med håndtering af OOXML-dokumenter. Nedenfor er én mulig løsningsmodel ift. modtagelse af OOXML for myndigheder med ODF som produktionsformat angivet: Én mulig løsningsmodel ift. modtagelse af OOXML for myndigheder med ODF som produktionsformat: Brugerne kan håndtere konvertering fra OOXML til ODF via OpenOffice.org OpenXML Translator og OpenOffice Novell Edition v2.1. Men da denne converter ikke kan forventes at fungere problemfrit, installeres Microsoft Word Viewer + Microsoft Compatibillity Pack på alle klienter til visning og validering af indholdet i modtagne OOXML-filer. Myndigheden har valgt at bruge organisationens decentrale superbrugere til at hjælpe med anvendelsen af converteren og viewerløsningen. 5 Udfordringer og mulige løsningsmodeller for myndigheder der benytter OOXML som produktionsformat En myndighed, der benytter OOXML-formatet i sit tekstbehandlingssystem, skal pr. 1. januar 2008, kunne modtage og læse ODF dokumenter. Myndigheder der allerede benytter OOXML (via Word 2007) som format i deres tekstbehandlingssystem, vil typisk være vant til at modtage DOC dokumenter som en del af deres dagligdag. Derfor vil dette afsnit koncentrere sig om modtagelse af ODF-dokumenter, som vil være det nye for disse myndigheder Hvordan står I generelt ved modtagelse af ODF? Erfaringerne fra pilotforsøgene viser, at der generelt er nogle udfordringer for myndigheder, som skal modtage ODF-formaterede dokumenter. For at kunne modtage og læse ODF i tekstbehandlingssystemet, er det nødvendigt at installere en converter. I pilotforsøgene er converteren SourceForge CleverAge Odfconverter Add-in for Word testet til modtagelse af ODF på en OOXML-baseret platform. Generelt kan det i pilotforsøgene konstateres, at konverteringer i dette scenarie med denne converter fungerer med nogle udfordringer. #66221-v4-Konsolideret testrapport Pilotforsøg CONNECTING BUSINESS & TECHNOLOGY

133 Bilagssamling Side 133 af 379 I løbet af pilotforsøgfasen er der lanceret forskellige versioner af converteren, hvorfor converteren er brugt i den nyeste version på det tidspunkt, som det enkelte pilotforsøg er gennemført. Derfor er converteren blevet testet i forskellige versioner. Herudfra generaliseres i det følgende. Generelt kan det dog konstateres, at de nyeste versioner af converteren fungerer bedst. Følgende versioner er indgået i pilotforsøgene: Version 1.0.0; version M1 samt version M2M Eksempler på udfordringer ved modtagelse af ODF I pilotforsøgene er der observeret en række konverteringsfejl med eksempler på tab af data. Der er endvidere flere fejlkonverteringer, der relateret til, at tekstbehandlingsformaterne er forskellige i deres måde, at bruge funktionaliteter på, samt at de hver i sær har funktionalitet, der ikke er understøttet af det andet format.. Generelt kan det, ud fra pilotforsøgene, konstateres, at der er udfordringer, når dokumenter indeholder billeder, tegninger og indsatte dynamiske elementer. Der er også i pilotforsøgene observeret fejlkonverteringer, som er meningsforstyrrende. Det er eksempelvis sider midt i dokumentet, der i ODF er landskabsorienteret, som får deres egen sektion i OOXML, hvilket kan bevirke, at sidehoved ændrer sig, hvis der er separat sidehoved for første side. Også indholdsfortegnelser for kapitler, der er understøttet i ODF, giver udfordringer. Disse er eksempelvis blevet konverteret til indholdsfortegnelser for hele dokumentet i OOXML, hvilket kan have store konsekvenser for dokumentets længde. Udseendemæssigt har pilotforsøgene vist, at der er udfordringer med at konvertere nummererede lister og punktopstillinger, sidehenvisninger og formatering i sidefod, så disse elementer forbliver visuelt identiske. Det er en gennemgående iagttagelse i pilotforsøgene, at flere på hinanden følgende konverteringer forøger mængden af fejlobservationer Eksempler på løsninger og forudsætninger ved modtagelse af ODF Observationerne fra pilotforsøgene indikerer, at myndighederne ikke kan basere deres løsning udelukkende på en converterinstallation. Pilotforsøgene viser, at det i hovedreglen er muligt at modtage og læse ODF-dokumenter succesfuldt med de ovennævnte convertere til Word, forudsat, a) at der ikke anvendes indsatte elementer i dokumentet af følgende typer: tegninger direkte i dokumentet, grafik og billeder, samt dynamiske objekter fra andre formater (OLE-objekter). b) at der ikke bliver foretaget flere på hinanden følgende konverteringer CONNECTING BUSINESS & TECHNOL

134 Bilagssamling Side 134 af /20 c) at udarbejdelsen af dokumenter hos samarbejdsmyndigheden, der sender ODFdokumenterne, er baseret på et funktionalitetsloft, hvor der ikke indgår avancerede funktionaliteter. Eksempelvis kan man undgå dokumenter med afsnitsspecifik indholdsfortegnelse. For myndigheder der anvender OOXML og som modtager komplekse dokumenter i ODF format, eller har særlige behov og kvalitetskrav, kan det blive relevant at installere et tekstbehandlingssystem, som kan læse ODF enten til at læse eller kvalitetssikre dokumenterne. Alternativt kan denne funktion varetages af myndighedens Service desk. Nedenfor er én mulig løsningsmodel ift. modtagelse af ODF for myndigheder med OOXML som produktionsformat angivet: Én mulig løsningsmodel ift. modtagelse af ODF for myndigheder med OOXML som produktionsformat: Brugerne kan fra Word 2007 importere ODF via SourceForge OpenXML/ODF Translator Add-in for Office V1.1. Herudover tilbydes en manuel ODF til PDF-konverteringsservice via myndighedens service desk i tilfælde, hvor brugeren eksempelvis er i tvivl om konverteringens kvalitet. Service desken anvender her OpenOffice v2.3, som kan eksportere direkte til PDF. I forbindelse med særligt krævende brugere tilbydes installering af OpenOffice v2.3 lokalt til visning og behandling af ODF-dokumenter. Dette program kan brugeren selv installere via et fællesdrev. Brugeren kan få hjælp til installationen hos service desken. Service desken har udarbejdet en kort vejledning, som guider brugerne i anvendelsen af løsningerne, men der ydes ikke funktionel support på løsningerne. 6 Overvejelser ifm. nyanskaffelser Myndigheder, som har anskaffet et ODF eller OOXML baseret tekstbehandlingsprogram må forvente at modtage DOC dokumenter fra myndigheder, der endnu ikke har opgraderet eller nyanskaffet også selvom de ikke er forpligtiget til at kunne håndtere dette format. Derfor indgik også DOC i pilotforsøgene. Dette afsnit vil, ud fra erfaringerne i pilotforsøgene, derfor behandle den situation, at DOC dokumenter bliver modtaget hos myndigheder, der lige er begyndt at understøtte de åbne dokumentstandarder. 6.1 Myndighed der overvejer løsning med ODF som produktionsformat I pilotforsøgene har det gennemgående tekstbehandlingsprogram for ODF været OpenOffice. Her er det ikke nødvendigt at installere en converter for at kunne modtage og læse DOC dokumenter. #66221-v4-Konsolideret testrapport Pilotforsøg CONNECTING BUSINESS & TECHNOLOGY

135 Bilagssamling Side 135 af 379 Det er generelt muligt at modtage DOC-dokumenter, og åbne dem i ODF, uden meningsforstyrrende indholdstab. Der er dog observeret eksempler på tab af data. Ved modtagelsen af DOC dokumenter, er der under pilotforsøgene set eksempler på, at billeder, tekstbokse og dynamisk indsatte objekter forsvinder. Ud over disse tab af data, er der kun observeret få visuelle afvigelser i forbindelse med konverteringerne. I forbindelse med gentagne konverteringer er der dog observeret mindre visuelle forskelle. Pilotforsøgene viser dermed, at det er muligt at modtage og læse DOC dokumenter, forudsat, a. at der ikke er anvendt indsatte elementer i dokumentet. For disse elementer gælder, at det drejer sig om tegninger direkte i dokumentet, grafik og billeder samt dynamiske objekter fra andre formater (OLE). b. at der ikke bliver foretaget flere på hinanden følgende konverteringer Der er i dag flere myndigheder, som bruger ODF i deres tekstbehandlingsprogram, og som modtager mange dokumenter i DOC format. Blandt disse myndigheder kan nævnes Gribskov Kommune og Region Midtjylland, som har indgået i IT- og Telestyrelsens pilotprojekt. Hos disse to myndigheder, har man ikke oplevet væsentlige problemer med at modtage og åbne DOC-dokumenter. Hvis myndigheden har et behov for at kunne se og validere de konverterede dokumenter, kan der anvendes en viewerløsning. Det er gratis at hente Word Viewer 2003 på Microsofts hjemmeside. Fra denne løsning kan myndighederne åbne, gemme og udskrive DOC dokumenter. Brug eventuelt myndighedens decentrale superbrugere til at hjælpe med anvendelsen af viewerløsningen. 6.2 Myndighed der overvejer løsning med OOXML som produktionsformat Microsoft Word 2007 er som udgangspunkt bagudkompatibel. Dette betyder, at der ikke er behov for installation af converterløsninger for at kunne modtage DOC dokumenter i Word 2007 Der er i pilotforløbet ikke fundet eksempler på fejlkonverteringer, der resulterer i tab af indhold eller meningsforstyrrende ændringer. Der er observeret få visuelle ændringer i punktopstilling og i sidehoved, hvor tekstbokse har ændret justering på siden. Herudover kan det konstateres i pilotforsøgene, at feltdefinitioner for dokumenter, der er opbygget med integration til fagsystemer, bliver konverteret korrekt. Der er i pilotforsøgene identificeret nogle mindre visuelle forskelle i dokumenterne ved gentagne konverteringer. CONNECTING BUSINESS & TECHNOL

136 Bilagssamling Side 136 af 379 Ved anskaffelse af Word 2007 eller andet tekstbehandlingsprogram, der understøtter OOXML, tyder observationerne i pilotforsøgene på, at der ikke vil være behov for yderligere løsninger for at modtage DOC-dokumenter. 7 Opsummerende anbefalinger Set på tværs af de scenarier, der er beskrevet i denne rapport, viser pilotforsøgene, at der er en række tiltag, som I som myndighed kan følge og iværksætte, for at gøre håndteringen af de åbne dokumentformater nemmere både for jer selv og for eventuelle samarbejdsparter. Disse forslag til tiltag er baseret på de foreløbige erfaringer i pilotforsøgene med åbne dokumentformater og den nuværende tilgængelige teknologi. I skal selv vurdere, hvilke tiltag der er relevante for netop jeres myndighed. 7.1 Beslut jer for et funktionalitetsloft Hvis I samarbejder med andre myndigheder om dokumenter, hvor samarbejdsmyndigheden bruger et andet format end jer som produktionsformat, vil det være givtigt, at se på hvilke funktionaliteter, der sandsynligvis vil skabe udfordringer, når I udveksler dokumenter. Med udgangspunkt heri, kan I beslutte jer for et funktionalitetsloft, som kan fremme udvekslingen med andre myndigheder. Eksempler på, hvad I kan forsøge for at sikre en høj succesrate: Brug standard fonte og typografier. Undlad brug af tekstbokse Undgå stregtegninger Undgå indsatte OLE-objekter Beskær billeder, inden de sættes ind i dokumentet Beskæring af billeder inden de sættes ind i et dokument, kan eksempelvis foregå på den måde, at I læser billedet ind i en billededitor, beskærer det til det ønskede format og afsnit, gemmer som en fil, og derefter indsætter denne fil i dokumentet. 7.2 Tilpasning af dokumentskabeloner med udgangspunkt i funktionalitetsloftet Når I har lagt jer fast på, hvilke funktioner I vil anvende, som en del af funktionalitetsloftet, kan I med fordel gennemgå jeres eksisterende skabeloner for at tjekke, om de understøtter dette funktionalitetsloft. De steder, hvor der indgår funktionalitet, der ligger uden for jeres funktionalitetsloft, kan I se på mulighederne for at tilrette skabelonen. CONNECTING BUSINESS & TECHNOL

137 Bilagssamling Side 137 af Undgå gentagne konverteringer Gentagne konverteringer er, når I for eksempel samarbejder omkring dokumenter med en myndighed, der bruger et andet format. Her bliver dokumentet typisk sendt frem og tilbage mellem myndighederne med gentagne konverteringer som konsekvens. Da der erfaringsmæssigt er en del udfordringer med denne praksis, kan I eksempelvis fra starten aftale et format, I vil bruge til at samarbejde om dokumentet, hvis der er behov for mange udvekslinger og redigeringsforløb. Eller I kan holde jer til ganske simpel funktionalitet i forbindelse med samarbejdsprocessen og vente med formatering af dokumentet til indholdet er færdigt. Gentagne konverteringer er også, hvis I modtager et dokument fra en anden myndighed, som I konverterer til jeres eget format, og fremsender dette konverteret dokument til en tredje myndighed med et tredje format, som derfor er nødt til at konvertere igen. I dette tilfælde bør I fremsende originaldokumentet til tredje myndighed. 7.4 Vælg PDF til udveksling af ikke redigerbare dokumenter Da der er udfordringer med udveksling af redigerbare dokumenter, bør I gennemgå jeres procedurer for, hvornår I sender dokumenter i PDF format frem for i redigerbare formater. I bør således vurdere, om der er et reelt behov for at udveksle dokumenter i et redigerbart format, eller om dokumenter kan sendes som PDF, der pt. giver den mest optimale fastholdelse af indhold. Anbefaling af PDF som fastholdelsesformat er del af den gældende edag-aftale. 7.5 Vurder hvilke dokumenter, I vil lave kvalitetscheck på efter konvertering I ved, at der kan opstå udfordringer med konvertering af dokumenter større eller mindre alt efter jeres specifikke situation. I nogle tilfælde kan dette være kritisk, at I har vished for, at dokumentet er konverteret korrekt. Det kan ikke anbefales, at I iværksætter er stort kvalitetssikringsapparat, men prioriterer hvor, hvornår og hvordan kvalitetssikringen skal udføres. Dette er principielt ikke anderledes end i, når I skanner dokumenter, eller genererer PDF-filer. Her skal I typisk også sikre, at den version I anvender, er korrekt og i overensstemmelse med originalen. Et væsentligt værktøj i denne forbindelse kan være at gennemføre en risikovurdering. Lav fra starten en fast definition af, hvilke dokumenter I skal kvalitetssikre, hvis de bliver konverteret fra et andet format ved modtagelsen. I bør her have kriterier på forskellige niveauer ud fra hvor komplekst dokumentet er, om det er juridisk/forvaltningsmæssigt bindende osv. CONNECTING BUSINESS & TECHNOL

138 Bilagssamling Side 138 af 379 Det vil være en stor hjælp i de daglige myndighedsprocesser, hvis I kan opnå en ensartet tilgang til, at bestemme hvornår det er i orden, med evt. konverteringsfejl, og hvornår risikoen for evt. konverteringsfejl skal aktivere en kvalitetssikringsprocedure. 7.6 Indfør tjekrutiner for udvalgte dokumenter Når I først ved hvilke dokumenter, I skal kvalitetssikre, kan I indføre veldefinerede tjekrutiner, så jeres myndighedsprocesser kan fortsætte så hurtigt som muligt. Der bør gennemføres en systematisk kvalitetssikring af konverteringsprocessen, som gør det muligt at sikre, at de konverterede dokumenter kan læses og at alle informationer er korrekte. Kvalitetssikring af konverteringen kan eventuelt ske ved statistisk stikprøvekontrol. 7.7 Installere en kontorpakke eller viewer, som understøtter det pågældende format Hvis I som myndighed har særlige behov for at kunne modtage og læse mere komplicerede dokumenter, eller modtager store mængder af dokumenter i andre formater end jeres produktionsformat, kan det være en fordel at installere viewere eller kontorpakker, som understøtter de relevante dokumentformater. For myndigheder, der benytter ODF, er der mulighed for at installere Word Viewer 2003 sammen med Microsoft Compatibility Pack. Dette giver adgang til at se, gemme og udskrive dokumenter, der har formaterne DOC og OOXML. For myndigheder der benytter DOC eller OOXML, er det eksempelvis en mulighed, at installere OpenOffice.org, der ud over at kunne åbne/læse, redigere, gemme og udskrive ODF dokumenter, eksempelvis også kan generere PDF-versioner af dokumenter. Der er forskellige modeller for, hvordan viewere og kontorpakker kan indgå som et supplement til jeres normale tekstbehandlingsprogram. F.eks. i jeres service desk eller hos udvalgte brugere (f.eks. superbrugere) eller forvaltningsområder. 7.8 Overvej harmonisering af sprogversioner Myndighederne kan overveje, om det er muligt at ensarte sprogversioner på tværs af flere myndigheder. Forskelle på kontorpakker, der er installeret med forskellige sprogversioner kan nemlig være årsag til, at der sker ændringer i dokumenterne når I konverterer. Dette kan endda forekomme mellem ens formater. Årsagen er, at typografier ikke hedder det samme på de forskellige sprog, så har man brugt for eksempel Heading 1 til overskrift i en engelsk version af et tekstbehandlingssystem, vil overskriften fejle i en dansk version, hvor programmet vil lede efter en Overskrift 1. CONNECTING BUSINESS & TECHNOL

139 Bilagssamling Side 139 af Følg med i udviklingen Der sker rigtigt meget inden for de åbne dokumentstandarder i øjeblikket. Der kommer løbende nye versioner af convertere, nye tekstbehandlingsprogrammer, der understøtter formaterne, og nye teknologier og måder at opnå interoperabilitet mellem formaterne på. Ved at følge med i denne udvikling og afprøve de nyeste versioner og teknologier, vil jeres myndighed givetvis kunne forbedre evnen til at håndtere dokumenter i andre formater. Dette vil også kunne være med til at reducere jeres behov for kvalitetssikring og kontrolprocedurer Indrapporter jeres tekniske udfordringer til leverandørerne Erfaringerne fra projektets pilot- og laboratorieforsøg har været, at leverandørerne gerne vil løse de tekniske udfordringer for myndighederne. Er der et behov hos mange myndigheder, prioriterer de problemløsningen. Derfor bør I indrapportere de fejl og udfordringer I finder, så leverandørerne får nemmere ved at sikre jer de rigtige løsninger i den rigtige kvalitet. CONNECTING BUSINESS & TECHNOL

140 Notat Bilagssamling Side 140 af 379 Bilag 2 Laboratorietest med åbne dokumentformater efteråret 2007 vejledningsrelevante konklusioner 1. Indledning IT- og Telestyrelsen har i samarbejde med en række centrale aktører i efteråret 2007 (uge 41-43) gennemført en laboratorietest vedrørende de obligatoriske åbne dokumentformater (ODF og OOXML). Laboratorietesten har udgjort en central del af styrelsens vejledningsgrundlag i forhold til at understøtte offentlige organisationers implementering af åbne dokumentformater. Laboratorietesten har taget afsæt i resultaterne fra de allerede gennemførte pilotforsøg og paralleltest vedr. de åbne dokumentformater. Dette notat er IT- og Telestyrelsens opsamling på laboratorietesten og indeholder bl.a. de vejledningsrelevante konklusioner, som IT- og Telestyrelsen har draget på baggrund af laboratorietesten. Disse konklusioner har styrelsen lagt til grund for efterfølgende udarbejdelse af diverse vejledningsmateriale til at understøtte offentlige myndigheders forberedelse til at kunne understøtte de obligatoriske åbne dokumentformater. 26. november 2007 IT- og Telestyrelsen Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr IT-arkitekturkontoret Jens Jakob Andersen Telefon E-post jjan@itst.dk IT- og Telestyrelsen Side 1 af 5 2. Metode Laboratorietesten er beskrevet i metodedokumentet for projektet 1 og i, testplan for laboratorie 2. Detaljeret dokumentation for test er beskrevet i testrapporten 3. Der er i laboratorietesten anvendt en testmetode, hvor der på baggrund af 1 Metodemæssige rammer for gennemførelse af test, version 1.0, august Testplan for Laboratorietest, Version 1.0, oktober Testrapport fra Laboratorietest, Version 1.3, november 2007

141 Bilagssamling Side 141 af 379 observationer fra pilotforsøg og paralleltest er opstillet hypoteser for hvilke underliggende tekniske årsager, der kunne være kilden til observationerne. Der blev i laboratorietesten anvendt både kildedokumenter fra pilotforsøg og konstruerede dokumenter til afprøvning af specifikke hypoteser. De i laboratorietesten undersøgte observationer har holdt sig inden for det i projektet tidligere definerede funktionalitetsloft. 4 Ud fra de opstillede hypoteser blev der defineret en række specifikke forsøg for at isolere de enkelte elementer af underliggende tekniske årsager, og afklare hvilke, der var årsager til observationerne. Testen blev løbende dokumenteret, og den blev gennemgået i plenum, hvor der blev opnået enighed om testresultater. Forløb og resultater blev ligeledes dagligt gennemgået i med deltagerne i laboratorietesten. Metoden viste sig i laboratoriet som et effektivt værktøj til at styre forløbet og sikre en fokuseret analyse af resultaterne fra pilotforsøg. IT- og Telestyrelsen Side 2 af 5 3. Dokumentation og reproducerbarhed Laboratorietest er gennemført efter detaljeret og dokumenteret metode, og alle resultater er fuldt dokumenteret både i forhold til testresultat og anvendt konfiguration m.v. Det betyder f.eks., at alle tests kan gentages på et senere tidspunkt. Det være sig med de originale konfigurationer eller med modificerede konfigurationer, f.eks. med nye versioner af convertere og programmer. Det vil således eksempelvist være muligt på et senere tidspunkt at undersøge om nye convertere og programmer skaber bedre mulighed for praktisk interoperabilitet mellem de åbne dokumentformater. 4. Organisation Arbejdet blev ledet af IT- og Telestyrelsen, bistået af Devoteam Consulting. Forudsætninger for gennemførelse af laboratorietesten var: Neutral grund Apolitisk sigte Forum, hvor der kunne skabes konsensus omkring resultater Mulighed for åbenhed og fortrolighed Testen er derfor afviklet i Sogetis Center of Test Excellence med konsulenter fra Sogeti til at sikre udførelse, koordination og rapportering. 4 Funktionalitetsloft, juli 2007

142 Bilagssamling Side 142 af 379 De i laboratorietesten deltagende leverandører har alle kernekompetencer i forhold til dokumentformater og dokumentkonvertering og har bragt kritisk merværdi til arbejdet i laboratoriet via deres store tekniske ekspertise og netværk. Leverandørernes deltagelse i laboratorietesten er ikke et udtryk for deres politiske holdning til den politiske beslutning om at indføre de to obligatoriske åbne dokumentformater. IT- og Telestyrelsen Side 3 af 5 Figur: Om organisation og roller i laboratorietesten 5. Anvendt konfiguration Tekstbehandlingsprogrammer og operativsystemer i laboratorietesten er udvalgt med udgangspunkt i anvendte/relevante konfigurationer hos pilotmyndighederne. I laboratorietesten blev der derfor anvendt tekstbehandlingsprogrammerne Microsoft Word 2003, Microsoft Word 2007 og OpenOffice Novell Edition 2.1 alle på Windows XP samt OpenOffice Novell Edition 2.1 og Lotus Notes Productivity tools begge på SUSE Linux Enterprise Desktop 10. Der blev anvendt converter-teknologier fra Sun, Novell, OpenOffice.org og Sourceforge ( Cleverage projektet ). De anvendte konfigurationer er detaljeret dokumenteret i testrapporten. 5 5 Testrapport fra Laboratorietest, Version 1.3, november 2007

143 Bilagssamling Side 143 af Vejledningsrelevante konklusioner Ud fra de givne softwarekonfigurationer, testdokumenter og udførte forsøg i laboratoriet, er det IT- og Telestyrelsens vurdering, at det er muligt at opstille en række af konsoliderede vejledningsrelevante konklusioner om praktisk interoperabilitet mellem de åbne dokumentformater med udgangspunkt i de i laboratorietesten anvendte konfigurationer: Konvertering I laboratorietesten blev der iagttaget varierende grad af konverteringsmodenhed på tværs af convertere og dokumenter og det samlede billede af converterne er, at alle convertere har potentiale for forbedring af modenheden. Generelt har alle de anvendte convertere udfordringer omkring håndtering af tekstbokse, stregtegninger og indlejrede dynamiske objekter ( OLE ). Derudover har alle converterne i varierende grad udfordringer med håndtering af mere avancerede dokumentfunktionaliteter og komplekse dokumenter. Dokumenter uden avanceret funktionalitet konverteres generelt uden eller med meget få udfordringer på tværs af programmer, formater og operativsystemer. De mange forskelligartede visuelle observationer fra pilotforsøgene er i laboratorietesten blevet henført til relativt få bagvedliggende tekniske udfordringer. Det drejer sig om særligt tekstbokse, stregtegninger, billeder og indlejrede dynamiske objekter ( OLE-objekter ). Slutbrugerne kan opleve relativt store visuelle afvigelser og uhensigtsmæssigheder med konverterede dokumenter, selvom den bagvedliggende årsag er et relativt enkelt teknisk problem i konverteringen. De udfordringer, der er observeret i laboratoriet i forhold til interoperabilitet mellem de åbne dokumentformater, er i vid udstrækning henførbare til de enkelte applikationers implementering, frem for de to dokumentformaters specifikationer. Konvertering foregår hurtigt og uden mærkbar ventetid for brugeren. IT- og Telestyrelsen Side 4 af 5 Converter- og programudvikling Da der er tale om relativt nye dokumentformater, er udvikling af convertere til konvertering mellem formaterne også et relativt nyt område. IT- og Telestyrelsen vurderer, at produkterne til konvertering stadig har et stort udviklingspotentiale, og det påvirker det nuværende niveau af faktisk og praktisk interoperabilitet. De fleste af de observationer af konverteringsudfordringer, som blev gjort i laboratorietesten, er af en sådan karakter, at IT- og Telestyrelsen vurderer, at de kan løses gennem udvikling af bedre convertere. Udvikling af convertere foregår relativt hurtigt, og udviklerne er åbne overfor input fra brugerne om fejl i converterne.

144 Bilagssamling Side 144 af 379 IT- og Telestyrelsen vurderer derfor, at det vil give værdi for offentlige myndigheder, hvis converterudviklingen også efter den 1. januar 2008 monitoreres af IT- og Telestyrelsen. Det er IT- og Telestyrelsens vurdering, at det også fremadrettet vil være applikationernes (både programmernes og converternes) implementering, herunder forskelle fra produkt til produkt i omfang af funktionalitet, som vil medfører de største udfordringer i forhold til praktisk interoperabilitet mellem de åbne dokumentformater. 7. Specifikt om convertere Der er i laboratorietesten anvendt convertere fra forskellige leverandører. Grundlæggende er der 3 hovedgrene indenfor udviklingen af convertere for de åbne dokumentformater: Cleverage projektet hvis officielle navn er Open XML / ODF Translator Add-ins for Office, jf. Cleverage-projektet udvikler convertere til understøttelse af ODF i Microsoft Word og baserer sig på konvertering ved hjælp af XSLTstylesheets. Novell OpenOffice OpenXML Translator. Denne converter er en portering af Cleverage converteren for Word, til at understøtte OOXML konvertering i OpenOffice Novell Edition. Jf. også SUN ODF plugin for Word. Denne plugin understøtter ODF i Microsoft Word, og baserer sig på konvertering af ODF til DOC ved hjælp af konverteringsmotoren indbygget i OpenOffice.org. Derudover arbejder Sun på at udvikle et OOXML importfilter i OpenOffice: IT- og Telestyrelsen Side 5 af 5 Det er varianter af disse tre convertere der primært ses anvendt i de forskellige udgaver af serverbaserede konverteringsløsninger. Det betyder, at de udfordringer med konvertering, som er observeret i laboratorietest (og i pilotforsøg), i væsentligt omfang også må forventes i forhold til de serverbaserede konverteringsløsninger.

145 Notat Bilagssamling Side 145 af 379 Bilag 3 Funktionalitetsloft - de mest benyttede formatrelevante funktionalitetsområder hos myndigheder Undersøgelser foretaget foråret 2007 har fastslået, at der ikke findes systematiske studier af, endsige et samlet overblik over, hvilke formatrelevante funktionaliteter offentlige myndigheder benytter sig af. It- og Telestyrelsen har derfor indsamlet viden om dette. På baggrund af en bruttoliste over områder af formatrelevante funktionaliteter er et funktionalitetsloft defineret. Funktionalitetsloftet er indkredset i et samarbejde med offentlige myndigheder og leverandører, og er bl.a. drøftet i ITarkitekturkomitéen og Datastandardiseringskomitéen. Funktionalitetsloftet er endvidere konsolideret på baggrund af analyser af konkrete eksempel-dokumenter fra myndighederne. Funktionalitetsloftet er brugt til at definere relevant fokus i test for at undersøge samspillet mellem tekstbehandlingsdokumentformaterne. 01 november 2007 IT- og Telestyrelsen Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Jeannette Nielsen Telefon Telefax E-post jpn@itst.dk Sagsnr. Dok nr. Side 1/1 Det konsoliderede funktionalitetsloft fremgår af tabellen nedenfor: Formatrelevante funktionalitetsområder Formatering fx fed skrift, typografier, overskrifter, linie- og afsnitsafstand, kursiv, farvet skrift eller baggrund, margen, tekstrotation, automatisk orddeling, tabulering Sidehoved og sidefod fx sidenummerering, forskelligt sidehoved/sidefod i sektionsopdelt dokument Indgår i testede dokumenter Ja Ja Flere myndigheder anvender Ja Fodnoter og slutnoter Ja Ja Nummererede lister og punktopstilling Ja Ja Indsatte dynamiske elementer fra andre filformater Ja Ja Ja

146 Bilagssamling Side 146 af 379 Formatrelevante funktionalitetsområder fx Excel, PowerPoint, OLE-objekt Indgår i testede dokumenter Flere myndigheder anvender Tabeller Ja Ja fx gentage kolonneoverskrift, tekstombrydning i celler, sammenfletning af celler, formatering af tabeller Indsatte statiske billeder og grafik Ja Ja herunder logo i forskellige formater (fx tif, jpg) Sideopsætning Ja Ja fx vende siderne til horisontalt, tekst i to spalter, sektionsopdeling Automatisk genereret indholdsfortegnelse Ja Ja Oprette og redigere tegning/model direkte i dokumentet Ja Ja Skabeloner (templates) og makroer Ja Ja Redigering Ja Ja Rettelsesmarkering og kommentarer Data hentet fra andre systemer Ja Ja fx ESDH-system Funktionalitetsområder der ikke er testet Rettighedsstyring Nej Ja fx spærring af dokument, så kun visning af dokumentet og ikke print eller redigering kan lade sig gøre Metadata Nej Ja fx dokumentegenskaber Versionering Nej Ja Brevfletning Nej Ja fx flettefelter Høringsfunktion (samarbejdsfunktion) Nej Nej I projektet har test og pilotforsøg fokuseret på specifikke delfunktionaliteter under de enkelte funktionalitetsområder. Afgrænsningen af delfunktionaliteter er baseret på konkret anvendelse af delfunktionaliteter i myndighedernes dokumenter. For funktionalitetsområdet Formatering har det fx vist sig, at de specifikke delfunktionaliteter Fed skrift, Kursiv samt Venstrejusteret margen ofte anvendes af myndighederne og at de specifikke delfunktionaliteter som Tekstrotation eller Gennemstreget tekst stort set ikke anvendes af myndighederne. De identificerede delfunktionaliteter fremgår af tabellen nedenfor: IT- og Telestyrelsen Side 2/2

147 Bilagssamling Side 147 af 379 Identificerede delfunktionaliteter i dokumenter der indgår i test og pilotfor- Formatrelevante funktionalitetsområder søg Farvet skrift Fed skrift Hyperlink Kursiv Linieskift Linieskift - manual break Formatering Margen - centreret Margen - højrejusteret Margen - venstrejusteret Mellemrum (space) Overskrift Tabulering Tekstfremhævning Understregning Forskelligt sidehoved i sektionsopdelt dokument Sidefod Sidefod - forskellig venstre og højre side Sidehoved og sidefod Sidehoved Sidehoved - Speciel første side Sidenummerering Sidenummerering - højrejusteret Sidenummerering - venstrejusteret Fodnoter og slutnoter Fodnote Nummereret liste Nummererede lister og punktopstilling Indsatte dynamiske elementer fra andre filmformater Tabeller Indsatte statiske billeder og grafik Sideopsætning Automatisk genereret indholdsfortegnel- - Punktopstilling OLE-objekt Regneark Cellejustering - centreret Cellejustering - højre Cellejustering - venstre Flettede celler Kanter Skygge Billede Tekstboks Tekstombrydning (Wrap off) Sideskift Ramme Tekst i spalter Tekstboks Vende siden til horisontalt IT- og Telestyrelsen Side 3/3

148 Bilagssamling Side 148 af 379 Identificerede delfunktionaliteter i do- Formatrelevante funktionalitetsområder kumenter der indgår i test og pilotforsøg se Oprette og redigere tegning/model direk-tegninte i dokumentet Skabeloner (templates) og makroer - Redigering Kommentar Rettelsesmarkering Data hentet fra andre systemer - IT- og Telestyrelsen Side 4/4

149 Bilagssamling Side 149 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag J

150 Bilagssamling Side 150 af 379 Vejledning i anvendelse af åbne standarder for dokumentudveksling December 2007, v1.1

151 Bilagssamling Side 151 af 379 > Vejledning i anvendelse af åbne standarder for dokumentudveksling November 2007, v1.1 Udgivet af: IT- & Telestyrelsen Holsteinsgade København Ø Publikationen kan hentes på IT- & Telestyrelsens hjemmeside: og ISBN (internet): Telefon: e-post: itst@itst.dk 2

152 Bilagssamling Side 152 af 379 > Vejledning i anvendelse af åbne standarder for dokumentudveksling December 2007 v1.1 IT- & Telestyrelsen januar 2008

153 Bilagssamling Side 153 af 379 Indhold [ Versionsoversigt 5 1 Indledning Formål med vejledningen Målgruppen for vejledningen Baggrund kort om B Afgrænsning og præcisering Metodegrundlag for vejledningen Læsevejledning 16 2 Hvad betyder de obligatoriske, åbne standarder for dokumentudveksling for jer forretningsmæssigt perspektiv Hvilke fordele kan åbne dokumentstandarder give jer? Hvordan kommer I i gang? Hvilke beslutninger skal I træffe? Hvordan vil det fungere i dagligdagen? Hvad skal der til? 23 3 Kravet om at kunne modtage ODF og OOXML Hvilke udfordringer er der, og hvordan er myndighederne generelt stillet? Mulige løsningsmodeller Kan jeres tekstbehandlingssystem i dag læse ODF og OOXML? Hvilken konverteringsløsning kan I bruge? Gode råd om driften hvilke udfordringer og løsningsmuligheder har I? Gode råd om implementering 47 4 Kravet om at understøtte de obligatoriske, åbne dokumentstandarder ved nyanskaffelser, opgraderinger mv Hvad ligger der i anskaffelseskravet? Hvilke systemer og hvilke funktioner skal understøttes? Forberedelse af anskaffelsen Vurdering af leverandørernes parathed Modtagelse af DOC efter anskaffelse af ny kontorpakke 54 5 Yderligere information og hjælp til selvhjælp Hjælp til selvhjælp Mere vejledningsmateriale Yderligere information 60

154 Bilagssamling Side 154 af 379 Versionsoversigt > Version 0.8 (offentliggjort) Version 0.9 (intern revision, ikke publiceret) Version november 2007 første del af vejledningen. Publiceret med 14 dages høringsfrist for forslag og kommentarer. 30. november 2007 samlet vejledning. Følgende ændringer implementeret: -oversigt over versionering -afsnit 1.2: præcisering af målgruppen for vejledningen herunder hvem der er omfattet -afsnit 1.4: uddybning og præcisering af formaternes filtyper -afsnit 2.2: revidering af underafsnit om hvordan kommer I i gang med henvisninger til Test-selv-pakke på projektets hjemmeside -afsnit 2.3: revideret underafsnit vedr. juridisk validitet -afsnit 3-5 tilføjet. Version 1.1 Versionen er åben for kommentarer og forslag i en periode på 14 dage efter publicering dvs. frem til d. 14. december kl Kommentarer fremsendes til dokumentformater@itst.dk 21. december 2007 samlet vejledning revideret Følgende ændringer er implementeret: -rettelse af div. fejl, præciseringer og versionsnumre 5

155 Bilagssamling Side 155 af Indledning > 1. januar 2008 vil en række åbne standarder blive obligatoriske at anvende for offentlige myndigheder ved fremtidige indkøb af software og it-løsninger. For offentlige myndigheder betyder det, at man skal sikre sig, at fremtidige itløsninger er baseret på, eller understøtter, disse obligatoriske, åbne standarder, hvis standarderne er relevante for it-løsningen. Herudover bliver det obligatorisk for alle offentlige myndigheder at kunne modtage tekstbehandlingsdokumenter i formaterne ODF og OOXML fra 1. januar Denne vejledning dækker de obligatoriske åbne standarder for dokumentudveksling (ODF og OOXML), som er ét ud af syv sæt af obligatoriske standarder. For en overordnet vejledning, som beskriver sammenhængen til de øvrige seks sæt af standarder samt generel vejledning i anskaffelse af nye it-løsninger mv., henvises til materialerne Sådan anvender du åbne standarder i din myndighed og Vejledning om anvendelse af obligatoriske åbne standarder for software i det offentlige, som fra december 2007 kan findes via Formål med vejledningen Denne vejledning giver konkrete anvisninger på, hvordan I sikrer, at jeres myndighed fra 1. januar 2008 kan leve op til kravene om anvendelse af åbne standarder for dokumentudveksling i det offentlige. Kravene er: > 1. januar 2008 skal alle offentlige myndigheder kunne modtage tekstbehandlingsdokumenter fra borgere, virksomheder og andre myndigheder i to formater: ODF og OOXML. > Pr. 1. januar 2008 bliver ODF og OOXML obligatoriske standarder for offentlige myndigheder. Løsninger, der indkøbes efter 1. januar 2008, skal understøtte mindst en af disse åbne standarder og kunne modtage tekstbehandlingsdokumenter i begge formater. Hvordan disse krav i praksis efterleves vil afhænge af bl.a. hvilket teknisk og organisatorisk udgangspunkt myndigheden har, såvel som deres forventede behov for at kunne modtage ODF og OOXML. En del myndigheder vil f.eks. have Word 2003 og DOC som produktionsformat 1. Nogle har f.eks. Word 2007 og OOXML som produktionsformat. Andre myndigheder bruger Open Office, f.eks. OpenOffice.org 2.3 Novell Edition og ODF som produktionsformat. I kan se 1 Termen produktionsformat anvendes i det følgende om det format, som myndigheden anvender til produktion af dokumenter dvs. det format tekstbehandlingssystemet som standard gemmer i. 6

156 Bilagssamling Side 156 af 379 > eksempler på, hvordan disse forskellige udgangspunkter påvirker potentielle tekniske og organisatoriske løsningsmodeller for modtagelse af ODF og OOXML i afsnit Derfor er det vigtigt at forberede din organisation både teknisk og organisatorisk, og derfor er der ikke én teknologisk eller organisatorisk løsning, som opfylder alle myndigheders behov. Vejledningen indeholder hjælp til selvhjælp, tjeklister, oversigter med videre, som kan hjælpe myndigheden med at finde den rigtige løsningsmodel. Vejledningen omfatter ikke alle forhold relateret til indførelsen af de nye obligatoriske åbne dokumentformater, men vil søge at svare på de mest centrale spørgsmål og udfordringer. 1.2 Målgruppen for vejledningen Vejledningens primære målgruppe er forretningsansvarlige og it-ansvarlige i offentlige myndigheder indenfor stat, regioner og kommuner. Den forretningsansvarlige får et indblik i de beslutninger og konsekvenser, der følger med kravene om anvendelse af åbne standarder for dokumentudveksling i det offentlige; den it-ansvarlige får konkret vejledning i, hvordan den praktiske implementering af kravene kan gennemføres. Vejledningens sekundære målgruppe er leverandører af it-løsninger, der håndterer redigerbare tekstdokumenter. It-leverandører kan med vejledningen få indsigt i, hvilke krav der stilles til deres offentlige kunders understøttelse af de åbne dokumentstandarder. Hvem er omfattet? Alle offentlige myndigheder er omfattet. Ved offentlige myndigheder forstås kommunale og regionale forvaltninger, statslige departementer, styrelser og direktorater. Eksempelvis er den kommunale forvaltning på rådhuset omfattet, men ikke den kommunale skole. Den regionale forvaltning er omfattet, men ikke det enkelte sygehus. Den statslige forvaltning - departement, styrelse og direktorat - er omfattet, men ikke statslige eller selvejende institutioner som universiteter, museer mv. Kravene gælder for de samme myndigheder, som er underlagt kravene fra edag1 og edag2. Vejledningen forventes også at have interesse for private virksomheder, borgere, offentlige myndigheders samarbejdspartnere mv. Vejledningen er ikke udarbejdet til direkte brug for supportfunktion og brugere internt i myndighederne. En sådan vejledning bør myndighederne selv udarbejde på baggrund af de konkrete implementeringer myndigheden foretager. 7

157 Bilagssamling Side 157 af 379 > 1.3 Baggrund kort om B juni 2006 vedtog Folketinget enstemmigt beslutningsforslag B103 om anvendelse af åbne standarder for software i det offentlige 2. Videnskabsministeren har efterfølgende, efter drøftelse, og i fuld enighed med Folketingets it-ordførere, lagt en køreplan for den fremtidige anvendelse af åbne standarder. Den 3. oktober 2007, indgik regeringen en "Aftale om anvendelse af åbne standarder for software i det offentlige" med Danske Regioner og KL. Det er denne aftale, der er udgangspunktet for denne vejledning. Det følger af aftalen, at fra 1. januar 2008 bliver en række åbne standarder obligatoriske at anvende for offentlige myndigheder. Det betyder, at nye offentlige it-løsninger skal understøtte disse obligatoriske, åbne standarder De to obligatoriske, åbne dokumentstandarder Standarderne for dokumentudveksling er ét sæt af standarder, og indgår som det ene sæt ud af syv sæt af obligatoriske, åbne standarder, som træder i kraft fra 1. januar De to obligatoriske, åbne standarder for redigerbare dokumentformater er: > ODF version: 1.0 (Open Document Format) godkendt som standard af standardiseringsorganisationen ISO. > OOXML version: 1.0 (Office Open-XML) godkendt som standard af standardiseringsorganisationen ECMA Anvendelseskrav for dokumentstandarder Modtagelse Fra 1. januar 2008 skal offentlige myndigheder kunne modtage tekstbehandlingsdokumenter fra borgere, virksomheder og andre myndigheder i de to åbne dokumentformater ODF og OOXML, evt. ved brug af tilføjelsesprogrammer (convertere i form af applikationer, plug-ins eller services). Det bemærkes, at kravet alene vedrører modtagelse. Modtagelseskravet medfører således ikke at offentlige myndigheder er forpligtet til at kunne afsende dokumenter i ODF- og OOXML-formatet. 2 Jf. 8

158 Bilagssamling Side 158 af 379 > Anskaffelse Pr. 1. januar 2008 bliver ODF og OOXML obligatoriske standarder for offentlige myndigheder. Dvs. at it-løsninger, der anskaffes 3 efter 1. januar 2008, skal understøtte mindst én af de åbne dokumentstandarder ODF og OOXML (og stadig kunne modtage tekstbehandlingsdokumenter i begge formater), hvis behandling af tekstbehandlingsdokumenter er relevant for it-løsningen. Dette er især tilfældet for kontorapplikationer og elektroniske dokumenthåndteringssystemer, men det kan også have relevans for CMS, fagsystemer og andre it-løsninger. Kravet medfører ikke, at offentlige myndigheder er forpligtet til at indkøbe nye tekstbehandlingsprogrammer Hvad betyder det, at standarden er åben? Standarden skal være: > fuldstændigt dokumenteret og offentligt tilgængelig, > frit implementérbar uden økonomiske, politiske eller juridiske begrænsninger på implementering og anvendelse, hverken nu eller i fremtiden, og > standardiseret og vedligeholdt i et åbent forum via en åben proces (standardiseringsorganisation) Hvorfor indføre obligatoriske, åbne standarder? Indførelsen af åbne standarder skal, uden at det medfører øgede udgifter for det offentlige, fremme et konkurrencepræget marked for software og medvirke til, at offentlige it-systemer uanset valg af software kan udveksle informationer på tværs. Endelig vil de medvirke til, at fremtidige forandringer i teknologi, organisation og opgaveløsning bliver enklere og mindre bekostelige Vedligeholdelse af kravet om dokumentstandarder Om ODF og/eller OOXML skal være obligatoriske, åbne standarder efter 1. juli 2009 afgøres efter en vurdering af en uafhængig tredjepart. Derfor er perioden fra 1. januar 2008 til afgørelsen i 2009 formelt at betragte som en forsøgsperiode. Som led i vurderingen indgår blandt andet: > Softwareleverandørernes evne til at sikre interoperabilitet mellem de to standarder i deres produkter i forhold til det offentliges udvekslingsbehov. > De reelle muligheder for og de praktiske erfaringer med at implementere standarderne uafhængigt af leverandør og platform. 3 Ved anskaffelser forstås eksempelvis: nyindkøb, opgraderinger og udvikling, med mindre dette foregår som en del af en allerede indgået aftale. 9

159 Bilagssamling Side 159 af 379 > > En konkret vurdering fra Konkurrencestyrelsen om effekten af anvendelse af obligatoriske åbne standarder for dokumentudveksling på konkurrencesituationen. At der formelt er tale om en forsøgsperiode ændrer imidlertid ikke på det forhold, at standarderne er obligatoriske fra 1. januar Afgrænsning og præcisering Vejledningen er afgrænset og præciseret som følger: Dokumentformater ODF og OOXML Vejledningen vedrører alene de to åbne dokumentformater ODF og OOXML. Dog indgår den mest benyttede lukkede standard DOC 4, som er Microsofts lukkede dokumentformat, også i vejledningen, idet formatet repræsenterer mange myndigheders virkelighed i dag, og samspillet mellem DOC, ODF og OOXML vil spille en rolle for myndigheder i 2008 (DOC vurderes at være formatet for over 90% af tekstbehandlingsdokumenterne i offentlige myndigheder). Kravene fra 1. januar 2008 om dokumentformater vedrører alene de redigerbare dokumentformater ODF og OOXML. Det offentliges nuværende udvekslingsformat for ikke-redigerbare dokumenter, PDF, vurderes ikke i projektet, ligesom håndtering og udveksling af øvrige formater som hjemmesideformater, regnearksformater og præsentationsformater ikke er behandlet i vejledningen. Vejledningen indeholder ikke en vurdering af standardernes konkrete indhold eller deres modenhed (udover hvad der eventuelt på baggrund af pilotforsøg og laboratorietest giver anledning til at vejlede myndighederne) Specielt om ODF- og OOXML-filtyper Implementeringer af såvel ODF som OOXML omfatter i praksis en række forskellige filtyper 5. Filtyper indikeres via filnavnet eksempelvis.docx eller.odt. Filtyperne og dermed deres navne er i nogen udstrækning fastlagt af de enkelte leverandører og indikerer i varierende omfang dokumentets indhold. Da beslutningen om åbne dokumentformater kun omfatter redigerbare tekstdokumenter til udveksling, gælder kravene kun de filtyper, som falder inden for denne definition. For en oversigt over de filtyper, som i dag er defineret under formaterne OOXML og ODF, henvises til oversigten over filtyper på 4 DOC er dokumentformatet i Microsoft Word for versioner før Microsoft Office 2007-pakken, men er også understøttet i Office 2007, der understøtter både OOXML og DOC, samt i OpenOffice, som understøtter både ODF og DOC. 5 Fil-typer kaldes også filekstensioner eller efternavne. 10

160 Bilagssamling Side 160 af 379 > dokumentformater.oio.dk/leverancer. For gode råd om anvendelse af filtyper henvises til afsnit , pkt Dokumenttyper redigerbare tekstbehandlingsdokumenter Beslutningen om to åbne dokumentformater gælder kun redigerbare tekstbehandlingsdokumenter. Det anbefales fortsat at benytte formatet PDF til udveksling af færdige publikationer og dokumenter, som myndighederne ikke forventer, der skal redigeres i igen, dvs. såkaldt statiske dokumenter 6. I vejledningen prioriteres det at belyse scenarier, hvor det offentlige udveksler redigerbare dokumenter, uanset om disse læses eller redigeres. Udveksling af ikkeredigerbare dokumenter falder dermed som udgangspunkt uden for vejledningsindsatsen Funktionalitet anvendt i dokumenter funktionalitetsloft Tekstbehandlingssystemer har en lang række funktionaliteter, spændende fra simpel formatering til avanceret grafik, høringsfunktion osv. Vejledningen forholder sig ikke til alle funktionaliteter, men tager udgangspunkt i de funktionaliteter, som gennem projektets dialog med myndigheder er identificeret som myndighedernes faktiske og mest væsentlige udvekslingspraksis og behov. Dette har vi valgt at kalde funktionalitetsloftet. Funktionalitetsloftet afspejler således ikke alle mulige udvekslingsbehov mellem myndigheder, men de prioriterede udvekslingsbehov. For en beskrivelse af Funktionalitetsloft, henvises til dokumentformater.oio.dk/leverancer. Det er vigtigt at understrege, at der ikke er krav om, at I kan udnytte samtlige de funktionaliteter og elementer, som kan være indlejret ODF og OOXML, selvom I skal kunne modtage forskellige varianter af filtyper under OOXML og ODF jf. afsnit Software al software, der skal kunne håndtere redigerbare tekstbehandlingsdokumenter Den berørte software er ikke kun tekstbehandlingssystemer, men kan eksempelvis også være ESDH, mail, CMS eller fagsystemer. Det afgørende i forbindelse med løsninger, der indkøbes efter 1. januar 2008 er, at softwaren skal kunne håndtere redigerbare tekstbehandlingsdokumenter. Vejledningen indeholder ikke anbefalinger af specifikke leverandører og produkter. Vejledning indeholder heller ikke anvisninger på, hvordan leverandørerne kan blive klar til at håndtere de nye standarder. Nøgleleverandører har dog selvevalueret 6 Anbefalingen af PDF som fastholdelsesformat til færdige officielle dokumenter og post til borgerne indgår som en del af den eksisterende edag-aftale. 11

161 Bilagssamling Side 161 af 379 > udvalgte løsninger. Disse leverandørers parathedsvurderinger findes på dokumentformater.oio.dk Dokumentudveksling kun mellem myndigheder og dens interessenter Beslutningen gælder kun udveksling af redigerbare tekstbehandlingsdokumenter mellem myndigheden og dens interessenter ikke myndighedens interne sagsbehandling Modtage ODF og OOXML både modtage og læse Kravet om, at alle offentlige myndigheder skal kunne modtage redigerbare tekstbehandlingsdokumenter i ODF og OOXML skal tolkes som både modtage og læse, hvor vejledningen primært behandler det at læse et modtaget tekstdokumentet i myndighedens eksisterende tekstbehandlingssystem. Vejledningen beskriver således udfordringer og mulige løsninger i forbindelse med at modtage (f.eks. per mail) og læse dokumenter i ODF- eller OOXML-format (i tekstbehandlingssystem), men også afledte problemområder vil blive beskrevet, f.eks. at arbejde videre i dokumenter i tekstbehandlingssystemer, lagre dokumenter (f.eks. i ESDH) eller publicere dokumenter (f.eks. i et CMS-system) Modtage/læse-situationer Vejledningen omfatter følgende situationer: 1. Myndigheden som anvender DOC skal kunne modtage/læse ODF 2. Myndigheden som anvender DOC skal kunne modtage/læse OOXML 3. Myndigheden som anvender ODF skal kunne modtage/læse OOXML 4. Myndigheden som anvender OOXML skal kunne modtage/læse ODF 5. Myndigheden som anvender ODF skal kunne modtage/læse DOC 6. Myndigheden som anvender OOXML skal kunne modtage/læse DOC Situation 1 og 2 vil være de mest typiske situationer, da de fleste myndigheder i dag anvender DOC-formatet. Udfordringer og mulige løsninger forbundet med disse to situationer er beskrevet i afsnit ( Udfordringer og mulige løsningsmodeller for myndigheder der benytter DOC ). Situation 3 og 4 vil være nye for de myndigheder, der allerede i dag gør brug af enten ODF- eller OOXML-formatet og nu skal til at modtage/læse det andet åbne dokumentformat. Udfordringer og mulige løsninger forbundet med disse to situationer er beskrevet i hhv. afsnit ( Udfordringer og mulige løsningsmodeller for myndigheder der benytter ODF ) og ( Udfordringer og mulige løsningsmodeller for myndigheder der benytter OOXML ). Situation 5 og 6 vil være kendte for de myndigheder, der allerede i dag gør brug af enten ODF eller OOXML, men nye for de myndigheder, der anskaffer ny kontorpakke efter 1. januar 2008, og forventeligt stadig modtager DOC fra mange myndigheder. Udfordringer og mulige løsninger forbundet med disse to situationer er beskrevet i hhv. afsnit ( Myndighed der overvejer løsning med ODF som 12

162 Bilagssamling Side 162 af 379 > produktionsformat ) og ( Myndighed der overvejer løsning med OOXML som produktionsformat ). Det skal understreges, at det fremadrettet ikke er et krav, at kunne modtage i DOC, men ikke desto mindre forventes det at være en realitet for mange myndigheder. Det skal endvidere bemærkes, at udfordringerne forbundet med situation 3 og 4 (scenarium 2 og 3) også vil være relevante for de myndigheder, der anskaffer ny kontorpakke efter 1. januar Vejledningen indeholder ikke Vejledningen er en hjælp til myndighederne med at finde den rigtige løsningsmodel i relation til kravene om dokumentstandarder. Vejledningen er imidlertid ikke udtømmende, idet følgende f.eks. ikke er indeholdt i vejledningen: > Detaljeret vejledning i hvordan myndighederne konfigurerer løsninger og driftsmiljø. > Detaljeret vejledning i hvordan de nødvendige løsninger udrulles. > Økonomiske konsekvensvurderinger. 1.5 Metodegrundlag for vejledningen Idet standarderne ODF og OOXML kun i begrænset omfang anvendes i det offentlige i dag, har IT- og Telestyrelsen gennemført en omfattende vidensindsamling samt pilotforsøg i en række myndigheder med henblik på at indhente viden om og erfaring med standarderne. Aktiviteterne er gennemført i dialog med it-branchen og andre interesserede og i et nært samarbejde med bl.a. OIO Datastandardiserings- og IT-Arkitekturkomitéerne. Endvidere har Folketingets itafdeling, Odense Kommunes KompetenceCenter IT og Videnskabsministeriets Koncern-IT bidraget med input til vejledningens struktur og indhold Vidensindsamling Vidensindsamlingen har haft følgende formål: > at inddrage eksisterende national og international viden i pilotforsøg samt i nærværende vejledning for at give afklaring om allerede testede områder samt overblik over de funktionaliteter, der giver udfordringer i forhold til interoperabilitet. > at give input til dialog med myndigheder om, hvad der er væsentligt at se på, når samspillet mellem dokumentformaterne undersøges i projektet. > at identificere de formatrelevante funktionaliteter myndighederne oftest anvender for at sikre, at disse testes i pilotforsøg og efterfølgende er medtaget i nærværende vejledning. 13

163 Bilagssamling Side 163 af 379 > Identifikation af andres erfaringer Indsamlingen af andre danske og udenlandske erfaringer i form af studier, pilotforsøg, laboratorietest og cases om anvendelse af åbne tekstdokumentformater er dokumenteret i materialet Identificerede pointer og funktionaliteter fra projektets vidensindsamling i foråret 2007, som kan findes på dokumentformater.oio.dk. Her er studiernes erfarede problemer med sameksistens mellem de to tekstdokumentformater listet, og det er angivet, om der er anvist løsning, eller om der på vidensindsamlingstidspunktet stadig udestod en udfordring. Denne viden blev brugt primært til at indkredse hvad pilotforsøgene skulle teste. Funktionalitetsloft - identifikation af de væsentligste funktionaliteter Bruttolisten over allerede identificerede erfaringer har sammen med en analyse af konkrete eksempler på myndigheders dokumenter givet input til en oversigt over områder af formatrelevant funktionalitet i tekstdokumenter f.eks. formatering eller anvendelse af tabeller. Funktionalitetsområderne er angivet i før omtalte dokument Identificerede pointer og funktionaliteter, som kan findes på dokumentformater.oio.dk. Listen over funktionalitetsområder er udviklet og kvalitetssikret i samarbejde med myndigheder og ved interview dels med leverandører med viden om myndighedernes anvendelse af funktionaliteter, dels med medarbejdere hos myndigheder, der har erfaring med brugerundervisning. Fokus har været på at afgrænse interessante funktionalitetsområder til at omfatte et antal væsentlige funktionaliteter, så hovedparten af myndighedernes behov er dækket. Dermed er et funktionalitetsloft dannet. Funktionalitetsloftet har defineret det relevante fokus i pilotforsøg og test samt i dialogen med de offentlige myndigheder med hensyn til, hvad der er væsentligt at se på, når samspillet mellem dokumentformaterne undersøges i projektet. Det endelige konsoliderede funktionalitetsloft er publiceret på dokumentformater.oio.dk/leverancer Pilotforsøg (pilotforsøg og paralleltest) og laboratorietest Der er gennemført pilotforsøg, paralleltest og laboratorietest med fokus på dokumentudveksling mellem myndigheder. Pilotforsøg og paralleltest er gennemført i samarbejde med myndigheder på tværs af stat, regioner og kommuner: Pilotmyndighed Ansvarlig Direktoratet for FødevareErhverv Jari Bøg jabl@dffe.dk Gribskov Kommune Michel van der Linden mvdli@gribskov.dk Region Midtjylland Henrik Jordt henrik.jordt@stab.rm.dk Statens Arkiver Anders Bo Nielsen abn@ra.sa.dk Århus Kommune Peter Henriksen ph@mag1.aarhus.dk Laboratorietest er gennemført i samarbejde med en række centrale leverandører. Metoden for disse forsøg og test er nærmere beskrevet i dokumentet Metodemæssige ramme for gennemførelse af test, v. 1.0 på dokumentformater.oio.dk/leverancer og er kort skitseret nedenfor. 14

164 Bilagssamling Side 164 af 379 > Pilotforsøg Formål Metode Formålet med pilotforsøget har været at indhente praktiske erfaringer med de udfordringer, der kan opstå ved at konvertere mellem dokumentformaterne Pilotmyndigheden har 1) udvalgt en række dokumenter fra deres forvaltning, der indeholdt de funktioner inden for funktionalitetsloftet, som de vurderede relevante 2) taget udgangspunkt i det tekstbehandlingssystem(er) og de driftsplatforme, som pilotmyndighederne normalt anvender 3) givet input til de udvalgte testscenarier for at gøre disse så virkelighedsnære som muligt 4) valgt en (eller flere) converter(e), som kan konvertere til og/eller fra de formater, der er relevante for pilotmyndigheden 5) selv forestået arbejdet med konvertering af dokumenterne i forhold til de specificerede testscenarier Myndigheden har således gennemført en række veldefinerede testscenarier, som tilsammen har givet et billede af de udfordringer, der er forbundet med at modtage og læse dokumenter i ODF eller OOXML-format i et tekstbehandlingssystem, men også afledte udfordringer f.eks. i forbindelse med efterfølgende at arbejde videre i dokumentet i tekstbehandlingssystemet, lagre dokumentet i et ESDH-system eller i forbindelse med publicering af dokumentet i et CMS-system. Efter konvertering af dokumentet var konverteret fra format A til format B, gennemføres en visuel kontrol af de konkrete funktionaliteter i dokumentet. Derudover gennemføres en generel vurdering. Ved fejl i konverteringen er det blevet afdækket, hvor i processen fejlen er opstået. Nærmere analyse er sket ved research eller gennem paralleltest og laboratorietest, se nedenfor. Paralleltest Formål Metode I de situationer, hvor gennemførelse af pilotforsøget med fordel kunne suppleres med yderligere test, er der gennemført paralleltest. Formålet har været at undersøge fejlkilder og om-teste scenariet med andre teknologier f.eks. med andre convertere. Paralleltestene er gennemført i piloternes egne miljøer. En række parametre kan ændres, således at paralleltesten giver en værdimæssig tilførsel til testen: - Converteren - Testdokumentet - Redigering i testdokument for provokation af isolerede hændelser - Styresystem - Tekstbehandlingsapplikation Ændring af ovennævnte parametre er sket i tæt samarbejde med pilotmyndigheden, da ændringerne er foretaget i myndighedens testmiljø og testgrundlag. Det er pilotmyndigheden, der har taget beslutning om behovet for paralleltest ud fra de testresultater, der forelå efter pilotforsøget. Laboratorietest Formål Laboratorietest er en testform, der har givet mulighed for en detaljeret test af konkret funktionalitet i et isoleret testmiljø på baggrund af kontrollerede og konstruerede dokumenter eller på en specifikt defineret testkonfiguration. Formålet med laboratorietesten har primært været at undersøge observationer fra de tidligere gennemførte pilotforsøg og paralleltest for at skabe et solidt og konsistent udgangspunkt for vejledningsindsatsen. 15

165 Bilagssamling Side 165 af 379 > Laboratorietest Metode Der er fra starten af pilotprojektet planlagt gennemførelse af laboratorietests. Input til disse er defineret ud fra en liste over erfaringsmæssige problemområder ved konvertering. Disse problemområder er udvalgt ud fra en kritiskhedsfaktor, hvor de, der er vurderet kritiske pga. indholdstab, er indstillet til laboratorietest. Resultatet af forsøg og test, og de vejledningsmæssige konsekvenser, er beskrevet i to konsoliderende rapporter: en vedrørende pilotforsøgene og en vedrørende laboratorietesten. Herudover er der udarbejdet et sammenfattende notat. De konsoliderende rapporter bygger på en række tekniske testrapporter. 1.6 Læsevejledning Hvilke afsnit, du bør læse i vejledningen, afhænger af dit ansvarsområde og jeres myndigheds eller virksomheds situation: > Hvis du er myndighedens forretningsansvarlige, bør du læse afsnit 2 (Hvad betyder de obligatoriske, åbne standarder for dokumentudveksling for jer forretningsmæssigt perspektiv), der angiver hvilke beslutninger og konsekvenser, kravet om åbne dokumentstandarder forventes at medføre. Du bør også læse udvalgte dele af afsnit 3 (Kravet om at kunne modtage ODF og OOXML) > Hvis du er myndighedens it-ansvarlige, bør du læse afsnit 3 (Kravet om at kunne modtage ODF og OOXML), som giver praktiske anvisninger på, hvordan du sikrer, at myndigheden kan overholde kravet om at kunne modtage ODF og OOXML pr. 1. januar > Hvis du er myndighedens it-ansvarlige og myndigheden står overfor at skulle anskaffe ny kontorpakke eller andre dokumenthåndterende systemer bør du læse afsnit 4 (Kravet om at understøtte de obligatoriske, åbne dokumentstandarder ved nyanskaffelser, opgraderinger mv.), som giver praktiske anvisninger på, hvad du bør forholde dig til, når du efter 1. januar 2008 står over for en system-anskaffelse med implikationer for redigerbar tekstbehandling. > Leverandører af it-systemer til offentlige myndigheder kan med fordel læse afsnit 4, der kan give et indblik i de udfordringer, myndighederne står over for. 16

166 Bilagssamling Side 166 af Hvad betyder de obligatoriske, åbne standarder for dokumentudveksling for jer forretningsmæssigt perspektiv > I dette afsnit beskrives de forretningsmæssige overvejelser og konsekvenser, der følger med kravet om åbne dokumentstandarder til dokumentudveksling i det offentlige. 2.1 Hvilke fordele kan åbne dokumentstandarder give jer? Standardiseringen og åbne standarder giver potentiale for større effektivitet og bedre opgaveløsning. Standarderne skal sikre sammenhæng mellem det offentliges itsystemer og fremme konkurrencen mellem leverandørerne. Udbredte og anerkendte standarder er en forudsætning for, > større konkurrence og valgmulighed mellem flere producenter og leverandører på et område, hvor flere systemer og komponenter skal spille sammen, > at der kan være bedre samspil (interoperabilitet) mellem flere systemer, løsninger og organisationer, og > at det bliver overskueligt at ændre opgaver og organisering uden at skulle udskifte it-løsninger, dvs. myndighederne opnår større fleksibilitet. De obligatoriske, åbne dokumentstandarder er formater baseret på XML, hvilket vil give bedre mulighed for at integrere og overføre informationer direkte mellem dokumenter og forretningssystemer. Samtidig giver de nye åbne formater mulighed for, at dokumenter kan genereres uafhængigt af kontorpakker, da formatet er det styrende. Leverandørparathedsvurderingen (publiceret på dokumentformater.oio.dk i november 2007) belyser bl.a., hvordan de enkelte leverandører kan tilføre ekstra værdi gennem anvendelse af de åbne standarder i deres software. 2.2 Hvordan kommer I i gang? For at blive klar til at kunne modtage tekstbehandlingsdokumenter fra borgere, virksomheder og andre myndigheder i formaterne ODF og OOXML pr. 1. januar 2008, er nedenfor anbefalet en række initiativer, I kan tage for at komme godt i gang. Listen af initiativer er ikke udtryk for den rækkefølge, som initiativerne bør gennemføres i. Anbefaling Udpeg en intern ansvarlig Uddybning Den internt ansvarlige skal sikre, at jeres myndighed bliver parat til at opfylde kravet om anvendelse af åbne dokumentstandarder Den internt ansvarlige skal allerede nu forberede jeres myndighed på at træffe de nødvendige beslutninger, inden kravet om anvendelse af de obligatoriske sæt af åbne standarder træder i kraft 1. januar Den internt ansvarlige skal identificere de nødvendige opgaver og roller og sikre, der bliver taget stilling til ansvarsplacering Den internt ansvarlige skal sikre, at der bliver udpeget en relevant teknisk løsning og sikre drift inden 1. januar

167 Bilagssamling Side 167 af 379 > Anbefaling Informer jeres medarbejdere om modtagelseskravet pr. 1. januar 2008 Afdæk jeres behov for at kunne modtage tekstdokumenter i formaterne ODF og OOXML Overvej jeres ambitionsniveau i forbindelse med modtagelse af de nye dokumentformater Overvej jeres ambitionsniveau i forbindelse med nyanskaffelser Forbered driftssituationen Indled en dialog med relevante systemleverandører Uddybning Informer alle relevante medarbejdere om, at jeres myndighed pr. 1. januar 2008 skal kunne håndtere modtagne tekstdokumenter i formaterne ODF og OOXML. Medarbejderne må ikke afvise at modtage disse dokumenter. Informer medarbejdere om, at der inden 1. januar 2008 vil blive implementeret en løsning, der vil sikre, at jeres myndighed kan modtage disse to dokumentformater. Undersøg hvor i organisationen, der i dag modtages tekstdokumenter i formaterne ODF og OOXML, og hvor mange det drejer sig om. Kortlæg hvilke andre myndigheder, I oftest udveksler dokumenter med, og hvilke tekstbehandlingssystemer/formater, de benytter. Formålet er, at I bliver i stand til at vurdere jeres konverteringsbehov og dermed at dimensionere og organisere jeres løsning. Sæt jer grundigt ind i de mulige konverteringsløsninger på dokumentformater.oio.dk/leverancer og hold jer løbende informeret (der kommer løbende nye konverteringsløsninger). Der er publiceret en ajourført converterkortlægning ultimo november 2007, som igen bliver ajourført medio Kravet er, at alle myndigheder pr. 1. januar 2008 som minimum skal kunne modtage de to tekstdokumentformater ODF og OOXML. Som myndigheder kan I imidlertid overveje, om I ønsker, at kunne mere end blot modtage (læse) de to dokumentformater. F.eks. kan jeres myndighed have en interesse i også at kunne gemme tekstdokumenter i de to formater i et dokumenthåndteringssystem, eller have en interesse i også at publicere informationer på nettet i de to formater. Kravet er, at alle myndigheder pr. 1. januar 2008 ved nyanskaffelser, opgraderinger og udvikling af nye systemer skal kunne understøtte mindst én af de åbne dokumentformater. I skal overveje, hvor ambitiøse I vil være i forhold til udnyttelse af de nye dokumentformaters muligheder. Identificer de driftsopgaver, som skal håndteres i organisationen som følge af de nye krav. Fastlæg eventuelle driftsaftaler Fastlæg ansvar for udførelsen af driftsopgaverne. Hvis jeres myndighed har systemrelaterede behov ud over, hvad I selv kan håndtere, bør I indlede en dialog med relevante systemleverandører om muligheder for evt. tilpasning af jeres nuværende systemer til håndtering af ODF og/eller OOXML. Som en del af vejledningen er der på dokumentformater.oio.dk publiceret en oversigt over leverandørernes egen vurdering af deres systemers parathed i forhold til håndtering af de to dokumentformater. 18

168 Bilagssamling Side 168 af 379 > Anbefaling Skab jeres første egne erfaringer med de to dokumentformater Indrapporter jeres tekniske udfordringer til leverandørerne Uddybning Hvis jeres myndighed er i tvivl om, hvorvidt I kan modtage og i øvrigt håndtere tekstdokumenter i ODF og OOXML, bør I foretage nogle indledende forsøg med de to formater i de relevante applikationer. Som del af vejledningsindsatsen er der publiceret en Test-selvpakke, som indeholder nogle test-dokumenter i de to formater, samt vejledning i anvendelse af disse. Pakken kan I hente på dokumentformater.oio.dk/leverancer. Overvej etablering af procedurer for at monitorere implementering og eventuelle problemer i en overgangsperiode, f.eks. hvem skal jeres medarbejdere henvende sig til, hvis de modtager en fil i ODF eller OOXML og har problemer med det efter 1. januar 2008? Erfaringerne fra projektets pilotforsøg og laboratorietest har været, at leverandørerne gerne vil løse de tekniske udfordringer for myndighederne. Er der et behov hos mange myndigheder, prioriterer de problemløsningen. Derfor bør I indrapportere de fejl og udfordringer, som I finder, så leverandørerne får nemmere ved at sikre jer de rigtige løsninger i den rigtige kvalitet Hvad gør I allerede? Sandsynligvis modtager I allerede i dag redigerbare tekstdokumenter i ODF og OOXML. Men hvor I i dag, i princippet, har mulighed for at afvise disse formater og bede afsenderen om at genfremsende i et andet format, er dette ikke en mulighed efter den 1. januar Kravet om at kunne modtage ODF og OOXML vil i praksis kunne løses på samme måde, som I måske allerede gør brug af i dag, hvis en borger sender et dokument til jer i et fremmed format, f.eks. ved at etablere en mulighed for konvertering af det modtagne dokument til et dokumentformat, der kan læses af jeres systemer Hvad forbliver uændret? Det er vigtigt at understrege, at selvom indførelsen af obligatoriske, åbne standarder har en række konsekvenser, forbliver meget uændret. > I er ikke forpligtet til at indkøbe nye tekstbehandlingsprogrammer som følge af de obligatoriske standarder. Kravet om at kunne modtage tekstbehandlingsdokumenter i både ODF- og OOXML-formatet kan ofte løses ved brug af en converter eller en viewer (se nærmere afsnit 3.2.2). > Udover at gøre jer klar til at modtage i de nye dokumentformater, behøver I ikke tilpasse eksisterende it-løsninger til de obligatoriske, åbne standarder. De obligatoriske, åbne standarder gælder udelukkende for nye løsninger. > I er ikke underlagt et forbud mod anvendelse af andre standarder end de obligatoriske, åbne standarder. Nye it-løsninger må således gerne anvende andre standarder end de obligatoriske, åbne standarder, så længe løsningerne også er 19

169 Bilagssamling Side 169 af 379 > baseret på, eller understøtter, anvendelsen af de relevante obligatoriske, åbne standarder. > I er ikke tvunget til at bruge bestemte typer software. Der er således ingen krav om at anvende bestemte typer eller leverandører af software, og der er ingen krav om, at de pågældende formater anvendes som det interne format i softwaren. 2.3 Hvilke beslutninger skal I træffe? Såfremt jeres indledende erfaringer med de to dokumentformater ODF og OOXML viser, at I i dag ikke kan modtage og læse de to formater, er der en række beslutninger, I skal træffe Vælge ambitionsniveau Kravet om at kunne modtage ODF og OOXML kan i praksis løses på forskellige måder. Én løsning er at etablere en simpel mulighed for konvertering eller læsning af det modtagne dokument. Denne løsning er "minimum-scenariet". En anden løsning er fuld integration af ODF og OOXML i alle systemer, der håndterer redigerbare tekstbehandlingsdokumenter. Denne løsning er maksimum-scenariet og kan være relevant, hvis I står overfor at skulle anskaffe nye systemer, men kan i enkelte tilfælde også være relevant, hvis det forretningsmæssige konverteringsbehov tilsiger det. I skal som myndighed beslutte hvilket ambitionsniveau, der passer til jer. For de fleste vil en pragmatisk kombination i forhold til generelle og specifikke behov være relevant Vælge systemmæssig løsningsmodel Alt efter hvilken teknisk platform I har i dag, og alt efter jeres konkrete behov for konvertering, vil flere forskellige systemmæssige løsningsscenarier kunne imødekomme jeres behov for at kunne håndtere de nye dokumentformater. Typisk inkluderer den systemmæssige del af løsningen en eller flere convertere. Her skal I træffe beslutning om, hvilken konverteringsløsning, der passer bedst til jeres behov. De fleste convertere er i dag gratis at anskaffe. I kan se de mulige konverteringsløsninger på dokumentformater.oio.dk/leverancer og holde jer løbende informeret (der kommer løbende nye konverteringsløsninger). De forskellige løsningsscenarier og convertere kan I endvidere læse mere om i afsnit (Systemmæssige muligheder) Vælge organisatorisk løsningsmodel De systemmæssige løsninger skal vurderes i forhold til jeres behov og ambitionsniveau, og implementeres organisatorisk i overensstemmelse hermed. Her skal I træffe valg om implementering af en af de følgende modeller: 20

170 Bilagssamling Side 170 af 379 > > Fuld udrulning: I kan vælge at udrulle en given konverteringsløsning til samtlige brugere. > Differentieret udrulning: Hvis jeres organisation har brugere med forskellige konverteringsbehov, kan I vælge at differentiere mellem løsningerne til forskellige brugergrupper. F.eks. udrulning i hele organisationen, men hvor én brugergruppe får én løsning og en anden gruppe en anden løsning. > Delvis udrulning: Hvis I vurderer, at ikke alle brugere vil have behov for konverteringsmuligheden, kan I vælge en delvis udrulning, dvs. at visse brugergrupper eller afdelinger ikke får en løsning. > Central løsning: I kan vælge en centraliseret model, hvor f.eks. service desken eller journalen forestår al konvertering af dokumenter for brugerne. I kan læse mere herom i afsnit (Organisatoriske muligheder) Vælge metode for imødegåelse af forventelige konverteringsproblemer Da dokumentformaterne ODF, OOXML og DOC ér forskellige, kan konvertering ikke altid forventes gennemført 100% korrekt. Dette forhold er også dokumenteret via pilotforsøg og laboratorietest, hvor en række udfordringer ved konvertering af tekstdokumenter fra et format til et andet er identificeret. Det vil i praksis sige, at det ved konvertering kan forekomme, at dele af dokumenternes formatering eller indhold bliver ændret eller helt forsvinder, hvilket i værste tilfælde kan få betydning for forståelsen af indholdet af dokumentet. Derfor skal I træffe beslutning om hvilke metoder, I vil anvende til at imødegå konverteringsproblemer. De mulige metoder spænder fra helt at forsøge at undgå, at der opstår konverteringsproblemer (f.eks. ved at undgå at anvende tekstbehandlingsfunktionalitet, der forventeligt giver konverteringsproblemer) til implementering af kvalitetsprocedurer, der skal fange og udbedre fejl opstået ved konvertering. I kan læse mere herom i afsnit 3.5 (Gode råd om driften) Sikre dokumenternes juridiske validitet Idet I kan risikere at miste indhold ved konverteringen, er det rimeligt at stille spørgsmål om, hvilken betydning det vil få, hvis I ikke gemmer og kan se det oprindelige dokument. Kan I f.eks. tillade jer at konvertere modtagne dokumenter og lagre dem i nyt format? Skal I gemme i originalt format? Eller skal I gemme begge formater? For nogle dokumenter herunder dokumenter af juridisk gyldighed er det afgørende, at det konverterede elektroniske dokument har den samme bevisværdi som det originale elektroniske dokument. Der findes imidlertid ikke en etableret retspraksis vedrørende bevisværdien af elektroniske dokumenter, herunder af konverterede elektroniske dokumenter. Om nødvendigt må afklaring af et elektronisk dokuments bevisværdi ske ved domstolene. 21

171 Bilagssamling Side 171 af 379 > I skal som myndighed derfor overveje, om originaldokumentet skal gemmes ved modtagelsen 7, og I skal overveje, hvordan I sikrer det konverterede dokuments kvalitet, eventuelt gennem en sammenligning med originalen. For hvilke dokumenter og i hvilke tilfælde særlige procedurer indtræder, må bero på en risikovurdering. Hver enkelt myndighed må vurdere hvilken løsning, der er mest hensigtsmæssig for jer, og I bør i den forbindelse fastlægge, dokumentere og kommunikere jeres arbejdsgange. Denne vejledning omhandler, hvordan I som myndighed kan sikre de konverterede dokumenters validitet bedst muligt ud fra den viden, som projektet har indsamlet inden for funktionalitetsloftet ikke hvorledes jeres kvalitetssikringsprocedurer bør se ud. IT- og Telestyrelsen anbefaler, at I kun iværksætter særlige kvalitetssikringsprocedurer i tilfælde, hvor omstændighederne kræver det. Ud over IT-Sikkerhedsrådets vejledning om sikring af digitale dokumenters bevisværdi fra 1998 kan I finde vejledning om krav til dokumenthåndtering i Statens Arkivers vejledning til cirkulære om anmeldelse og godkendelse af elektroniske journaler og elektroniske dokumenthåndteringssystemer fra Hvordan vil det fungere i dagligdagen? Når I som myndighed kommer i den situation, at I er nødt til at konvertere et dokument for at kunne læse det, skal I som nævnt være opmærksomme på, at I kan risikere at formateringen ændrer sig, og at I i værste fald kan miste indhold. Eksempler på typiske problemer, der kan opstå ved konvertering er: > Tabeller og tekstbokse forsvinder > Indsatte objekter (f.eks. regneark) forsvinder > Figurer og tegninger rykkes væk fra deres oprindelige placering > Layout, som f.eks. linjeafstand, sideskift, rammer om logoer og lignende, rykkes eller ændres > Sidehoved og sidefod ændres, f.eks. sidenummerering Denne vejledning peger på nogle af de typiske konverteringsproblemer, I som myndighed vil kunne støde på. Vejledningen anviser endvidere mulige løsninger på udfordringerne som f.eks., at den enkelte myndighed kan overveje: 7 Nogle myndigheder har allerede den praksis, at den originale version af dokumentet altid arkiveres ved modtagelsen, og at det konverterede dokument gemmes sammen med det originale. 8 Jf. 22

172 Bilagssamling Side 172 af 379 > > at beslutte et funktionalitetsloft, som skal være med til at sikre, at I undgår at anvende funktioner, der med stor sandsynlighed ikke konverteres korrekt. > at tilpasse jeres dokumentskabeloner til det valgte funktionalitetsloft. > at gennemgå jeres procedurer for, hvornår I sender dokumenter i PDF-format i stedet for redigerbare formater. I bør således vurdere, om der er et reelt behov for at udveksle dokumenter i et redigerbart format, eller om dokumenter kan sendes som PDF, der giver den optimale fastholdelse af indhold. > at vurdere hvilke dokumenter, I vil lave kvalitetscheck af efter konvertering, og indføre tjekrutiner for disse udvalgte dokumenter. > som supplement at installere en kontorpakke eller en viewer, der understøtter det pågældende format. > at indrapportere jeres tekniske problemer til leverandørerne. Vores erfaringer i projektets pilotforsøg og laboratorietest har været, at leverandørerne gerne vil løse de tekniske udfordringer for myndighederne. Kommer presset fra mange myndigheder, prioriterer de problemknusningen. For en mere detaljeret beskrivelse af konkrete udfordringer og løsningsforslag henvises til afsnit 3.5 Gode råd om driften hvilke udfordringer og løsningsmuligheder har I?. 2.5 Hvad skal der til? Hvor stor en indsats, I står overfor, afhænger helt af det ambitionsniveau og dermed den løsning, I vælger at implementere. Fælles for alle løsninger er imidlertid at > den tekniske del af løsningen skal implementeres > organisationen skal gøres parat vidensmæssigt og teknisk > nye procedurer skal beskrives (vejledning i hvordan gør vi det? ) > brugere og supportfunktion skal forberedes og i visse situationer måske uddannes Derfor er det vigtigt, at I sætter jeres ambitionsniveau ud fra de behov, I har identificeret. Tænk over, hvad arbejdsbyrden bliver for den eller de medarbejdere, der skal foretage konverteringer, sådan at I ikke får skabt flaskehalse eller unødvendige arbejdsgange, og heller ikke bruger unødvendige ressourcer på implementering af en konverteringsløsning, der derefter ikke bliver brugt. Samtidig skal I også være fremsynede. De udfordringer, I vil møde omkring ændring og tab af indhold, når I konverterer, er en afspejling af, at de åbne dokumentformater, ODF og OOXML, er nye standarder, og derfor sker der en markant teknologisk udvikling lige nu især inden for converterudvikling. Læg jeres ambitionsniveau og løsningsvalg sådan, at I kan bygge oven på eller skifte konverteringsløsning i fremtiden, hvor der sandsynligvis vil være endnu bedre 23

173 Bilagssamling Side 173 af 379 > mulighed for at automatisere konverteringerne og mindre behov for kvalitetskontroller. Når I fra starten skal foretage valg af løsning, der afspejler ovenstående, må I gennem et samarbejde mellem it-funktion og forretning analysere de tilgængelige løsninger og deres fremtidsperspektiver. It-funktionen vil kunne give en række værdifulde input til forudsætninger og implementering, og forretningen vil kunne beskrive de reelle behov for konvertering og kvalitet i løsningerne. Derfor er det yderst vigtigt, af forretningen og it-funktionen går sammen om at gøre jeres myndighed parat. For konkrete råd i forbindelse med implementering af konverteringsløsning henvises til afsnit 3.6 Gode råd om implementering. 24

174 Bilagssamling Side 174 af Kravet om at kunne modtage ODF og OOXML > Alle myndigheder skal pr. 1. januar 2008 kunne modtage de obligatoriske, åbne redigerbare dokumentformater ODF og OOXML. Dette afsnit i vejledningen giver jer et overblik over, hvordan I er stillet i dag, hvilke løsningsmuligheder, der eksisterer, samt gode råd om, hvordan I kan fungere med dokumentformaterne i hverdagen. Fokus i vejledningen er på at modtage (f.eks. i mail) og læse dokumenter i ODFeller OOXML-format (i et tekstbehandlingssystem). 3.1 Hvilke udfordringer er der, og hvordan er myndighederne generelt stillet? Da det er kendt, at ODF, OOXML og DOC ikke understøtter nøjagtig de samme sæt af egenskaber og funktionaliteter, kan der være egenskaber i et dokumentformat, som ikke understøttes i et andet 9. Det betyder, at converterne kan have problemer med at oversætte indhold korrekt. Gennem en række pilotforsøg og laboratorietest, som IT- og Telestyrelsen har gennemført i samarbejde med en række myndigheder og leverandører, er der identificeret forskellige udfordringer i forbindelse med konvertering og modtagelse af de nye dokumentformater. Generelt kan det konstateres, at der i forbindelse med konvertering kan opstå varierende former for informations- og datatab. Pilotforsøgene har vist eksempler på: > Billeder forsvinder > indsatte filer, som fx ODFregneark eller Microsoft Visiodokumenter, forsvinder > Tegninger forsvinder > Tekstbokse forsvinder > Problemer ved skift mellem sprogversioner af værktøj > Forankringer flytter sig > Problemer med bl.a. indholdsfortegnelser i forbindelse med sektions- og kapitelopdelinger > Problemer ved forskellig layout på første side hhv. efterfølgende sider > Problemer vedrørende sidehoved og -fod > Tekst forskubber sig (linjeafstand og tekstfonte) > Problemer med punktopstillinger 9 Det skal dog pointeres, at OOXML er bagudkompatibelt med DOC, jf. eksempelvis office.microsoft.com/da-dk/word/ha aspx?pid=ch

175 Bilagssamling Side 175 af 379 > Der er stor forskel på kvaliteten af konverteringerne alt efter hvilke scenarier, der undersøges, hvilke convertere, der anvendes, og hvilke formater, der er tale om 10. Det skal understreges, at konvertering i de givne eksempler er ensbetydende med import af dokumenter fra et fremmed format i et tekstbehandlingssystem. Konvertering som eksport er dermed ikke undersøgt. I praksis har pilotforsøgene og laboratorietest vist, at de eksisterende convertere for nuværende ikke altid er tilstrækkelige til, at man som myndighed kan basere sig udelukkende på disse. Det er dog IT- og Telestyrelsens vurdering, at udfordringerne med rimelig sandsynlighed vil kunne afhjælpes i takt med, at kvaliteten af convertersoftware forbedres. En relevant løsningsmodel kan derfor bestå af en konverteringsløsning, som efter behov kan suppleres med en strategisk anvendelse/udrulning af en supplerende tekstbehandlingsapplikation eller viewer. Denne anbefalede tekniske løsningsmodel skal så kombineres med en hensigtsmæssig og effektiv arbejdsproces. Generelt kan det konstateres, at mere komplekse dokumenter giver større udfordringer. Men i nogle tilfælde kan også simple dokumenter give udfordringer. I praksis har pilotforsøgene og laboratorietest vist, at de eksisterende convertere for nuværende ikke altid er tilstrækkelige til, at man som myndighed kan basere sig udelukkende på disse. En relevant løsningsmodel kan bestå af en konverteringsløsning, som efter behov kan suppleres med en strategisk anvendelse/udrulning af en supplerende tekstbehandlingsapplikation eller viewer. Denne anbefalede tekniske løsningsmodel skal så kombineres med en hensigtsmæssig og effektiv arbejdsproces. I figur 1 har vi illustreret den modenhed, som generelt er observeret i brugen af convertere i de forskellige situationer, hvor man som myndighed modtager dokumentformater 11 : 10 For en detaljeret gennemgang af resultaterne fra pilot og laboratorietest, henvises til testrapporter på dokumentformater.oio.dk 11 Der er naturligvis enkelte variationer i kvaliteten mellem de enkelte convertere, men billedet er ret konsistent på tværs af teknologierne. 26

176 Bilagssamling Side 176 af 379 > Stigende modenhed Import af DOC til OOXML Import af OOXML til DOC Import af DOC til ODF Import af ODF til DOC Import af ODF til OOXML Import af OOXML til ODF Observationer inden for funktionalitetsloft Konvertering kan fungere med få udfordringer Konvertering kan som oftest fungere Generelt er der nogle udfordringer med konvertering Konvertering- og konverteringsmuligheder er mangelfulde Figur 1 Illustration af modenhed i de forskellige modtagesituationer Som det fremgår af modellen, er der eksempelvis stor forskel på, om man som ODF-myndighed modtager OOXML, eller om man som OOXML-myndighed modtager DOC. Mulighederne for succesfuld konvertering og dermed også de foranstaltninger og procedurer, man som myndighed må definere, varierer derfor alt efter myndighedens teknologianvendelse og behov. 3.2 Mulige løsningsmodeller For at kunne modtage de nye dokumentformater skal I overveje hvilken løsning, der passer bedst til jer. Løsningen bør være resultatet af en balancering af relevante systemmæssige løsninger med jeres behov, processer og systemvalg. Derfor gennemgås i det følgende en række mulige løsningsmodeller såvel systemmæssige som organisatoriske Systemmæssige muligheder Alt efter hvilken teknisk platform, I kører med i dag, og alt efter jeres konkrete behov for konvertering, vil der være flere forskellige systemmæssige løsningsscenarier, der kan imødekomme jeres behov for at kunne håndtere de nye dokumentformater: > En kontorpakke, som understøtter begge de obligatoriske, åbne dokumentformater (her kan I med fordel læse afsnit 4 om anskaffelse af nye systemer). > En kontorpakke, som understøtter et af de obligatoriske, åbne dokumentformater suppleret med en converter til understøttelse af det andet format. > En kontorpakke, som ikke understøtter nogle af de obligatoriske åbne dokumentformater, suppleret med to convertere. > To kontorpakker, som hver håndterer et af de åbne dokumentformater, evt. gennem convertere. 27

177 Bilagssamling Side 177 af 379 > > Viewere til ODF og OOXML som supplement til den eksisterende kontorpakke f.eks.: > ODFviewer (opendocumentfellowship.com/odfviewer) 12 > Microsoft Word Viewer med MS compatibility pack installeret (support.microsoft.com/kb/925180) Herudover vil der være variationer af ovenstående alt efter valg af konverteringsløsning mv Mulige konverteringsløsninger De forskellige typer af konverteringsløsninger, som kan indgå i ovenstående løsningsscenarier, er som følger: 12 Afprøvninger i laboratoriet af denne ODF-viewer-løsning og andre lignende løsninger viser, at løsningerne bærer præg af at være eksperimenterende projekter, og ikke har den nødvendige modenhed på nuværende tidspunkt. 28

178 Bilagssamling Side 178 af 379 > Beskrivelse Fordele/ ulemper Konverteringsløsning installeres på klienten Klintbaseret converter, hvor konverteringsmuligheden er en del af selve tekstbehandlingsprogrammet. Enten via en tilføjet plugin, eller som et selvstændigt konverteringsprogram installeret på brugerens computer. Gør det relativt enkelt for brugeren at foretage visning/konvertering af dokumenter samtidigt med, at brugeren bevarer kontrollen over dokumenterne. Løsningen kræver typisk, at converterne bliver installeret og vedligeholdt på alle brugernes computere. Figur 2 Mulige konverteringsløsninger Konverteringsløsning installeres på fælles server Serverbaseret integreret converter, hvor converteren installeres i forbindelse med f.eks. en e-postserver og automatisk opfanger e- post med vedhæftede filer, som den konverterer baseret på nogle givne regler, uden at brugeren involveres. Denne type løsning kan implementeres uden at involvere brugerne. Til gengæld mister man kontrollen med, om resultatet af konverteringen er acceptabelt, fordi brugeren typisk ikke ser originaldokumentet. Det er problematisk, hvis man konverterer dokumenter, hvor der er risiko ved indholdstab. Løsningen kræver typisk, at myndigheden har adgang til kompetencer, der kan etablere og vedligeholde løsningen. Konverteringsløsning udbydes som service enten internt eller via internettet Webtjeneste en intern eller ekstern hjemmeside eller en e- postkasse, hvor brugeren kan uploade/sende dokumenter til og få konverterede udgaver af dokumenterne tilbage. Disse løsninger kan være mere eller mindre automatiserede. I forbindelse med denne type løsning skal myndigheden overveje, hvorledes sikkerheden i forhold til fortrolige oplysninger håndteres. Det vurderes, at sikkerhedsniveauet i nogle af de eksisterende eksterne services, som udbydes offentligt via internettet, generelt ikke vil leve op til myndighedernes sikkerhedskrav ift. persondatalov mv. Herudover skal det overvejes, om serviceniveauet ift. oppetider, support, mv. lever op til myndighedens krav, når der anvendes eksterne løsninger. Hvis løsningen etableres som en intern simpel manuel service, er løsningen til gengæld hurtig og nem at etablere f.eks. via myndighedens service desk Organisatoriske muligheder De forskellige tekniske konverteringsmuligheder skal hver især vurderes i forhold til jeres myndigheds behov og implementeres organisatorisk i overensstemmelse hermed. Forskellige brugere kan have forskellige behov for konvertering. I bør også overveje, om jeres behov ændrer sig over tid, efterhånden som mængden af modtagne nye dokumentformater stiger. Nedenfor er en række muligheder nævnt. I alle tilfælde er det vigtigt, at brugerne er opmærksomme på hvor og hvordan, de tilbudte løsninger er til rådighed. 29

179 Bilagssamling Side 179 af 379 > Fuld udrulning i organisationen I kan vælge at udrulle en given konverteringsløsning til samtlige brugere. Dette kan eksempelvis være via plugins i brugernes almindelige kontorpakker. I princippet kan den fulde udrulning også være via en service, som tilbydes samtlige brugere i organisationen. Differentieret udrulning i organisationen Hvis jeres organisation har brugere med forskellige konverteringsbehov, kan I vælge at differentiere mellem løsningerne. Det kan eksempelvis være, at I opdeler jeres brugere i forskellige kategorier og tilbyder dem løsninger derefter eksempelvis: > Brugere som kun sjældent forventes at få ODF/OOXML-dokumenter > kan se dokumenter via en ODF- eller OOXML-viewer > kan få konverteret dokumenter via fremsendelse til service desken eller en webservice på internet eller intranet > Brugere som jævnligt forventes at få ODF/OOXML-dokumenter > får installeret de nødvendige convertere på deres klienter og modtager fornøden information omkring brug eller adgang til support > Brugere som modtager mange dokumenter i ODF/OOXML eksempelvis de funktioner, som tømmer fællespostkassen eller journalen > får tilknyttet en serverbaseret konverteringsløsning, som automatisk konverterer dokumenterne ved modtagelsen I skal vurdere, om I har et behov for at differentiere mellem de forskellige tilbud til jeres brugere, og om det er teknisk muligt. OBS! Generelt skal it-funktionen være opmærksom på, at der kan være udfordringer med at udrulle klientbaserede convertere via standardfunktionalitet eksempelvis som MSI-pakker 13 (et automatisk installations-script). Derfor bør mulighederne herfor indgå i overvejelserne om udrulning. Yderligere information kan hentes i converterkortlægning og converteroversigt på dokumentformater.oio.dk/leverancer 13 MSI står for MicroSoft Installer og er en system-service til at installere og håndtere applikationer. 30

180 Bilagssamling Side 180 af 379 > Delvis udrulning i organisationen Hvis I vurderer, at ikke alle brugere har behov for konverteringsmuligheden, kan I vælge en delvis udrulning til udvalgte brugere eller brugergrupper fra starten af, eller I kan vælge at udrulle efterhånden, som behovet opstår hos brugerne. Hvis I vælger sidstnævnte løsning, bør jeres supportfunktion have det nødvendige beredskab, og igen er det vigtigt, at brugerne er opmærksomme på det potentielle behov og den relevante løsning. Central løsning Det kan være, at I ikke vælger at udrulle convertere til jeres slutbrugere, men at I i stedet vælger en centraliseret model for konvertering af dokumenter. Her kan opgaven eksempelvis placeres hos: > Service desken > Journalen > Superbrugerne > 3. part via outsourcing Som et eksempel på en central løsning, kan service desken have de relevante convertere installeret og konvertere dokumenter manuelt for brugerne via fremsendelse til en fælles postkasse eller lignende. Det kan også være, at I nøjes med at lade service desken lave PDF-versioner af dokumenterne, som returneres til brugerne. Eller måske tager I skridtet videre og etablerer en automatiseret løsning til varetagelse af disse opgaver. I skal overveje, hvad der er den rigtige model for jer. 3.3 Kan jeres tekstbehandlingssystem i dag læse ODF og OOXML? Nedenfor kan I se, om jeres nuværende tekstbehandlingssystem i dag kan, eller kan komme til, at understøtte modtagelse af ODF og OOXML Oversigten er et uddrag af den converterkortlægning, som kan findes på dokumentformater.oio.dk/leverancer 31

181 Bilagssamling Side 181 af 379 > Kontorpakke (tekstbehandling) AppleWorks ver Corel WordPerfect Office X3 IBM Lotus Word Pro 9.8 IBM Lotus Symphony (Notes 8) Microsoft Office Word 2000 Microsoft Office Word XP Microsoft Office Word 2003 Microsoft Office Word 2007 Microsoft Office Word for Mac 2004 SUN StarOffice Writer ver. 8 KWord (del af Koffice) ver OpenOffice.org ver. 2.3 Open Office.org Novell Edition 2.3 Understøtter som standard ODF Understøtter som standard OOXML Kan opgraderes med converterplugin til ODF Kan opgraderes med converterplugin til OOXML Nej Nej Nej Nej Nej 15 (visning understøttet i ny betaudgave) Nej (visning understøttet i ny beta-udgave) Nej Nej Nej Nej Nej Nej Ja Nej Nej Nej Nej Nej Ja Ja Nej Nej Ja Ja Nej Nej Ja Ja Nej Ja Ja ikke relevant Nej Nej Nej (konvertering til RTF Ja Nej understøttes) ikke relevant Nej Ja Nej ikke relevant Nej Ja Nej ikke relevant Nej Ja Nej Ikke relevant Ja Figur 3 Tekstbehandlingssystemers muligheder for at understøtte ODF eller OOXML Hvis ovenstående skema viser, at jeres tekstbehandlingssystem mangler understøttelse af ODF og/eller OOXML, og der ikke findes et converter-plugin, der tager hånd om dette, kan I finde alternative forslag i form af eksterne convertere i converterkortlægningen på dokumentformater.oio.dk/leverancer. I det følgende kan I se eksempler på hvilke specifikke løsninger, der findes til netop jeres kontorpakke. 3.4 Hvilken konverteringsløsning kan I bruge? Hvilken konverteringsløsning, I kan bruge i jeres myndighed, afhænger først og fremmest af hvilke(t) tekstbehandlingssystem(er), I anvender. I nedenstående 15 Standard-produktionsformatet i Corel WordPerfect Office X3 er DOC eller Corels eget format "WPD, afhængig af hvilken mode brugeren vælger at arbejde i. 32

182 Bilagssamling Side 182 af 379 > oversigter får I en oversigt over løsninger til hhv. modtagelse af ODF og OOXML. I kan læse mere om disse og andre konverteringsløsninger, som kan være relevante for jer, i den detaljerede converterkortlægning på dokumentformater.oio.dk/leverancer. I skemaerne angives muligheden for ekstern converter. Med en ekstern converter menes en konverteringsmulighed, der ikke er knyttet direkte til tekstbehandlingssystemet enten i form af indbygget funktionalitet eller et plugin/udvidelse til tekstbehandlingssystemet. En ekstern converter kan f.eks. være et selvstændigt konverteringsprogram, et parallelt installeret tekstbehandlingsprogram på brugerens maskine med bedre konverteringsmuligheder, eller en webtjeneste f.eks. på brugerens intranet, hvor brugen kan få konverteret filer Løsninger til modtagelse af ODF Der findes forskellige løsninger til modtagelse og konvertering af ODF. Blandt disse findes der pt. to convertere, der kan integreres direkte i et Microsoft Word tekstbehandlingssystem med henblik på at understøtte ODF: > "OpenXML/ODF Translator Add-in for Office", som er et SourceForge-projekt med deltagelse af Clever Age, Microsoft, Novell, m.fl. Konverteringen foregår her vha. XSLT-stylesheets. > "Sun ODF Plugin 1.1 for Microsoft Office", som er baseret på konverteringsmotoren fra OpenOffice.org. Nedenfor følger en oversigt over nogle af de centrale løsninger til modtagelse af ODF, som er afspejlet i denne vejledning Oversigten er baseret på pilotforsøg og laboratorietest, samt den converterkortlægning, som kan findes på dokumentformater.oio.dk/leverancer 33

183 Bilagssamling Side 183 af 379 > Kontorpakke (tekstbehandling) AppleWorks ver Corel WordPerfect Office X3 Mulig konverteringsløsning Indbygget understøttelse af ODF uden brug af converter OpenXML/ODF Translator Add-in for Office - Word 1.1 Release M2+M3 Sun ODF Plugin 1.1 for Microsoft Office Ekstern converter Nej Nej Nej Ja Nej (visning understøttet i ny betaudgave) Nej Nej Nej Nej Nej Ja Ja IBM Lotus Word Pro 9.8 IBM Lotus Ja Nej Nej ikke relevant Symphony (Notes 8) Microsoft Office Nej (Ja) Ja Ja Word 2000 Microsoft Office Nej Ja Ja Ja Word XP Microsoft Office Nej Ja Ja Ja Word 2003 Microsoft Office Nej Ja Nej Ja Word 2007 Microsoft Office Nej Nej Nej Ja Word for Mac 2004 SUN StarOffice Ja Nej Nej ikke relevant Writer ver. 8 KWord (del af Ja Nej Nej ikke relevant Koffice) ver OpenOffice.org ver. Ja Nej Nej ikke relevant 2.3 Open Office.org Ja Nej Nej ikke relevant Novell Edition 2.3 Figur 4 Løsninger til modtagelse af ODF afspejlet i nærværende vejledning Løsninger til modtagelse af OOXML Der findes forskellige løsninger til modtagelse og konvertering af OOXML. Blandt disse findes der pt. to convertere, der kan integreres direkte i et tekstbehandlingssystem med henblik på at understøtte OOXML 17 : 17 Bidragsyderne til OpenOffice.org-projektet arbejder på at indbygge mulighed for at åbne OOXML-tekstdokumenter i OpenOffice.org version

184 Bilagssamling Side 184 af 379 > > "Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats", som er Microsofts udvidelsespakke til tidligere udgaver af bl.a. Word. Compatibility Pack en understøtter også Microsofts Word Viewer. > "OpenOffice.org OpenXML Translator", som er Novells converter til OpenOffice.org Novell Edition baseret på programkode fra SourceForge-projektet "OpenXML/ODF Translator Add-in for Office". Nedenfor følger en oversigt over nogle af de centrale løsninger til modtagelse af ODF, som er afspejlet i denne vejledning 18.. Mulig konverteringsløsning Kontorpakke (tekstbehandling) AppleWorks ver Corel WordPerfect Office X3 Indbygget understøttelse af OOXML uden brug af converter Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats OpenOffice.org OpenXML Translator Ekstern converter Nej Nej Nej Ja Nej (visning Nej Nej Ja understøttet i ny beta-udgave) Nej Nej Nej Ja IBM Lotus Word Pro 9.8 IBM Lotus Nej Nej Nej Ja Symphony (Notes 8) Microsoft Office Nej Ja Nej Ja Word 2000 Microsoft Office Nej Ja Nej Ja Word XP Microsoft Office Nej Ja Nej Ja Word 2003 Microsoft Office Ja Nej Nej ikke Word 2007 relevant Microsoft Office Nej Nej Nej Ja Word for Mac 2004 SUN StarOffice Nej Nej Nej Ja Writer ver. 8 KWord (del af Nej Nej Nej Ja Koffice) ver OpenOffice.org ver. Nej Nej Nej Ja 2.3 Open Office.org Nej Nej Ja Ja Novell Edition 2.3 Figur 5 Løsninger til modtagelse af OOXML afspejlet i nærværende vejledning 18 Oversigten er baseret på pilotforsøg og laboratorietest, samt den converterkortlægning, som kan findes på dokumentformater.oio.dk/leverancer 35

185 Bilagssamling Side 185 af 379 > 3.5 Gode råd om driften hvilke udfordringer og løsningsmuligheder har I? Hvad går typisk godt i forbindelse med konvertering? De gennemførte pilotforsøg viser, at der er stor forskel på kvaliteten af konverteringerne alt efter, hvad der er testet. Der er imidlertid en række situationer, hvor konverteringerne fungerer tilfredsstillende. Overordnet går det godt, når et OOXML-dokument bliver konverteret til DOC og omvendt. Det skyldes i høj grad, at Word 2007 er bagudkompatibel, og at konverteren Microsoft Compatibility Pack fungerer tilfredsstillende. Konvertering fra DOC til ODF går i hovedreglen også godt. Der er imidlertid ved denne konvertering nogle begrænsninger. Pilotforsøgene har vist, at funktionaliteter som formatering, redigering og sideopsætning generelt konverteres korrekt, når man ser på tværs af de forskellige konverteringskombinationer. Funktionalitetsområderne sidehoved/sidefod, fodnoter og slutnoter, nummererede lister og punktopstilling, samt automatiske indholdsfortegnelser bliver generelt konverteret uden meningsforstyrrende informationstab, men der kan forekomme visuelle afvigelser i forbindelse med konverteringerne. Med den konfiguration, som Statens Arkiver valgte i deres pilotforsøg, viste det sig endvidere, at der ikke er betydeligt flere eller færre problemer ved konvertering fra åbne tekstbehandlingsdokumentformater til afleveringsformat for tekstdokumenter (TIFF), end der er ved konvertering fra lukkede tekstbehandlingsdokumentformater til afleveringsformat for tekstdokumenter (TIFF) Udfordringer og mulige løsningsmodeller for myndigheder der benytter DOC som produktionsformat En myndighed, der benytter DOC-formatet i sit tekstbehandlingssystem, skal pr. 1. januar 2008 både kunne modtage og læse ODF- og OOXML-dokumenter. Modtagelse og læsning af ODF-dokumenter På baggrund af erfaringerne i pilotforsøgene behandler dette afsnit den del af modtagekravet, som omhandler ODF. Hvordan står I generelt ved modtagelse af ODF? Generelt er der nogle udfordringer for myndigheder, som skal modtage ODFformaterede dokumenter. For at kunne modtage og læse ODF i tekstbehandlingssystemet er det nødvendigt at installere en converter. I pilotforsøgene er to forskellige convertere til modtagelse af ODF på en DOC-baseret platform testet: > OpenXML/ODF Translator Add-in for Office V1.1 > SUN ODF Plug-in for Microsoft Word 36

186 Bilagssamling Side 186 af 379 > Generelt kan det konstateres, at konverteringer i dette scenarie med disse convertere fungerer med nogle udfordringer. Der er ikke observeret væsentlige forskelle i konverteringskvaliteten mellem de to convertere. Der er dog forskel i den måde, hvorpå de er integreret til Word 19. I løbet af pilotforsøgsfasen er der lanceret forskellige versioner af disse convertere. Derfor er de to convertere også blevet testet i forskellige versioner 20. I det følgende generaliseres på tværs af disse. Generelt kan det dog konstateres, at de nyeste versioner af converterne fungerer bedst. Eksempler på udfordringer ved modtagelse af ODF Sammenligninger af konverterede dokumenter har på tværs af pilotforsøgene vist nogle udfordringer med at konvertere ODF-dokumenter til DOC. Samtidig skal det understreges, at flere dokumenter er konverteret korrekt fra ODF til DOC. I de tilfælde, hvor der er observeret deciderede visuelle informationstab, er det typisk billeder, tegninger og indsatte filer, der er forsvundet. Derudover er der observeret visuelle forskelle ved konverteringerne, som imidlertid ikke har været direkte meningsforstyrrende. Disse observationer drejer sig om ændringer af tabuleringer og formatering af punktopstillinger i relation til skrifttyper og punkttegn. I de tilfælde, hvor der er tale om andengangs-konvertering, hvilket vil sige konvertering af dokumenter, som i forvejen er konverteret fra et andet format til ODF, er der flere visuelle forskelle i dokumenterne. Her er der yderligere observeret ændringer i dokumenternes marginer, nummererede lister og punkttegn. Der er også eksempler på, at dokumenter med separat sidehoved på første side ikke bliver konverteret korrekt. Eksempler på løsninger og forudsætninger Observationerne fra pilotforsøgene indikerer, at myndighederne ikke kan basere deres løsning udelukkende på en converterinstallation. Derfor vil en relevant teknisk løsningsmodel typisk bestå af en konverteringsløsning, som efter behov kan suppleres med en strategisk anvendelse/udrulning af en supplerende tekstbehandlingsapplikation eller viewer. Den tekniske løsningsmodel skal kombineres med en hensigtsmæssig og effektiv arbejdsproces. Pilotforsøgene viser dog også, at det i hovedreglen er muligt at modtage og læse ODF-dokumenter succesfuldt med de ovennævnte convertere til Word, forudsat, 19 Jf. converterkortlægningen på dokumentformater.oio.dk/leverancer 20 Jf. oversigt over anvendte konfigurationer fra pilotforsøg og laboratorietest på dokumentformater.oio.dk/leverancer 37

187 Bilagssamling Side 187 af 379 > > at der ikke anvendes indsatte elementer i dokumentet af følgende typer: Tegninger direkte i dokumentet, grafik og billeder, samt dynamiske objekter fra andre formater, fx ODF-regneark eller Microsoft Visio-dokumenter. > at der ikke bliver foretaget flere på hinanden følgende konverteringer > at udarbejdelsen af dokumenter hos afsenderen af ODF-dokumenterne, er baseret på et funktionalitetsloft, hvor der ikke indgår avancerede funktionaliteter. Eksempelvis kan man undgå dokumenter med afsnitsspecifik indholdsfortegnelse. For myndigheder, der anvender DOC, og som modtager komplekse dokumenter i ODF-format, eller har særlige behov og kvalitetskrav, kan det blive relevant at installere et tekstbehandlingssystem eller en viewer, som kan læse ODF enten til at læse eller til at kvalitetssikre dokumenterne. Alternativt kan denne funktion varetages af myndighedens service desk. Nedenfor er én mulig løsningsmodel ift. modtagelse af ODF for myndigheder med DOC som produktionsformat angivet: Én mulig løsningsmodel ift. modtagelse af ODF for myndigheder med DOC som produktionsformat: Dokumenter i ODF kan modtages via en ODF-plugin eksempelvis Sun ODF Plugin 1.1 for Microsoft Office eller OpenXML/ODF Translator Add-in for Office V 1.1-M2+M3. Herudover tilbydes en manuel ODF til PDF-konverteringsservice via myndighedens service desk i tilfælde, hvor brugeren eksempelvis er i tvivl om konverteringens kvalitet. Service desken anvender her Open Office v2.3, som kan eksportere direkte til PDF. Hvordan står I generelt ved modtagelse af OOXML? Erfaringerne fra pilotforsøgene er, at der generelt kun er få udfordringer for myndigheder, som skal modtage OOXML-formaterede dokumenter, når de allerede anvender DOC. For at kunne modtage og læse OOXML i tidligere udgaver af Microsoft Word er det nødvendigt at installere Microsoft Compatibility Pack. Det er muligt at hente denne gratis på Microsofts hjemmeside 21. Dette er pt. den eneste konverteringsløsning, som opfylder behovet for konvertering mellem DOC og OOXML. Løsningen fungerede tilfredsstillende i langt de fleste tilfælde i pilotforsøgene. 21 Jf. 38

188 Bilagssamling Side 188 af 379 > Eksempler på udfordringer ved modtagelse af OOXML Med denne converter installeret er der ikke i pilotforløbet konstateret eksempler på markante konverteringsfejl inden for det anvendte funktionalitetsloft. Der har kun været tale om enkelte eksempler på, at rækkehøjde og kolonnebredde i tabeller bliver lidt større. I et enkelt tilfælde har en større kolonnebredde medført, at tekst i en kolonne faldt uden for højremarginen. I pilotforsøgene har vi ikke testet konvertering af de nye funktionaliteter, som eksempelvis er understøttet af OOXML men ikke i DOC. Der kan dog være udfordringer i denne henseende, hvilket I kan læse mere om på Microsofts hjemmeside 22. En mulig løsning, hvis der opstår problemer, er, at afsenderen søger at udgå de funktioner, som ikke kan læses i tidligere versioner af Word 23. Eksempler på løsninger og forudsætninger ved modtagelse af OOXML Det anbefales, at myndigheder, der benytter Word-versioner ældre end 2007 versionen, bruger Microsofts Compatibility Pack til konvertering af OOXMLdokumenter. Hvis brugerne ikke har denne pakke installeret, men har de seneste opdateringer fra Microsoft, vil der automatisk komme en dialogboks frem ved forsøg på at åbne et OOXML-dokument. Via denne dialogboks kan brugerne installere Compatibility Pack en, såfremt de har de fornødne rettigheder dertil. Nedenfor er den pt. eneste converterbaserede løsningsmodel ift. modtagelse af OOXML for myndigheder med DOC som produktionsformat angivet: Løsningsmodel ift. modtagelse af OOXML for myndigheder med DOC som produktionsformat: Microsoft Office Compatibility Pack gør det muligt for myndigheden at modtage OOXML-dokumenter Udfordringer og mulige løsningsmodeller for myndigheder der benytter ODF som produktionsformat En myndighed, der benytter ODF-formatet i sit tekstbehandlingssystem, skal pr. 1. januar 2008 kunne modtage og læse OOXML-dokumenter. Myndigheder, der allerede benytter ODF som format i deres tekstbehandlingssystem, vil typisk være vant til at skulle modtage DOC-dokumenter som en del af deres dagligdag. Derfor vil dette afsnit primært behandle udfordringerne ved modtagelse af OOXMLdokumenter, som vil være det nye krav for disse myndigheder. Hvordan står I generelt ved modtagelse af OOXML? I pilotforsøgene var konverteringer og konverteringsmuligheder, hvor en myndighed vil importere OOXML til ODF, generelt mangelfulde. For at kunne modtage og læse 22 Jf. office.microsoft.com/da-dk/word/ha aspx?pid=ch Jf. office.microsoft.com/da-dk/word/ha aspx?pid=ch

189 Bilagssamling Side 189 af 379 > OOXML i tekstbehandlingssystemet er det nødvendigt at installere en converter, men udbudet af relevante og tilfredsstillende tekniske løsninger er meget begrænset. Den eneste converter på markedet, da pilotforsøgene blev afviklet, som understøtter direkte import af OOXML-dokumenter i ODF-baserede tekstbehandlingssystemer, er Novells ODF-converter, der pt. er udgivet i en version til MS Windows, og en version til Linux 24. Samtidig er det eneste tekstbehandlingsprogram, converteren kan integreres til, OpenOffice Novell Edition fra version 2.0.4,. Dette indebærer, at myndigheder der f.eks. benytter sig af andre OpenOffice versioner på nuværende tidspunkt ikke kan konvertere med plugin i deres udgave af OpenOffice, men er nødsaget til at konvertere til ODF via en ekstern konverter. Generelt kan det i pilotforsøgene konstateres, at konverteringer i dette specifikke scenarie, med anvendelse af Open Office Novell Edition som tekstbehandlingssystem, er mangelfulde. For øvrige ODF-baserede kontorpakker er konvertering direkte via kontorpakken ikke en mulighed ultimo Her må der findes alternative løsninger, jf. nedenfor. Eksempler på udfordringer ved modtagelse af OOXML I pilotforsøgene har sammenligninger af dokumenter før og efter konvertering vist, at myndigheder ikke kan forvente en fejlfri konvertering af OOXML-dokumenter til ODF. Der er også flere eksempler i pilotforsøgene på, at der opstår læsefejl, når et OOXML-dokument bliver indlæst i OpenOffice med henblik på konvertering til ODF. Det betyder i praksis, at dokumentet ikke kan åbnes. Dette er observeret, når bogstaverne æ, ø eller å indgår i navnet på mappens sti eller i dokumentets filnavn. Denne læsefejl er ikke set i pilotforsøgenes paralleltest, når løsningen har været installeret på en Linux-platform med version af Novells ODF-converter. Der er i pilotforsøgene observeret tab af data i forbindelse med konvertering af visse billedtyper. Herudover er der observeret en successiv stigning i konverteringsfejl, når der er tale om flere på hinanden følgende konverteringer. Her har datatab eksempelvis resulteret i, at hele og halve sider er forsvundet. Også feltdefinitioner i skabeloner er gået tabt i konverteringerne, hvilket betyder, at dokumenter, der integrerer til fagsystemer, kan miste deres integrationsmuligheder. Ud over direkte tab af data er der i pilotforsøgene observeret en række udfordringer, der får dokumenterne til at ændre udseende efter konvertering. Her er der udfordringer med overskrifter, der omdannes til sorte streger eller punktopstillinger, punktopstillinger, der bliver til punkttegn, sideopsætninger med rammer/tekstbokse, der konverteres forkert, samt tabeller, der ændrer kanter og justeringer. Alt i alt er der altså set en række udfordringer i pilotforsøgene, hvilket kalder på andre løsninger end rene converterløsninger, jf. nedenfor. 24 Platformen er den eneste forskel på de to versionsnumre. 40

190 Bilagssamling Side 190 af 379 > Eksempler på løsninger og forudsætninger ved modtagelse af OOXML Ud fra ovenstående erfaringer fra pilotforsøgene er det ikke muligt, alene, at basere sin tekniske løsning på den eksisterende converter fra Novell. For de myndigheder, som arbejder med ODF, men ikke allerede har valgt OpenOffice Novell Edition, er det en løsning at overgå til denne, men for de fleste vil dette ikke være den mest nærliggende vej særligt ikke i det perspektiv, at pilotforsøgene viser, at konverteringerne, som nævnt, er mangelfulde. Derfor må myndighederne søge komplementerende løsninger. En let tilgængelig løsning, som betyder, at myndigheden kan opfylde kravet om at kunne modtage og læse dokumenter i OOXML, er at installere en decideret viewer. Dette betyder dog, at brugene ikke kan arbejde videre på dokumenterne. Herudover kan det blive relevant at installere en supplerende tekstbehandlingsapplikation, som kan håndtere OOXML enten til at læse, kvalitetssikre eller redigere dokumenterne. Hvis der blot er behov for at læse dokumenterne, kan myndighedens service desk eksempelvis også konvertere dokumenterne til pdf eller andre formater, som brugene kan læse. Myndighederne kan eksempelvis bruge de decentrale superbrugere til at hjælpe med anvendelsen af de implementerede løsninger, og service desken kan varetage flere roller i forbindelse med håndtering af OOXML-dokumenter. Nedenfor er én mulig løsningsmodel ift. modtagelse af OOXML for myndigheder med ODF som produktionsformat angivet: Én mulig løsningsmodel ift. modtagelse af OOXML for myndigheder med ODF som produktionsformat: Brugerne kan håndtere konvertering fra OOXML til ODF via Novell ODFconverter og OpenOffice Novell Edition v2.3. Men da denne converter ikke kan forventes at fungere problemfrit, installeres Microsoft Word Viewer samt Microsoft Compatibillity Pack på alle klienter til visning og validering af indholdet i modtagne OOXML-filer. Myndigheden har valgt at bruge organisationens decentrale superbrugere til at hjælpe med anvendelsen af converteren og viewerløsningen Udfordringer og mulige løsningsmodeller for myndigheder der benytter OOXML som produktionsformat En myndighed, der benytter OOXML-formatet i sit tekstbehandlingssystem, skal pr. 1. januar 2008 kunne modtage og læse ODF-dokumenter. Myndigheder, der allerede benytter OOXML (via Word 2007) som format i deres tekstbehandlingssystem, vil typisk være vant til at modtage DOC-dokumenter som en del af deres dagligdag. Derfor vil dette afsnit koncentrere sig om modtagelse af ODF-dokumenter, som vil være nyt for disse myndigheder. 41

191 Bilagssamling Side 191 af 379 > Hvordan står I generelt ved modtagelse af ODF? Erfaringerne fra pilotforsøgene viser, at der generelt er nogle udfordringer for myndigheder, som skal modtage ODF-formaterede dokumenter. For at kunne modtage og læse ODF i tekstbehandlingssystemet er det nødvendigt at installere en converter. I pilotforsøgene er forskellige versioner af converteren OpenXML/ODF Translator Add-in for Office testet til modtagelse af ODF på en OOXML-baseret platform. Denne converter var under pilotforsøget den eneste, der direkte integreret til Word 2007 kunne konvertere ODF-dokumenter til OOXML-format. Generelt kan det i pilotforsøgene konstateres, at konverteringer i dette scenarie med denne converter fungerer med nogle udfordringer. I løbet af pilotforsøgsfasen er der lanceret forskellige versioner af converteren, hvorfor converteren er brugt i den nyeste version på det tidspunkt, som det enkelte pilotforsøg er gennemført 25. Derfor er converteren blevet testet i forskellige versioner. Herudfra generaliseres i det følgende. Generelt kan det dog konstateres, at de nyeste versioner af converteren fungerer bedst. Eksempler på udfordringer ved modtagelse af ODF I pilotforsøgene er der observeret en række konverteringsfejl med eksempler på tab af data. Generelt kan det, ud fra pilotforsøgene, konstateres, at dette sker, når dokumenter indeholder billeder, tegninger og indsatte dynamiske elementer. Der er endvidere eksempler på fejlkonverteringer, som viser, at de åbne dokumentformater har forskellig måde at bruge funktionaliteter på. Eksempler på observerede fejlkonverteringer, som er relateret til forskelle i formaternes funktionalitet, er, > sider midt i ODF-dokumenter, som har en anden orientering (portræt /landskab) i modsætning til resten af dokumentet. Disse sider får deres egen sektion i OOXML, hvilket kan medføre ændring af sidehoved, hvis der er separat sidehoved for første side. > indholdsfortegnelser for kapitler, der er understøttet i ODF. Disse bliver konverteret til indholdsfortegnelser for hele dokumentet i OOXML, hvilket kan have store konsekvenser for dokumentets længde. Udseendemæssigt har pilotforsøgene vist, at der er udfordringer med at konvertere nummererede lister og punktopstillinger, sidehenvisninger og formatering i sidefod, så disse elementer forbliver visuelt identiske. Det er en gennemgående iagttagelse i pilotforsøgene, at flere på hinanden følgende konverteringer giver successivt flere fejlobservationer. 25 De forskellige versioner fremgår af konfigurationsoversigten på dokumentformater.oio.dk/leverancer 42

192 Bilagssamling Side 192 af 379 > Eksempler på løsninger og forudsætninger ved modtagelse af ODF Observationerne fra pilotforsøgene indikerer, at myndighederne ikke kan basere deres løsning udelukkende på en converterinstallation. Derfor vil en relevant løsningsmodel typisk bestå af en teknisk løsning kombineret med de rette organisatoriske procedurer og strukturer. Det kan være via en kombination af en converterløsning, supplerende kontorpakker og evt. support via sevice desk eller andre organisatoriske enheder. Pilotforsøgene viser, at det i hovedreglen er muligt at modtage og læse ODFdokumenter succesfuldt med de ovennævnte convertere til Word, forudsat, > at der ikke anvendes indsatte elementer i dokumentet af følgende typer: Tegninger direkte i dokumentet, grafik og billeder, samt dynamiske objekter fra andre formater, fx ODF-regneark eller Microsoft Visio-dokumenter. > at der ikke bliver foretaget flere på hinanden følgende konverteringer > at udarbejdelsen af dokumenter hos samarbejdsmyndigheden, der sender ODFdokumenterne, er baseret på et funktionalitetsloft, hvor der ikke indgår avancerede funktionaliteter. Eksempelvis kan man undgå dokumenter med afsnitsspecifik indholdsfortegnelse. For myndigheder, der anvender OOXML, og som modtager komplekse dokumenter i ODF-format, eller har særlige behov og kvalitetskrav, kan det blive relevant at installere en tekstbehandlingsapplikation eller en viewer, som kan læse ODF enten til at læse eller til at kvalitetssikre dokumenterne. Alternativt kan denne funktion varetages af myndighedens service desk. Nedenfor er én mulig løsningsmodel ift. modtagelse af ODF for myndigheder med OOXML som produktionsformat angivet: Én mulig løsningsmodel ift. modtagelse af ODF for myndigheder med OOXML som produktionsformat: Brugerne kan fra Word 2007 importere ODF via OpenXML/ODF Translator Addin for Office V1.1-M2+M3. Herudover tilbydes en manuel ODF til PDF-konverteringsservice via myndighedens service desk i tilfælde, hvor brugeren eksempelvis er i tvivl om konverteringens kvalitet. Service desken anvender her Open Office v2.3, som kan eksportere direkte til PDF. I forbindelse med særligt krævende brugere tilbydes installering af Open Office v2.3 lokalt til visning og behandling af ODF-dokumenter. Dette program kan brugeren selv installere via et fællesdrev. Brugeren kan få hjælp til installationen hos service desken. Service desken har udarbejdet en kort vejledning, som guider brugerne i anvendelsen af løsningerne, men der ydes ikke funktionel support på løsningerne. 43

193 Bilagssamling Side 193 af 379 > Generelle mulige tiltag og anbefalinger i forbindelse med driften Set på tværs viser pilotforsøg og laboratorietesten, at der er en række tiltag, som I kan følge og iværksætte for at gøre håndteringen af de åbne dokumentformater nemmere både for jer selv og for eventuelle samarbejdsparter. Disse forslag til tiltag er baseret på de foreløbige erfaringer med åbne dokumentformater og den nuværende tilgængelige teknologi. I skal selv vurdere hvilke tiltag, der er relevante for netop jeres myndighed. 11 gode råd 1. Beslut jer for et funktionalitetsloft Tilpas dokumentskabeloner med udgangspunkt i funktionalitetsloftet 3. Hold jer til de mest almindelige filtyper og vær opmærksom på makroer 4. Undgå gentagne konverteringer 5. Vælg PDF til udveksling af ikke-redigerbare dokumenter 6. Vurder hvilke dokumenter, I vil lave kvalitetscheck på efter konvertering 7. Indfør tjekrutiner for udvalgte dokumenter 8. Installer en kontorpakke eller viewer, som understøtter det pågældende format 9. Overvej harmonisering af sprogversioner 10. Følg med i udviklingen 11. Indrapporter jeres tekniske udfordringer til leverandørerne 1. Beslut jer for et funktionalitetsloft Hvis I samarbejder med andre myndigheder om dokumenter, hvor samarbejdsmyndigheden bruger et andet format end jer, vil det være givtigt at se på hvilke funktionaliteter, der sandsynligvis vil skabe udfordringer, når I udveksler dokumenter. Med udgangspunkt heri kan I beslutte jer for et funktionalitetsloft, som kan fremme udvekslingen med andre myndigheder. Eksempler på, hvad I kan forsøge, for at sikre en høj succesrate: > Brug standard fonte og typografier > Undlad brug af tekstbokse > Undgå stregtegninger > Undgå indsatte filer, som fx ODF-regneark eller Microsoft Visio-dokumenter > Beskær billeder, inden de sættes ind i dokumentet > Vær opmærksom på anvendelse af makroer i dokumenter 26 Jf. beskrivelsen af begrebet Funktionalitetsloft i afsnit

194 Bilagssamling Side 194 af 379 > Beskæring af billeder, inden de sættes ind i et dokument, kan eksempelvis foregå på den måde, at I læser billedet ind i en billededitor, beskærer det til det ønskede format og afsnit, gemmer som en fil, og derefter indsætter denne fil i dokumentet. Det er således i afsenderens interesse at sikre, at dokumentet er komplet og transmitterbart til et andet format og en anden platform, men det er modtagerens opgave at orientere afsenderen, hvis der opstår problemer. Derfor er det også et fælles anliggende for samarbejdende myndigheder at sikre sig, at problemerne bliver løst, f.eks. i forhold til filtyper, makroer o.l., så udveksling af dokumenter kan foregå så gnidningsfrit som muligt. 2. Tilpas dokumentskabeloner med udgangspunkt i funktionalitetsloftet Når I har lagt jer fast på hvilke funktioner; I vil anvende som en del af funktionalitetsloftet, kan I med fordel gennemgå jeres eksisterende skabeloner for at tjekke, om de understøtter dette funktionalitetsloft. De steder, hvor der indgår funktionalitet, der ligger uden for jeres funktionalitetsloft, kan I se på mulighederne for at tilrette skabelonen. 3. Hold jer til de mest almindelige filtyper og vær opmærksom på makroer Erfaringsmæssigt viser IT- og Telestyrelsens pilotforsøg og laboratorietest at ikke alle filtypevarianter er lige godt understøttet af convertere og øvrige systemer i myndighederne. IT- og Telestyrelsen anbefaler derfor, at myndighederne så vidt muligt holder sig til de mest almindelige filtyper for redigerbare tekstdokumenter til udveksling, dvs. hhv..odt og.docx. Herudover skal I være opmærksomme på at nogle filtyper indeholder indlejret funktionalitet, som f.eks. makroer. Makroer er programstumper eller hele programmer, som ikke er afhængige af dokumentformatet, men er specifikke for applikationen. Derfor kan man ikke forvente, at makroernes funktion bibeholdes ved konvertering, og i nogle tilfælde må det forventes, at makroerne kan have en effekt på, hvordan dokumentet fremtræder. Hvis I alligevel anvender makroer bør I sikre, at informationer i dokumenter til udveksling kan læses, hvad enten makroer er aktiveret eller ej. For en uddybning af dette emne henvises oversigt over kendte filtyper i OOXML og ODF, samt notat om interoperabilitetsproblemer og makroer på dokumentformater.oio.dk/leverancer 4. Undgå gentagne konverteringer Gentagne konverteringer er, når I for eksempel samarbejder omkring dokumenter med en myndighed, der bruger et andet format. Her bliver dokumentet typisk sendt frem og tilbage mellem myndighederne, hvor det gentagne gange redigeres og konverteres. Da der erfaringsmæssigt er en del udfordringer med denne praksis, kan I eksempelvis fra starten aftale et format, I vil bruge til at samarbejde om dokumentet. Eller I kan holde jer til ganske simpel funktionalitet i forbindelse med samarbejdsprocessen og vente med formatering af dokumentet, til indholdet er færdigt. Gentagne konverteringer er også, hvis I modtager et dokument fra en anden myndighed, som I konverterer til jeres eget format og fremsender dette konverterede 45

195 Bilagssamling Side 195 af 379 > dokument til en tredje myndighed med et tredje format, som derfor er nødt til at konvertere igen. I dette tilfælde bør I fremsende originaldokumentet til tredje myndighed. 5. Vælg PDF til udveksling af ikke redigerbare dokumenter Da der er udfordringer forbundet med udveksling af redigerbare dokumenter, bør I gennemgå jeres procedurer for, hvornår I sender dokumenter i PDF-format frem for i redigerbare formater. I bør således vurdere, om der er et reelt behov for at udveksle dokumenter i et redigerbart format, eller om dokumenter kan sendes som PDF, der pt. giver den mest optimale fastholdelse af indhold. Anbefalingen af PDF som fastholdelsesformat til færdige officielle dokumenter og post til borgerne indgår som en del af den eksisterende edag-aftale. 6. Vurder hvilke dokumenter, I vil lave kvalitetscheck på efter konvertering I ved, at der kan opstå udfordringer med konvertering af dokumenter større eller mindre alt efter jeres specifikke situation. I nogle tilfælde kan det være kritisk, at I har vished for, at dokumentet er konverteret korrekt. I bør derfor have en hensigtsmæssig kvalitetssikringsprocedure. Dette er principielt ikke anderledes, end når I skanner dokumenter eller genererer PDF-filer. Her skal I typisk også sikre, at den version, I anvender, er korrekt og i overensstemmelse med originalen. Et væsentligt værktøj i denne forbindelse kan være at gennemføre en risikovurdering. Lav fra starten en fast definition af hvilke dokumenter, I skal kvalitetssikre, hvis de bliver konverteret fra et andet format ved modtagelsen. I bør her have kriterier på forskellige niveauer ud fra hvor komplekst dokumentet er, om det er juridisk/forvaltningsmæssigt bindende, osv. Det vil være en stor hjælp i de daglige myndighedsprocesser, hvis I kan opnå en ensartet tilgang til at bestemme, hvornår det er i orden med evt. konverteringsfejl, og hvornår risikoen for evt. konverteringsfejl skal aktivere en kvalitetssikringsprocedure. 7. Indfør tjekrutiner for udvalgte dokumenter Når I først ved hvilke dokumenter, I skal kvalitetssikre, kan I indføre veldefinerede tjekrutiner, så jeres myndighedsprocesser kan fortsætte så hurtigt som muligt. Der bør gennemføres en systematisk kvalitetssikring af konverteringsprocessen, som gør det muligt at sikre, at de konverterede dokumenter kan læses, og at alle informationer er korrekte. Kvalitetssikring af konverteringen kan eventuelt ske ved statistisk stikprøvekontrol. 8. Installer en kontorpakke eller viewer, som understøtter det pågældende format Hvis I som myndighed har særlige behov for at kunne modtage og læse mere komplicerede dokumenter, eller modtage store mængder af dokumenter i andre formater end jeres interne produktionsformat, kan det være en fordel at installere viewere eller kontorpakker, som understøtter de relevante dokumentformater. 46

196 Bilagssamling Side 196 af 379 > For myndigheder, der benytter ODF, er der mulighed for at installere Microsoft Word Viewer sammen med Microsoft Compatibility Pack. Dette giver adgang til at se, gemme og udskrive dokumenter, der har formaterne DOC og OOXML. For myndigheder, der benytter DOC eller OOXML, er det eksempelvis en mulighed at installere OpenOffice.org, der ud over at kunne åbne/læse, redigere, gemme og udskrive ODF-dokumenter eksempelvis også kan generere PDF-versioner af dokumenter. Begge ovenstående eksempler er licensfri. Der er forskellige modeller for, hvordan viewere og kontorpakker kan indgå som et supplement til jeres normale tekstbehandlingsprogram. Det kan være jeres service desk, der har disse installeret, udvalgte brugere eller forvaltningsområder, eller alle jeres brugere via en fuld udrulning i jeres myndighed. 9. Overvej harmonisering af sprogversioner Myndighederne kan overveje, om det er muligt at ensarte sprogversioner på tværs af flere myndigheder. Forskelle på kontorpakker, der er installeret med forskellige sprogversioner, kan nemlig være årsag til, at der sker ændringer i dokumenterne, når I konverterer. Dette kan endda forekomme mellem ens formater. Årsagen er, at typografier ikke hedder det samme på de forskellige sprog. Så har man brugt for eksempel Heading 1 til overskrift i en engelsk version af et tekstbehandlingssystem, vil overskriften fejle i en dansk version, hvor programmet vil lede efter en Overskrift Følg med i udviklingen Der sker rigtigt meget inden for de åbne dokumentstandarder i øjeblikket. Der kommer løbende nye versioner af convertere, nye tekstbehandlingsprogrammer, der understøtter formaterne, og nye teknologier og måder at opnå interoperabilitet mellem formaterne på. Ved at følge med i denne udvikling og afprøve de nyeste versioner og teknologier vil jeres myndighed givetvis kunne forbedre evnen til at håndtere dokumenter i andre formater. Dette vil også kunne være med til at reducere jeres behov for kvalitetssikring og kontrolprocedurer. 11. Indrapporter jeres tekniske udfordringer til leverandørerne Erfaringerne fra projektets pilotforsøg og laboratorietest har været, at leverandørerne gerne vil løse de tekniske udfordringer for myndighederne. Er der et behov hos mange myndigheder, prioriterer de problemløsningen. Derfor bør I indrapportere de fejl og udfordringer, I finder, så leverandørerne får nemmere ved at sikre jer de rigtige løsninger i den rigtige kvalitet. 3.6 Gode råd om implementering I dette afsnit gives gode råd om organisatorisk og teknisk implementering samt input til, hvordan I kan teste den konverteringsløsning, I vælger. 47

197 Bilagssamling Side 197 af 379 > Organisatorisk implementering I forbindelse med den organisatoriske implementering af den valgte konverteringsløsning, anbefales følgende: > Definér og beskriv de nye arbejdsgange ved modtagelse af ODF og OOXML > Informer slutbrugerne om de nye arbejdsgange > Sikre løbende support til slutbrugerne. I det følgende er disse anbefalinger uddybet. Definer og beskriv de nye arbejdsgange I skal definere og beskrive: > Hvilke opgaver er forbundet med konverteringen? > Hvem skal udføre hvilke opgaver (roller)? > Hvilke procedurer skal følges? Herunder > Hvilke risici er der, hvis dokumenter ikke konverteres korrekt? > Hvordan sikrer man sig, at konverteringen er gået tilfredsstillende? > Hvilke procedurer skal følges, hvis alt går, som det skal? > Hvilke procedurer skal følges, hvis noget går galt i konverteringen? > Hvilken vejledning og støtte skal være til rådighed? Informer slutbrugerne om de nye arbejdsgange Denne vejledning er ikke skrevet til slutbrugerne i jeres organisation, men til itledelsen og forretningsledelsen. Derfor er det jeres ansvar at sikre den fornødne detaljerede vejledning og kommunikation til brugerne medarbejderne i organisationen. Kommuniker fra starten omkring de nye krav, så alle er informeret om, at der er en ny situation, og hvad den indebærer. Jeres myndighed og brugere skal modtage dokumenter i ODF og OOXML. Som et minimum skal brugerne vide, hvad de gør, i det øjeblik de står overfor et af de nye dokumentformater. Hvad er de forpligtet til? Findes der vejledninger til den konverteringsløsning, I har valgt? Kan service desken hjælpe med konverteringen? Hvilken rolle har superbrugerne? Kan service desken hjælpe med installering og support af relevante konverteringsløsninger? I bør som organisation være forberedt på og kunne svare på denne type af spørgsmål, samt have den rette organisering og de rigtige procedurer på plads. 48

198 Bilagssamling Side 198 af 379 > Sikre løbende support til slutbrugerne En god metode til at sikre, at slutbrugerne hele tiden får den støtte, de har behov for, er, at have superbrugere, der er klædt godt på omkring muligheder og løsninger inden for modtagelse af ODF- og OOXML-formaterede dokumenter. Derfor er det vigtigt, at superbrugerne gennemgår en vidensoverdragelse eller egentlig uddannelse, så de kender produkterne, udviklingen og løsningerne, inklusiv de nye arbejdsgange. Hos myndigheder, der har deres service desk tæt på slutbrugerne, kan denne også udfylde denne funktion. Fortæl slutbrugerne klart og tydeligt, hvor de kan læse om de nye forretningsgange og procedurer, hvor de kan henvende sig for hjælp, og hvor de kan søge information Teknisk implementering og test Pilotforsøgene og laboratorietesten, som bl.a. ligger til grund for denne vejledning, har vist, at der kan være tekniske udfordringer forbundet med implementeringen af en konverteringsløsning. Når I vælger en løsning for modtagelse af de åbne dokumentstandarder, er der derfor en række tekniske forhold omkring implementeringen og test, I bør overveje. Nedenfor er givet en række gode råd i forbindelse med implementering og test af løsninger. Myndigheder med Word 97 Myndigheder med Word 97 vil ikke kunne installere Microsoft Compatibility Pack, eller nogle af ODF-converterne til Word. Myndigheden kan så vælge at anskaffe en converter, der ikke er integreret til tekstbehandlingsprogrammet, men som kan konvertere OOXML-dokumenter til f.eks. RTF, text eller unicode, der derefter bliver indlæst i Word 97. Her vil funktionaliteter som f.eks. formatering, skabeloner og grafik dog kunne gå tabt. Hvis disse myndigheder vælger en sådan løsning, vil det være nødvendigt med en detaljeret kvalitetssikring af alle konverteringer. En sådan kvalitetssikring kan ske ved at installere en Microsoft Word Viewer sammen med Microsoft Compatibility Pack. Derudover vil det være nødvendigt for disse myndigheder at installere en OpenOffice.org eller en ODF-viewer til håndtering af modtagelsen af ODFdokumenter. Implementering af convertere, der kan konvertere OOXML til ODF Myndigheder, der vælger at bruge en konverteringsløsning, der kan konvertere OOXML-dokumenter til ODF, er bundet til at vælge OpenOffice Novell Edition som kontorpakke eller supplerende kontorpakke. Denne kan man hente gratis på Novells hjemmeside, men det kræver, at man registrerer sig. Det er muligt at hente kontorpakken som en zip fil og som en iso fil. I iso-filen er converteren allerede installeret i det image, der ligger i filen. Hvis I vælge at hente zip-filen, skal I huske at hente converteren separat og tilføje denne til de aktive tilføjelsesprogrammer i OpenOffice Writer. 49

199 Bilagssamling Side 199 af 379 > Implementering af OpenXML/ODF Translator Add-in for Office V1.1- M2+M3 For de myndigheder, der vælger at basere deres løsning på at installere OpenXML/ODF Translator Add-in for Office 1.1-M2+M3, vil det være en forudsætning, at der også er installeret.net Framework på den pc, der skal have installeret converteren. Dette tjekker og udfører installationsprogrammet selv. Hvis.NET bliver installeret på pc en, efter Word 2007 er installeret, vil det være nødvendigt at aktivere.net programmérbarhed for Word 2007, for at Add-in virker. Dette gør man i Kontrolpanelet i Windows under Tilføj/fjern Programmer. Brug af automatiske installationsscripts Ved implementering af løsninger, kan myndigheden alt efter valg af den organisatoriske model for implementering vælge at distribuere convertere til brugerne via automatiske installationsscripts. Dette bliver typisk gjort via myndighedens it-afdeling. Test af løsningen Uanset hvilke løsninger, myndigheden vælger for at kunne modtage dokumenter i de åbne formater ODF og OOXML, skal løsningen testes. På dokumentformater.oio.dk findes en Test-selv-pakke med ODF- og OOXML-dokumenter mv., som jeres myndighed kan anvende som input til at gennemføre test af jeres løsning. Denne Test-selv-pakke er anvendelig både inden og efter udrulning af løsningen. Det kan være en fordel for jeres myndighed at teste flere kombinationer af konverteringer. Derved får I også en ide om, hvilken situation I selv og jeres samarbejdsmyndigheder kommer til at være i, når I udveksler dokumenter. Håndtering af sikkerhed Som en del af jeres generelle arbejde med it-sikkerhed, bør I også sikre validiteten af indholdet i jeres dokumenter. Sikring af den juridiske værdi af digitale dokumenter bør derfor betragtes som en overbygning på den høje grad af teknisk sikkerhed, som allerede af andre grunde skal etableres omkring et elektronisk arkiv, herunder at man sikrer sig mod tab/forvanskning af data, sikrer tilgængeligheden af data og sikrer sig mod uautoriseret adgang til data. Support af de valgte løsninger Når jeres myndighed har valgt en løsning, skal I sikre jer, at den nødvendige support et tilgængelig, samt, at I løbende vurderer jeres behov for løsninger ift. tilgængelige tekniske løsningsmuligheder. Nedenfor finder I en række forsalg til, hvor I kan hente hjælp i denne henseende: > leverandører af konverteringsløsninger > leverandører af operativsystemer og applikationer > hjemmesiden dokumentformater.oio.dk, hvor I bl.a. finder en converteroversigt > Forskellige hjemmesider, herunder kontorpakkeleverandørers hjemmesider, samt hjemmesider, der omhandler tekstbehandlingsprogrammer 50

200 Bilagssamling Side 200 af Kravet om at understøtte de obligatoriske, åbne dokumentstandarder ved nyanskaffelser, opgraderinger mv. > I dette afsnit i vejledningen får I et overblik over, hvordan I skal forholde jer, hvis I skal anskaffe nye løsninger. I kan blandt andet læse om, hvornår og for hvilke systemer kravene gælder, hvilke overvejelser I skal gøre jer, og hvor I kan hente hjælp. 4.1 Hvad ligger der i anskaffelseskravet? Pr. 1. januar 2008 bliver OOXML og ODF obligatoriske standarder for offentlige myndigheder. Det betyder, at løsninger, der anskaffes efter 1. januar 2008, skal understøtte mindst én af disse åbne standarder. Ved nye løsninger forstås nyindkøb og nyudvikling, samt videreudvikling og opgradering af software, med mindre dette foregår som en del af en allerede indgået aftale før 1. januar Det er myndigheden, som i forbindelse med nyanskaffelsen vurderer, om dokumentformater er relevante for løsningen. I givet fald skal mindst en af standarderne understøttes af softwaren Hvor kan I hente hjælp? IT- og Telestyrelsen har i oktober 2007 udsendt en vejledning om anvendelse af obligatoriske, åbne standarder for software i det offentlige, hvori det forudsættes, at al offentlig nyudvikling fra 1. januar 2008 udarbejdes på grundlag af obligatoriske, åbne standarder, jf. Vejledning om anvendelse af obligatoriske åbne standarder i det offentlige Undtagelser fra anskaffelseskravet Løsninger, der anskaffes efter 1. januar 2008, skal understøtte mindst én af de åbne standarder OOXML og/eller ODF, med mindre anskaffelsen foregår som en del af en allerede indgået aftale før 1. januar Derudover kan offentlige myndigheder undtage sig selv fra reglerne om at anvende obligatoriske, åbne standarder, hvis myndigheden ved at følge reglerne tvinges til en løsning, der enten: > er væsentligt fordyrende i forhold til anvendelse af andre standarder, > svækker sikkerhedsniveauet væsentligt i forhold til anvendelse af andre standarder, > medfører væsentlig funktionel forringelse, der er direkte forårsaget af, at den er baseret på de obligatoriske, åbne standarder, > øger implementeringstiden markant, eller

201 Bilagssamling Side 201 af 379 > > medfører konflikt med standarder, der på grund af internationale forpligtelser er gældende indenfor enkeltområder. Vurderes det, at reglerne om anvendelse af åbne standarder skal fraviges, skal dette kunne forklares og begrundes efter følg eller forklar -modellen. Følg eller forklarmodellen, er beskrevet i vejledning om anvendelse af obligatoriske, åbne standarder for software i det offentlige, jf Hvilke systemer og hvilke funktioner skal understøttes? Hvis I som myndighed står overfor en anskaffelse, bør I identificere, hvilke obligatoriske, åbne standarder, som er relevante for den efterspurgte løsning. Den berørte software er således ikke kun tekstbehandlingssystemer, men kan eksempelvis også være ESDH, Mail, CMS eller fagsystemer. Det afgørende er, om softwaren skal kunne håndtere redigerbare tekstbehandlingsdokumenter. I så fald skal et nyanskaffet system understøtte mindst ét af de åbne dokumentformater. Ved anskaffelser forstås samlede systemer eller platforme. Kravene gælder altså ikke, hvis I blot anskaffer en enkelt ny licens til en kontorpakke. I nedenstående skema ses en oversigt over de funktionsområder, som forskellige systemtyper skal kunne håndtere og understøtte for de åbne dokumentformater (oversigten er ikke udtømmende): Kontorpakker (tekstbehandling) EDH/ ESDH Mail CMS og portaler Dokumenthåndterende fagsystemer Modtage (begge Nej Ja Ja Nej (Ja) formater) Lagre Nej Ja Ja Ja (Ja) Læse Ja Ja Nej (Ja) (Ja) Producere Ja Ja Nej (Ja) (Ja) Publicere Nej Ja Nej Ja (Ja) Distribuere Nej Ja Ja (Ja) (Ja) Generere ud fra skabeloner Figur 6 Krav til forskellige systemtyper Nej Ja Nej Nej (Ja) Som det fremgår af oversigten, er der forskel på, hvad de forskellige systemer skal kunne understøtte. Oversigten skal tages som en vejledning, da I selv skal vurdere, om netop det system, I skal anskaffe, skal understøtte de nye obligatoriske standarder. Specielt i forhold til dokumenthåndterende fagsystemer vil det afhænge af det enkelte system, hvilke funktioner, der skal understøttes. 52

202 Bilagssamling Side 202 af 379 > 4.3 Forberedelse af anskaffelsen Indkøb af it-software kræver en høj grad af forberedelse. Ved større anskaffelser af it-software bør myndigheden altid indlede med en grundig foranalyse. Der henvises til vejledningen Obligatoriske, åbne standarder og udbud, som I kan finde via fra december Foranalyse Ved nyanskaffelser skal I analysere, hvorvidt og i hvilken grad den nye løsning får berøring med tekstbehandlingsprogrammer, eller andre applikationer til for eksempel publicering, journalisering og lignende, der skal kunne håndtere redigerbare tekstbehandlingsdokumenter. Der kan også være tale om løsninger, hvorfra I skal udtrække rapporter. Skal disse udtræk/rapporter være i PDF eller regneark, eller skal de være i tekstformat og derved i ODF eller OOXML? Nedenfor er angivet en række spørgsmål til inspiration for foranalysen: > Hvordan integrerer den nye løsning til de gamle applikationer og løsninger hos myndigheden? Er der afledte krav til opgradering/nyanskaffelse på andre områder end dem, den nye løsning er tiltænkt at dække, for at imødegå kravet om åbne dokumentformater? > Er der integration til fagsystemer via skabeloner, der ligger i tekstbehandlingsformater? og bliver disse berørt af den nye løsning? > Henter myndigheden data fra eksterne kilder, der er berørt af kravet til åbne dokumentstandarder? > Leverer myndigheden data til eksterne brugere eller systemer, som er berørt af kravet til åbne dokumentstandarder? > Er der skabeloner til indberetninger til offentlige myndigheder, som endnu ikke understøtter de åbne dokumentformater, og som derfor stiller ekstra krav til den nye løsning for at kunne modtage og arbejde videre med dokumenter i andre formater? > Vil den nye løsning stille krav til andre dokumenttyper end tekstbehandling, som for eksempel regneark, for integration til andre systemer eller samarbejdsmyndigheder? Ovenstående er eksempler på, hvor I som myndighed skal sikre jer, at de rigtige krav bliver stillet til jeres leverandører. I skal selv vurdere, hvilke andre eksempler, der kan være relevante for jer. 53

203 Bilagssamling Side 203 af 379 > Krav i forbindelse med aflevering til Statens Arkiver Når I som myndighed nyanskaffer løsninger efter 1. januar 2008, skal I være opmærksom på, at de dokumenter, der bliver genereret fra den nye løsning ligesom det hele tiden har været tilfældet skal afleveres til Statens Arkiver. De pilotforsøg, som er gennemført i Statens Arkiver, har vist, at der ikke er betydeligt flere eller færre problemer ved konvertering fra åbne tekstbehandlingsdokumentformater til afleveringsformat for tekstdokumenter (TIFF), end der er ved konvertering fra lukkede tekstbehandlingsdokumentformater til afleveringsformat for tekstdokumenter (TIFF) Vurdering af leverandørernes parathed Når I skal anskaffe nye systemer, eller I bare skal vurdere, om jeres eksisterende systemer er klar til at håndtere de nye dokumentformater, kan I med fordel starte med at tjekke leverandørernes parathed. Derfor har IT- og Telestyrelsen udarbejdet en parathedsvurdering, hvor en række leverandører har deltaget i en undersøgelse omkring understøttelse af ODF og OOXML. Denne parathedsvurdering, som leverandørerne selv har udfyldt, finder I på dokumentformater.oio.dk/leverancer. 4.5 Modtagelse af DOC efter anskaffelse af ny kontorpakke Myndigheder, som har anskaffet et ODF- eller OOXML-baseret tekstbehandlingsapplikation, må forvente at modtage DOC-dokumenter fra myndigheder, der endnu ikke har opgraderet eller nyanskaffet også selvom de ikke er forpligtiget til at kunne håndtere dette format. Dette afsnit vil derfor behandle den situation, at DOC-dokumenter bliver modtaget hos myndigheder, der lige er begyndt at understøtte de åbne dokumentstandarder Myndighed der overvejer løsning med ODF som produktionsformat I pilotforsøgene har det gennemgående tekstbehandlingssystem for ODF været OpenOffice. Her er det ikke nødvendigt at installere en converter for at kunne modtage og læse DOC-dokumenter, da dette allerede ligger i systemet. Erfaringer med modtagelse af DOC Pilotforsøgene har vist, at det i OpenOffice generelt er muligt at modtage DOCdokumenter og åbne dem i ODF uden meningsforstyrrende indholdstab. Der er dog observeret eksempler på tab af data. Ved modtagelsen af DOC-dokumenter er der under pilotforsøgene set eksempler på, at billeder, tekstbokse og dynamisk indsatte objekter forsvinder. 28 Jf. også oplysninger om krav til dokumenthåndtering i Statens Arkivers vejledning til cirkulære om anmeldelse og godkendelse af elektroniske journaler og elektroniske dokumenthåndteringssystemer fra 2002 på 54

204 Bilagssamling Side 204 af 379 > Ud over disse tab af data er der kun observeret få visuelle afvigelser i forbindelse med konverteringerne. I forbindelse med gentagne konverteringer er der dog observeret mindre visuelle forskelle. Pilotforsøgene viser dermed, at det er muligt at modtage og læse DOC-dokumenter forudsat, > at der ikke er anvendt indsatte elementer i dokumentet. For disse elementer gælder, at det drejer sig om tegninger direkte i dokumentet, grafik og billeder samt dynamiske objekter fra andre formater, som fx ODF-regneark eller Microsoft Visio-dokumenter. > at der ikke bliver foretaget flere på hinanden følgende konverteringer Der er i dag flere myndigheder, som anvender ODF som produktionsformat i deres tekstbehandlingsprogram, og som modtager mange dokumenter i DOC-formatet. Blandt disse myndigheder kan nævnes Gribskov Kommune og Region Midtjylland, som begge har indgået i IT- og Telestyrelsens pilotprojekt. Hos disse to myndigheder har man ikke oplevet væsentlige problemer med at modtage og åbne DOC-dokumenter. Løsninger Hvis myndigheden har et behov for at kunne se og validere de konverterede dokumenter, kan der anvendes en viewerløsning. Det er gratis at hente Microsoft Word Viewer på Microsofts hjemmeside. Fra denne løsning kan I åbne, gemme og udskrive DOC-dokumenter Myndighed der overvejer løsning med OOXML som produktionsformat Microsoft Word 2007 er pt. (november 2007) det eneste tekstbehandlingssystem, der understøtter OOXML som standard produktionsformat. Systemet er som udgangspunkt bagud-kompatibelt. Det betyder, at der ikke er behov for installation af konverteringsløsninger for at kunne modtage DOC-dokumenter i Word Erfaringer med modtagelse af OOXML Der er i pilotforløbet ikke fundet eksempler på fejlkonverteringer, der resulterer i tab af indhold eller meningsforstyrrende ændringer. Der er observeret få visuelle ændringer i punktopstilling og i sidehoved, hvor tekstbokse har ændret justering på siden. Herudover kan det konstateres, at feltdefinitioner for dokumenter, der er opbygget med integration til fagsystemer, bliver konverteret korrekt. Der er i pilotforsøgene identificeret nogle mindre visuelle forskelle i dokumenterne ved gentagne konverteringer. Løsninger 55

205 Bilagssamling Side 205 af 379 > Ved anskaffelse af Word 2007 eller andet tekstbehandlingsprogram, der understøtter OOXML, vil der ikke være behov for yderligere løsninger for at modtage DOCdokumenter. Bemærk at Microsoft Word 2007 giver mulighed for at arbejde i en særlig kompatibilitetstilstand, som ifølge Microsoft sikrer, at brugere, der arbejder med tidligere versioner af Word og modtager det i Word 2007 oprettede dokument, har alle redigeringsmuligheder På Microsofts hjemmeside kan man læse, hvordan man aktiverer kompatibilitetstilstanden i Word 2007: office.microsoft.com/da-dk/word/ha aspx?pid=ch

206 Bilagssamling Side 206 af Yderligere information og hjælp til selvhjælp > I dette afsnit i vejledningen får I et overblik over hvilke øvrige relevante oplysninger og redskaber, der er tilgængelige for jer som myndigheder, når I skal implementere åbne dokumentformater i jeres myndighed. I kan blandt andet finde test-selvpakken, converterkortlægningen, information om funktionalitetsloftet, metoden og resultaterne fra pilotforsøg og laboratorietest, mv. 5.1 Hjælp til selvhjælp Test-selv-pakke For at hjælpe jer med at få de første erfaringer med de nye dokumentformater har IT- og Telestyrelsen lavet en test-selv-pakke. Den indeholder forskellige eksempeldokumenter i ODF og OOXML og en vejledning i, hvordan I tester modtagelsen af disse. I kan enten vælge at bruge den samlede test-selv-pakke til at gennemføre en struktureret og dokumenteret test efter den metode, som er anvendt i projektets pilotforsøg, eller I kan blot vælge at bruge eksempeldokumenterne i ODF og OOXML og prøve jer frem efter jeres egen metode. Test-selv-pakke kan hentes på dokumentformater.oio.dk Er din leverandør parat? For at give jer informationer om leverandørernes parathed i forhold til understøttelse af de nye dokumentformater, har IT- og Telestyrelsen gennemført en leverandørparathedsvurdering i samarbejde med it-branchen. Formålet med vurderingen har været at afdække leverandørernes parathed i forbindelse med kravet om anvendelse af åbne dokumentformater i det offentlige. Undersøgelsen er gennemført som en "selvvurdering". I undersøgelsen svarer leverandørerne eksempelvis på: > Hvilke systemfunktioner, der er understøttet ved anvendelse af de forskellige dokumentformater > Historik > Versionsstyring > Livscyklus > Check ind/ check ud > Publicering > Distribuering > Brevfletning 57

207 Bilagssamling Side 207 af 379 > > Hvilke køreplaner, der findes for understøttelse af ODF/OOXML i kommende versioner af systemet > Hvilke produktionsværktøjer, der er oprettet aktive integrationer til > Hvordan leverandørerne vil orientere/rådgive offentlige myndigheder om muligheden for at anvende ODF/OOXML i deres systemer > Hvordan XML-baseret indhold via de nye dokumentformater kan tilføje ekstra værdi i det konkrete system > > Hvilke scenarier, der er afprøvet sammen med kunder > Hvilke systemfunktioner, der er understøttet ved anvendelse af de forskellige dokumentformater I kan læse leverandørernes besvarelser og finde relevante kontaktpersoner fra de enkelte leverandører på dokumentformater.oio.dk Erfaringsudveksling myndigheder imellem Denne vejledning og de øvrige materialer, som I kan finde via IT- og Telestyrelsens hjemmeside, kan ikke give jer svaret på alt i relation til håndtering af åbne dokumentformater. Derfor anbefaler IT- og Telestyrelsen, at I udveksler informationer og erfaringer med andre offentlige myndigheder. Det kan være myndigheder, som ligner jer selv, eller myndigheder, som blot har gjort sig interessante erfaringer, I kan drage nytte af FAQ - Frequently asked questions IT- og Telestyrelsen besvarer løbende myndighedernes spørgsmål vedr. beslutningen om åbne standarder. Se aktuelle spørgsmål og svar på dokumentformater.oio.dk 5.2 Mere vejledningsmateriale Converterkortlægning og oversigt For at give jer et overblik over relevante konverteringsløsninger har IT- og Telestyrelsen lavet en kortlægning af de konverteringsmulighederne. Kortlægningen blev første gang gennemført maj 2007 og den nyeste version, som ligger på IT- og Telestyrelsens hjemmeside, er fra ultimo november Se kortlægningen på dokumentformater.oio.dk/leverancer. Desuden er der udarbejdet en converteroversigt, som giver et hurtigt overblik over de tilgængelige convertere. Se oversigten på dokumentformater.oio.dk/leverancer. Da udviklingen inden for convertere går hurtigt, har IT- og Telestyrelsen valgt at følge denne udvikling nøje i løbet af første halvår Relevante informationer og nyheder vil løbende blive publiceret på hjemmesiden, og der vil senest medio 2008 blive publiceret endnu en ajourført udgave af converterkortlægningen. 58

208 Bilagssamling Side 208 af 379 > Resultater fra pilotforsøg og laboratorietest I kan se sammenfatningen af resultaterne fra de gennemførte pilotforsøg og laboratorietest på dokumentformater.oio.dk/leverancer. Indholdet af denne sammenfatning er primært indarbejdet i afsnit 3 og 4 i nærværende vejledning. I kan læse mere om de vejledningsrelevante konklusioner fra pilotforsøg og laboratorietest i afsnit i nærværende vejledning Metode for gennemførelse af pilotforsøg og laboratorietest Pilotforsøg og laboratorietest er begge gennemført efter detaljeret og dokumenteret metode, og alle resultater er fuldt dokumenteret både i forhold til testresultat og anvendt konfiguration m.v. Det betyder f.eks., at alle tests kan gentages på et senere tidspunkt. Det være sig med de originale konfigurationer eller med modificerede konfigurationer, f.eks. med nye versioner af convertere og programmer. Det vil således f.eks. være muligt på et senere tidspunkt at undersøge om nye convertere og programmer skaber bedre mulighed for praktisk interoperabilitet mellem de åbne dokumentformater. Den detaljerede metodebeskrivelse for pilotforsøg, paralleltest og laboratorietest findes på dokumentformater.oio.dk/leverancer. Se desuden overordnet formåls- og metodebeskrivelse i afsnit i nærværende vejledning Funktionalitetsloft Gennem vejledningen er der løbende refereret til funktionalitetsloftet se det konsoliderede funktionalitetsloft på dokumentformater.oio.dk/leverancer. I kan også se en overordnet beskrivelse af funktionalitetsloftets formål i afsnit i nærværende vejledning Udvalgte interoperabilitetsproblemer mellem ODF og OOXML makroer I forbindelse med udarbejdelse af vejledningen, er der afdækket specielle udfordringer, som vedrører udveksling af dokumenter, hvor der indgår makroer. Opsummeringen på dette arbejde findes i et notatet udvalgte interoperabilitetsproblemer mellem ODF og OOXML makroer på dokumentformater.oio.dk/leverancer Kendte filtyper i OOXML og ODF overblik Da modtagerkravet ift. åbne dokumentformater kun omfatter redigerbare tekstdokumenter til udveksling, gælder kravene kun de filtyper, som falder inden for denne definition. For en oversigt over de filtyper, som i dag er defineret under formaterne OOXML og ODF, henvises til oversigten Kendte filtyper i OOXML og ODF overblik på dokumentformater.oio.dk/leverancer. 59

209 Bilagssamling Side 209 af 379 > 5.3 Yderligere information Internationale erfaringer Denne vejleding er baseret på nationale og internationale erfaringer. En række andre lande har påbegyndt lignende tiltag om åbne dokumentformater, men der er ikke gennemført tiltag af samme omfang som det, der nu iværksættes i Danmark. Eksempelvis findes der ingen konkrete officielle vejledninger som nærværende i udlandet. Nedenfor er listet de lande, der har gennemført projekter, som er blevet undersøgt i forbindelse med projektet omkring åbne dokumentformater. > Belgien > EU (IDABC) > Frankrig > Holland > Norge > USA (Massachusetts) Endelig skal det nævnes, at IT- og Telestyrelsen løbende vil søge at inddrage relevante udenlandske erfaringer med praktisk håndtering af de åbne dokumentformater. Dette vil bl.a. ske i regi af EU-organet PEGSCOs igangsatte undersøgelse ODEF (Open Document Exchange Formats), som undersøger sameksistensen mellem de to dokumentformater ODF og OOXML. ODEF forventes at få stort overlap med de i Danmark gennemførte pilotforsøg og laboratorietest. ODEF forventes i 2008 bl.a. at tilvejebringe: > Retningslinjer for interoperabilitet > Værktøj for kontrol af interoperabilitet > Vejledninger for design af og indhold i oversættelsesbare dokumenter Referenceliste På dokumentformater.oio.dk/leverancer kan I finde en liste over en række ressourcer, der er anvendt internt i forbindelse med IT- og Telestyrelsens udarbejdelse af nærværende vejledning om åbne tekstdokumentformater. Ressourcerne har primært tjent et procesmæssigt formål, og rummer derfor ikke et væsentligt vejledningsindhold for myndighederne. 60

210 Bilagssamling Side 210 af 379

211 Bilagssamling Side 211 af 379 < Vejledning i anvendelse af åbne standarder for dokumentudveksling December 2007, v januar 2008 vil en række åbne standarder blive obligatoriske at anvende for offentlige myndigheder ved fremtidige indkøb af software og it-løsninger. For offentlige myndigheder betyder det, at man skal sikre sig, at fremtidige itløsninger er baseret på, eller understøtter, disse obligatoriske, åbne standarder, hvis standarderne er relevante for it-løsningen. Herudover bliver det obligatorisk for alle offentlige myndigheder at kunne modtage tekstbehandlingsdokumenter i formaterne ODF og OOXML fra 1. januar Idet der er begrænset erfaring med brug af de to formater, har IT- og Telestyrelsen i 2007 gennemført en omfattende vidensindsamling, pilotforsøg og laboratorietest, herunder en omfattende afprøvning af mulighederne for at håndtere modtagne dokumenter i de to åbne dokumentformater. Resultaterne af dette arbejde har givet den erfaringsmæssige baggrund for IT- og Telestyrelsens udarbejdelse af denne vejledning i anvendelse af de åbne dokumentformater, ODF og OOXML. Vejledningen giver konkrete anvisninger på, hvordan I sikrer, at jeres myndighed fra 1. januar 2008 kan leve op til kravene om anvendelse af åbne standarder for dokumentudveksling i det offentlige. Vejledningen dækker de obligatoriske åbne standarder for dokumentudveksling (ODF og OOXML), som er ét ud af syv sæt af obligatoriske standarder. For en overordnet vejledning, som beskriver sammenhængen til de øvrige seks sæt af standarder samt generel vejledning i anskaffelse af nye it-løsninger mv., henvises til materialerne Sådan anvender du åbne standarder i din myndighed og Vejledning om anvendelse af obligatoriske åbne standarder for software i det offentlige, som kan findes via IT- og Telestyrelsen, IT-Arkitekturkontoret December 2007

212 Bilagssamling Side 212 af 379

213 Bilagssamling Side 213 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag K

214 Bilagssamling Side 214 af 379 Converter-kortlægning Et øjebliksbillede af de tilgængelige convertere til åbne dokumentformater juni 2008 CONNECTING BUSINESS & TECHNOLOGY Converterkortllægning Devoteam Consulting. Kopiering og distribution kun tilladt efter aftale med Devoteam Consulting.

215 Bilagssamling Side 215 af 379 Indholdsfortegnelse 1. Indledning Konvertering af tekstbehandlingsdokumenter Konverteringsmetoder Funktionalitet kontra integration Lavt modenhedsniveau mere arbejde for brugere og administratorer Ændringer siden sidste udgave af converterkortlægningen Muligheder for brug af OOXML og ODF i udvalgte tekstbehandlingsprogrammer Brug af OOXML og ODF i udvalgte tekstbehandlingsprogrammer AppleWorks ver Corel WordPerfect Office X IBM Lotus Word Pro Microsoft Office Word Microsoft Office Word XP Microsoft Office Word Microsoft Office Word Microsoft Office Word for Mac 2004 og SUN StarOffice Writer ver KWord (del af KOffice) ver OpenOffice.org Writer ver Opsummering på mulighed for anvendelse af OOXML og ODF i udvalgte tekstbehandlingsprogrammer Gennemgang af relevante convertere Convertere fra og/eller til ODF BOpenDoc Docvert JODConverter OpenOffice.org Format Converter Open XML/ODF Translator Add-ins for Office - Word Sun ODF Plugin 1.2 for Microsoft Office beta Xena Brug af OpenOffice.org s konverteringsteknologi i eksterne convertere Convertere fra og/eller til OOXML OpenOffice.org OpenXML Translator Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats Microsoft File Converter en del af Office Migration Planning Manager Microsoft Office Open XML File Format Converter for Mac (Beta)... 41

216 Bilagssamling Side 216 af 379 Converterkortlægning docxconverter Docx-converter.com Konvertering fra og til både OOXML og ODF NeoOffice ODFTrans Relaterede undersøgelser NA VT Working Group Translation Staten Massachusetts undersøgelse Bilag 1. Forklaringer og noter...56 Dokumentformater Open Source-licenstyper nævnt i denne kortlægning... 56

217 Bilagssamling Side 217 af 379 Converterkortlægning 1. Indledning Dette notat præsenterer en kortlægning af en række konverteringsprogrammer i det følgende omtalt som convertere. De nævnte convertere er programmer eller plugins, som konverterer et dokument fra ét format til et andet. Deres formål er at gøre brugeren i stand til at kunne læse og gemme i de åbne dokumentformater ODF hhv. OOXML. Formålet med converter-kortlægningen er at skabe et overblik over: - Hvilke convertere, der findes i relation til udvalgte tekstbehandlingsprogrammer - Hvem der leverer converterne - Hvad converterne kan funktionalitetsmæssigt - Hvordan converterne kan integreres med eksisterende systemer - Hvad de forskellige convertere koster Målgruppen for dette notat er primært it-ansvarlige hos offentlige myndigheder. Præcisering Siden sidste opdatering af converterkortlægningen i november 2008, er ISO/IEC DIS 29500, Information technology Office Open XML file formats blevet godkendt som ISO/IEC-standard: Godkendelsen skete som følge af en fast track -procedure hos ISO/IEC, hvor et udkast til standarden er blevet godkendt forudsat at en række kommentarer indarbejdes. Den endelige tekst i standarden kendes derfor i skrivende stund ikke. Som følge deraf er der endnu ikke nogen convertere, der implementerer ISO/IEC fuldt ud. Den første understøttelse ventes at komme i efterfølgeren til Microsofts Office Når der i denne kortlægning henvises til OOXML, menes der derfor den hidtidige ECMA-376-standard, hvor intet andet er nævnt. Der er også kommet mere fokus på de forskellige versioner af OpenDocument Format(ODF)-specifikationen. OpenOffice.org understøtter ODF 1.1, Microsoft vil tilføje ODF 1.1-understøttelse til Microsoft Office Derfor skelnes der i denne udgave af kortlægningen mellem de forskellige versioner, idet der dog i det følgende menes version 1.0, hvis intet andet er nævnt. Det skyldes, at OASIS sætter lighedstegn mellem OpenDocument version 1.0 og ISO-standarden 26300:2006:

218 Bilagssamling Side 218 af 379 Converterkortlægning Det samme gør ISO på siden: Bemærk, at ODF version 1.0 er godkendt som standard af ISO og OASIS, mens version 1.1 indtil videre kun er godkendt af OASIS. Metode for kortlægningen Kortlægningen er gennemført som et desk study i forbindelse med projektet Vejledning & pilotforsøg om åbne dokumentstandarder ODF og OOXML (Ecma Open Office XML). Rammerne for opgaven er i øvrigt beskrevet i et selvstændigt dokument, der vedlægges som bilag. Kortlægningen er baseret på en omfattende vidensindsamling, herunder bl.a.: - Besøg på leverandørhjemmesider for alle i bilaget nævnte tekstbehandlingsprogrammer, hvor der er søgt efter oplysninger om understøttelse af OOXML/ODF, plugins, convertere og planer for kommende versioner af tekstbehandlingsprogrammerne. - Generelle søgninger på Google og andre søgemaskiner efter kombinationer af ord som; OOXML, Open XML, ODF, OpenDocument, converter, plugin, addin, varianter af navne på tekstbehandlingsprogrammerne, m.fl. - De generelle søgninger har ledt til en række forskellige artikler, blogs, fora, mv., der er blevet skimmet for relevante oplysninger. - Specifikke søgninger på: - Software-download/informationssider som eksempelvis download.novell.com, msdn.microsoft.com og - Interessegrupper for OOXML/ODF, bl.a Standardiseringsinstitutter, bl.a I den efterfølgende gennemgang er ikke medtaget projekter, der synes at være opgivet eller irrelevante, f.eks. - (opgivet projektet nåede ikke at udvikle egentligt software)

219 Bilagssamling Side 219 af 379 Converterkortlægning - (konvertering mellem ODF og det kinesiske XML-filformat UOF) Selvom der i forbindelse med kortlægningen er søgt inddragelse af en lang række forskellige kilder, kan det ikke udelukkes, at der forefindes relevante oplysninger ud over de her afdækkede. Notatets opbygning Notater er opbygget som følger: - I denne indledning gives først et overblik over konverteringsmetoder og teknologier (afsnit 1). - Efterfølgende beskrives væsentlige nyheder, ændringer og opdateringer relateret til convertere siden sidste udgave af converterkortlægningen, der er omtalt i denne udgave (afsnit 2). - Herefter præsenteres mulighederne for at anvende de to dokumentformater i en række forskellige tekstbehandlingssystemer (afsnit 3). - Herefter gennemgås de relevante convertere, som er identificeret i forbindelse med undersøgelsen (afsnit 4) Konvertering af tekstbehandlingsdokumenter I forbindelse med enhver konvertering er der risiko for tab af data (eks. tekst, formatering og indsatte objekter/elementer). Derfor er det aftalt, at der i forbindelse med indførelsen af de obligatoriske standarder afdækkes forskellige muligheder og udfordringer i forbindelse med konvertering. Det er kendt, at OOXML og ODF ikke understøtter de samme sæt af egenskaber og funktionaliteter. Derfor kan der være egenskaber i det ene dokumentformat, som ikke understøttes i det andet og omvendt. Det betyder, at converterne kan have problemer med at oversætte indhold korrekt. Eksempelvis indeholder OOXML samlet set flere funktioner end ODF, bl.a. fordi det er bagudkompatibelt med tidligere versioner af Microsoft Office-dokumentformater. Denne kortlægning handler om muligheden for at konvertere tekstbehandlingsdokumenter. Derfor er konvertering af andre dokumenttyper som regneark eller præsentationer kun omtalt sporadisk i det følgende. Man skal dog være opmærksom på, at hvis man konverterer tekstbehandlingsdokumenter, hvor der indgår dynamiske objekter fra andre applikationer, som f.eks. regneark, kan disse ved konverteringen enten forsvinde eller blive omformet til statiske elementer som tabel-

220 Bilagssamling Side 220 af 379 Converterkortlægning ler eller billeder i det konverterede dokument. Derfor kan det i et efterfølgende testforløb være relevant at se på converternes faciliteter til at konvertere relevante indlejrede elementer, herunder regneark mv Konverteringsmetoder Der er overordnet tre metoder for at anvende convertere i forbindelse med tekstbehandling: - Klientbaseret hvor konverteringsmuligheden er en del af selve tekstbehandlingsprogrammet. Enten via en tilføjet plugin, eller som et selvstændigt konverteringsprogram installeret på brugerens computer. - Web/ tjeneste en hjemmeside eller en e-postkasse på et inter- eller intranet, hvor brugeren kan uploade/sende dokumenter til og få konverterede udgaver af dokumenterne tilbage. - Serverbaseret integreret konvertering hvor converteren installeres i forbindelse med f.eks. en e-postserver og automatisk opfanger e-post med vedhæftede filer, som den konverterer baseret på nogle givne regler, uden at brugeren involveres. De undersøgte convertere i denne kortlægning anvender hver især en eller flere af de nævnte metoder. Der er i kortlægningen fundet convertere, som dækker alle de nævnte metoder, om end der kun er fundet ét eksempel på en serverbaseret integreret converter Funktionalitet kontra integration Når man gennemgår listen af convertere, skal man være opmærksom på, at der er nogle convertere, der anvender selvudviklet konverteringsteknologi, mens andre blot pakker eksisterende konverteringsteknologi - udviklet af andre leverandører - ind i ekstra funktionalitet, der f.eks. letter integrationen af teknologien i brugernes hverdag. Selvom der umiddelbart er tale om en række forskellige konverteringsprogrammer, bygger flere af dem altså på den samme teknologi. Således bliver OpenOffice.org s konverteringsteknologi brugt i flere af de undersøgte convertere. Tilsvarende bliver kode fra Sourceforge-projektet Open XML/ODF Translator Add-ins for Office genbrugt i converteren NeoOffice 2.2.3, og i Novell s OpenOffice.org OpenXML Translator.

221 Bilagssamling Side 221 af 379 Converterkortlægning Selv om to convertere anvender samme grundlæggende konverteringsteknologi, kan der være forskelle i resultatet af en konvertering med de to programmer. Dette kan skyldes converterens øvrige funktionalitet og den måde, hvorpå converteren anvender den genbrugte service eller kode. De identificerede convertere er i de fleste tilfælde engelsksprogede og er evt. først udviklet til engelsk og senere oversat til dansk. Man må derfor antage, at der kan forekomme fejl i forbindelse med konvertering af specialtegn som de danske æ, ø og å Lavt modenhedsniveau mere arbejde for brugere og administratorer Udvikling af programmer til konvertering til og fra ODF/OOXML og andre almindelige dokumentformater, som f.eks. DOC, er en svær opgave. Hvis man ser på konvertering mellem ODF og DOC, så har udviklerne af kildekoden til OpenOffice.org brugt flere år på studere DOC og udvikle nogle import/eksport-filtre. Alligevel er de ikke fejlfri eller komplette. OOXML er kun ca. halvandet år gammel som Ecma-standard. Microsoft har selv gjort meget for at sikre inteoprabiliteten med DOC, primært i form af deres Compatibility Pack". De har formodentligt kunne starte dette arbejde, mens de stadig udviklede OOXML, og de har derfor haft nogen tid til det. Anderledes forholder det sig med interoperabiliteten mellem ODF og OOXML, og med Words evne til at importere og eksportere ODF. Væsentlige bidrag omtalt i denne kortlægning som "Open XML/ODF Translator Add-ins for Office" (Clever Age, Microsoft, Novell, m.fl.), "Sun ODF Plugin for Microsoft Office" (Sun) og "OpenOffice.org OpenXML Translator" (Novell) er stadig relativt nye på markedet. "OpenOffice.org OpenXML Translator" er desuden udsprunget af "Open XML/ODF Translator Add-ins for Office". De er bestemt ikke fejlfri. De nævnte er alle opdaterede siden sidste udgave af converterkortlægningen.. Ingen af dem understøtter endnu ODF ver Selv om de kan bruges til ODF 1.0, som de er nu, må de derfor fortsat betragtes som produkter, der er under udvikling.

222 Bilagssamling Side 222 af 379 Converterkortlægning Den relativt lave modenhed har konsekvenser for både brugere af converterne og de administratorer, der skal vælge, installere og supportere konverteringsløsningerne. Brugerne kan aldrig helt regne med, at et konverteret dokument gengiver alt relevant indhold fra originaldokumentet. Dette kan give misforståelser og ekstraarbejde både til kvalitetssikring og til at rette op på fejl begået pga. misforståelser omkring indholdet af det konverterede dokument. Administratorerne vil ofte skulle vælge en konverteringsløsning mellem flere produkter, der ikke kan betragtes som modne, og supportere løsningen bagefter. Argumenterne for valg af en converterløsning kan desuden vise sig at være kortvarige. Dels fordi den valgte løsning kan vise sig at give problemer i et bestemt miljø, som administratoren har ansvar for. Men også fordi det kan være, at der et halvt år efter den første beslutning om at bruge én konverteringsløsning, kommer en væsentlig opdatering til en anden, der vil gøre denne til et bedre valg. Man må forvente, at både brugernes og administratorernes arbejde vil blive lettet, efterhånden som modenhedsniveauet stiger. Men på kort sigt skal begge grupper være forberedt på de udfordringer, som modenhedsniveauet af converterne giver.

223 Bilagssamling Side 223 af 379 Converterkortlægning 2. Ændringer siden sidste udgave af converterkortlægningen Nærværende kortlægning er udarbejdet første gang i maj 2007 og tidligere opdateret i november Denne udgave er en opdatering foretaget ultimo maj primo juni 2008 med henblik på at inddrage nye convertere og opdateringer til de gamle. Følgende er en liste over de væsentligste ændringer og nyheder, der er medtaget i denne udgave (ikke-prioriteret rækkefølge): - Det tyske standardiseringsinstituts arbejdsgruppe vedrørende forskelle på og muligheder for oversættelse mellem ODF og OOXML har udgivet et udkast til en rapport i ISO-regi. Den endelige rapport vil komme i februar Se Relaterede undersøgelser. - Tilføjet beskrivelse af den gratis, eksterne, serverbaserede converter OD- FTrans 0.7.3, der giver mulighed for at få konverteret dokumenter ved at sende dem til en server på en (intern) adresse. o (Et regeringsorgan i Holland har i maj 2008 lovet at frigive et program, der også giver adgang til konvertering via en tjeneste, som open source. Programmet minder således om ODFTrans. De supplerende informationer på siden er på hollandsk: ) - ISO/IEC 29500, Information technology Office Open XML file formats blevet godkendt som ISO/IEC-standard. - "Sun ODF Plugin for Microsoft Office er opgraderet fra 1.1 til 1.2. Den kan nu også anvendes til Microsoft Office 2007 (Service Pack 1 eller højere) - Microsoft har annonceret, at Microsoft Office Word 2007 vil få tilføjet understøttelse af ODF 1.1, når Service Pack 2 bliver frigivet i Word-converteren i Open XML/ODF Translator Add-ins for Office er blevet opgraderet fra version 1.1 Release M2+M3 (beta-udgave) til OpenOffice.org er blevet opgraderet fra version 2.3 til 2.4. o OpenOffice.org 2.4 understøtter ODF 1.1, men ikke OOXML. Visse brugere hævder, at OpenOffice.org kan modificeres, så det bliver muligt at åbne.docx-filer. Se afsnittet om OpenOffice.org Writer. - Microsoft Office Open XML File Format Converter for Mac er blevet opgraderet fra 0.2 til (Beta) o Opgraderingen har forlænget udløbsdatoen med et år til 31/ OpenOffice.org, Novell Edition er blevet opgraderet til version 2.4

224 Bilagssamling Side 224 af 379 Converterkortlægning o Den tilhørende OpenOffice.org OpenXML Translator er opgraderet til version Corel WordPerfect Office er blevet opgraderet fra X3 til X4. Den nye version giver mulighed for at åbne og læse ODF og OOXML. - Øvrigt: o NeoOffice er blevet opgraderet fra version til o har ændret deres vilkår, så man nu får ubegrænsede konverteringer i et år efter den første betaling. Gratis konvertering er mulig, men med 24 timers forsinkelse. o har fået en betalingstjeneste, der giver ekstra muligheder den understøtter dog de samme formater, som den gratis udgave. o Der er tilføjet et link til 2007-udgaven af Word Viewer under Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats.

225 Bilagssamling Side 225 af 379 Converterkortlægning 3. Muligheder for brug af OOXML og ODF i udvalgte tekstbehandlingsprogrammer 3.1. Brug af OOXML og ODF i udvalgte tekstbehandlingsprogrammer Nedenfor gennemgås muligheden for brug af OOXML og ODF i følgende udvalgte tekstbehandlingsprogrammer: - AppleWorks ver Corel WordPerfect Office X4 - IBM Lotus Word Pro Microsoft Office Word Microsoft Office Word XP - Microsoft Office Word Microsoft Office Word Microsoft Office Word for Mac 2004 og SUN StarOffice Writer ver. 8 - KWord (del af KOffice) ver OpenOffice.org ver. 2.3 De to sidstnævnte tekstbehandlingssystemer KWord og OpenOffice.org 2.4 er open source under LGPL-licensen. De øvrige undersøgte testbehandlingssystemer er proprietær software, der skal betales licens for. For hvert tekstbehandlingsprogram nævnes relevante plugins. Hvor disse ikke er tilgængelige eller mangler funktionalitet, henvises i stedet til eksterne convertere. Med en ekstern converter menes en konverteringsmulighed, der ikke er knyttet direkte til tekstbehandleren enten i form af indbygget funktionalitet eller et plugin/udvidelse til tekstbehandlingsprogrammet. En ekstern converter kan f.eks. være et parallelt installeret tekstbehandlingsprogram på brugerens maskine med bedre konverteringsmuligheder, eller en webtjeneste f.eks. på brugerens intranet, hvor brugen kan få konverteret filer. Det er også muligt at anvende en ekstern converter, selv om der findes plugins til tekstbehandlingsprogrammet. Dette kan være relevant, hvis det ved en afprøvning bliver konstateret, at de tilgængelige plugins ikke giver en tilfredsstillende konvertering, og at dette i stedet kan opnås med en ekstern converter.

226 Bilagssamling Side 226 af 379 Converterkortlægning AppleWorks ver AppleWorks ver understøtter hverken OOXML eller ODF, og der er ikke udsigt til, at der kommer en udvidelse eller en converter rettet direkte mod AppleWorks. Apple har standset salget af AppleWorks pr. 15/8-2007, programmet har fået "end-of-life-cycle -status, og henviser i stedet til iwork 08, hvor tekstbehandlingsprogrammet Pages 08 er i stand til at åbne OOXML men tilsyneladende ikke ODF: - Brugere af dette tekstbehandlingsprogram kan i stedet forsøge at anvende en ekstern converter. Alternativt kan man overveje at skifte til NeoOffice (se omtalen af denne). TekstEdit i Mac OS X Leopard skulle også være i stand til at åbne og gemme både ODF- og OOXML-filer: Corel WordPerfect Office X4 Corel WordPerfect Office X4, der er udgivet foråret 2008, har indbygget mulighed for at åbne og vise både ODF og OOXML: - Vores afprøvning viser, at det ikke er muligt at gemme i hverken ODF eller OOXML-format. Den tidligere version X3 havde slet ingen understøttelse af ODF eller OOXML. Forslag til alternative convertere er omtalt i den tidligere udgave af converterkortlægningen fra november IBM Lotus Word Pro 9.8 IBM Lotus Word Pro 9.8 understøtter hverken OOXML eller ODF, og der er pt. ingen convertere for OOXML og ODF, der er direkte rettet mod IBM Lotus Word Pro ODF-understøttelse i IBM Productivity Tools / IBM Lotus Symphony IBM har tilføjet IBM Productivity Tools, der understøtter ODF, til Lotus Notes 8. Fra Lotus Notes er IBM Productivity Tools dog omdøbt til IBM Lotus Symphony.

227 Bilagssamling Side 227 af 379 Converterkortlægning Hvis man har Lotus Notes 8, kan man derfor bruge dette værktøj til at håndtere ODF. IBM Productivity Tools / IBM Lotus Symphony er baseret på en tidligere udgave af OpenOffice.org. IBM Lotus Symphony 1.0 blev frigivet som en gratis, selvstændig kontorpakke den 30. maj Den kan bl.a. åbne og gemme.doc og ODF dokument-filer: ftp://ftp.software.ibm.com/software/lotus/pub/lotusweb/misc/ibm_productivit y_tools_overview.pdf OOXML er ikke understøttet af IBM Productivity Tools / IBM Lotus Symphony, hvorfor Lotus Word Pro-brugere vil skulle bruge en af de eksterne convertere til dette Microsoft Office Word 2000 Microsoft Office Word 2000 understøtter hverken OOXML eller ODF som standard. Brugere af Microsoft Office Word 2000 kan installere Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats, der integreres fuldt ud i Word. Brugeren kan efter installationen åbne, læse og redigere OOXML-tekstfiler (.docx og.docm). Bemærk, at det i Word 2000 ikke er muligt at åbne adgangskodebeskyttede filer af typen.docx eller.docm, og at makroer vil blive fjernet (se beskrivelsen af Microsoft Office Compatibility Pack nedenfor). Det er uklart, om det er producentens mening, at Open XML/ODF Translator Add-ins for Office skal virke til Word Det fremgår ikke eksplicit af hjemmesiden, men det synes at virke i praksis. Converteren bliver delvist integreret i Word. Brugeren kan efter installationen vha. en særlig ODF-menu, som plugin et tilføjer, konvertere ODF-formatterede tekstfiler til en skrivebeskyttet OOXML-fil, der kan redigeres og efterfølgende gemmes som OOXML eller konverteres tilbage til ODF-format.

228 Bilagssamling Side 228 af 379 Converterkortlægning Alternativt kan brugerne installere Sun ODF Plugin 1.2 for Microsoft Office, der giver en tættere integration i tekstbehandlingssystemet, idet den tilføjer muligheden for at åbne og gemme.odt-filer i de almindelige åbne/gemme-menuer i Word Microsoft Office Word XP Microsoft Office Word XP understøtter hverken OOXML eller ODF som standard. Brugere af Microsoft Office Word XP kan installere Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats, der integreres fuldt ud i Word. Brugeren kan efter installationen åbne, læse og redigere OOXML-tekstfiler (.docx og.docm). Brugere af Microsoft Office Word XP kan installere Open XML/ODF Translator Add-ins for Office, der bliver delvist integreret i Word. Brugeren kan efter installationen vha. en særlig ODF-menu, som plugin et tilføjer, konvertere ODFformatterede tekstfiler til en skrivebeskyttet OOXML-fil, der kan redigeres og efterfølgende gemmes som OOXML eller konverteres tilbage til ODF-format. Alternativt kan brugerne installere Sun ODF Plugin 1.2 for Microsoft Office, der giver en tættere integration i tekstbehandlingssystemet, idet den tilføjer muligheden for at åbne og gemme.odt-filer i de almindelige åbne/gemme-menuer i Word Microsoft Office Word 2003 Microsoft Office Word 2003 understøtter hverken OOXML eller ODF som standard. Brugere af Microsoft Office Word 2003 kan installere Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats, der integreres fuldt ud i Word. Brugeren kan efter installationen åbne, læse og redigere OOXML-tekstfiler (.docx og.docm). Brugere af Microsoft Office Word 2003 kan installere Open XML/ODF Translator Add-ins for Office, der bliver delvist integreret i Word. Brugeren kan efter

229 Bilagssamling Side 229 af 379 Converterkortlægning installationen vha. en særlig ODF-menu, som plugin et tilføjer, konvertere ODFformatterede tekstfiler til en skrivebeskyttet OOXML-fil, der kan redigeres og efterfølgende gemmes som OOXML eller konverteres tilbage til ODF-format. Alternativt kan brugerne installere Sun ODF Plugin 1.2 for Microsoft Office, der giver en tættere integration i tekstbehandlingssystemet, idet den tilføjer muligheden for at åbne og gemme.odt-filer i de almindelige åbne/gemme-menuer i Word Microsoft Office Word 2007 OOXML er en fast del af Microsoft Office Word 2007, der er systemets standard tekstdokumentformat. Det understøtter dog ikke ISO Brugere af Microsoft Office Word 2007 kan installere Open XML/ODF Translator Add-ins for Office, der bliver delvist integreret i Word. Brugeren kan efter installationen vha. en særlig ODF-menu, som plugin et tilføjer, konvertere ODFformatterede tekstfiler til en skrivebeskyttet OOXML-fil, der kan redigeres og efterfølgende gemmes som OOXML eller konverteres tilbage til ODF-format Understøttelse af ODF 1.1 i Office 2007 Service Pack 2 og ODF + ISO i Office 14 Microsoft offentliggjorde den 21. maj 2008, at Office 2007 Service Pack 2 med forventet udgivelse i første halvdel af 2009 vil indeholde integreret understøttelse af ODF 1.1. Det vil være muligt at åbne, redigere og gemme ODF-dokumenter uden ekstra plugins, ligesom det vil blive muligt at sætte ODF som standardformatet i Word ODF-understøttelse i de tidligere versioner af Word ( ) vil fortsat kun ske via Open XML/ODF Translator Add-ins for Office. Service Pack 2 vil ikke indeholde understøttelse af Microsofts egen ISO/IEC Dette vil først komme i næste udgave af Microsoft Office, kaldet Office 14, der forventes i slutningen af Det bemærkes, at Microsoft ikke forventer at kunne understøtte ISO/IEC i Service Pack 2, selvom der er indbygget understøttelse af det konkurrerende ODF-format. Der har været mange gæt på årsagen i pressen og på diverse blogs. En forklaring kunne være, at teksten til ISO/IEC i skrivende stund ikke er frigivet i en endelig version, hvor kommentarerne fra fast track -godkendelses-

230 Bilagssamling Side 230 af 379 Converterkortlægning processen er indarbejdet. Det kan derfor være svært at afgøre, hvor stort et arbejde det vil være at tilpasse den eksisterende understøttelse af OOXML til ISO/IEC Microsofts udmelding hilses velkommen fra flere sider, bl.a. fra EUkommissionen, der vil følge nøje med i, om den annoncerede integration af ODFunderstøttelse i Office 2007 vil føre til, at brugerne får lettere ved at behandle og udveksle dokumenter: - Andre reaktioner har været mere forbeholdende: - Indtil Service Pack 2 frigives, kan man hente Sun ODF Plugin 1.2 for Microsoft Office i stedet, og få en tilsvarende integration, dog kun til ODF Microsoft Office Word for Mac 2004 og 2008 Microsoft Office Word for Mac 2008 understøtter OOXML, men ikke ODF. Det tidligere Microsoft Office Word for Mac 2004 understøtter hverken OOXML eller ODF. Brugere af Microsoft Office Word for Mac 2004 kan benytte Microsoft Office Open XML File Format Converter for Mac (Beta) eller docxconverter 3.0, der begge kan konvertere OOXML-dokumenter til RTF-formatet, som Microsoft Office Word for Mac 2004 kan læse. I den generelle beskrivelse af Sourceforge-projektet Open XML/ODF Translator Add-ins for Office står der, at målet med projektet er at tilvejebringe oversættere, der kan muliggøre interoperabilitet mellem ODF og Microsoft OpenXML based Office applications. - Office 2008 er baseret på OOXML. Der er dog endnu ikke noget, der tyder på, at partnerne bag Sourceforge-projektet Open XML/ODF Translator Add-ins for Office vil udvikle en version af converteren til Word Alternativt kan Mac-brugere benytte den gratis kontorpakke NeoOffice som ekstern converter til at oversætte mellem OOXML, ODF og andre tekstdokumentformater.

231 Bilagssamling Side 231 af 379 Converterkortlægning SUN StarOffice Writer ver. 8 SUN StarOffice Writer ver. 8 understøtter ODF, idet det er muligt at importere og eksportere ODF-tekstfiler. SUN StarOffice Writer ver. 8 understøtter ikke OOXML. Men StarOffice 9 vil have indbygget understøttelse. Den skulle komme i fjerde kvartal af 2008: I mellemtiden kan StarOffice-brugere anvende en ekstern converter til at konvertere mellem OOXML og et dokumentformat, som StarOffice kan håndtere, som f.eks. RTF KWord (del af KOffice) ver KWord version har indbygget understøttelse af ODF, der er systemets standard tekstdokumentformat, men systemet understøtter ikke OOXML. KWord anbefaler at udveksle dokumenter med Microsoft Word ved at konvertere til RTF: F jf.: KDE har ingen planer om at tilføje understøttelse af OOXML heller ikke til den kommende version 2.0 (artikel fra 9. oktober 2007): (side 2) Ved konvertering fra og til OOXML vil en bruger af KWord version derfor skulle bruge en ekstern converter OpenOffice.org Writer ver. 2.4 OpenOffice.org Writer 2.4 har indbygget understøttelse af ODF 1.1, der anvendes som standard tekstbehandlingsformat, men den understøtter ikke OOXML. Understøttelse af OOXML i OpenOffice.org forventes i ver. 3.0, der er planlagt til at udkomme i september Understøttelsen er rettet mod at give mulighed for at åbne/vise OOXML-filer:

232 Bilagssamling Side 232 af 379 Converterkortlægning - Release Der er udgivet en beta-udgave af version 3.0, der kan åbne/vise OOXML-filer. Visse brugere hævder, at man kan modificere eksisterende, færdige udgaver af OpenOffice.org til Linux, så den kan åbne.docx-filer. Se f.eks.: Det er væsentligt at bemærke, at der på de ovenfor nævnte sider er eksempler på brugere, hvis installationer af OpenOffice er blevet beskadiget af modificeringen (muligvis som følge af fejlbetjening). Det er også usikkert, om det virker med OpenOffice ver Det hævdes at virke med version 2.2 under visse Linuxdistributioner. Et nyere, eksperimentel program odf-converter-integrator benytter også Novells kode. Den skulle tillige virke til OpenOffice.org på Windows Opsummering på mulighed for anvendelse af OOXML og ODF i udvalgte tekstbehandlingsprogrammer Som ovenstående viser, er der en række forskellige muligheder for at anvende OOXML og ODF i de mest udbredte tekstbehandlingsprogrammer, men der er forskel på, hvordan det lader sig gøre. Adskillige af tekstbehandlingsprogrammerne understøtter hverken OOXML eller ODF i den nuværende udgave. Til nogle af disse findes plugins, der hver især giver en delvis understøttelse af konvertering mellem tekstbehandlerens standardformat og OOXML/ODF. Det gør det muligt at konvertere fra/til det ene af de to formater, medens nogle af tekstbehandlingsprogrammerne er henvist til at bruge en ekstern converter. Man skal være opmærksom på, at AppleWorks ikke bliver opdateret længere, og undersøgelsen tyder på, at brugere af både dette program og af IBM Lotus Word Pro alene må basere sig på eksterne convertere. Brugere af Word 2000/XP/2003/2007 kan klare sig uden en ekstern converter med en kombination af Microsofts kompatibilitetspakke til OOXML (ikke nødvendig

233 Bilagssamling Side 233 af 379 Converterkortlægning for Word 2007) og enten det Microsoft-financierede ODF-plugin eller SUN s plugin (der nu også understøtter Word 2007). Dette under forudsætning af, at de nævnte plugins reelt virker i brugerens opsætning og giver et tilfredsstillende resultat med det dokument, brugeren ønsker at arbejde med. I modsat fald kan det være nødvendigt at anvende en ekstern converter alligevel. Hvis man vælger at bruge Microsofts ODF-plugin skal brugerne dog vænne sig til at bruge forskellige menuer afhængigt af, om de skal arbejde med OOXML eller ODF, fordi det Microsoft-financierede plugin til ODF bliver integreret i Word på en anden måde end kompatibilitetspakkens og Word 2007 s understøttelse af OOXML (se også beskrivelsen af Open XML/ODF Translator Add-ins for Office ).

234 Bilagssamling Side 234 af 379 Converterkortlægning 4. Gennemgang af relevante convertere I det følgende gennemgås de relevante convertere identificeret i forbindelse med kortlægningen. Gennemgangen er udarbejdet med udgangspunkt i listen over tekstbehandlingsprogrammer (afsnit 2) samt via den generelle informationssøgning. - I afsnit 4.1 gennemgås convertere fra og/eller til ODF; - I afsnit 4.2 gennemgås convertere fra og/eller til OOXML. Gennemgangen beskriver kort følgende for hver converter: - Kort beskrivelse - Leverandør - Link (evt. hvor converter kan downloades) - Funktionalitet - Systemkrav - Kendte problemer - Integration - Styrker og svagheder - Omkostninger De angivne informationer er ikke nødvendigvis udtømmende. Da der er stor forskel på, hvordan converterne er dokumenteret på producenternes hjemmesider, og i hvilket omfang de er omtalt andre steder, vil dette forhold være afspejlet i de nedenfor angivne oplysninger. Producenterne er generelt ikke særligt specifikke mht. at beskrive de fejl, de retter i forbindelse med opdateringer, og fejl der er konstateret men endnu ikke løst. Det er sandsynligt, at der kan findes andre convertere fra/til ODF eller OOXML end de her nævnte. I så fald antages det, at det drejer sig om convertere udviklet med udgangspunkt i en af de her undersøgte convertere. På baggrund af den omfattende informationssøgning, især hos de store leverandører, forekommer det usandsynligt, at der på nuværende tidspunkt (primo juni 2008) skulle forefindes yderligere convertere baseret på selvstændig konverteringsteknologi, som ikke er afdækket via denne kortlægning. I gennemgangen af convertere skal det bemærkes, at det kun er følgende convertere, som anvender selvstændig konverteringsteknologi:

235 Bilagssamling Side 235 af 379 Converterkortlægning - Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats (afsnit 4.2.2) - OpenOffice.org / OpenOffice.org Novell Edition (afsnit og afsnit 4.2.1) - Open XML/ODF Translator Add-ins for Office (afsnit 4.1.5) - Sun ODF Plugin for Microsoft Office (afsnit 4.1.6) De øvrige convertere genbruger i forskelligt omfang teknologien fra OpenOffice.org og/eller kode fra Open XML/ODF Translator Add-ins for Office. Microsoft Office Word 2007 anvender også sin egen konverteringsteknologi, men denne er alene indbygget i tekstbehandlingsprogrammet og kan ikke gøres tilgængelig som en service, der kan benyttes af andre covertere, som eksempelvis er tilfældet med OpenOffice.org. Desuden medfører det licensomkostninger at installere Microsoft Office Word Det forekommer derfor ikke sandsynligt, at f.eks. en bruger af SUN StarOffice Writer ver. 8 vil købe og installere Microsoft Office Word 2007 parallelt med det andet tekstbehandlingsprogram alene med det formål at benytte Word som en converter. Derfor betragtes Microsoft Office Word 2007 i denne sammenhæng som et tekstbehandlingsprogram og ikke som en converter Convertere fra og/eller til ODF En næsten opdateret liste over applikationer (herunder convertere), der understøtter ODF, kan findes på: Der bliver henvist til listen fra flere forskellige hjemmesider relateret til ODFunderstøttelse, og den er også brugt i Ovitas AS s rapport, der ligger på OIO: (domænet er dog ændret fra.org til.com) Ud for hver applikation på listen er der angivet en rating via nogle stjerner, der skal vise, hvor moden den enkelte applikation er. Da denne rating er angivet af leverandøren selv, og der ikke synes at være nogle objektive kriterier eller nærmere detaljer om tildelingen, har vi valgt ikke at anvende dem i denne kortlægning BOpenDoc Kort beskrivelse: Serverbaseret, automatisk konvertering til og fra OpenDocument (ODF). Er først

236 Bilagssamling Side 236 af 379 Converterkortlægning og fremmest baseret på OpenOffice.org s konverteringsteknologi (se nedenstående links), men har pr. oplyst også at bruge andre biblioteker. Leverandør: 3BView ( Link: - (om programmet) - (særligt om ODF) - (online demonstration af konvertering) - (flere detaljer om 3BOpenDoc - bl.a. at det benytter OpenOffice.org) Programmet kan ikke downloades via de nævnte links. (Det er en betalingsløsning, jf. nedenstående afsnit om omkostninger). Funktionalitet: Tovejs konvertering til og fra ODF og en række andre formater. Produktet anvender OpenOffice.org og tilbyder således præcis de konverteringsmuligheder, som denne pakke understøtter. OOXML understøttes pt. ikke. Firmaet oplyser pr. , at OOXML først vil være understøttet i Det hænger formodentligt sammen med, at OpenOffice.org forventer at understøtte læsning af OOXML-filer i version 3.0, der skulle komme sidst i Systemkrav: Det er en Java-løsning. Firmaet oplyser, at de understøtter Linux og Windows 2003 (ikke andre versioner), men de leverer og anbefaler Linux og en Tomcatserver. Løsningen siges at kunne anvendes med enhver SMTP- server og burde derfor kunne anvendes sammen med både Lotus Notes og Microsoft Exchange. Nærmere systemkrav er ikke beskrevet. Kendte problemer: Der er hverken fundet oplysninger om kendte problemer eller omvendt påstande om, at converteren skulle være helt uden fejl. Det er nødvendigt at afprøve converteren, hvis dette skal afdækkes. Integration: 3BOpenDoc s formål er at integrere konverteringen på serversiden, så brugerne ikke behøver at tænke over, at de skal foretage en konvertering.

237 Bilagssamling Side 237 af 379 Converterkortlægning Produktet installeres i forbindelse med organisationens e-postserver, content management system (CMS) eller document management system (DMS). Her opfanger det på baggrund af nogle definerede regler de dokumenter, der skal konverteres, og foretager den nødvendige konvertering transparent for brugeren. Det vil sige, at hvis der på 3BOpenDoc-serveren hos myndighed A er defineret en regel, der angiver, at vedhæftede filer til myndighed B skal konverteres til ODF, så vil en bruger hos myndighed A kunne sende en med f.eks. vedhæftede docfiler, og 3BOpenDoc vil så opfange den, konvertere filerne og levere en, uden at brugeren hos myndighed A behøver at gøre noget aktivt for at få konverteringen til at ske. 3BOpenDoc vil også kunne konvertere vedhæftede filer fra ODF til f.eks. RTF, eller et af de andre formater, som OpenOffice.org kan konvertere til, før de bliver leveret til en intern bruger, i tilfælde af at myndighedens anvendte tekstbehandlingsprogram ikke understøtter ODF. Styrker og svagheder: Det er som nævnt en betalingsløsning (jf. nedenstående afsnit om omkostninger), og funktionaliteten mht. konverteringen er baseret på, hvad OpenOffice.org kan levere. Funktionaliteten mht. integrationen er kun overfladisk beskrevet på firmaets hjemmeside, og der har ikke været adgang til f.eks. en demonstrationsopstilling, hvorfor vi ikke ved, hvordan det virker i praksis. Det kan være et problem, at brugeren mister muligheden for at kontrollere resultatet af konverteringen, når den sker automatisk på serversiden, så f.eks. vedhæftede.doc-filer til en ekstern modtager automatisk bliver konverteret til.odt, før e- posten bliver leveret til modtageren. Hvis man ikke kan være sikker på, at enhver konvertering giver et tilfredsstillende resultat, må det formodes, at brugeren vil ønske at kunne kontrollere, hvordan et dokument ser ud efter konverteringen, før det bliver sendt til en e-postmodtager eller gemt i et system, og det er ikke muligt ved automatiske konvertering på serversiden. Omkostninger: Det har været svært at kontakte firmaet pr. og telefon, en i juni 2008 mhp. af få opdateret informationerne forblev ubesvaret, men i en modtaget d. 29. maj 2007, anslås prisen til Euro pr. server pr. år afhængigt af antallet af brugere og mængden af s. Prisen indikerer, at der er tale om individuelt

238 Bilagssamling Side 238 af 379 Converterkortlægning tilpassede løsninger, men det er ikke klart, præcist hvilken tilpasning af software og evt. support man får for pengene Docvert 3.3 Kort beskrivelse: Envejs konvertering fra.doc til ODF og evt. videre til HTML eller anden XMLformat. Der er tale om en Webservice baseret på PHP, der til konverteringerne bruger JODConverter (eller den skrabede udgave PyODConverter fra samme leverandør) og dermed OpenOffice.org (eller det knapt så opdaterede Abiword - Leverandør: Matthew Cruickshank ( Link hvor converter kan downloades: - eller Funktionalitet: Se den korte beskrivelse ovenfor. Løsningen er beregnet til envejs-konvertering, men man vil formodentligt kunne modificere PHP-filerne, så man kan udnytte flere af OpenOffice.org s konverteringsmuligheder. Systemkrav: Løsningen er afprøvet på Linux og Windows, men ikke på Mac OS X. - PHP 5.0 or later with the "ZLIB" and "XSL" extensions. - En af følgende - OpenOffice.org eller nyere - På en Linux/BSD/OSX skal man også bruge Xvfb. - Abiword eller nyere med Import/Export OpenDocument plugin - JODConverter eller PyODConverter, hvis man ønsker at øge hastigheden af konverteringen - Ved særlige konverteringsbehov kan det være nødvendigt at installere yderligere (gratis) softwarebiblioteker: - Kendte problemer: Der er hverken fundet oplysninger om kendte problemer eller modsat påstande

239 Bilagssamling Side 239 af 379 Converterkortlægning om, at converteren skulle være helt uden fejl. Det er nødvendigt at afprøve converteren, hvis dette skal afdækkes. Integration: Det er et PHP-program, der er beregnet til at blive kørt fra en webserver. Det er potentielt muligt at eksekvere det i en kommandoprompt. Der medfølger et Wordplugin til Word for Windows (version 97 og nyere), der skulle gøre det muligt at dele en Docvert-server via netværket. Der er en kort beskrivelse her: Desuden er der skærmbilleder her: Styrker og svagheder: I denne sammenhæng kan Docvert ses som et eksempel på en ekstern converter dvs. en webtjeneste, der benytter OpenOffice.org eller lign. konverteringsteknologi til at tilbyde konvertering via netværket. Den er dog noget begrænset, idet man kun kan konvertere til ODF, og den vil derfor kun være interessant, hvis det kan betale sig at modificere de PHP-filer, den består af, i stedet for at skræddersy en ny overbygning til OpenOffice.org s konverteringsteknologi fra bunden. Omkostninger: Gratis JODConverter Kort beskrivelse: Overbygning til OpenOffice.org skrevet i Java, der giver mulighed for at automatisere konvertering, indlejre en konverteringstjeneste i en Java-applikation eller kalde den fra en webtjeneste. Leverandør: Art of Solving (enkeltperson Link, hvor converter kan downloades: Funktionalitet:

240 Bilagssamling Side 240 af 379 Converterkortlægning Selve konverteringen bliver foretaget af konverteringsservicen i programmet OpenOffice.org. Det er derfor muligt at foretage alle de former for konverteringer, som dette program understøtter, og dokumenter konverteret med JODConverter vil også have de fejl, der eventuelt måtte forekomme med Openoffice.org. Med OpenOffice.org ver. 2.4 kan der konverteres til og fra ODF og en række andre formater. OOXML er ikke understøttet og vil først blive det (delvist) med OpenOffice.org ver JODConverter kan anvendes som: - simpel web-applikation, hvor man kan uploade et dokument, vælge et format man vil konvertere til, og downloade den konverterede version - Java-bibliotek, der kan anvendes i en egenudviklet Java-applikation - kommandolinje-værktøj installeret på den enkelte klient Systemkrav: - JODConverter kræver: - Java runtime environment version 1.4 eller nyere. - OpenOffice.org eller nyere (evt. StarOffice 8 eller NeoOffice burde virke men er ikke afprøvet) - Ethvert operativsystem hvortil både Java og OpenOffice.org er tilgængelige. - For at bruge JODConcerter som web application/web-service skal man desuden have: - En Servlet 2.3-container som Apache Tomcat 4.1 eller nyere. - OpenOffice.org installeret som en service på samme computer som JODConverter eller tilgængelig via netværket. Kendte problemer: Converteren genkender filtypen på baggrund af filnavnet. Det kan give større risiko for fejl, end når man benytter genkendelse på baggrund af indholdet af filen. Det er programmøren selv, der har rapporteret fejlen, og man kunne derfor formode, at han vil arbejde på en forbedring i en senere udgave. Se: Integration: Afhænger af, hvordan man vælger at bruge den (se under funktionalitet ovenfor).

241 Bilagssamling Side 241 af 379 Converterkortlægning Styrker og svagheder: Potentielt en meget fleksibel konverteringsmulighed. I øjeblikket mangler standardudgaven af OpenOffice.org mulighed for at håndtere OOXML-filer, men version 3.0 kommer til at indeholde mulighed for at åbne og læse (import) OOXML. Programmøren bag Docvert (se omtalen af denne) beskriver JODConverter som en effektiv måde (mht. performance) at tilgå OpenOffice.org s konverteringsbiblioteker, fordi den gør det muligt at bruge OpenOffice.org i server-mode (daemon mode): - Omkostninger: Gratis open source under GPL v3-licensen OpenOffice.org Format Converter Kort beskrivelse: Batch-konvertering (konvertering af mange filer på en gang) mellem de formater, som OpenOffice.org understøtter, udviklet af Tim Donohue, forskningsprogrammør, University of Illinois at Urbana-Champaign. Leverandør: University of Illinois at Urbana-Champaign ( Link til information og download: - nternal/openofficeconvert Funktionalitet: Konvertering af en eller flere filer fra og til et format, der er understøttet af Open- Office.org (batch-konvertering). Systemkrav: Der er tale om et Java-program, og det skulle i princippet være platformsuafhængigt. Programmøren har dog kun afprøvet det på Linux, ikke på Windows og Mac OS X. Programmet kræver: - OpenOffice.org, version 2.x (som service) - Java 1.5 eller nyere OpenOffice.org Format Converter minder om JODConverter, som der også henvises til for oplysninger om installation i et Windows-miljø.

242 Bilagssamling Side 242 af 379 Converterkortlægning Kendte problemer: Der er hverken fundet oplysninger om kendte problemer eller omvendt påstande om, at converteren skulle være helt uden fejl. Det er nødvendigt at afprøve converteren, hvis dette skal afdækkes. Integration: Programmet afvikles fra en kommandoprompt eller via Java API. OpenOfficeservicen kan være installeret på den samme computer som programmet eller på en server, der er tilgængelig via en netværksforbindelse. Styrker og svagheder: Brugerinterfacet (kommandoprompt) er ikke særligt brugervenligt og er næppe anvendeligt for almindelige brugere. Muligheden for at kunne konvertere mange filer på en gang kan dog være praktisk i nogle sammenhænge. Omkostninger: Gratis ( The University of Illinois/NCSA Open Source -licens), kan downloades via ovennævnte link Open XML/ODF Translator Add-ins for Office - Word 1.1 Kort beskrivelse: Samling af plugins til Office (2000/)XP/2003/2007, der gør det muligt at åbne, redigere og gemme OpenDocument 1.0 (ODF)-dokumenter i Word, Excel og Powerpoint. Understøttelse af ODF 1.1 skulle komme i version 2.0 i august Leverandør: Sourceforge-projekt med følgende partnere: Clever Age ( Sonata-Software ( Aztecsoft ( DIaLOGIKa ( Microsoft ( og Novell ( Link: Funktionalitet:

243 Bilagssamling Side 243 af 379 Converterkortlægning Tovejs konvertering til og fra ODF 1.0. Gør det muligt at åbne, redigere og gemme OpenDocument tekstfiler (.odt) i Microsoft Word (2000,) XP, 2003 og 2007 samt i de tilsvarende udgaver af Excel og Powerpoint. Systemkrav: - Microsoft Word (2000), XP, 2003 eller For Microsoft Office Word (2000/)XP/2003 desuden: - Office Compatibility Pack -.NET framework For Microsoft Office Word 2007 desuden: - Word 2007 med.net Programmability Support aktiveret -.NET framework 2.0 Kravene fremgår af nedenstående side, der kan være forældet. I hvert fald nævner den ikke Word 2000, selv om vi har konstateret, at det er muligt at installere ODF Add-in for Word 1.1 i denne udgave af Word: - Word 2000 er også nævnt i projektets Changelog : - Kendte problemer: Release Notes for ODF Translator for MS-WORD 1.1 indeholder 21 fejl, der ikke er blevet rettet. Fejlene spænder fra småfejl i formatering til risiko for overskrivning af en eksisterende fil med en ny fil med samme filnavn uden forudgående advarsel. Projektet har desuden oversigter over kendte fejl og ønsker til forbedringer under menupunktet Tracker på siden De har kortlagt en lang række egenskaber, der ikke er understøttet i hhv. OOXML og ODF. Dette er et udtryk for generelle forskelle på ODF og OOXML. Disse forskelle kan give problemer, hvis man benytter funktioner i ét dokumentformat og ønsker at konvertere dokumentet til et andet format, hvor funktionerne ikke er understøttet. Se listen over egenskaber, der ikke er understøttet på I eksperimentel afprøvning med converteren installeret i Word 2000 ville converteren ikke gemme en åben fil som ODF, hvis den lå i et EDH-system. Det gav fejlmeddelelsen: "Please save your document before exporting to ODF". Først ef-

244 Bilagssamling Side 244 af 379 Converterkortlægning ter at filen var gemt på den lokale harddisk, kunne den gemmes (eksporteres) som ODF. Dette problem fandtes også i den tidligere beta-udgave af version 1.1. Integration: Integreres i nogen grad med den pågældende version af Microsoft Word. Se også næste punkt. Der findes desuden en udgave, der kan benyttes til selvstændig konvertering uden brug af Microsoft Office: OpenXML/ODF Translator Command Line Tools, der bl.a. benyttes af ODFTrans (se beskrivelse af denne). Styrker og svagheder: Ved installation af add-in et til Word, bliver der tilføjet to nye menupunkter til filmenuen; hhv. Open ODF og Save as ODF. Man skal benytte disse særlige menupunkter for at åbne/gemme filer. Det er ikke muligt at bruge Word s almindelige menuer og genveje til dette. Dobbeltklik på et.odt-dokument åbner ikke dokumentet korrekt i Word, man skal starte Word først og derefter benytte menupunktet Open ODF. Når man åbner en ODF-fil i Word vha. dette plugin, bliver filen importeret som en skrivebeskyttet.docx-fil. Hvis man redigerer i filen og ønsker at gemme sine ændringer, skal man først lave en kopi af dokumentet ved at gemme den under et nyt navn og derefter eksportere filen til ODF. Disse forhold gør det væsentligt mere besværligt for brugeren at anvende denne converter til ODF, end det f.eks. er at bruge Microsoft Office Compatibility Pack for til at arbejde med OOXML-filer. Microsoft Office Compatibility Pack integrerer sig i Word s almindelige menuer i Word-udgaver før 2007, så man f.eks. kan åbne med Ctrl+O og gemme via Ctrl+S. Converterens hukommelsesforbrug (processen OdfConverterHost.exe) er observeret til at være op til 57 MB. Processen starter, når man åbner eller gemmer et ODF-dokument i Word, og forbliver aktiv indtil Word lukkes, hvilket også får converteren til at afslutte. Der er dog set eksempler på, at WinWord.exe-processen har hængt, efter at Word ellers var blevet lukket. I disse tilfælde er OdfConverterHost.exe ikke blevet stoppet. Desuden benyttes hjælpefunktioner fra Microsoft Office Compatibility Pack, hvilket også tager ressourcer. Særligt om distribution af converteren:

245 Bilagssamling Side 245 af 379 Converterkortlægning Et (eksperimentelt) forsøg med at installere en tidligere udgave af Wordconverteren via Microsoft Systems Management Server mislykkedes pga. problemer med installationsfilen. Der skulle være rettet nogle fejl vedr. installation i den her omtalte udgave af converteren. Det er ikke afprøvet, om det nu er muligt at installere den fra centralt hold, ligesom der ikke er fundet oplysninger om andres erfaringer med distribution af converteren. Omkostninger: Gratis, en open source BSD-lignende licens, der kan ses på Sun ODF Plugin 1.2 for Microsoft Office Kort beskrivelse: Plugin til Microsoft Office 2000/XP/2003/2007, der gør det muligt for brugere af Microsoft Word, Excel og Powerpoint at åbne, redigere og gemme ODFdokumenter. Her fokuseres på den del af converteren, der integreres i Word. Converteren giver mulighed for at ændre Word s standard dokumentformat til ODF, og den kan dækkes af en Enterprise-supportaftale. Leverandør: Sun Microsystems ( Link: - (beskrivelse og link til download) Funktionalitet: Tovejs konvertering til og fra ODF. Gør det muligt at åbne, redigere og gemme OpenDocument tekstfiler (.odt) i Microsoft Word 2000, XP og 2003, 2007, samt i de tilsvarende udgaver af Excel og Powerpoint. Converteren giver også mulighed for at ændre Word s standard dokumentformat til ODF Text Document (.odt). Systemkrav: - Microsoft Windows 98, ME, 2000 (Service Pack 2 eller høere), XP eller Vista - Microsoft Office 2000/XP/2003/2007 eller de tilsvarende enkeltestående udgaver af Word, Excel og Powerpoint

246 Bilagssamling Side 246 af 379 Converterkortlægning - PC med Pentium-kompatibel processor MB RAM (512 MB RAM anbefales) - 45 MB plads på harddisken Kendte problemer: SUN har ikke publiceret mange oplysninger om problemer og fejlrettelser. Man kan i FAQ en for produktet læse. The document import and export accuracy has been improved in this release. Det er uvist, hvad det indebærer, og hvilke problemer i tidligere udgaver det evt. har løst. I FAQ en er der desuden beskrevet, at Word i nogle udgaver kan vise en advarselsboks, hvis der bruges et ukendt filformat, eller benyttes en ekstern converter. Der gives samtidigt tips til, hvordan man kan slå disse advarsler fra: - I forbindelse med vores afprøvning af en tidligere version er der observeret et problem: Converteren kan fejle, hvis stinavnet til den fil, der skal konverteres, er meget langt, og/eller brugerens navn er meget langt. Converteren foretog et programkald, der involverede en fil placeret under C:\Documents and Settings\brugernavn\ Application Data\SunODFPluginforMicrosoftOffice1. Det antoges, at fejlen opstod, hvis programkaldet overskrider en intern grænseværdi for længden af argumenter. Ved afprøvningen af version 1.2 var der stadig problemer med at åbne.odt-filer, hvis stien var meget lang, men det samme gjaldt for.doc- og.docx-filer fra samme katalog og med tilsvarende navn, og Word ville ikke gemme nogen filer i kataloget, fordi stien var for lang. Det er altså muligt, at denne og den observerede fejl i den tidligere udgave skyldes et og samme Word-problem: - Windows Vista-brugere vil bemærke, at Windows Vista ikke er på listen af de operativsystemer, man kan hente versioner af Sun ODF Plugin til. Der er dog bloggere, der skriver, at de har hentet versionen til Windows XP Pro og brugt den uden problemer. Integration: Converteren integreres tæt i Word. Efter installationen optræder.odt som et af de øvrige dokumentformater, man kan vælge at åbne eller gemme i Word, hvorfor brugeren kan benytte Word s almindelige genveje og menuer uden at behøve at tænke over, at der er en converter involveret. Hvis brugeren har behov for at åbne/gemme et ODF-dokument, vælges

247 Bilagssamling Side 247 af 379 Converterkortlægning dette, som var det ethvert andet tekstdokumentformat. Det er også muligt at gøre ODF til det format, som Word gemmer i som standard. Styrker og svagheder: Den tætte integration med Microsoft Word 2000/XP/2003/2007 gør det let for brugeren at arbejde med ODF-dokumenter. SUN fremhæver i den forbindelse modsætningen til den mere besværlige integration i " Open XML/ODF Translator Add-ins for Office": - Brugeren skal ikke anvende andre programmer for at kunne åbne eller gemme ODF-filer. Version 1.2 understøtter nu også Microsoft Office 2007, hvilket den ikke har gjort tidligere, som omtalt i en tidligere version af converterkortlægningen. Microsoft har tilsyneladende med SP1 fjernet et teknisk problem i Office 2007, som SUN tidligere har beklaget sig over. Nogle organisationer og virksomheder vil måske sætte pris på, at det er muligt at tegne en support-aftale med SUN på denne converter. Det er dog ikke undersøgt, hvilke fordele en sådan aftale giver, eller hvad den koster. Converterens hukommelsesforbrug (processen soffice.bin) er observeret til at variere mellem 50 og 80 MB, hvilket er en mindre stigning i forhold til version 1.1. Processen starter, når man åbner eller gemmer et ODF-dokument i Word via converteren første gang. Der vises et splash screen, og der bliver føjet et ikon til statusområdet ved siden af uret. Converteren forbliver aktiv indtil Windows lukkes, også efter at Word afsluttes, hvilket virker uhensigtsmæssigt, da den fortsat optager +50 MB RAM. Man kan afslutte processen manuelt, men man må stadig håbe, at SUN i en fremtidig udgave af converteren gør det muligt at konfigurere den til at lukke med Word. Særligt om distribution af converteren: Et (eksperimentelt) forsøg med at installere en tidligere version af Wordconverteren via Microsoft Systems Management Server lykkedes. Det er dog væsentligt, at man selv afprøver distributionsmulighederne i sin opsætning, før man lægger sig fast på en converter. Der ikke er fundet oplysninger om andres erfaringer med distribution af converteren. Omkostninger: Gratis.

248 Bilagssamling Side 248 af 379 Converterkortlægning Det fremgår af converterens FAQ (se link ovenfor), at man kan købe sig til supplerende service/support-aftaler hos SUN, der dækker converteren beta Kort beskrivelse: Online konvertering mellem.doc og.odt baseret på OpenOffice.org. Domænenavnet er en forkortelse af firmaets ønske om at OpenDocumentifying your documents. Leverandør: pbr systems GbR ( Link: Funktionalitet: Lader brugeren uploade en fil, som konverteres med det samme til.doc eller.odt, som derefter kan downloades. Systemkrav: Computer med internetforbindelse og Firefox eller Internet Explorer ver. 6 eller nyere. Kendte problemer: Der er hverken fundet oplysninger om kendte problemer eller omvendt påstande om, at converteren skulle være helt uden fejl. Det er nødvendigt at afprøve converteren, hvis dette skal afdækkes. Integration: Webtjeneste. Styrker og svagheder: Kan ikke bruges til nogen form for fortrolig information, idet tjenesten er udenfor brugerens kontrol, og der ikke er understøttet nogen form for sikkerhed i forbindelse med webtjenesten. Understøtter pt. ikke OOXML, og der er ikke angivet en tidsramme for, om dette evt. vil komme senere.

249 Bilagssamling Side 249 af 379 Converterkortlægning Omkostninger: Gratis Xena 4.1 Kort beskrivelse: Envejs konvertering til et åbent XML-format, herunder angiveligt også ODF. Programmet er udviklet af National Archives of Australia. Leverandør: National Archives of Australia ( Link: - Funktionalitet: Xena er en forkortelse for XML Electronic Normalising of Archives. Programmet er udviklet mhp. at konvertere elektroniske arkiver til et offentligt dokumenteret format, der kan læses i lang tid fremover uafhængigt af specifikke applikationer. Det hævdes at kunne konvertere til flere forskellige åbne formater, herunder ODF, og version 3.0 er nævnt på den liste, der er omtalt først i dette afsnit om ODFconvertere, men som standard konverterer den til Xenas eget XML-format, og det er ikke klart, hvordan der skiftes til et andet format, som f.eks. ODF. Systemkrav: Xena er baseret på Java og er i princippet platformsuafhængigt, men det skal bruge Runtime Environment version eller nyere. OpenOffice.org benyttes til at konvertere Microsoft Office-dokumenter, hvorfor dette også skal være installeret. Kendte problemer: Har problemer med at konvertere RTF. Se: Problemet ligger i den underliggende OpenOffice.org, Det skulle blive rettet i version 3.0, der kommer i efteråret Integration: Java-program, der kan køres fra den computer, hvor Xena er installeret.

250 Bilagssamling Side 250 af 379 Converterkortlægning Styrker og svagheder: Envejs konvertering til ét format, der som standard ikke er ODF. Programmet er primært medtaget her, fordi det er nævnt på den ovenfor refererede liste over ODF-convertere, som der henvises til fra mange andre hjemmesider om ODF. Det kan måske benyttes som inspiration for udvikling af andre convertere, der bygger videre på konverteringsteknologien i OpenOffice.org. Omkostninger: Gratis (GPL2) Brug af OpenOffice.org s konverteringsteknologi i eksterne convertere Som det fremgår af ovenstående gennemgang, er der flere af converterne, der bygger på OpenOffice.org s konverteringsteknologi. Det skyldes, at dette program udover at kunne bruges til dokumentbehandling, også kan installeres som en service på en server, så andre convertere/programmer kan tilgå den lokalt på serveren eller via det interne netværk. Denne egenskab er værd at fremhæve, da den gør det realistisk at fremstille egne webservices til konvertering, når udviklerne kan fokusere på at lave brugergrænsefladen og funktionalitet til håndtering af konverteringsopgaverne og genbruge selve konverteringsteknologien fra OpenOffice.org. Instruktion i at installere OpenOffice.org som en service kan findes på: - (Windows) - nvert#configure_openoffice_org_install (Linux og Mac OS X) Nævnte konverteringsmuligheder er bl.a.: - Konvertering til og fra o Microsoft Word (*.doc), o OpenDocument Text (*.odt), o OpenOffice.org 1.0 Text (*.sxw), o Rich Text Format (*.rtf) - Konvertering fra WordPerfect til et af de ovenfor nævnte formater Konverteringsmulighederne vil afhænge af, hvilken udgave af OpenOffice.org, der benyttes.

251 Bilagssamling Side 251 af 379 Converterkortlægning Den almindelige OpenOffice.org 2.4 understøtter ikke OOXML. Import af OOXML-filer vil version 3.0, der er ude i en beta-udgave, og skal være færdig i efteråret 2008 (se afsnittet om OpenOffice.org Writer ver. 2.4 ). Det er ikke undersøgt, om OpenOffice.org Novell Edition med det tilhørende OpenOffice.org OpenXML Translator kan anvendes som konverteringsservice på samme måde som OpenOffice.org Convertere fra og/eller til OOXML En liste over applikationer (herunder convertere), der understøtter OOXML, kan findes på: OpenOffice.org OpenXML Translator Kort beskrivelse: Plugin til Novells udgave af OpenOffice.org, der gør det muligt at åbne og gemme OOXML-tekstdokumenter (docx). Bygger på kode fra Sourceforge-projektet Open XML/ODF Translator Add-ins for Office nævnt i pkt Plugin et er i foråret 2008 opdateret til version Leverandør: Novell ( Link: - Både plugin et og OpenOffice.org Novell Edition kan hentes på: e=sdbuildbean&families=3402&version=&date_range=&keywords=&x=38 &y= or.html (installationsoplysninger) - Funktionalitet: Tovejs konvertering til og fra OOXML, herunder også mellem OOXML og ODF, da OpenOffice.org Novell Edition understøtter ODF. Systemkrav:

252 Bilagssamling Side 252 af 379 Converterkortlægning - Windows-udgaven: - OpenOffice.org eller senere Novell edition til Windows - Linux-udgaven: SUSE Linux Enterprise, SUSE Linux, eller opensuse og en af flg. - OpenOffice.org eller senere til SUSE Linux Enterprise Desktop 10 og opensuse OpenOffice_org-2.0 package til SUSE Linux 9.3 og OpenOffice_org package til opensuse OpenOffice_org-2.3 package for opensuse 10.3 Novell anbefaler dog at bruge den til enhver tid nyeste udgave af OpenOffice.org Novell edition. Kendte problemer: Der er hverken fundet oplysninger om kendte problemer eller omvendt påstande om, at converteren skulle være helt uden fejl. Vi har tidligere konstateret en fejl i forbindelse med vores afprøvning af version 1.1: Hvis der er æ, ø eller å i stien til den fil, der skal konverteres, fejler converteren ( den fryser ). Fejlen blev verificeret på Windows-platformen og meldt til Novell. Der blev ikke fundet samme fejl i Linux-udgaven af converteren. Det er ikke verificeret, om fejlen er rettet i version Integration: Integreres i de almindelige menuer i OpenOffice.org Novell Edition. Styrker og svagheder: Udvider Novells udgave af OpenOffice.org, så den ud over ODF også bliver i stand til at håndtere OOXML. Fungerer officielt kun med Novells udgave af OpenOffice.org (se dog omtalen af modificeringer i afsnittet om OpenOffice.org Writer ver. 2.4 ). Omkostninger: Gratis Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats Kort beskrivelse: Udvidelsespakke til Microsoft Office Word og Word Viewer. Se i øvrigt punktet Funktionalitet.

253 Bilagssamling Side 253 af 379 Converterkortlægning Leverandør: Microsoft ( Link: - (installationsvejledning og download). - (omtale). Funktionalitet: Pakken gør det muligt at åbne, redigere og gemme de nye dokumentformater fra Microsoft Office 2007 i Microsoft Office Word 2000/XP/2003. I Word Viewer er det alene muligt at åbne filerne. Se: (Artiklen omhandler den tidligere udgave af Word Viewer, der var version Den nyeste udgave, fra september 2007, hedder blot Word Viewer og kan hentes her: 457a-9aec-f4f827f20cac&DisplayLang=en ) Systemkrav: - Operativsystem: Windows 2000 Service Pack 4, Windows Server 2003, Windows Vista, Windows XP Service Pack 1 eller Windows XP Service Pack 2 - Tekstbehandler: Microsoft Word 2000, XP eller Eller Word Viewer (fra september 2007) Kendte problemer: Microsoft har beskrevet en række kendte problemer. De går primært på, at selv om man kan åbne et OOXML tekstdokument i en tidligere udgave af Word, er det ikke sikkert, at man kan ændre i det. Det er de elementer i dokumentet, der er oprettet vha. nye eller ændrede funktioner i Word 2007, der vil blive påvirket, f.eks. bliver ligninger til grafik, og forskellige dynamiske elementer konverteres til statisk tekst. Man bør særligt bemærke begrænsningerne i forhold til Word Word 2000 vil ikke være i stand til at åbne adgangskodebeskyttede filer af typen.docx eller.docm, selv om man kender adgangskoden, og generelt vil postflettedata og makroer gå tabt: -

254 Bilagssamling Side 254 af 379 Converterkortlægning Integration: Integreres med tekstbehandleren ved installationen og tilføjer mulighed for at åbne/gemme i de kendte menuer og via de almindelige genveje (Crtl+o og Crtl+s ) i Word 2000/XP/2003. Styrker og svagheder: Pakken bliver tæt integreret i den eksisterende version af Word. Muligheden for at åbne og gemme i OOXML-filer bliver tilføjet til de almindelige menuer og genveje. Denne integrerede løsning findes ikke tilsvarende i Open XML/ODF Translator Add-ins for Office, som Microsoft også financierer. Der er tillige integration, så man kan få opdateringer til sikkerhedsproblemer i kompatibilitetspakken via Microsoft Update (f.eks. følgende fra Microsoft Knowledge Base: KB og KB934062). Omkostninger: Gratis Microsoft File Converter en del af Office Migration Planning Manager Kort beskrivelse: Værktøj til envejskonvertering af et større antal filer fra et ældre Microsoft Office-format til OOXML. Værktøjet bygger på Microsoft Office Compatibility Pack og er en del af pakken Office Migration Planning Manager (OMPM). Leverandør: Microsoft ( Link: - (download). - (instruktion) - (omtale). Funktionalitet: Kommandolinjeværktøj til konvertering af ældre Microsoft Word, Excel og Powerpoint-filer til OOXML.

255 Bilagssamling Side 255 af 379 Converterkortlægning Det bygger oven på Microsoft Office Compatibility Pack, der står for selve konverteringen. Værktøjet kan automatisere konvertering af et stort antal filer, der kan være placeret i foldere og underfoldere i en Windows-filstruktur. Værktøjet konfigureres via en tekstbaseret konfigurationsfil. Systemkrav: - Operativsystem: Windows Server 2003, Windows Vista, Windows XP Service Pack 2 - Microsoft Office Compatibility Pack (se systemkravene for denne) Kendte problemer: Ingen tilgængelige oplysninger. Integration: Kommandolinjeværktøj. Som navnet på pakken (Office Migration Planning Manager) antyder, er værktøjet ikke beregnet til at blive integreret i en daglig arbejdsproces. Det er beregnet til en enkelt samlet konvertering af alle gamle filer til det nye format. Det vil selvfølgelig kunne anvendes efter behov f.eks. i forbindelse med flere, mindre konverteringsopgaver. Styrker og svagheder: Værktøjet formodes at kunne være en betydelig hjælp for administratorer eller superbrugere i en migrationssituation, hvor man ønsker at konvertere alle dokumenter i et Windows-filarkiv til OOXML. Det er til gengæld uegnet til brug for almindelige brugere pga. den ikke-trivielle konfiguration og brugergrænseflade. Omkostninger: Gratis Microsoft Office Open XML File Format Converter for Mac (Beta) Kort beskrivelse: Envejs konvertering af dokumenter fra.docx til RTF. Selvstændig converter, der gør det muligt for Mac-brugere at konvertere OOXML-formatterede tekstfiler til RTF, der kan åbnes i Microsoft Word for Mac 2004 og Microsoft Word X for Mac.

256 Bilagssamling Side 256 af 379 Converterkortlægning Opgraderingen fra ver. 0.2 til har tilsyneladende alene til formål at forlænge beta-perioden med et år til 31/ Leverandør: Microsoft ( Link: - Kan hentes på Microsoft Download Center: o b5bf-37c3-41bb-945e fc582c&displaylang=en - eller på Mac-siden (under Office 2004) o - Oprindelige udgave omtalt på: o Funktionalitet: Programmet kan konvertere Open XML-formaterne - Word Document (*.docx) og - Word Macro-Enabled Document (*.docm) til Rich Text Format (RTF), der kan åbnes i Microsoft Word 2004 og Microsoft Word X. Denne version af converteren kan desuden konvertere OOXML s Powerpoint-formater. Der kan konverteres én eller flere filer af gangen. Systemkrav: - Operativsystem: Mac OS X (Tiger) eller nyere udgave af Mac OS - Office (eller senere) eller Office v. X (eller senere) kan vise den konverterede RTF-fil. Kendte problemer: Microsoft understreger på download-siden, at converteren ikke må installeres, hvis man i forvejen har installeret Microsoft Office 2008 for Mac, da det kan give problemer med Office Da der er tale om en beta-udgave, er det ikke sikkert, at OOXML-filer vil blive oversat korrekt. Der er derfor risiko for tab af informationer ved en konvertering.

257 Bilagssamling Side 257 af 379 Converterkortlægning Betaversion havde en række kendte fejl, der var beskrevet på downloadsiden. I den nuværende version har man i stedet beskrevet forbedringerne uden at beskrive, hvad der er forbedret uden at beskrive udestående fejl. Følgende er nævnt som forbedret i version 0.2 (ver forlænger alene betaperioden): - conversion of Word documents that contain XML content, - inline graphics, - hyperlinked graphics, - WMF/EMF graphics, - SmartArt graphics, - tracked changes in the document header and footer, - Unicode characters, - Japanese Rubi fields. Følgende kendte problemer fra version er ikke specifikt omtalt som helt eller delvist rettet i version 0.2: - Macros and Visual Basic content are not included in the converted file. - Graphics and other objects in the document might appear with a different size. - Color fills and shading in tables might not be preserved. - Conversion might not succeed if the document contains WordArt. - Document layout and formatting might not be preserved. - Conversion might not succeed if the document contains very large pictures. - Conversion might not succeed if you use an SMB network volume as the preferred destination for converted files. - Picture bullets might not be preserved. - Fonts might be substituted. Integration: Converteren er et selvstændigt program, der skal installeres på brugerens Mac. Ved modtagelse af OOXML-filer skal brugeren først benytte converteren til at konvertere dokumentet til RTF. Derefter kan brugeren åbne det konverterede dokument i sin tekstbehandler. Styrker og svagheder: Det er en fordel, at converteren arbejder lokalt på computeren, og at den er gratis, set i forhold til docxconverter, der er shareware.

258 Bilagssamling Side 258 af 379 Converterkortlægning Det er tilsyneladende rettet nogle fejl i denne udgave, men vi har ikke afprøvet eller fundet oplysninger om, hvor godt den virker i praksis. Omkostninger: Gratis docxconverter 3.0 Kort beskrivelse: Envejs konvertering af dokumenter fra.docx,.xlsx og.cwk (Apple- Works/ClarisWorks) til RTF. Opgraderingen fra 2.0 til 3.0 har blot tilføjet.cwkunderstøttelse og fejlrettelser. Version 3.0 virker kun på Mac OS X ver , mens version 2.0 også kan bruges på Microsoft Windows 98-Vista. Måske interessant for Word for Mac-brugere som alternativ til Microsofts gratis beta-udgave, NeoOffice, eller at købe Microsoft Office 2008 for Mac. Leverandør: Panergy Link: Information, køb og download på: - Funktionalitet: Følgende er taget fra Panergy s beskrivelse af converteren: docxconverter converts the docx or.cwk format to RTF while preserving the content and form of the original docx document including: - Paragraphs: margins, alignment, line spacing, tabs, borders, bullets and numbering - Styles: character styles, paragraph styles, list styles, table styles - Font name, size, style and color - Tables - Headers and footers - Footnotes and endnotes - Page attributes - Document information - Sections - Fields

259 Bilagssamling Side 259 af 379 Converterkortlægning - Objects - Graphics (with wrapping and scaling information) - Drawings and word art - Revision marks - Comments and hidden text - Language attributes - Theme information RTF-formatet kan læses af de fleste tekstbehandlingsprogrammer. Panergy fremhæver selv: - Microsoft Word (any version) - Corel WordPerfect for Windows (any version) - WordPad for Windows (any version) - TextEdit for Macintosh (any version) Systemkrav: - Operativsystem: o Version 3.0 Mac OS X ver o Version 2.0 Microsoft Windows 98-Vista, eller Mac OS Tekstbehandler, der kan læse RTF. Kendte problemer: Om visning af konverterede filer i tekstbehandlingsprogrammer taget fra Panergys hjemmeside: Some programs are able to show all the features that were converted, in which case you will get a 100% conversion. Others only partially support the converted features. These programs will show the converted document to the best of their ability. For example, revision marks are supported only by Word. If you open a docx file that contains revision marks in another program such as TextEdit, revision marks will be ignored. Integration: docxconverter er en selvstændig converter, der skal installeres på brugerens Windows-pc eller Mac. Hvis man vælger docxconverter som det program, man som standard åbner.docx-filer med, vil docxconverter åbne dokumentet, konver-

260 Bilagssamling Side 260 af 379 Converterkortlægning tere det til RTF og derefter åbne standardprogrammet for RTF (f.eks. Word for Mac 2004) og vise den konverterede fil. Konverteringen kan derfor klares med et enkelt dobbeltklik. Man kan også vælge kun at konvertere filer uden at åbne en tekstbehandler bagefter, dette giver mulighed for konvertering af flere filer samtidigt. Styrker og svagheder: Der er kun tale om envejs konvertering. Panergy giver deres egne eksempler på konvertering af Word 2007 til Word for Mac 2004: Der er afprøvet bl.a. fonte, lister, punktopstilling, slutnoter, tabeller og billeder. Resultatet af deres egen afprøvning ser ud til at være næsten identisk med originalen. Man må dog tage højde for, at der er tale om producentens egen afprøvning, og at resultatet offentliggøres i markedsføringsøjemed. Omkostninger: Shareware, prisen er - $19,95 for standardudgaven, - $29,95 for premium -udgave med to års opdateringer og 48 timers e- mailsupport. - Mulighed for rabat ved køb af 10+ licenser Docx-converter.com Kort beskrivelse: Envejs, online konvertering af dokumenter fra OOXML (.docx) til HTML. Leverandør: docx-converter.com Link: - (Information og gratis online konvertering) - (Download af widget til Mac) Funktionalitet: "Docx-converter.com offers a portable solution for your compatibility needs. It will convert a Microsoft Office.docx file into a simple html file. It strips out some of the formatting, but now supports bold, italic, and underlined text. Left, right, center, and justified alignment. Unicode characters. Tables. And more!"

261 Bilagssamling Side 261 af 379 Converterkortlægning Systemkrav: - Online-version: - Computer med browser og internetforbindelse - Mac-version: - En Mac OS-version, der understøtter widgets (Mac OS X v10.4 eller senere) Kendte problemer: Et par brugere har skrevet, at widget en til Mac ikke virker: Desuden kan det give problemer i forhold til it-sikkerheden at bruge konverteringstjenester på internettet, der er udenfor brugerens og brugerens organisations kontrol. Tjenesten synes at have udvidet listen af dokumentformater, som docx-filer kan konverteres til siden sidste opdatering af converterkortlægningen. Men ved en afprøvning i forbindelse med denne opdatering i juni 2008, virkede tjenesten ikke. Den gav en fejl om, at der var en serverfejl, når filer blev forsøgt uploadet. Integration: Webtjeneste og widget. Webtjenesten fungerer ved, at brugeren uploader et dokument, og den konverterede version (HTML) bliver sendt til brugerens e- mailadresse. Widget en er et lille konverteringsværktøj, der kan placeres på skrivebordet i et Mac OS X, og det virker således kun med Mac OS X. Styrker og svagheder: Envejs konvertering med begrænset funktionalitet, der fjerner en del af formateringen. Vi har udført en enkelt afprøvning med et docx-dokument med tekst, hvoraf en del var skrevet med rødt, et billede og en tekstboks. I det tilfælde blev alt teksten konverteret, men billede, ramme om tekstboks og den røde farve på tekst forsvandt. Converteren kan bruges i tilfælde, hvor man alene ønsker at læse teksten i dokumentet og ikke har andre muligheder for konvertering. Men den kan kun bruges til

262 Bilagssamling Side 262 af 379 Converterkortlægning dokumenter, man kan tillade sig at konvertere eksternt. Den er medtaget her for at give et billede af bredden i udvalget af convertere. Omkostninger: Gratis Kort beskrivelse: Envejs, online konvertering af dokumenter fra OOXML (.docx) til.doc. Leverandør: Link: - (Information og gratis online konvertering) Funktionalitet: Online konvertering af.docx-dokumenter til.doc. Brugeren oplyser sin e- postadresse og uploader den fil, der skal konverteres. Link til den konverterede fil sendes til brugeren. Leverandørens kommentar på hjemmesiden: "docx2doc.com is the only online service in the world that converts your file in seconds and supports images, tables and advanced formatting." Udsagnet in seconds gælder kun, hvis man betaler. Systemkrav: Computer med browser og internetforbindelse. Kendte problemer: Ingen tilgængelige oplysninger ud over, at det kan give problemer i forhold til itsikkerheden at bruge konverteringstjenester på internettet, der er udenfor brugerens og brugerens organisations kontrol. Som der står på hjemmesiden. I urge users to not upload sensitive or classified documents for security reasons. Integration: Webtjeneste. Online-versionen fungerer ved, at brugeren uploader et dokument, og den konverterede version (.doc) bliver sendt til brugerens adresse. Styrker og svagheder:

263 Bilagssamling Side 263 af 379 Converterkortlægning Envejs konvertering. Da der konverteres til doc-formatet, kunne man formode, at der bliver bevaret en større del af formateringen, end det er tilfældet med Docxconverter.com, men det er ikke afprøvet. Den kan kun bruges til dokumenter, man kan tillade sig at konvertere eksternt. Den er medtaget her for at give et billede af bredden i udvalget af konvertere. Omkostninger: Første konvertering koster $5 USD, derefter får man gratis konverteringer i et år. Betalingen registreres på adressen. Gratis konvertering er mulig, men den konverterede fil er først tilgængelig efter 24 timers forsinkelse Konvertering fra og til både OOXML og ODF Der er nu et par muligheder for indbygget tovejs konvertering af både OOXML og ODF; NeoOffice til Mac og ODFTrans. Webtjeneste kan konvertere fra både.docx og.odt. Det er dog uvist, hvilken teknologi den bygger på. Corel WordPerfect Office X4 og beta-udgaven (og den kommende fulde udgave) af OpenOffice.org 3.0 kan som tidligere omtalt kun åbne/vise ODF- og OOXMLfiler NeoOffice Kort beskrivelse: Tovejs konvertering mellem OOXML, ODF og en række andre dokumentformater. Kun til Mac OS X. Leverandør: Planamesa Software ( Link: ww.neooffice.org (Information og gratis download). Funktionalitet: NeoOffice er baseret på OpenOffice.org 2.2.1, men der er foretaget en række udvidelser, herunder en portering af kode fra Sourceforge-projektet Open

264 Bilagssamling Side 264 af 379 Converterkortlægning XML/ODF Translator Add-ins for Office, der gør det muligt at håndtere OOXML. Se en sammenligning af funktionerne i NeoOffice og MS Office 2008 for Mac Systemkrav: Minimum: - Mac OS X 10.3 eller nyere MB hukommelse MB fri harddiskplads Kendte problemer: Der er hverken fundet oplysninger om kendte problemer eller omvendt påstande om, at converteren skulle være helt uden fejl. Det er nødvendigt at afprøve converteren, hvis dette skal afdækkes. Integration: En fuld kontorpakke, der evt. kan installeres parallelt ved siden af andet tekstbehandlingsprogram og alene bruges som converter. Kan så vidt vides ikke afvikles som service på en måde svarende til OpenOffice.org (se nedenfor). Styrker og svagheder: NeoOffice er i øjeblikket det eneste program/converter til Mac, der kan håndtere både OOXML og ODF. Omkostninger: Gratis GPL-licens ODFTrans Kort beskrivelse: Serverbaseret automatisk konvertering til og fra OpenDocument (ODF), OOXML (DOCX) og DOC af filer, som brugeren sender til ODFTrans-serveren via . Det er tænkt som en converter til ODF, deraf navnet, men inkluderer også understøttelse af OOXML. Leverandør: HWD et tysk firma (

265 Bilagssamling Side 265 af 379 Converterkortlægning Link til information: Leverandørens eget: - (beskrivelse og kontaktoplysninger på engelsk, hvor man kan anmode om information/download) - (supplerende information - linket til download er kun brugbart, hvis man har fået et kodeord fra HWD) Øvrigt - (Fra oktober i afsnit 4.2 er en omtale af et oplæg om ODFTrans, hvoraf det fremgår, at ODFTrans bliver benyttet til klienter i "German Federal Foreign Office". Bemærk at oplægsholderen er Hans W. Dahm, CEO for HWD.) - (præsentation en anden workshop med data fra en sammenligning af convertere inkl. ODFTrans ) Funktionalitet: ODFTrans er en simpel ide i en smart indpakning: Når der ikke er en klar vinder blandt converterne, så giv brugeren mulighed for på en let måde at drage nytte af konkurrencen mellem flere produkter: Hvis ikke en converter fra den ene producent er i stand til at give et acceptabel resultat, kan man ved at prøve med en anden converter, måske få et, der er bedre. ODFTrans er således ikke en selvstændig converter, men en indpakning af convertere fra Cleverage/Microsoft/Novell, SUN og OpenOffice.org. Alt softwaren installeres på én computer, der kontinuerligt søger efter nye s, konverterer vedhæftede filer og sender dem retur til afsenderen. Brugeren kan udbede sig brug af en bestemt converter ved f.eks. at sende et ODTdokument og skrive DOC_SUN i emnefeltet. ODFTrans vil så benytte SUN s converter til at konvertere ODT til DOC. Programmet understøtter i alt 10 muligheder for oversættelse mellem ODT, DOCX og DOC med de forskellige convertere. Systemkrav: Én fysisk eller virtuel computer med: - Microsoft Windows XP SP2 eller Windows Server Microsoft Office o Office 2003 SP3 (min. Outlook og Word) og "Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats" eller

266 Bilagssamling Side 266 af 379 Converterkortlægning o Office 2007 SP1 (min. Outlook og Word) -.NET Framework 2.0 (med nyeste SP) - Netværksforbindelse til postserver - Oprettelse af en konto - En Microsoft Outlook-profil kaldet ODFTrans - OpenOffice.org 2.4 eller nyere - Sun ODF Plugin 1.2 for Microsoft Office - OpenXML/ODF Translator Command Line Tools (en selvstændig udgave af Open XML/ODF Translator Add-ins for Office -projektet) Kendte problemer: HWD har ikke kunnet oplyse om kendte problemer i selve applikationen. -regler og opsætning af postserveren kan udgøre en kilde til problemer, der ikke skyldes ODFTrans selv, men måden programmet kan blive brugt på. Det kan være antivirusfiltre, der blokerer filer med visse vedhæftninger, eller begrænsninger på størrelsen af vedhæftede filer. Integration: tjeneste. Brugen sender dokumentet i en og skriver en kode i emnefeltet for, hvordan ODFTrans skal konvertere det. Styrker og svagheder: ODFTrans er beregnet til myndigheder, organisationer og virksomheder. HWD har tidligere tilladt private brugere at hente programmet, men det gav for mange supportforespørgsler fra folk, der blot lige ville prøve programmet for sjov og ikke kunne finde ud af det. Man er derfor nødt til at kontakte HWD og få et password, før man kan hente programmet. Det er dog tilladt at videresende programmet til andre, hvis man inkluderer de originale licens- og copyright-informationer. HWD fremhæver selv følgende fordele ved ODFTrans: - nemt at benytte for brugerne - ikke behov for at installere og vedligeholde convertere på alle klienter - lader Linux- (og Mac-) brugere anvende Windows convertere - minimerer support til konverteringsopgaver Det kan være problematisk at sende dokumenter med fortrolige eller følsomme dokumenter via . Men det problem kan måske løses, hvis brugeren, postserveren og ODFTrans-computeren alle befinder sig på det samme interne netværk. Datatilsynet skriver på sin hjemmeside:

267 Bilagssamling Side 267 af 379 Converterkortlægning Datatilsynet har taget stilling til sikkerhedsforanstaltningerne ved behandling af følsomme personoplysninger i et lokalt e-post system. Datatilsynet udtalte i den forbindelse, at så længe der er tale om en transmission, der foregår i et lokalnet, og der således ikke er tale om ekstern kommunikation, stilles der ikke krav om kryptering Læs om kravene til et sådan lokalt e-postsystem på hjemmesiden: Det er muligt at vælge, hvilke postdomæner ODFTrans må behandle s fra. Bemærk, at ODFTrans ikke understøtter krypterede s/krypterede vedhæftninger. Omkostninger: Gratis. Ifølge hjemmesiden vil der komme en open source-udgave i 4. kvartal Kort beskrivelse: Webtjeneste på internettet, der kan konvertere ODF-dokumenter(.odt) til f.eks..doc og OOXML-dokumenter (.docx) til.doc eller.odt. Kan ikke konvertere til.docx. Leverandør: Zamzar ( Link: - Funktionalitet: Liste over understøttede formater findes her: - Se i øvrigt punktet om integration nedenfor. Systemkrav: - Computer med browser og internetforbindelse - adresse og adgang til

268 Bilagssamling Side 268 af 379 Converterkortlægning Kendte problemer: Ingen tilgængelige oplysninger ud over, at det kan give problemer i forhold til itsikkerheden at bruge konverteringstjenester på internettet, der er udenfor brugerens og brugerens organisations kontrol. Integration: Webtjeneste. Webtjenesten fungerer ved, at brugeren uploader et dokument, vælger et destinationsformat, og angiver sin adresse. Den konverterede version derefter bliver sendt til brugerens adresse. Styrker og svagheder: Da det er en webtjeneste på internettet, kan converteren bruges i tilfælde, hvor man alene ønsker at læse teksten i dokumentet og ikke har andre muligheder for konvertering. Men den kan kun bruges til dokumenter, man kan tillade sig at konvertere eksternt. Den er medtaget her for at give et billede af bredden i udvalget af convertere. Omkostninger: Gratis basisudgave. Mulighed for at købe en abonnementsordning til $7-$49 om måneden, der giver mulighed for online lagring, meget store filer (200MB 1 GB) og bedre support.

269 Bilagssamling Side 269 af 379 Converterkortlægning 5. Relaterede undersøgelser 5.1. NA VT Working Group Translation Det tyske standardiseringsinstitut nedsatte i maj 2007 en arbejdsgruppe, der skal behandle spørgsmål relateret til forskelle på ODF og OOXML og konvertering mellem formaterne. Arbejdsgruppen har i februar 2008 udgivet et udkast til en rapport, der er lagt ud til kommentarer i ISO/IEC-regi. Den endelige tekniske rapport med perspektiver, forslag og modeller for konvertering mellem OOXML og ODF ventes i februar Udkastet til rapporten og fremtidige udgivelser kan findes på arbejdsgruppens hjemmeside (engelsk): Fraunhofer FOKUS, Dialogika GmbH, Novell OpenOffice Entwicklergruppe, Innovimax og Microsoft Deutschland GmbH har bidraget til rapporten. Arbejdsgruppen er tidligere annonceret her: /05/DIN-E.pdf Staten Massachusetts undersøgelse I marts-maj 2006 efterlyste staten Massachusetts it-division informationer vedrørende et plugin til Microsoft Office, der skulle kunne håndtere OpenDocument. Tilbagemeldingerne på denne forespørgsel kan læses på: es&l2=opendocument&l3=odf+plug-in+for+microsoft+rfi&sid=aitd Billedet har ændret sig noget siden denne informationsindsamling, da f.eks. både Microsoft og Sun efterfølgende har medvirket til frigivelsen af sådanne plugins, der er omtalte i nærværende kortlægning.

270 Bilagssamling Side 270 af 379 Converterkortlægning Bilag 1. Forklaringer og noter Dokumentformater OOXML-tekstfiler (.docx og.docm) - Word 2007-dokument (.docx) - Word 2007-dokument med aktiverede makroer (.docm) ODF-tekstfiler (.odt og.ott) - OpenDocument-tekst (.odt) - OpenDocument-tekstskabelon (.ott) Open Source-licenstyper nævnt i denne kortlægning BSD - Navnet stammer fra Berkeley Software Distribution. Den første udgave af licensen blev brugt til dette Unix-agtige operativsystem. - BSD betragtes som mere fri (færre restriktioner) end LGPL (se nedenfor). - Der er tale om en kladde til en licens, som man selv kan udfylde - GPL2 - GPL2 står for GNU General Public License, version 2 - Se mere information på: - GPL v3 - GPL v3 står for GNU General Public License, version 3 - Se mere information på: - LGPL - LGPL står for GNU Lesser General Public License - Se mere information på:

271 Bilagssamling Side 271 af 379 EKSPERTUDVALGET OM ÅBNE STANDARDER Bilag L

272 Bilagssamling Side 272 af 379 Konsulentundersøgelse af åbne dokumentformater (ODF/OOXML) Oktober 2008 CONNECTING BUSINESS & TECHNOLOGY Devoteam Consulting. Kopiering og distribution kun tilladt efter aftale med Devoteam Consulting.

273 Bilagssamling Side 273 af 379 Indholdsfortegnelse 1. Introduktion Baggrund og formål Afgrænsning af analysen Begreber og definitioner Metode Analyse 1: Analyse af softwareleverandørernes evne til at sikre interoperabilitet Fremgangsmåde Udfordringer De typiske udfordringer i forbindelse med konvertering Hvordan er myndighederne stillet i forskellige scenarier for interoperabilitet Hvilke løsningsmodeller vælger myndighederne? Systemtekniske muligheder Organisatoriske muligheder Sammenfatning Analyse 2: Implementering af standarderne uafhængigt af platform Fremgangsmåde Muligheder for nyanskaffelse Nyanskaffelser af tekstbehandlingssystem uafhængigt af platform Nyanskaffelser af andre it-løsninger end tekstbehandlingssystemer Opfyldelse af modtagekravet ved nyanskaffelser uafhængigt af platform Sammenfatning Bilag 1: Resultat af spørgeskemaundersøgelse Bilag 2: Spørgeskemaundersøgelse tabeller og udsagn # v

274 Bilagssamling Side 274 af Introduktion 1.1. Baggrund og formål På baggrund af folketingets vedtagelse fra forespørgselsdebat F24 den 25. april 2008 om anvendelse af åbne standarder samt konklusionspapiret fra juni 2007 har videnskabsministeren nedsat et ekspertudvalg. Ekspertudvalget har bedt Devoteam Consulting bidrage til udvalgets undersøgelse af: - Softwareleverandørernes evne til at sikre interoperabilitet mellem de to standarder i deres produkter i forhold til det offentliges udvekslingsbehov - De reelle muligheder og praktiske erfaringer med at implementere standarderne uafhængigt af platform, herunder: - Undersøgelse af produkter på markedet - Undersøgelser af konkrete implementeringer i myndigheder Disse to analyser kaldes i det følgende for hhv. Analyse 1 og Analyse 2. IT- og Telestyrelsen er sekretariat for ekspertudvalget Afgrænsning af analysen Det er besluttet i videst muligt omfang at basere undersøgelsen på eksisterende materiale og allerede gennemførte undersøgelser, herunder dokumentation fra ITog Telestyrelsens tidligere gennemførte undersøgelser på dokumentformatområdet og den igangværende ajourføring frem til 1. juli 2008 af markedet for convertere mv. Det er besluttet, at analysen gennemføres i perioden september-oktober Undersøgelsen tager afsæt i den situation, som er gældende 1. juli 2008, hvad angår produkter på markedet, og hvad angår implementerede standarder. Det betyder bl.a., at versionen af OOXML er den af ECMA godkendte, og at versionen af ODF er version 1.0. Der fokuseres i undersøgelsen på interoperabilitet mellem dokumentformater. Det vil sige, at der kun i begrænset omfang undersøges interoperabilitet mellem applikationer. For at analysere interoperabiliteten vil de relevante redigeringsværktøjer som fx tekstbehandlingssystemer dog blive belyst, især i forhold til mulighederne for nyanskaffelser af it-løsninger, der opfylder anskaffelseskravet. Det skal præciseres, at Devoteam Consulting i denne rapport har sigtet mod at levere et fact-orienteret analysemateriale, som ekspertudvalget kan anvende i det videre arbejde. # v

275 Bilagssamling Side 275 af Begreber og definitioner I det følgende er nogle væsentlige begreber fra analysen beskrevet. Interoperabilitet og interoperabilitetsniveauer Interoperabilitet er i denne rapport defineret som Softwareleverandørernes evne til at sikre interoperabilitet mellem de to standarder i deres produkter. Dvs. muligheden for, at de to åbne dokumentformater OOXML og ODF kan fungere i sameksistens. Funktionalitetsloft Interoperabilitet undersøges inden for et såkaldt funktionalitetsloft, som er den relevante afgrænsning af de formatrelevante funktionaliteter, der er de mest benyttede i en dansk forvaltningsmæssig kontekst. Det nuværende funktionalitetsloft er indkredset i et samarbejde med offentlige myndigheder og leverandører på baggrund af analyser af konkrete eksempeldokumenter fra myndighederne, og det er bl.a. drøftet i IT-arkitekturkomitéen og Datastandardiseringskomitéen. Funktionalitetsloftet indgår i IT-ordførernes bilagsmappe i Bilag 29 funktionalitetsloft for tekstbehandlingsdokumenter i den offentlige sektor. Det indeholder følgende funktionaliteter: - Formatering - Sidehoved og sidefod - Fodnoter og slutnoter - Nummererede lister og punktopstilling - Indsætte elementer fra andre fil-formater - Tabeller - Anvende billeder og grafik - herunder logo i forskellige formater - Sideopsætning - Automatisk generering af indholdsfortegnelse - Stavekontrol - Autokorrektur - Udarbejde tegninger direkte i dokumentet - Skabeloner - Rettighedsstyring - Metadata - Rettelsesmarkering - Versionering - Skabeloner der henter data fra andre systemer - Brevfletning - Publicering - Høringsfunktion (samarbejdsfunktion) Funktionalitetsloft for tekstbehandlingsdokumenter i den offentlige sektor 1.4. Metode Devoteam Consulting har i samarbejde med ekspertudvalget sammensat en fremgangsmåde for undersøgelsen. # v

276 Bilagssamling Side 276 af 379 Helt overordnet har den valgte fremgangsmåde været at samle og ajourføre den eksisterende viden på dokumentformatområdet, at supplere denne viden med praktiske erfaringer på området, samt endelig at konsolidere den samlede viden på området med udgangspunkt i og med fokus på undersøgelsens to analyser. I figur 1 er den overordnede metode for undersøgelsen gengivet: Dataindsamling Eksiste- Eksisteren Eksisteren rende viden viden viden Ajourføring af eksisterende viden Nye praktiske erfaringer Konsolidering ift. Analyse 1 Analyse 1: Softwareleverandører nes evne til at sikre interoperabilitet Vidensindsamling Pilotforsøg Laboratoriatest Div. Rapporter og notater Converterkortlægning v. 3 juli 2008 Spørgeskemaundersøgelse i statslige myndigheder Konsolidering ift. Analyse 2 Analyse og bearbejdning Analyse 2: Implementering af standarderne uafhængigt af platform Figur 1: Overordnet metode for gennemførelse af undersøgelsen Metoden baserer sig på desk-research i form af converterkortlægning, kombineret med en spørgeskemaundersøgelse hos statslige myndigheder om de praktiske erfaringer med de åbne dokumentformater. Der er således ikke gennemført nye praktiske forsøg i forbindelse med udarbejdelse af denne konsulentrapport. I det følgende gennemgås de enkelte undersøgelseselementer i undersøgelsen. Ajourføring af eksisterende viden Der er foretaget en ajourføring af converterkortlægningen (undersøgelse af produkter på markedet) for at få et opdateret og komplet billede af interoperabilitet med afsæt i de tidligere gennemførte studier. Her er den samme metode brugt, som blev anvendt under de første versioner af converterkortlægningen. Undersøgelsen er således gennemført uden videre involvering af leverandører ved at rekvirere/søge materiale fra udvalgte leverandører, som er gennemgået med henblik på en kritisk vurdering af, i hvilken grad implementering på forskellige platforme har været mulig. # v

277 Bilagssamling Side 277 af 379 Nye praktiske erfaringer: Undersøgelse af konkrete implementeringer hos statslige myndigheder Undersøgelsen er gennemført som en spørgeskemaundersøgelse. Der er sendt elektroniske spørgeskemaer (web-survey) ud til 33 it-ansvarlige fra departementer, direktorater og styrelser. Respondenterne er blevet spurgt om følgende: - Deres udgangspunkt i forhold til hvilke styre- og tekstbehandlingssystemer samt dokumentformater, de anvender - Den tekniske løsning, som de har valgt til at leve op til modtagelseskravet for henholdsvis ODF og OOXML, samt hvordan de har valgt at implementere løsningen organisatorisk. - De konkrete erfaringer, de har med de obligatoriske formater herunder: - Volumen - Kvaliteten af konverteringen - Hvilke typer funktionalitet, som evt. skaber problemer i konverteringen - Evt. indvirkning på brugernes produktivitet, samt deres vurdering af brugernes tilfredshed Feltperioden var fra mandag d. 15. september til tirsdag d. 23. september 2008, og respondenterne modtog udover selve invitationen til undersøgelsen en påmindelse. Begge er udsendt via respondenter ud af de 33 inviterede har svaret, hvilket giver en svarprocent på 67%. Konsolidering ift. Analyse 1: Analyse af softwareleverandørernes evne til at sikre interoperabilitet Der er foretaget en konsolidering af resultater med afsæt i de følgende tidligere gennemførte vidensindsamlinger, analyser og undersøgelser: - Vidensindsamling 2007 (Devoteam Consulting) - Konsolideret testrapport fra pilotforsøg gennemført i løbet af 2007 i hhv. Region Midtjylland, Statens Arkiver, Direktoratet for FødevareErhverv, Gribskov Kommune og Århus Kommune (Devoteam Consulting) - Resultater fra det gennemførte laboratorieforsøg 2007 (Sogeti) med deltagelse af hhv. IBM, Ciber, Magenta og Microsoft (ITST) - Vejledning i anvendelse af åbne standarder for dokumentudveksling 2007 (ITST) - Rapport_monitor_final_1.1 (Magenta) - Converterkortlægning v.3 juli 2008 (Devoteam Consulting) - Spørgeskemaundersøgelse i Staten 2008 (Devoteam Consulting) Denne del af undersøgelsen, hvor softwareleverandørernes evne til at sikre interoperabilitet er i fokus, er afgrænset ved, at der udelukkende er kigget på modtagekravet. Dette ligger i naturlig forlængelse af det tidligere analysearbejde og rammerne for B103. # v

278 Bilagssamling Side 278 af 379 Konsolidering ift. Analyse 2: Implementering af standarderne uafhængigt af platform Der er foretaget en konsolidering af resultater med afsæt i følgende analyser: - Parathedsvurdering afrapportering 2007 (Devoteam Consulting) - Vejledning i anvendelse af åbne standarder for dokumentudveksling 2007 (ITST) - Converterkortlægning v (Devoteam Consulting) - Spørgeskemaundersøgelse i Staten 2008 (Devoteam Consulting) Med platform menes her operativsystem og følgende platforme indgår i undersøgelsen: - Windows - Linux i relevante versioner / udgivelser - Mac OS X Denne definition er imidlertid for snæver, hvorfor platform også vil blive inddraget i en bredere forstand med henblik på at belyse applikationsmiljøets betydning for understøttelse af de åbne standarder. Mac OS X har ikke tidligere indgået i IT- og Telestyrelsens undersøgelser af interoperabilitet. Undersøgelsen af de praktiske erfaringer for denne platform har imidlertid fulgt de samme retningslinjer som undersøgelsen af de øvrige platforme. # v

279 Bilagssamling Side 279 af Analyse 1: Analyse af softwareleverandørernes evne til at sikre interoperabilitet Analysen af softwareleverandørernes evne til at sikre interoperabilitet er en analyse af de interoperabilitetsudfordringer mellem OOXML- og ODF-formater, som myndighederne oplever eller vil opleve afhængigt af deres valg af produktionsformat i deres tekstbehandlingssystem. Også interoperabilitetsudfordringerne mellem de to åbne dokumentformater og DOC, som de fleste myndigheder anvender som deres primære dokumentformat i dag, er behandlet i analysen. Dette for at belyse de udfordringer, der er ved at modtage de åbne formater ODF og OOXML i tekstbehandlingssystemer, hvor DOC er produktionsformatet i tekstbehandlingssystemet Fremgangsmåde Analysen og de deraf udledte konklusioner i dette afsnit bygger på resultaterne af de gennemførte test: pilottest 1 og laboratorietest 2 samt efterfølgende test foretaget af Magenta 3, som har afrapporteret deres observationer i en rapport fra oktober måned Resultaterne fra disse test bliver sammenstillet for at give et overblik over hvilke udfordringer, der eksisterer for myndighederne alt efter hvilket produktionsformat, der ligger i deres tekstbehandlingssystem. Derudover er der gennemført en spørgeskemaundersøgelse i en række statslige myndigheder, som giver et opdateret input på den faktiske situation hos flere myndigheder. Spørgeskemaet giver både input til de udfordringer, som myndighederne oplever mht. interoperabiliteten mellem de to åbne dokumentformater samt DOC, men også hvordan de har designet deres konverteringsløsning og hvilke tekniske platforme, de opererer på Udfordringer Formaterne ODF, OOXML og DOC understøtter ikke nøjagtig de samme sæt af egenskaber og funktionaliteter. Derfor kan der være egenskaber i et dokumentformat, som ikke understøttes i et andet. Det betyder, at converterne generelt kan have problemer med at oversætte indhold korrekt ved brugen af visse funktionaliteter. Magenta peger i deres rapport eksempelvis på, at en egenskab som fodnoter ikke er defineret ens i de to åbne formater ODF og OOXML. Derudover vil der selv inden for 1 Jf. rapporten Konsolideret testrapport_pilotforsøg 2 Jf. rapporten Testrapport v _jjan_dirfor 3 Jf. rapporten: Rapport_monitor_final_1.1 forfattet af Magenta # v

280 Bilagssamling Side 280 af 379 samme format være udfordringer med tekstfonte, da forskellige PC ere/operativsystemer vil fortolke tekstfonte forskelligt De typiske udfordringer i forbindelse med konvertering De praktiske test fra pilotforsøgene og laboratorietest viser, at eksisterende convertere ikke er modne nok til, at man som myndighed kan basere sig udelukkende på disse. Bl.a. viser testene, at modtagelse og konvertering af de åbne dokumentformater skaber varierende former for informations- og datatab. Generelt er det i pilottestforløbet konstateret, at mere komplekse dokumenter giver større udfordringer, men i nogle tilfælde gav også simple dokumenter problemer. Her er kompleksitet defineret som antallet af forskellige funktionaliteter inden for det definerede funktionalitetsloft og ikke udelukkende længden på dokumentet. Pilotforsøgene har vist eksempler på følgende problemer: 5 - Billeder forsvinder - Indsatte filer, som fx ODFregneark eller Microsoft Visiodokumenter, forsvinder - Tegninger forsvinder - Tekstbokse forsvinder - Problemer ved skift mellem sprogversioner af værktøj - Forankringer flytter sig - Problemer med bl.a. indholdsfortegnelser i forbindelse med sektions- og kapitelopdelinger - Problemer ved forskellig layout på første side hhv. efterfølgende sider - Problemer vedrørende sidehoved og -fod - Tekst forskubber sig (linjeafstand og tekstfonte) - Problemer med punktopstillinger Eksempler på udfordringer i forbindelse med konvertering Disse observationer er fulgt op i laboratorietesten, og for nogle af de forekommende fejls vedkommende fandt deltagerne i laboratoriet tekniske forklaringer. Dette gør dog ikke udfordringerne mindre for myndighederne, hvor det ikke er forventeligt, at brugerne har den tekniske indsigt til omgå disse tekniske problemstillinger. Der var ikke væsentlige forskelle på resultaterne på tværs af de testede convertere 6. Nye versioner af de eksisterende convertere, der udkom under gennemførelsen af pilottestene, viste dog en udvikling mod færre udfordringer. Det var dog på et niveau der gjorde, at Devoteam Consulting vurderede, at resultaterne af konverteringerne godt kunne generaliseres på tværs af versionerne. 4 Jf. rapporten: Rapport_monitor_final_1.1 forfattet af Magenta. 5 Resultatet af Pilotforsøgene jf.: Konsolideret Testrapport fra Pilotforsøg 6 Resultatet af Pilotforsøgene jf.: Konsolideret Testrapport fra Pilotforsøg # v

281 Bilagssamling Side 281 af 379 For at følge op på de observationer, der blev foretaget i pilot- og laboratorietest, og for at følge udviklingen i modenhedsniveauet i de forskellige convertere har Magenta gennemført efterfølgende tests både for at teste nye versioner, men også for at uddybe nogle af problemstillingerne. Den væsentligste konklusion fra Magenta s rapport (Rapport_monitor_final_1.1) er, at udviklingen i modenhedsniveauet for de eksisterende convertere ikke går så hurtigt, som det var forventet. Der er endnu ikke convertere, der kan konvertere problemfrit mellem de to åbne formater OOXML og ODF. De to hovedområder, som Magenta har identificeret som væsentlige problemområder, er felter (inkl. formularfelter) og fodnoter: De største mangler ved konverterne set i forhold til funktionalitetsloftet er: Felter. Her mangler tilsyneladende en del udvikling af konverterne. Men det spiller også ind, at de to formater har meget forskellige fortolkninger af, hvordan et felt i et tekstdokument skal fungere. Grundlæggende er et felt en pladsholder for en eller anden type information, som a) kommer fra en ekstern kilde (databasefelter) b) er beregnet (f. eks. sidenummer- og sideantalsfelter) c) er indtastet/kan indtastes via en særlig indtastningsboks el. lign. Feltets indhold vises som en del af dokumentets tekst, men har altså en særlig status i forhold til denne. Felter er oplagte at bruge i forbindelse med maskinel bearbejdning af dokumenter (for eksempel maskinel udfyldelse af en fakturaskabelon). Det ville derfor være en fordel, hvis felter var mere interoperable mellem de åbne dokumentformater. Fodnoter. Fodnoters layout forvanskes som hovedregel i forhold til originaldokumentet. Dette skal også ses i lyset af problemstillingen vedrørende de forskellige kontorpakkers faste layout af fodnoter (beskrevet i afsnittet 'Problemstillinger udenfor scope'). Uddrag af Rapport_monitor_final_1.1 I bilag 4 er Magenta s resultater sat ind for at give et overblik over, hvordan interoperabiliteten p.t. ser ud 7. Det er disse testresultater, der ligger til grund for konklusionen om, at de nuværende interoperabilitetsproblemer i vid udstrækning handler om felter og fodnoter. Derudover viser resultatet af Magenta s test, at fx OLE-objekter, tegninger og sidenummereringer også har en høj hyppighed af fejlobservationer. Ifølge Magenta er der kun sket marginale forbedringer af convertere siden gennemførelsen af pilottestene. Magenta indikerer således i deres rapport, at udviklingen af modenhedsniveauet for convertere går langsomt: Samlet set er konverterkvaliteten kun forbedret marginalt over de 6 måneder, over hvilke vi har monitoreret udviklingen. 7 Taget fra rapporten: Rapport_monitor_final_1.1 forfattet af Magenta. # v

282 Bilagssamling Side 282 af 379 Så hvordan er myndighederne stillet i lyset af ovenstående? De to hovedproblemområder, felter og fodnoter, er funktionaliteter, som ikke er strengt nødvendige i de daglige rutiner hos myndighederne. Derfor kan myndighederne vælge at lægge et loft over anvendte funktionaliteter og derved minimere problemområderne. Den generelle tilbagemelding fra spørgeskemaundersøgelse er, at konvertering kan giver problemer (fx ifm. formatering, tabeller og skabeloner) Samtidig viser undersøgelsen imidlertid, at myndighederne stadig modtager meget få dokumenter i de to åbne formater. Derfor vurderes disse udfordringer ikke at udgøre et problem Hvordan er myndighederne stillet i forskellige scenarier for interoperabilitet Ovenstående afsnit har givet et billede af hvilke typiske udfordringer, der er forbundet med konvertering mellem de omtalte dokumentformater. Der er imidlertid forskel på, hvor store udfordringerne er for myndighederne afhængig af, hvad der konverteres fra og til, dvs. modtagescenariet. Fra Pilottestene blev resultaterne analyseret til at give følgende modenhed for konvertering i seks mulige modtagescenarier (se figur 2): 8 Stigende modenhed Import af DOC til OOXML Import af OOXML til DOC Import af DOC til ODF Import af ODF til DOC Import af ODF til OOXML Import af OOXML til ODF Observationer inden for funktionalitetsloft Konvertering kan fungere med få udfordringer Konvertering kan som oftest fungere Generelt er der nogle udfordringer med konvertering Konvertering- og konverteringsmuligheder er mangelfulde Figur 2: Modenhed for konvertering ved seks konverteringsscenarier 8 Modenhedsniveauet for konverteringer, som offentliggjort i IT- og Telestyrelsens vejledning om åbne dokumentformater: Vejledningen Vejledning i anvendelse af åbne standarder for dokumentudveksling (2007) # v

283 Bilagssamling Side 283 af 379 Som figuren viser, er der forskel i converternes modenhed. Der er således mindst modenhed, dvs. størst udfordringer, ved konvertering mellem de to åbne dokumentformater ODF og OOXML. Der er højst modenhed, og dermed færrest udfordringer, ved konvertering mellem DOC og OOXML. Resultaterne af spørgeskemaundersøgelsen understøtter ovenstående billede af converternes modenhed, hvor de adspurgte myndigheder har svaret, at der er en større tilfredshed med konverteringen af OOXML end med ODF 9. Samtlige adspurgte har Word med DOC-formatet som det mest udbredte produktionsformat, hvilket betyder, at graden af tilfredshed relaterer til konvertering fra de åbne dokumentformater til DOC. To af de seks modtagescenarier er ikke medtaget i denne analyse Da denne analyse har fokus på interoperabiliteten/modtagelsen af de to åbne formater, vil der i det efterfølgende ikke være fokus på konvertering af DOCdokumenter til et åbent format. Myndigheder, der allerede benytter ODF som format i deres tekstbehandlingssystem, vil typisk være vant til at skulle modtage DOC dokumenter som en del af deres dagligdag og kender til rutinen med at konvertere. Fx understøtter OpenOffice.org Writer DOC formatet, og man kan vælge at anvende DOC som produktionsformat. Samtidig er MS Word 2007 bagudkompatibel og understøtter derfor fuldt ud DOC. Interoperabiliteten i forhold til at modtage dokumenter fra myndigheder, der endnu ikke har nyanskaffet kontorpakker med et af de to åbne formater, må derfor konkluderes at være moden. I ovenstående figur var konverteringen fra DOC til de to åbne formater også placeret højt på modenhedsstigen. Scenarie for interoperabilitet: OOXML -> DOC Erfaringerne fra pilotforsøgene viste, at der generelt kun er få udfordringer omkring formatering, for myndigheder, som skal modtage OOXML-formaterede dokumenter, når de allerede anvender DOC. For at kunne modtage og læse OOXML i tekstbehandlingssystemet er det nødvendigt at installere Microsoft Compatibility Pack. Det er muligt at hente denne gratis på Microsofts hjemmeside 10. Dette er pt. den eneste konverteringsløsning, som opfylder behovet for konvertering mellem OOXML og DOC. Converteren fungerede tilfredsstillende i langt de fleste tilfælde i pilotforsøgene inden for funktionalitetsloftet. 9 Taget fra Resultat af spøgeskemaundersøgelse Spørgsmålene 55 og Jf. # v

284 Bilagssamling Side 284 af 379 Erfaringerne fra pilotforsøgene er blevet understøttet af spørgeskemaundersøgelsen, som viser, at der blandt myndighederne er tilfredshed med konverteringen fra OOXML til DOC. I forhold til funktionalitet svarer således kun en enkelt, at der kan være problemer med formateringen, når man konverterer et OOXML-dokument til DOC. Spørgeskemaundersøgelsen viser, at Microsoft-formaterne OOXML og DOC i sig selv skaber forvirring flere steder, da brugerne har svært ved at overskue hvilket format, de modtager dokumenter i, og hvornår der er behov for at konvertere. Scenarie for interoperabilitet: ODF ->DOC Modtagelsen af ODF-dokumenter hos en myndighed, der endnu ikke har nyanskaffet, vil ifølge spørgeskemaundersøgelsen betyde, at ODF-dokumentet skal konverteres til DOC-format. Generelt er der i denne situation nogle udfordringer for myndighederne. For at kunne modtage og læse ODF i tekstbehandlingssystemet med DOC som produktionsformat er det nødvendigt at installere en converter. I pilotforsøgene er to forskellige convertere til modtagelse af ODF på en DOC-baseret platform testet: - SourceForge CleverAge Odfconverter Add-in for Word - SUN ODF Plug-in for Microsoft Word 1.1 Generelt kan det konstateres, at konverteringer i dette scenarie med disse convertere fungerer med nogle udfordringer. Der er ikke observeret væsentlige forskelle i konverteringskvaliteten mellem de to konvertere. For en detaljeret gennemgang af forskellene i brugen af de to konvertere, henvises til Converterkortlægningen på Svarene fra spørgeskemaundersøgelsen viser ligeledes, at der er problemer ved konvertering fra ODF til DOC. De problemer, som flest nævner, er: - Formatering - Tabeller - Indsatte statiske billeder og grafik - Skabeloner og makroer Disse punkter svarer godt over ens med observationerne fra pilottestene. Scenarie for interoperabilitet: OOXML -> ODF En myndighed, der benytter ODF-formatet i sit tekstbehandlingssystem, skulle pr. 1. januar 2008 kunne modtage og læse OOXML-dokumenter. I pilotforsøgene var konverteringer og konverteringsmuligheder, hvor en myndighed vil importere OOXML til ODF, generelt mangelfulde. Pilottestene og Magenta s test af convertere peger fx på udfordringer ved konvertering i forbindelse med følgende funktionaliteter: - Felter # v

285 Bilagssamling Side 285 af Fodnoter - Sideopsætninger - OLE objekter (fx indsat regneark) - Læsefejl (dokumentet kan ikke åbnes) For at kunne modtage og læse OOXML i tekstbehandlingssystemet er det nødvendigt at installere en converter, men udbuddet af relevante tekniske løsninger var her stadig begrænset. Den eneste converter på markedet, da pilotforsøgene blev afviklet og ved udgangen af 2007, som understøttede direkte import af OOXML-dokumenter i ODF-baserede tekstbehandlingssystemer, var Novells ODF-converter, OpenOffice.org OpenXML Translator, der dengang var udgivet i en version til MS Windows, og en version til Linux 11. Samtidig var det eneste tekstbehandlingsprogram, converteren kan integreres til, OpenOffice Novell Edition version og 2.1. Disse pakker er senere kommet i en nyere version, som Magenta har testet (OpenOffice Novell Edition version 2.3 med en version 1.1 af converteren på en Vista baseret PC). Magenta s konklusion er, at den nyeste version af Novellconverteren kun klarer sig marginalt bedre end den gamle. Dette understøtter konklusionen fra pilottestene og betyder, at der stadig er tale om mangelfuld konvertering. Scenarie for interoperabilitet: ODF -> OOXML Også konvertering den anden vej er kompliceret. Når en myndighed har valgt at basere sine tekstbehandlingssystemer på OOXML som produktionsformat, er modtagelsen af ODF-dokumenter en udfordring. Erfaringerne fra pilotforsøgene viser, at der generelt er nogle udfordringer for myndigheder, som skal modtage ODF-formaterede dokumenter. Fx kan udfordringer i forbindelse med følgende funktionaliteter nævnes: - OLE objekter - Tegninger - Billeder - Tekstbokse - Formatering, herunder punktopstillinger og tabuleringer For at kunne modtage og læse ODF i tekstbehandlingssystemet er det nødvendigt at installere en converter. I pilotforsøgene er converteren SourceForge CleverAge ODF-converter Add-in for Word testet til modtagelse af ODF på en OOXMLbaseret platform. Generelt kan det i pilotforsøgene konstateres, at konverteringer i dette scenarie med denne converter fungerer med nogle udfordringer. Det er også Magenta s 11 Platformen er den eneste forskel på de to versionsnumre. # v

286 Bilagssamling Side 286 af 379 observation, at konvertering denne vej ikke er optimal, men meget lig konverteringen fra OOXML til ODF. Det er samme kildekode, der ligger til grund for de to konverteringer, hvorfor det ikke er overraskende, at kvaliteten af konverteringen er meget ens. Efterfølgende er SUN-converteren SUN ODF Plug-in for Microsoft Word kommet i en ny version (1.2), som også virker sammen med MS Word Magenta har testet denne nye version, og resultatet viser, at denne version klarer sig bedre end den converter, der blev brugt under pilotforsøgene Hvilke løsningsmodeller vælger myndighederne? For at myndighederne kan opfylde kravene om modtagelse af både OOXML- og ODFtekstdokumenter, er der nogle konkrete løsningsmodeller, de kan tage i anvendelse. Der er som vist i afsnit 2.2 ingen løsningsmodeller, der kan konvertere problemfrit. Derfor kan en løsningsmodel fx bestå af en konverteringsløsning, som efter behov kan suppleres med en strategisk anvendelse/udrulning af en supplerende tekstbehandlingsapplikation eller viewer. Denne anbefalede tekniske løsningsmodel skal så kombineres med en hensigtsmæssig arbejdsproces, der sikrer, at der er minimalt tab af data efter konverteringen Systemtekniske muligheder De systemtekniske muligheder er bestemt af, hvilket produktionsformat der er i det valgte tekstbehandlingssystem, og derved hvilket løsningsscenarie, en myndighed har valgt. Det vil sige, at afhængigt af hvilket tekstbehandlingssystem, som myndigheden vælger, er der forskellige muligheder for teknisk at understøtte modtagerkravet for de åbne dokumentformater ODF og OOXML Løsningsscenarier Systemteknisk vil der være en række mulige løsningsscenarier, som myndighederne kan gøre brug af. Hvilke af scenarierne myndighederne vælger er til dels bestemt af, om myndigheden har opgraderet eller nyanskaffet kontorpakke siden 1. januar Scenarie Et tekstbehandlingssystem, som understøtter begge de obligatoriske, åbne dokumentformater Beskrivelse Dette scenarie er p.t. ikke udbredt. Blandt de adspurgte statslige myndigheder i spørgskemaundersøgelsen var der da heller ingen, der gjorde brug af dette løsningsscenarie. Som converterkortlægningen viser, er der stadig ikke mange tekstbehandlingssystemer, der i dag understøtter begge åbne standarder. Magenta har identificeret AbiWord som en mulighed, da # v

287 Bilagssamling Side 287 af 379 den seneste version kan åbne OOXML, men understøttelsen af OOXML er ifølge AbiWord selv eksperimentel. Også WordPerfect X4 kan åbne både ODF og OOXML, men kan ikke gemme eller konvertere mellem formaterne. Microsoft har meldt ud, at MS Word 2007 vil understøtte ODF (Word 2007 understøtter OOXML som default), når den næste Service Pack udkommer i Derved kommer dette tekstbehandlingssystem til at understøtte begge de obligatoriske åbne formater. Tiden må vise hvilket modenhedsniveau, denne understøttelse har. Endvidere kan OpenOffice.org 3.0 læse OOXML (OpenOffice.org er baseret på ODF som default). De første indtryk af dette er, at der stadig mangler noget, før der er tale om gnidningsfri interoperabilitet. Faktum er, at der ikke blandt de adspurgte myndigheder er nogen, der har indikeret, at de bruger et af de tekstbehandlingssystemer, som er nævnt her. Et tekstbehandlingssystem, som understøtter et af de obligatoriske, åbne dokumentformater suppleret med en converter til understøttelse af det andet format. Et tekstbehandlingssystem, som ikke understøtter nogle af de obligatoriske åbne dokumentformater, suppleret med to convertere. To tekstbehandlingssystemer, som hver håndterer et af de åbne dokumentformater, evt. Dette er et meget sandsynligt scenarie i myndighederne, især efter nye investeringer i kontorpakker efter 1. januar 2008 har fundet sted. Af spørgeskemaundersøgelsen fremgår det, at to af de adspurgte myndigheder, har Microsoft Word 2007, og derfor har dette løsningsscenarie. Alt efter, hvilket af de åbne dokumentformater, der er understøttet, findes der convertere, der kan åbne/læse/skrive det andet format. Disse er specificeret i converterkortlægningen (Converterkortlægning - opdatering juni 2008). Dette er et meget sandsynligt scenarie, hvis myndigheden endnu ikke har investeret i nye kontorpakker. Fx vil brugen af Microsoft Word, der er ældre end 2007 versionen, falde ind under denne kategori. De adspurgte myndigheder i spørgeskemaundersøgelsen har næsten alle (på nær de to myndigheder, der har MicroSoft Word 2007) dette løsningsscenarie. I dette scenarie har myndigheden to tekstbehandlingssystemer til at repræsentere hvert sit format. Dette kan evt. kombineres med en organisatorisk implementering, hvor det ikke er samtlige brugere hos # v

288 Bilagssamling Side 288 af 379 gennem convertere myndigheden, der har to tekstbehandlingssystemer på hver deres PC. Ingen af de adspurgte myndigheder i spørgeskemaundersøgelsen havde denne løsning. Kun fire myndigheder anvender i det hele taget mere end et tekstbehandlingssystem. Disse fire myndigheder bruger alle Microsoft Word, der er ældre end 2007, som deres primære tekstbehandlingssystem. To anvender OpenOffice.org Writer version 2.4 som sekundær tekstbehandlingssystem, mens andre to angiver, at de anvender Microsoft Word 2007 som sekundært tekstbehandlingssystem. Viewere til ODF og OOXML som supplement til det eksisterende tekstbehandlingssystem Eksempelvis kan følgende viewere være relevante for dette scenarie: - ODFviewer (opendocumentfellowship.com/odfviewer) - Microsoft Word Viewer med MS compatibility pack installeret (support.microsoft.com/kb/925180) Dette scenarie kan være relevant i forhold til verificeringsprocedurer og kan rent organisatorisk kombineres med et andet af de nævnte scenarier. Kun en enkelt myndighed i spørgeskemaundersøgelsen har svaret, at de anvender en Word Viewer inklusiv med MS compatibility pack installeret til at kunne se OOXMLdokumenter. Mulige løsningsscenarier Andre systemtekniske løsninger Det er ved nogle myndigheder observeret, at konverteringen foregår over et tredje format. F.eks sker konverteringen fra OOXML til ODF via DOC. Dvs. at OOXML-dokumentet bliver konverteret til det lukkede DOC-format, som er anvendt i MS Word versioner ældre end version 2007, og videre fra DOCformatet til ODF. Er en myndighed med OpenOffice.org som kontorpakke ikke i besiddelse af Novell s version af OpenOffice, er ovenstående den eneste reelle mulighed for decideret konvertering. Disse myndigheder oplever endvidere, at denne metode giver den bedste og mest stabile konvertering af OOXML-dokumenter til ODF, når der bliver sammenlignet med alternativet, som er at installere OpenOffice.org Novell Edition med den dertil udviklede converter. # v

289 Bilagssamling Side 289 af Hvad har myndighederne installeret? De adspurgte myndigheder i spørgeskemaundersøgelsen anvender udelukkende Microsoft Word som det primære tekstbehandlingssystem. To af myndighederne anvender version 2007, der kan have både OOXML og DOC som produktionsformat, resten af de adspurgte myndigheder anvender ældre versioner med en stor overvægt på version På den baggrund har samtlige respondenter valgt DOC-formatet som deres primære produktionsformat. Dette betyder, at næsten alle adspurgte myndigheder, har et tekstbehandlingssystem, der som udgangspunkt ikke understøtter nogen af de åbne formater. Derfor har myndighederne installeret typisk to convertere til konvertering af hhv. OOXML og ODF. Converterne kan enten være klientbaserede eller serverbaserede. Klientbaserede convertere bliver installeret på brugerens PC, typisk som et plugin til det installerede tekstbehandlingssystem, hvor de serverbaserede convertere bliver installeret på en intern fælles server. Serverbaserede convertere kan både være et tekstbehandlingssystem i sig selv, men der findes en række convertere, der kan konvertere fx ved, at man sender en til en adresse på serveren. Modtagelse af OOXML Samtlige respondenter med Word version ældre end 2007 benytter den klientbaserede converter Microsoft Compatibility Pack til at modtage OOXMLdokumenter. Der er da også en stor overvægt af myndigheder, der har svaret, at konvertering fra OOXML sker via en converter installeret på klienten (PC en). Dette giver mulighed for, at brugerne selv kan foretage konverteringen, hvilket også fremgår af svarene, hvor stort set alle myndighederne lader brugerne selv modtage OOXML-dokumenter. Der er nogle få myndigheder, der modtager/konverterer OOXML-dokumenter centralt på en fælles intern server, ligesom nogle få myndigheder har angivet Word 2007 som et sekundært tekstbehandlingssystem, der bruges til at modtage OOXML-dokumenter. Modtagelse af ODF I modsætning til modtagelsen af OOXML-dokumenter, hvor det i praksis var alle myndighederne, der lader brugerne modtage og konvertere selv, er det kun ca. halvdelen af de adspurgte myndigheder, hvor det er brugerne, der selv modtager/konverterer ODF-dokumenter. For den anden halvdels vedkommende foregår konverteringen af ODF-dokumenter ved hjælp fra superbrugere, en intern fælles server eller endnu mere almindeligt, via en helpdesk løsning. De to mest almindelige convertere for modtagelse af ODF-dokumenter er de samme to (klientbaserede) convertere, som blev testet i pilottestene: - Open XML/ODF Translater Add-in for Office Word 2.0 (eller 1.1) (Cleverage) # v

290 Bilagssamling Side 290 af SUN ODF Plugin 1.2 for Microsoft Office (eller 1.1) De myndigheder, som benytter en intern fælles serverløsning, benytter specifkke convertere til dette formål fx kan OpenOffice.org i sig selv fungere som en serverbaseret converter, hvilket der også er et eksempel på. Derudover har myndigheder, der afvikler deres tekstbehandlingssystem via Citrix-løsninger på en fælles intern server, behov for en central serverløsning. Her anvendes Microsoft Compatibility Pack samt ODFConverter, hvor sidstnævnte er et online batchkonverteringsprogram baseret på Java. Endvidere er converteren JODConverter (ligeledes et online Java-baseret konverteringsprogram) brugt hos én myndighed. Nogle af de myndigheder, hvor der er udpegede brugere, der gennemfører konverteringen af modtagne ODF-dokumenter, har valgt at benytte sekundære tekstbehandlingssystemer. Det vil sige, at de udpegede brugere har installeret et tekstbehandlingssystem, som har ODF som produktionsformat (OpenOffice.org eller SUN StarOffice) Organisatoriske muligheder Implementeringen af den systemtekniske løsning for konvertering af de åbne formater kan ikke stå alene. I vejledningen om de åbne formater på dokumentformater.oio.dk/leverancer er der redegjort for organisatoriske tiltag, som myndighederne kan gennemføre for at understøtte den systemtekniske løsning. Den samlede interoperabilitet, det er muligt at opnå, afhænger af disse organisatoriske tiltag. I vejledningen har IT- og Telestyrelsen på basis af de foreløbige erfaringer med åbne dokumentformater og den nuværende tilgængelige teknologi opsummeret følgende forslag til tiltag: # v

291 Bilagssamling Side 291 af gode råd 1. Beslut jer for et funktionalitetsloft Tilpas dokumentskabeloner med udgangspunkt i funktionalitetsloftet 3. Hold jer til de mest almindelige filtyper og vær opmærksom på makroer 4. Undgå gentagne konverteringer 5. Vælg PDF til udveksling af ikke-redigerbare dokumenter 6. Vurder hvilke dokumenter, I vil lave kvalitetscheck på efter konvertering 7. Indfør tjekrutiner for udvalgte dokumenter 8. Installer et tekstbehandlingssystem eller en viewer, som understøtter det pågældende format 9. Overvej harmonisering af sprogversioner 10. Følg med i udviklingen 11. Indrapporter jeres tekniske udfordringer til leverandørerne Hvordan har myndighederne valgt organisatorisk at implementere modtagekravet Spørgeskemaundersøgelsen viser, at myndighederne har grebet den organisatoriske implementering af modtagerkravet af de to åbne standarder forskelligt an. Undersøgelsen viser også, at der typisk er forskel på, hvordan den enkelte myndighed har implementeret modtagerkravet for hvert af de to dokumentformater, og myndigheden har således forskellige konverteringsprocedurer alt efter hvilket format, der modtages. Dette er eksempelvis afspejlet i det faktum, at halvdelen af myndighederne har implementeret en central helpdesk, der foretager konverteringen af modtagne ODF-dokumenter, mens det kun er hver femte myndighed, der stiller den løsning til rådighed, når det drejer sig om OOXML-dokumenter. Stort set alle myndighederne lader konverterløsningen for modtagelse af OOXML-dokumenter stå alene som en systemteknisk løsning. Tilfredsheden med konverteringen fra OOXML til DOC er meget høj, og i de hidtidige tests, der er foretaget inden for funktionalitetsloftet, er der heller ikke observeret nogen udfordringer med denne konvertering. Spørgeskemaundersøgelsen viser som tidligere nævnt, at myndighederne modtager få dokumenter i de åbne dokumentformater sammenholdt med den samlede mængde af modtagne dokumenter. Derfor har der endnu ikke været stillet de store krav til de procedurer, som myndighederne har omkring modtagelse og konvertering af de åbne dokumentformater. 12 Jf. beskrivelsen af begrebet Funktionalitetsloft i vejledningen på dokumentformater.oio.dk/leverancer # v

292 Bilagssamling Side 292 af 379 Kun omkring halvdelen af myndighederne har direkte defineret og beskrevet nye arbejdsgange for modtagelse af henholdsvis ODF- og OOXML-dokumenter, mens andelen, der har informeret og vejledt slutbrugerne om, hvordan de skal håndtere de åbne formater, er lidt større. Kun en enkelt af myndighederne har aftalt produktionsformat med samarbejdsmyndigheder, og kun fire myndigheder har defineret et funktionalitetsloft med henblik på at gøre samarbejde eller konvertering lettere. I forhold til den daglige support af løsningerne har to tredjedele af myndighederne har valgt at forankre supporteren i en helpdesk, mens en fjerdedel har valgt skriftlige vejledninger som den primære hjælp til brugerne. Et enkelt sted har man valgt at forankre supporten hos superbrugerne. Halvdelen af respondenterne svarer, at de har procedurer for, hvordan de sikrer de konverterede dokumenters validitet (juridisk bevisværdi). Kun én enkelt myndighed svarer, at de har lavet procedurer for selve kvalitetssikringen. En fjerdedel råder brugerne til at gemme dokumenter i ESDH-løsningen i originalformatet, mens kun hver femte har direkte regler for det Sammenfatning Det, der først og fremmest træder frem af spørgeskemaundersøgelsen, er, at myndighederne endnu ikke har oplevet en dagligdag, hvor det er normalt at modtage dokumenter i et af de to åbne formater ODF og OOXML. Gennemgangen har også vist, at det endnu ikke er alle myndigheder, der har følt nødvendigheden af, at følge de 11 gode råd for at blive klar til modtagelse af de åbne dokumentformater. Der er ingen tvivl om, at myndighederne p.t. er meget tilfredse med at kunne installere Microsoft Compatibility Pack og så kunne modtage OOXMLdokumenter i deres ældre Word-versioner. Denne konvertering sker generelt på tilfredsstillende vis og har ikke på noget tidspunkt været genstand for fejlobservationer under det valgte funktionalitetsloft. Modtagelsen og konverteringen af ODF-dokumenter giver lidt flere udfordringer, men de eksisterende convertere, der giver mulighed for at modtage og konvertere til DOC-formatet, er af anvendelig karakter. Sameksistensen mellem de to formater er p.t. den mest umodne kombination, uanset om der er tale om konvertering af ODF til OOXML eller omvendt. Her er der observeret en række udfordringer, der på sigt kan give problemer. Så længe myndigheder ikke har nyanskaffet og ikke benytter et af de åbne dokumentformater som produktionsformat, og antallet af modtagne dokumenter i # v

293 Bilagssamling Side 293 af 379 de to åbne formater er så lavt, vil myndighederne ikke opleve de store udfordringer ved at efterleve modtagerkravet. Men med den nuværende modenhed for konvertering mellem de to åbne formater indbyrdes vil myndighederne efter gennemførte nyanskaffelser i deres dagligdag begynde at opleve udfordringer med konverteringer og derved opleve en klar forringelse af den nuværende evne til at modtage dokumenter i begge de to åbne dokumentformater. # v

294 Bilagssamling Side 294 af Analyse 2: Implementering af standarderne uafhængigt af platform Denne analyse tager udgangspunkt i de produkter på markedet, som understøtter et eller begge af de åbne standarder, når myndighederne skal nyanskaffe applikationer eller systemer. Analysen lægger vægt på at belyse, om softwaren kan implementeres uanset hvilken platform, myndigheden baserer sine it-systemer på. Med platform menes hovedsageligt operativsystem, men en brede betragtning vil også blive anvendt i analysen for at belyse applikationsmiljøets betydning for understøttelse af de åbne standarder. Formålet er at analysere de reelle muligheder og praktiske erfaringer med at implementere standarderne uafhængigt af platform, herunder: - Undersøgelse af produkter på markedet - Undersøgelser af konkrete implementeringer i myndigheder 3.1. Fremgangsmåde Analysen og de deraf udledte konklusioner i dette afsnit bygger på resultaterne af leverandørparathedsvurderingen og den gennemførte spørgeskemaundersøgelse, suppleret med viden fra Converterkortlægningen 13, der også indeholder information om tekstbehandlingssystemers understøttelse af de to åbne dokumentformater. Hvor det er relevant, er baggrundsviden fra arbejdet med vejledningen 14 brugt som fundament for analysen. Resultaterne fra disse datakilder er sammenstillet for at give et overblik over myndighedernes muligheder for at anskaffe it-systemer, der opfylder både anskaffelses- og modtagekravet for de åbne standarder uanset deres it-platform. De operativsystemer, der er i fokus, er Microsoft Windows, Linux 15 og Mac OS X. 13 Converterkortlægning - opdatering juni Læs vejledningen på dokumentformater.oio.dk/leverancer 15 Linux kommer i en række udgaver, men de har alle en fælles kerne, der giver Linuxbetegnelsen. # v

295 Bilagssamling Side 295 af Muligheder for nyanskaffelse Der er en række typer af systemer, hvor det er særligt relevant at se på understøttelsen af de åbne formater OOXML og ODF. Disse typer af systemer kan inddeles i: - Tekstbehandlingssystemer - EDH/ESDH-systemer - CMS og Portal - Mail - Dokumenthåndterende fagsystemer Ved anskaffelse af et nyt it-system, der understøtter det ene af de to formater, vil myndighederne ofte vælge at implementere en løsning, der også opfylder modtagekravet, og dermed skal it-løsningen være i stand til at kunne modtage det andet åbne format også. Derfor er der ud over anskaffelsesmulighederne fokus på, om it-løsningen kan opfylde modtagekravet uanset hvilken platform, den er implementeret på Nyanskaffelser af tekstbehandlingssystem uafhængigt af platform Mulighederne for at nyanskaffe et tekstbehandlingssystem er bestemt af, om tekstbehandlingssystemet har en af de to åbne standarder som produktionsformat. Nedenstående liste af tekstbehandlingssystemer er tidligere blevet identificeret under udarbejdelsen af vejledningen om åbne standarder for dokumentudveksling. Listen er opdateret med de seneste versioner og viden om planlagte frigivelser. Kontorpakke (tekstbehandling) Understøtter som standard ODF Understøtter som standard OOXML Kan opgraderes med converterplugin til ODF Kan opgraderes med converterplugin til OOXML NeoOffice Ja Ja ikke relevant ikke relevant iwork 08 Nej Ja Nej ikke relevant Corel WordPerfect Office X4 17 IBM Lotus Word Pro 9.8 IBM Lotus Symphony (Notes 8) Microsoft Office Word 2000 Microsoft Office Word XP Nej (visning Nej (visning Nej Nej understøttet) understøttet) Nej Nej Nej Nej Ja Nej Nej Nej Nej Nej Ja Ja Nej Nej Ja Ja 16 Er kun udgivet til Mac OS 17 Standard-produktionsformatet i Corel WordPerfect Office X4 er DOC eller Corels eget format "WPD, afhængig af hvilken mode brugeren vælger at arbejde i. # v

296 Bilagssamling Side 296 af 379 Kontorpakke (tekstbehandling) Microsoft Office Word 2003 Microsoft Office Word 2007 Microsoft Office Word for Mac 2004 Microsoft Office Word for Mac 2008 SUN StarOffice Writer ver. 8 KWord (del af Koffice) ver OpenOffice.org ver. 2.3 OpenOffice.org ver. 3.0 Open Office.org Novell Edition 2.4 Understøtter som standard ODF Understøtter som standard OOXML Kan opgraderes med converterplugin til ODF Kan opgraderes med converterplugin til OOXML Nej Nej Ja Ja Nej (kommer Ja Ja ikke relevant med den nye service pack) Nej Nej Nej (konvertering til RTF understøttes) Nej Ja Nej Ikke relevant Ja Nej Ikke relevant Nej Ja Nej Ikke relevant Nej Ja Nej Ikke relevant Nej Ja Ja Ikke relevant Ikke relevant Ja Nej Ikke relevant Ja Figur 3 Tekstbehandlingssystemers muligheder for at understøtte ODF eller OOXML I forhold til opfyldelse af anskaffelseskravet er det relevant at kigge på de to første kolonner, hvorimod de to sidste kolonner giver information om, hvorvidt tekstbehandlingssystemet kan opfylde modtagerkravet. På Mac OS X- platformen findes Microsoft Office Word for Mac 2004 (understøtter ikke de åbne standarder) og Microsoft Office Word for Mac 2008 og iwork 08 (disse kan ikke modtage ODF-dokumenter). Mac-brugere kan vælge det gratis program NeoOffice 18, som understøtter både ODF og OOXML. Microsoft leverer ikke produkter til Linux, hvorfor valg af Linux som platform giver en begrænsning i valget af tekstbehandlingssystemer. Linux som platform giver således mere begrænsede muligheder for at opfylde anskaffelses- og modtagerkravet samtidig. Linux og Mac OS X brugere kan dog vælge at installere en Windows-emulator eller afvikle programmer via en virtuel Windows maskine, og derigennem have adgang til at afvikle tekstbehandlingssystemerne fra Microsoft. Microsoft Windows giver som platform den bredeste vifte af muligheder for at nyanskaffe tekstbehandlingssystemer, der opfylder anskaffelseskravet. Windowsbrugere kan vælge at nyanskaffe Microsoft Office Word 2007, hvilket for de fleste vil være den nyeste version af det tekstbehandlingssystem, som de bruger i dag. Derudover er alle OpenOffice.org-produkterne frigivet til at køre på 18 Se omtale af NeoOffice i Converterkortlægning opdateret juni 2008 # v

297 Bilagssamling Side 297 af 379 Windows, så Windows platformen giver fuld valgfrihed omkring understøttelse af det ene eller andet af formaterne. Microsoft Office Word 2007 kan udvides med en converter. Bl.a. kan converteren SUN ODF Plugin 1.2 for Microsoft Office installeres som plugin, og derved er det muligt at modtage ODF-dokumenter. Denne converter er den, der klarer sig bedst i Magentas test. Microsoft arbejder med at udgive en ny service pack til Office Word Denne service pack giver fuld understøttelse af ODF. Når denne service pack udkommer, vil Office Word 2007 blive en af meget få tekstbehandlingssystemer, der understøtter begge de åbne formater (sammen med OpenOffice.org 3.0 og Abiword jf. tabellen i afsnit ). I spørgeskemaundersøgelsen har samtlige respondenter Microsoft Windows som operativsystem, hvoraf et par enkelte også anvender Citrix til at afvikle programmer. Derfor er der ikke blandt de adspurgte myndigheder væsentlige forskelle på mulighederne for at nyanskaffe tekstbehandlingssystemer, der opfylder anskaffelseskravet for de åbne standarder ODF og OOXML Nyanskaffelser af andre it-løsninger end tekstbehandlingssystemer Nyanskaffelser af andre it-løsninger end tekstbehandlingssystemer omhandler, jf. afsnit 3.2, anskaffelser af bl.a. ESDH, mail, CMS og andre fagsystemer. Her bliver leverandørernes evne til at understøtte de åbne dokumentformater i andre systemer end tekstbehandlingssystemer belyst. I leverandørparathedsvurderingen 19 er der en sammenfattende vurdering fra leverandørerne, der lyder: De nye formater vurderes at give - En højere grad af frihed i valget af "produktionsværktøj" - Nemmere integrationer til tredje part - Nemmere dataudveksling og integrering af informationer i forretningsprocesser - En bedre fremtidssikring, da formaterne er åbne Leverandørerne forventer med andre ord, at myndighederne bliver bedre stillet i forhold til integration til fagsystemer og dataudveksling, og at der vil blive større valgfrihed ved indførsel af de åbne standarder. 10 ud af de 14 leverandører svarede i undersøgelsen, at deres it-løsninger understøtter ODF/OOXML i en eller flere af deres versioner. En del af 19 Parathedsvurdering afrapportering fra november 2007 # v

298 Bilagssamling Side 298 af 379 leverandørerne svarede dog, at de har oplevet udfordringer med at håndtere de åbne standardformater. Størstedelen af de systemer, der indgår i besvarelserne af parathedsvurderingen, er ESDH-systemer, fulgt af CMS-systemer. Da disse systemer ikke i sig selv producerer dokumenter i de åbne formater, men opbevarer/publicerer dem, er det vigtig at se på hvilke redigeringsværktøjer, disse systemer integrerer til, da det vil fuldende billedet af myndighedernes muligheder for at nyanskaffe en it-løsning på det pågældende område. Resultatet af leverandørparathedsvurderingen viser, at det i største omfang er Microsoft Office Word, løsningerne kan integrere til. Dette giver en situation, hvor myndighederne skal kigge på Microsoft Word som supplement til nyanskaffelsen. Der er kendskab til, at integrationen til tekstbehandlingssystemer både kan være baseret på formatet, men også i andre tilfælde være applikationsspecifik. Ved de integrationer, der er baseret på formatet, er det formatets anvendelse af eksempelvis feltdefinitioner og makroer, der er afgørende for, om integrationen virker, og derved om formatet er understøttet. Når integrationen er applikationsspecifik, er der tale om, at fagsystemerne danner et udtræk, der kan læses af et tekstbehandlingssystem. Her skal udtrækket være formateret til at blive modtaget af det pågældende tekstbehandlingssystem, og dermed er det udtrækkets format, der er afgørende for understøttelse af de åbne dokumentformater. Flere besvarelser fra spørgeskemaundersøgelsen peger på, at der ikke har været de store udfordringer med integrationen til fagsystemer. Igen ser det ud til, at mængden af de modtagne dokumenter i de to formater er så lille, at det ikke har givet anledning til væsentlige bekymringer. Der er et eksempel på, at integrationen til ESDH-systemet for arkivering ikke virker. En myndighed peger således på, at de foreløbigt har ventet i otte måneder på deres leverandør, så de kan arkivere dokumenter i formaterne ODF og OOXML. Dermed er det også indikeret, at selv om leverandørerne svarer, at deres itløsninger understøtter de åbne formater, kræver det en ændring i opsætningen eller implementering af en opdatering, før dette gælder i praksis for myndighederne. # v

299 Bilagssamling Side 299 af Opfyldelse af modtagekravet ved nyanskaffelser uafhængigt af platform Når myndighederne nyanskaffer it-systemer, der opfylder anskaffelseskravet om, at de nye systemer skal understøtte en af de to åbne standarder ODF eller OOXML, skal de samtidig være sikre på, at de kan modtage begge de åbne standarder for at opfylde modtagekravet. Derfor er det relevant at se på interoperabiliteten mellem formaterne uafhængigt af platform, så det bliver belyst, om myndighederne har frit valg af løsninger uanset hvilken platform, de opererer på. Her kommer de tilgængelige convertere og deres tilgængelighed på tværs af operativsystemer i fokus. Implementeringsmuligheder af converterløsninger uafhængigt af operativsystemer er et område, der er styret af markedets efterspørgsel. Leverandørerne vil først og fremmest koncentrere sig om at udvikle convertere til de operativsystemer, der er mest udbredt, hvilket i praksis vil sige, at convertere først bliver udviklet til Microsoft Windows. En anden måde at udvikle convertere på er ved for eksempel at udvikle dem i Java. Udviklingen af plug-ins på en Java-platform gør, at programmet bliver uafhængigt af operativsystem. I converterkortlægningen er der for hver af de identificerede convertere angivet systemkrav, herunder hvilket operativsystem, de er anvendelige til. Converterkortlægningen viser, at det først og fremmest er Microsoft Windows, der er udviklet convertere til, hvilket er med til at understøtte hypotesen om, at udviklingen af convertere er markedsdrevet. Også Linux er bredt repræsenteret blandt de listede convertere, så Linux-brugere har god mulighed for at benytte de samme convertere som Windows-brugere. Til gengæld er convertere til brug for Mac OS X næsten helt fraværende. Converterkortlægningen giver også et bud på en række convertere, der kan installeres på en intern/fælles server. Flere af disse er Java-baserede og derfor uafhængige af operativsystem, mens andre er udviklet til Windows og Linux. Ved konvertering via en server bliver operativsystemet på klienten uvæsentlig i forhold til konverteringens praktiske gennemførelse og kvalitet. I spørgeskemaundersøgelsen har samtlige respondenter Microsoft Windows som operativsystem, hvoraf et par enkelte også anvender Citrix til at afvikle programmer. De myndigheder, der benytter afvikling af deres tekstbehandlingssystemer via Citrix, har i spørgeskemaundersøgelsen ikke nogen afvigelser i tilfredshed med løsninger eller konverteringer i forhold til de myndigheder, der afvikler programmer lokalt på klienterne. # v

300 Bilagssamling Side 300 af 379 Ved krydsning af spørgeskemaets resultater mellem operativsystemer og hvilke tekstbehandlingssystemer, myndigheden anvender, sammen med brugernes tilfredshed med løsning og brugervenlighed, er der ikke nogen varians på operativsystemet inden for de enkelte tekstbehandlingssystemer og converterløsninger. Også de observerede fejl i konverteringen er de samme på tværs af operativsystemer. Således er der ikke noget, der tyder på, at de forskellige versioner af Microsoft Windows, som myndighederne i spørgeskemaundersøgelsen anvender, giver anledning til forskelle i interoperabiliteten mellem formaterne. Der er i spørgeskemaundersøgelsen heller ingen indikation af, at myndigheder, der anvender en løsning, hvor konvertering sker på en intern/fælles server, har større eller mindre tilfredshed med konverteringerne og løsningen, end hos de myndigheder, hvor konvertering sker på brugernes klienter Sammenfatning Når myndighederne skal nyanskaffe it-løsninger, er deres it-platform afgørende. Gennemgangen har vist, at brugen af Mac OS X som operativsystem alene giver én mulighed for samtidig at overholde anskaffelseskravet og modtagekravet, hvilket så kræver installering af en ekstra applikation. Derudover har gennemgangen vist, at myndigheder, der har Linux som operativsystem, ikke umiddelbart har adgang til Microsofts produkter, hvorfor det er sværere for disse myndigheder at have adgang til produkter, der møder anskaffelses- og modtagekravet. Myndighederne kan imidlertid vælge at installere en Windows-afvikler (emulator eller virtuel afvikler) for at imødekomme behovet. Langt de fleste leverandører hævder, at deres it-løsninger understøtter de åbne standardformater ODF og OOXML. It-løsningerne vil dog ofte have brug for et editeringssystem, der som udgangspunkt er et tekstbehandlingssystem. Gennemgangen viste, at de tilbudte it-løsninger i bredt omfang integrerer til Microsoft Office Word. Denne integration bliver derved den laveste fællesnævner for de valgmuligheder, som myndighederne har, når de skal nyanskaffe it-løsninger. Det blev også indikeret, at leverandørernes it-løsninger skal modificeres, enten via opsætning eller opdatering, for at kunne opfylde modtagerkravet, samt at det kan tage tid at få leverandøren til at gennemføre denne modificering. Spørgeskemaundersøgelsen viste også, at myndighederne endnu ikke oplever en dagligdag med modtagelse af dokumenter i de åbne formater, og derfor er # v

301 Bilagssamling Side 301 af 379 myndighedernes it-løsninger og konverteringsprocedurer endnu ikke blevet presset til at yde det maksimale. Når dette sker, vil det igen medføre et større krav fra myndighederne til leverandørerne om at integrere fuld understøttelse af de åbne formater i it-løsningerne. Udviklingen af convertere sker på baggrund af efterspørgsel i markedet. Det betyder i praksis, at convertere bliver udviklet til Microsoft Windows / Microsoft Office først, og at udbuddet af convertere er størst til dette segment. Modenheden af konverteringerne på tværs af operativsystemer må dog ud fra det her tilgængelige materiale siges at være på et jævnbyrdigt niveau uafhængig af operativsystemerne Windows og Linux. Kun Mac OS X-brugere kan få svært ved at finde tilgængelige convertere. Gennemgangen har også vist, at brugen af Citrix ikke har nogen indflydelse på mulighederne for at nyanskaffe eller på konverteringerne for opfyldelse af modtagerkravet. # v

302 Bilagssamling Side 302 af 379 Bilag - Resultat af spøgeskemaundersøgelse Bilag 1 - Resultat af spøgeskemaundersøgelse #84586 v1 1

303 Bilagssamling Side 303 af 379 Bilag - Resultat af spøgeskemaundersøgelse Indholdsfortegnelse 1. Resumé Udgangspunktet: Styresystemer, tekstbehandlingssystemer og formater Styresystemer Tekstbehandlingssystemer Dokumentformater Opsummering af udgangspunktet Løsningen: Læsning og konvertering af de åbne formater Teknisk løsning Læsning og konvertering af ODF Læsning og konvertering af OOXML Organisatorisk implementering Opsummering af løsningen Erfaringerne med ODF og OOXML i Staten Volumen for modtagne formater Kvaliteten af konverteringen Brugernes produktivitet og tilfredshed Opsummering af erfaringer #84586 v1 2

304 Bilagssamling Side 304 af 379 Bilag - Resultat af spøgeskemaundersøgelse 1. Resumé Undersøgelsen er gennemført i Staten, og der er sendt spørgeskemaer ud til 33 itansvarlige fra departementer, direktorater og styrelser. 22 respondenter 1 har svaret, hvilket giver en svarprocent på 67%. På baggrund af det forholdsvis entydige resultat, som spørgeskemaundersøgelsen giver, vurderer Devoteam, at det er forsvarligt at anvende resultaterne. Endvidere er antallet af it-brugere, som respondenterne repræsenterer, stort. 64% af respondenterne har mere end 500 it-brugere. Antal it-brugere 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 0% 14% 14% 9% 23% < % > 1000 n = 22 Spørgsmål: Hvor mange it-brugere har I (brugere med en itarbejdsplads)? I forhold til respondenternes it-fundament, løsning og erfaringer er de vigtigste observationer gengivet i denne tabel: Område Observation Styresystemer 87% anvender Microsoft Windows XP eller Vista udgør de 73%-point, mens Windows 2000 udgør de sidste 14%-point. 14% anvender Citrix Tekstbehandlingssystemer Alle har Microsoft Word som primært tekstbehandlingssystem 77% anvender Office Én ud af de 22 har ikke svaret på samtlige spørgsmål, så der vil være nogle spørgsmål, hvor n kun er 21. #84586 v1 3

305 Bilagssamling Side 305 af 379 Bilag - Resultat af spøgeskemaundersøgelse Område Observation Dokumentformater Alle har DOC som internt arbejdsformat Mere end 76% sender dokumenter, som ikke skal redigeres, i PDF Håndtering af ODF Nogle myndigheder har flere løsninger: o 77% har installeret convertere eller plug-ins på klienterne o 18% har en intern serverløsning o 18% læser ODF-dokumenter i et andet tekstbehandlingssystem end det, brugerne normalt skriver i Den mest populære ODF-converter er med 56% Sun ODF Plugin for Microsoft Office Håndtering af OOXML Nogle myndigheder har flere løsninger: o 85% har installeret convertere eller plug-ins på klienterne o 10% har en intern serverløsning o 10% læser OOXML-dokumenter i et andet tekstbehandlingssystem end det, brugerne normalt skriver i Den mest populære OOXML-converter er med 83% Microsoft Office Compatibility Pack Organisatorisk implementering Omkring halvdelen af institutionerne har defineret og beskrevet arbejdsgangen ved modtagelse af enten ODF eller OOXML Mere end halvdelen har procedurer for at sikre konverterede dokumenters validitet (juridisk bevisværdi) Volumen Respondenterne er blevet bedt om at vurdere, hvilke formater de modtager. 4% af de modtagne dokumenter er efter respondenternes vurdering i enten OOXML eller ODF Kvaliteten af konverteringen Brugernes produktivitet og tilfredshed 100% er enten tilfredse eller meget tilfredse med konverteringen af OOXML-dokumenter 63% er enten tilfredse eller meget tilfredse med konverteringen af ODF-dokumenter Problemerne med ODF drejer sig primært om: o Formatering (19%) o Tabeller (14%) o Indsatte statiske billeder og grafik (14%) o Skabeloner og makroer (14%) 71% vurderer, at der ikke er sket en produktivitetsnedgang som følge af modtagelseskravet. 85% vurderer, at brugerne er enten tilfredse eller meget tilfredse med henholdsvis løsningerne og deres brugervenlighed. #84586 v1 4

306 Bilagssamling Side 306 af 379 Bilag - Resultat af spøgeskemaundersøgelse 2. Udgangspunktet: Styresystemer, tekstbehandlingssystemer og formater Dette kapitel redegør for hvilket udgangspunkt eller it-fundament, institutionerne har. Det vil sige hvilke styre- og tekstbehandlingssystemer, der er installeret hos slutbrugerne, samt hvilke dokumentformater, de normalt arbejder i Styresystemer Den grundlæggende platform er for langt hovedparten Microsoft Windows (87%), mens resten har en Citrix-løsning. 73% anvender enten Windows XP eller Vista, hvor XP med 68% blandt samtlige respondenter er det mest udbredte. Primære styresystemer 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 73% Windows XP eller Vista 14% 14% Windows 2000 Citrix n = 22 Spørgsmål: Hvilket styresystem er det mest udbredte på slutbrugernes arbejdsstation/it-arbejdsplads? I 68% af institutionerne har man kun udrullet ét styresystem til slutbrugerne. De, som har mere end ét styresystem, anvender med få undtagelser forskellige versioner af Windows, evt. som supplement til Citrix, eller Citrix som supplement til Windows. #84586 v1 5

307 Bilagssamling Side 307 af 379 Bilag - Resultat af spøgeskemaundersøgelse Sekundære styresystemer Styresystem % af respondenter AIX 5 14 % Citrix 29 % Linux Ubuntu 14 % Windows 2000 SP3 eller senere 14 % Windows Vista uden Service Packs 14 % Windows XP før Service Pack 2 14 % Windows XP Service Pack 2 14 % Windows XP Service Pack 3 14 % n = 7 Spørgsmål: Hvilke andre styresystemer anvender brugerne? NB: Respondenterne har kunnet markere mere end ét styresystem. Derfor er det andelen af de syv institutioner, som anvender mere end ét styresystem, der er gengivet. 14% svarer til en institution. Af samme årsag summerer procenterne til mere en Tekstbehandlingssystemer Det mest anvendte tekstbehandlingssystemer er Microsoft Word % af institutionerne har 2003-versionen som primært tekstbehandlingssystem - To institutioner svarende til 9% anvender Microsoft Word Mens en enkelt institution (5%) anvender XP-versionen. En enkelt institution svarer, at flere versioner af Word er deres primære tekstbehandlingssystem. Kun fire institutioner anvender mere end et tekstbehandlingssystem. To anvender OpenOffice.org Writer version 2.4, mens andre to angiver, at de anvender Microsoft Word 2007 som sekundært tekstbehandlingssystem Dokumentformater Samtlige respondenter svarer, at DOC er det primære format til tekstdokumenter internt i institutionen. #84586 v1 6

308 Bilagssamling Side 308 af 379 Bilag - Resultat af spøgeskemaundersøgelse Når institutionerne sender dokumenter, som modtageren ikke har behov for at ændre i, så sender 76% som PDF, 5% som DOC, mens 19% anvender både PDF og DOC. Sendte dokumenter uden behov for redigering DOC 5% PDF 76% Begge 19% n = 21 Spørgsmål: Hvad gør I, når I sender dokumenter, som ikke er beregnet til videreredigering? Hvis de dokumenter, som medarbejderne sender, skal kunne redigeres af modtageren, så er det kun i én institution (5%), hvor man direkte aftaler et arbejdsformat. 33% arbejder i det interne format og konverterer, hvis det er nødvendigt, mens andre 33% ikke har forholdt sig til det. Formater til samarbejde Vi arb ejde r i vore s in terne arbejd sfo rma t og ko nvertere r om nødve ndigt % 33% Vi aftaler et format at arb ejde i 5% Vi har ikke fo rholdt o s til prak sis i fo rbindelse med sam arb ejde 33% Andet 5% Ikke relevant 24% To tal 100% n = 21 Spørgsmål: Hvordan håndterer I samarbejde om redigerbare dokumenter med andre myndigheder, som bruger et andet dokumentformat end jer?? Under svarmuligheden Andet angiver en enkelt respondent, at de normalt svarer i det dokumentformat, som de modtager, men at det kan være svært at overskue for brugerne, da der er mange formater at vælge imellem i tekstbehandlingssystemet. #84586 v1 7

309 Bilagssamling Side 309 af 379 Bilag - Resultat af spøgeskemaundersøgelse 2.4. Opsummering af udgangspunktet Alt i alt kan følgende opsummeres om it-fundamentet i de deltagende institutioner i Staten: - Microsoft Windows er med 87% langt det mest udbredte styresystem, og de mest anvendte versioner er XP og Vista (samlet 73%). - Alle har Microsoft Word i forskellige versioner som deres primære tekstbehandlingssystem. Langt hovedparten af institutionerne (77%) anvender 2003-versionen. - Alle har DOC som deres interne arbejdsformat, og mere end 76% sender i PDF, hvis modtageren ikke har behov for at redigere i dokumentet. #84586 v1 8

310 Bilagssamling Side 310 af 379 Bilag - Resultat af spøgeskemaundersøgelse 3. Løsningen: Læsning og konvertering af de åbne formater Kapitlet ovenfor redegjorde for det fundament, som de statslige institutioner har bygget deres løsning oven på. I dette kapitel ser vi på hvilken løsning, institutionerne har valgt til at håndtere ODF og OOXML Teknisk løsning Det mest udbredte princip for konvertering er at anvende to convertere en til konvertering af ODF og en til konvertering af OOXML. 36% anvender denne løsning. Andre 27% har et tekstbehandlingssystem, som understøtter et af formaterne og anvender en converter til det andet format. 18% har et tekstbehandlingssystem, som kan læse begge formater, mens 14% anvender to tekstbehandlingssystemer til at læse (ikke konvertere) de åbne formater. 2 En enkelt respondent svarer, at løsningen er forskellig fra institution til institution. Teknisk løsning En tekstbehandler, som understøtter både ODF og OOXML 18% En tekstbehandler, som understøtter enten ODF eller OOXML suppleret med en converter til understøttelse af det andet format 27% En tekstbehandler, som hverken understøtter ODF eller OOXML, suppleret med to convertere 36% To tekstbehandlere, som understøtter henholdsvis ODF og OOXML (evt. gennem indbyggede convertere/plug-ins) 14% Institutionsafhængigt 5% Total 100% n = 22 Spørgsmål: Hvilken løsningsmodel beskriver bedst jeres håndtering af modtagekravet - dvs. at kunne modtage både ODF og OOXML? 2 Det skal her bemærkes, at der ikke er konsistens mellem flere af svarene og de løsninger, som bliver tilbudt til deres tekstbehandlingssystemer. Der er fire, som svarer, at de anvender et tekstbehandlingssystem, som understøtter både ODF og OOXML. Tre af dem anvender Word 2003, hvorfor de må have to convertere. Én har Word 2007 som primært tekstbehandlingssystem, og de må derfor anvende en converter til ODF. Én svarer, at de anvender Word 2007 og har to convertere, hvilket ikke stemmer overens med, at Word 2007 understøtter OOXML. #84586 v1 9

311 Bilagssamling Side 311 af 379 Bilag - Resultat af spøgeskemaundersøgelse Læsning og konvertering af ODF Når en institution modtager et dokument i ODF, er det primært brugerne selv, som håndterer dokumentet (68%), men 45% angiver dog også, at en central funktion fx en servicedesk, håndterer dokumenterne. Hvem håndterer ODF? % af respondenter Brugerne selv 68% Udpegede personer - fx sekretærer eller superbrugere 9% En central funktion - fx servicedesk, helpdesk eller lignende 45% n = 22 Spørgsmål: Når I modtager et dokument i ODF-format, hvem håndterer så konverteringen? NB: Respondenterne har kunnet markere mere end én løsning Derfor summerer procenterne til mere en 100. Hos 77% af respondenterne har man valgt at installere en converter eller plug-in på brugernes klienter. 18% har en løsning på en fælles intern server, mens 18% har installeret et andet tekstbehandlingssystem, som kan læse ODF. Ingen anvender en internetservice. Der er således flere løsningerne i spil hos flere af respondenterne. ODF løsning % af respondenter Konvertering via converter/plug-in installeret på klienten 77% Konvertering via løsning på fælles intern server 18% Konvertering via ekstern internetservice 0% Læses i anden tekstbehandler end brugernes primære 18% Læses via viewer 0% n = 22 Spørgsmål: Hvilken eller hvilke løsninger anvender I til at konvertere eller læse ODF-dokumenter? NB: Respondenterne har kunnet markere mere end én løsning Derfor summerer procenterne til mere en 100. Convertere - Klient-løsninger Sun ODF Plugin for Microsoft Office er med 56% den mest anvendte converter. En enkelt respondent svarer, at de anvender version 1.1, mens resten har version 1.2 installeret. 31% bruger Open XML/ODF Translator, mens JODC Converter og #84586 v1 10

312 Bilagssamling Side 312 af 379 Bilag - Resultat af spøgeskemaundersøgelse OpenOffice.org Format Converter hver især tegner sig for 6% - svarende til én respondent. ODF convertere (klient-løsninger) % af respondenter Docvert 3.3 0% JODConverter % Open XML/ODF Translator Add-ins for Office - Word % OpenOffice.org Format Converter 6% Sun ODF Plugin 1.1 eller 1.2 for Microsoft Office 56% Xena 4.1 0% n = 16 Spørgsmål: Hvilken eller hvilke convertere/plug-ins, der er installeret på klienten, anvender I til at konvertere ODF? NB: Respondenterne har kunnet markere mere end én løsning Derfor summerer procenterne til mere en 100. Convertere - Serverløsninger Fire respondenter svarer, at de anvender convertere, der er installerede på servere. Der anvendes tre forskellige serverløsninger nemlig ODFTrans, ODF Command Line Translator på en Citrix-installation og OpenOffice.org. Alle anvendes kun ét sted, mens en enkelt respondent svarer, at han eller hun ikke ved, hvilken serverløsning, de anvender. Tekstbehandlingssystem-løsninger De fire respondenter, som læser ODF-dokumenterne i et andet tekstbehandlingssystem end brugerens primære, anvender OpenOffice.org i enten version 2.3 eller 2.4 (henholdsvis 25% og 50%), mens Sun Star Office version 8 tegner sig for de resterende 25% Læsning og konvertering af OOXML For 95% vedkommende står brugerne selv for at håndtere dokumenter i OOXML, mens det hos en enkelt respondent er en central funktion, som står for dette. Hos 14% af respondenterne har man både en lokal og en central funktion. #84586 v1 11

313 Bilagssamling Side 313 af 379 Bilag - Resultat af spøgeskemaundersøgelse Hvem håndterer OOXML? % af respondenter Brugerne selv 95% Udpegede personer - fx sekretærer eller superbrugere 0% En central funktion - fx servicedesk, helpdesk eller lignende 19% n = 21 Spørgsmål: Når I modtager et dokument i OOXML-format, hvem håndterer så konverteringen? NB: Respondenterne har kunnet markere mere end én løsning Derfor summerer procenterne til mere en 100. Hos 86% af respondenterne har brugerne en converter eller plug-in installeret direkte på klienten. 10% har en løsning installeret på en intern server, mens andre 10% læser OOXML-dokumenterne i et andet tekstbehandlingssystem end brugerens primære. Et enkelt sted anvender man en viewer til at læse dokumenter i OOXML. Ingen bruger en internetservice til konvertering. OOXML løsning % af respondenter Konvertering via converter/plug-in installeret på klienten 86% Konvertering via løsning på fælles intern server 10% Konvertering via ekstern internetservice 0% Læses i anden tekstbehandler end brugernes primære 10% Læses via viewer 5% n = 21 Spørgsmål: Hvilke løsninger anvender I til at konvertere eller læse OOXML-dokumenter? NB: Respondenterne har kunnet markere mere end én løsning Derfor summerer procenterne til mere en 100. Convertere - Klient-løsninger Langt den mest udbredte converter er Microsoft Compatibility Pack. 83% af respondenterne anvender denne, mens 11% anvender OpenOffice.org OpenXML Translator. 6% bruger docxconverter, og andre 6% bruger Microsoft Office Open XML File Format Converter for Mac. 3 3 Der er inkonsistens mellem, at ingen af respondenterne har en Mac-platform, og at én svarer, at de anvender en converter til Mac. #84586 v1 12

314 Bilagssamling Side 314 af 379 Bilag - Resultat af spøgeskemaundersøgelse OOXML convertere (klient-løsninger) % af respondenter docxconverter 3.0 6% Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats 83% Microsoft Office Open XML File Format Converter for Mac (Beta) 6% OpenOffice.org OpenXML Translator % Spørgsmål: Hvilken eller hvilke convertere/plug-ins, der er installeret på klienten, anvender I til at konvertere OOXML? n = 18 NB: Respondenterne har kunnet markere mere end én løsning Derfor summerer procenterne til mere en 100. Convertere - Serverløsninger Af de to respondenter, som har angivet, at de bruger en serverløsning, anvender den ene Microsoft Compatibility Pack på Citrix, mens den anden svarer, at han eller hun ikke ved, hvad de bruger. Tekstbehandlingssystem-løsninger De tre institutioner, som bruger et andet tekstbehandlingssystem end det primære til at læse OOXML dokumenter, anvender hver især Microsoft Office Word 2003 med Compatibility Pack, Microsoft Office Word 2007 eller OpenOffice.org Writer version 2.4 med converter plug-in. Hos den ene respondent, hvor man har en viewer, bruger de Word Viewer med Microsoft Compatibility Pack Organisatorisk implementering Lidt over halvdelen af institutionerne har direkte defineret og beskrevet nye arbejdsgange for modtagelse af henholdsvis ODF- og OOXML-dokumenter. 71% har informeret og vejledt slutbrugerne om, hvordan de skal håndtere de åbne formater, mens 52% sikrer løbende support til brugerne. #84586 v1 13

315 Bilagssamling Side 315 af 379 Bilag - Resultat af spøgeskemaundersøgelse Implementering % af respondenter Vi har defineret og beskrevet de nye arbejdsgange ved modtagelse af ODF 52% Vi har defineret og beskrevet de nye arbejdsgange ved modtagelse af OOXML 48% Vi har informeret og vejledt slutbrugerne om de nye arbejdsgange 71% Vi sikrer løbende support til slutbrugerne 52% n = 21 Spørgsmål: Hvordan har I implementeret løsningen organisatorisk? NB: Respondenterne har kunnet markere mere end én løsning Derfor summerer procenterne til mere en % har valgt at forankre supporteren i en help- eller servicedesk, mens 24% har valgt skriftlige vejledninger, som deres primære hjælp til brugerne. Et enkelt sted har man valgt at forankre supporten hos superbrugerne. Support % Support via helpdesk/servicedesk 67% Support via superbrugere 5% Vi har udarbejdet vejledningsmateriale/intranetvejledning til slutbrugerne 24% Ingen support til modtagelse af fremmede 0% dokumentformater Institutionsafhængigt 5% Total 100% n = 21 Spørgsmål: Hvilken model beskriver bedst jeres supportløsning? 48% af respondenterne svarer, at de ikke har procedurer for, hvordan de sikrer de konverterede dokumenters validitet (juridisk bevisværdi). Kun en enkelt (5%) svarer, at de har lavet procedurer for selve kvalitetssikringen. 24% råder brugerne til at gemme i originalformatet, mens 19% har direkte regler for at gemme i originalformatet. #84586 v1 14

316 Bilagssamling Side 316 af 379 Bilag - Resultat af spøgeskemaundersøgelse Kvalitetssikring % af respondenter Vi har retningslinjer for, hvornår dokumenter skal kvalitetssikres 0% Vi har procedurer, som beskriver kvalitetssikringsprocessen 5% Vi råder brugerne til at opbevare dokumenterne i originalformatet, såfremt der skulle være tvivl om konverteringens kvalitet 24% Vi har lavet regler om, at brugerne skal opbevare dokumenterne i originalformatet, såfremt der skulle være tvivl om konverteringens kvalitet 19% Laver ODF om til PDF 10% Ingen 48% n = 21 Spørgsmål: Hvis I har sådanne: Hvilken eller hvilke procedurer findes til at sikre de konverterede dokumenters validitet (juridisk bevisværdi - dvs. fx bevis for, at dokumentet er konverteret korrekt)? NB: Respondenterne har kunnet markere mere end én løsning Derfor summerer procenterne til mere en Opsummering af løsningen For den tekniske løsning kan følgende opsummeres: - Det mest udbredte princip for konvertering er to convertere en til konvertering af ODF og en til konvertering af OOXML (36%) - Det næstmest udbredte princip er et tekstbehandlingssystem, som understøtter et af de åbne formater, suppleret med en converter (27%) - Hovedparten af brugerne står selv for håndteringen af de åbne formater (95% for OOXML og 68% for ODF) - Den mest udbredte løsningsmodel er convertere og plug-ins, der er installeret på klienterne (86% for OOXML og 77% for ODF). De mest udbredte klient-baserede convertere er: o OOXML: Microsoft Compatibility Pack (83%) o ODF: Sun ODF Plugin for Microsoft Office (56%) Den organisatoriske implementering er foregået således: - 71% af institutionerne har direkte informeret brugerne om modtagelse af ODF og OOXML, mens omkring halvdelen har defineret og beskrevet arbejdsgangen i relation hertil. - Supporten foregår primært via service- eller helpdesk. - Næsten halvdelen af institutionerne har ikke procedurer til at sikre validiteten (den juridiske bevisværdi) af konverteringen. For de, som har, består proceduren primært i at gemme det originale dokument. #84586 v1 15

317 Bilagssamling Side 317 af 379 Bilag - Resultat af spøgeskemaundersøgelse 4. Erfaringerne med ODF og OOXML i Staten I dette kapitel vil vi samle op på nogle af de erfaringer, som man har gjort sig med at kunne modtage de åbne formater i Staten. Det drejer sig dels om: - Volumen - Kvaliteten af konverteringen - Brugernes erfaringer 4.1. Volumen for modtagne formater Respondenterne er blevet bedt om at vurdere, hvor mange procent ud af det samlede antal modtagne dokumenter de enkelte dokumentformater udgør. Der er således tale om respondenternes umiddelbare vurdering og ikke en egentlig optælling. Vurderingen er, at de åbne formater tegner sig for en meget lille andel af de dokumenter, som de statslige myndigheder modtager. Respondenterne angiver, at OOXML står for 3% og ODF for 1%. DOC er langt det mest udbredte format med 76%, mens PDF tegner sig for 17%. Andre formater udgør 2%. Modtagne formater 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 76% 17% 3% 1% 2% DOC PDF OOXML ODF Andre formater n =21 Spørgsmål: Du bedes vurdere hvor stor en andel af de dokumenter, I modtager, som er i følgende formater. Angiv venligst et skønnet ca. tal i procent - summen skal give Kvaliteten af konverteringen Respondenterne er blevet bedt om at vurdere kvaliteten af konverteringen. 81% har gjort dette for OOXML, mens 19% har svaret ved ikke. For ODF er fordelin- #84586 v1 16

318 Bilagssamling Side 318 af 379 Bilag - Resultat af spøgeskemaundersøgelse gen 76% og 24%. Tilfredsheden er størst med OOXML. 100% af de respondenter, som har været i stand til at komme med en vurdering, svarer, at de enten er tilfredse eller meget tilfredse med konverteringen af OOXML. For ODF er det tilsvarende tal 63%, og 19% svarer, at de er henholdsvis neutrale eller utilfredse. Tilfredshed med kvaliteten af konverteringen 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 29% 19% Meget tilfreds 71% Tilfreds 44% 0% 19% Hverken tilfreds eller utilfreds ODF OOXML 19% 0% 0% 0% Utilfreds Meget utilfreds OOXML ODF n = 21 n =21 Ved ikke = 4 (19%) Ved ikke = 5 (24%) n for figur = 17 n for figur = 16 Spørgsmål: Hvor tilfredse er I med kvaliteten af konverteringen af ODF? Hvor tilfredse er I med kvaliteten af konverteringen af OOXML? I forhold til konkrete former for funktionalitet, der kan være problemer med, svarer en enkelt, at der kan være problemer med formateringen, når man konverterer et OOXML-dokument. Fem respondenter nævner, at der er problemer med konkrete former for funktionalitet, når de konverterer et ODF-dokument. De problemer, som de nævner, er: #84586 v1 17

319 Bilagssamling Side 319 af 379 Bilag - Resultat af spøgeskemaundersøgelse Problemer med funktionalitet vedodf-konvertering % af respondenter Formattering 19% Tabeller 14% Indsatte statiske billeder og grafik 14% Skabeloner og makroer 14% Sidehoved og sidefod 10% Fodnoter og slutnoter 10% Nummererede lister og punktopstilling 10% Andet 10% Indsatte dynamiske elementer fra andre filformater 5% Sideopsætning 5% Automatisk genereret indholdsfortegnelse 5% Oprette og redigere tegning direkte i dokumentet 5% Rettighedsstyring 5% Metadata 5% Data hentet fra andre systemer 0% Versionering 0% Brevfletning 0% Høringsfunktion 0% Har ikke oplevet problemer med funktionalitet (udelukker andre 43% svar) Ved ikke (udelukker andre svar) 33% n = 21 Spørgsmål: Hvis I har oplevet problemer med funktionalitet ved modtagelse af ODF, så bedes I markere alternativt beskrive dem neden for. NB: Respondenterne har kunnet markere mere end én løsning 4.3. Brugernes produktivitet og tilfredshed 71% af respondenterne vurderer, at modtagelseskravet ingen betydning har haft for medarbejdernes produktivitet. 19% mener, at det har haft nogen indflydelse, mens 10% svarer Ved ikke. #84586 v1 18

320 Bilagssamling Side 320 af 379 Bilag - Resultat af spøgeskemaundersøgelse Eventuel negativ indvirkning på produktivitet Ingen indflydelse 71% Nogen indflydelse 19% Betydelig indflydelse 0% Ved ikke 10% Total 100% n = 21 Spørgsmål: Vurderer I, at modtagelseskravet har haft negative konsekvenser i forhold til produktiviteten blandt brugerne? % 13 ud af 21 respondenter (62%) har givet en vurdering af brugernes tilfredshed med løsningen. Af dem svarer 85%, at brugerne er enten tilfredse eller meget tilfredse med løsningen. Det samme gør sig gældende for brugernes tilfredshed med brugervenligheden - her svarer en enkelt dog, at brugerne er utilfredse. Brugernes overordnede tilfredshed med løsningen Brugernes tilfredshed med brugervenligheden 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 31% 54% 15% 0% 0% 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 31% 54% 8% 8% 0% Meget tilfreds Tilfreds Hverken tilfreds eller utilfreds Utilfreds Meget utilfreds Meget tilfreds Tilfreds Hverken tilfreds eller utilfreds Utilfreds Meget utilfreds n = 21 Ved ikke = 8 (38%) n i figur = 13 Spørgsmål: Hvor tilfredse er it-brugerne i alt med den løsning, som det har været muligt at tilbyde it-brugerne? n = 21 Ved ikke = 8 (38%) n i figur = 13 Spørgsmål: Hvor tilfredse er it-brugerne med bruger venligheden i den tilbudte løsning? #84586 v1 19

321 Bilagssamling Side 321 af 379 Bilag - Resultat af spøgeskemaundersøgelse 4.4. Opsummering af erfaringer Erfaringerne med modtagelseskravet - gengivet af respondenterne - er: - At de åbne dokumentformater udgør en meget lille andel af den samlede mængde dokumenter, som de statslige myndigheder modtager 4% samlet set. - At der er tilfredshed med kvaliteten af konverteringen af OOXML, men at der er nogle problemer med ODF. Her fremhæves fx formatering (19%) som et problem. - At man ikke har observeret en produktivitetsnedgang som følge af modtagelseskravet. - At der synes at være tilfredshed med løsningerne og deres brugervenlighed blandt brugerne. #84586 v1 20

322 Bilagssamling Side 322 af 379 Bilag 2 Spørgeskemaundersøgelse Tabeller og udsagn CONNECTING BUSINESS & TECHNOLOGY Devoteam Consulting. Kopiering og distribution kun tilladt fter aftale med Devoteam Consulting.