Forvaltningsstandarder for publisering av nettleserbaserte ... · 2. Valgfritt format PDF eller HTML utifra modenhet og behov 3. HTML, med obligatorisk utskrifts- og nedlastingsmulighet,

Forvaltningsstandarder for publisering av nettleserbaserte tjenester

Direktoratet for forvaltning og IKT

1 Sammendrag ................................................................................................................................... 4

2 Innledning ....................................................................................................................................... 6

2.1 Metode for informasjonsinnhenting ....................................................................................... 6

2.2 Om Difi sitt standardiseringsarbeid ......................................................................................... 7

3 Anvendelsesområde ..................................................................................................................... 10

3.1 Omfang ................................................................................... Feil! Bokmerke er ikke definert.

3.2 Avgrensning ........................................................................................................................... 10

3.3 Formål .................................................................................................................................... 11

3.4 Tidligere utredninger på området ......................................................................................... 12

4 Behov ............................................................................................................................................ 13

4.1 Bakgrunn ................................................................................................................................ 13

4.2 Nåsituasjon ............................................................................................................................ 13

4.3 Ønsket situasjon ..................................................................................................................... 14

5 Kartlegging .................................................................................................................................... 16

5.1 Identifiserte standarder ......................................................................................................... 16

6 Evaluering ...................................................................................................................................... 18

6.1 HTML ...................................................................................................................................... 18

6.2 PDF ......................................................................................................................................... 18

6.3 ODF ......................................................................................................................................... 18

6.4 OOXML ................................................................................................................................... 19

7 Ulike alternativer .......................................................................................................................... 20

7.1 Alternativ 1 ............................................................................................................................. 20

7.2 Alternativ 2 ............................................................................................................................. 20

7.3 Alternativ 3 ............................................................................................................................. 21

7.4 Alternativ 4 ............................................................................................................................. 21

7.5 Alternativ 5 ............................................................................................................................. 21

8 Konklusjon ..................................................................................................................................... 23

9 Anbefalt versus obligatorisk.......................................................................................................... 24

10 Økonomiske og administrative konsekvenser .......................................................................... 25

1 Appendiks A: Evaluering av identifiserte format .......................................................................... 26

1.1 HTML 4.01 (W3C 1999) og HTML5 ................................................................................. 26

1.2 XHTML 1.0 (W3C 2000) og XHTML 1.1 .......................................................................... 26

1.3 PDF (PDF 1.7, PDF/A-1, PDF/A-2, PDF/A-3) .................................................................. 36

1.4 ODF ......................................................................................................................................... 48

2 av 62


1.5 ISO/IEC 29500:2008 (OOXML) ............................................................................................... 56

3 av 62


1 Sammendrag Direktoratet for forvaltning og IKT (Difi) er fagansvarlig for hvilke IT-standarder som skal være anbefalte og obligatoriske i offentlig sektor, og forvalter med det innholdet i Forskrift om IT-standarder i forvaltningen og Referansekatalogen for anbefalte og obligatoriske IT-standarder i offentlig sektor.

I denne utredningen har Difi sammen med private og offentlige virksomheter sett nærmere på standarder for området publisering av nettleserbaserte tjenester. Med publisering menes i denne sammenheng formatet som benyttes for å tilgjengeliggjøre tjenester i nettlesere.

Offentlig sektor har som hovedmål å levere enkle og brukervennlige tjenester sett fra brukers ståsted, samtidig som rettssikkerhet og personvern ivaretas. I tillegg skal tjenestene leveres så effektivt som mulig. Det å standardisere måten nettleserbaserte tjenester publiseres kan bidra i å nå hovedmålet. Blant annet kan det bidra til følgende:

• Bruk av selvforklarende og enkle brukergrensesnitt • Tilgjengelighet til tjenestene på det utstyret brukeren har, og til det tidspunktet som

passer brukeren, samtidig som informasjonssikkerheten ivaretas. • Gjenbruk av informasjon brukeren allerede har avgitt til offentlig sektor og gjenbruk

av prosesser andre etater allerede har realisert. • Høy automatiseringsgrad i saksbehandling, samtidig som mulighet for å vise skjønn

ved behov og hensynet til brukere med manglende digital kompetanse blir ivaretatt. • Enkelt å sette krav ved anskaffelser

En forvaltningsstandard er ikke nok alene, men kan bidra til å gjøre dette mulig.

Difi har evaluert ulike versjoner av standardene HTML med scripting og CSS, PDF, ODF og OOXML, og konkludert med hvilke standarder som anses som egnet som forvaltningsstandarder for publisering av nettleserbaserte tjenester. Deretter har Difi sett på følgende sammensetninger av de mest egnede standardene:

1. Ingen krav 2. Valgfritt format PDF eller HTML utifra modenhet og behov 3. HTML, med obligatorisk utskrifts- og nedlastingsmulighet, ved bruk av CSS eller PDF. 4. HTML, med valgfri utskrifts- og nedlastingsmulighet, ved bruk av CSS eller PDF. 5. HTML, uten mulighet for manuell innsending.

Difi vurderer sammensetningen i alternativ 4 til å være best egnet som forvaltningsstandard.

Kort oppsummert er hovedargumentene for det anbefalte alternativet som følger:

• HTML er formatet med best støtte i ulikt brukerutstyr • HTML har best støtte for den funksjonaliteten offentlig sektor har behov for • Funksjonaliteten i HTML gjør det mulig for offentlige virksomheter å utvikle

tjenester som i størst mulig grad tilfredsstiller målene om brukervennlighet, gjenbruk av data og automatisering.

• Det er fortsatt et stort antall brukere som er ikke-digitale, så muligheten til å henvende seg ikke-digitalt eller via alternative kanaler bør være tilstede.

4 av 62


Dersom offentlige virksomheter skal møte regjeringens strategi om flere og bedre tjenester, frigjøre ressurser i tjenesteproduksjon og modernisering og avbyråkratisere tjenestene, vil en overgang til alternativ 4 være å anbefale.

For å sikre at digitaliseringen skal få en tydeligere retning hos alle offentlige virksomheter, og for å sikre mer og bedre samhandling for alle, bør standarden gjøres til en obligatorisk standard. Det bør være obligatorisk at alle nye tjenester baserer seg på standarden og alle eldre tjenester bør flyttes over i løpet av noen år.

Standardisering av publiseringsformat er ikke nok alene. Skal offentlige virksomheter realisere gevinstpotensialet ved å digitalisere, er det avgjørende at virksomhetene går gjennom dagens arbeidsrutiner og vurderer hvordan man ved å ta i bruk den nye teknologien kan lage nye rutiner som gir gode brukeropplevelser og effektiv tjenesteproduksjon, samt styrket rettssikkerhet og personvern.

5 av 62


2 Innledning Det finnes mange ulike definisjoner på tjenester tilgjengeliggjort brukeren via nettet, og vi har i denne utredningen valgt å benytte definisjonen «nettleserbaserte tjenester».

I regjeringens digitaliseringsprogram, som ble lagt frem i april 2012, satte regjeringen seg som mål at «all kommunikasjon med innbyggere og næringsliv på sikt skal være nettbasert. Som et tiltak for å oppnå dette, skal innbyggere og næringsliv kunne sende inn informasjon via nettet for alle tjenester som har over 3000 innsendinger årlig. Unntaket er tjenester der digitalisering ikke er hensiktsmessig verken for bruker eller forvaltning.»

Direktoratet for forvaltning og IKT har ansvar for å forvalte innholdet i Forskrift om IT-standarder i forvaltningen og Referansekatalogen for anbefalte og obligatoriske IT-standarder i offentlig sektor. I forvaltningsregimet ligger en jevnlig vurdering av behov for ytterligere krav og revisjon av eksisterende krav.

Denne utredningen vurderer behovet for å vedta nye krav til bruk av standarder på bruksområdet publisering av nettleserbaserte tjenester i offentlig sektor. Arbeidet er gjennomført i tråd med Standardiseringsrådets arbeidsmetodikk. Utredningen vil ligge til grunn for Standardiseringsrådets anbefaling til Difi om og i så fall hvilke standarder som bør gjøres anbefalte og obligatoriske på området. I tillegg til denne rapporten vil Standardiseringsrådet få tilgang til kommentarer til rapporten som har kommet inn på nettet og en eventuell anbefaling fra arbeidsgruppen som er satt ned for å bistå utredningsarbeidet.

Difi vil deretter på bakgrunn av Standardiseringsrådets anbefaling vurdere behovet for å utarbeide revidert utkast til Forskrift om IT-standarder og/ eller ny del-versjon av referansekatalog.

2.1 Metode for informasjonsinnhenting Utredningen baserer seg på informasjon hentet inn fra offentlige virksomheter og deres leverandører gjennom intervjuer, arbeidsgruppemøter og leverandørworkshop.

Sekretariatet for arbeidet har bestått av følgende personer:

• Jorid Bache Heggelund, Difi • Kristian Bergem, Difi • Marit Hagen, Difi • Ragnhild Haga, Difi

Det er satt ned en arbeidsgruppe for å bistå Difi i utredningen av standarder for publisering av nettleserbaserte tjenester. Arbeidsgruppen har bestått av representanter fra Oslo kommune, NAV, Politidirektoratet, Brreg, SKD og SSB

Difi har intervjuet følgende om problemstillingene: Brønnøysundregistrene, Bærum kommune, NAV, Oslo kommune og SSB.

Vi inviterte til åpen workshop hvor alle leverandører som ønsket var velkommen. De som møtte var fra Sem & Stenersen Prokom AS, More Software Solutions AS og Bekk Consulting AS.

6 av 62

http://www.regjeringen.no/nb/dep/fad/kampanjer/dan/regjeringen-stoltenbergs-digitaliserings/pa-nett-med-innbygerne.html?id=677791

http://www.standard.difi.no/forslag-og-saker/saker/standardiseringsraadets-arbeidsmetodikk


2.2 Om Difi sitt standardiseringsarbeid Forskrift om IT-standarder i offentlig forvaltning setter krav til hvilke standarder som er obligatorisk å benytte i forvaltningen. Referansekatalog for IT-standarder i offentlig sektor inneholder ikke bare obligatoriske krav, men også anbefalte krav til bruk av standarder. Det er ofte lurt å se anbefalinger og obligatoriske krav i sammenheng når man skal lage nye løsninger, og det anbefales derfor å benytte referansekatalogen som kilde. Referansekatalogen skal også oppsummere krav om bruk av obligatoriske IT-standarder fra alle generelle lover og forskrifter, slik at offentlige virksomheter kan finne én oversikt ett sted. Foreløpig er ikke denne oversikten total, men det jobbes med å komme dit. Referansekatalogen finner du på Standardiseringsportalen.

Difi er fagorganet som utarbeider det faglige grunnlaget for hvilke standarder som bør være anbefalte og obligatoriske i offentlig sektor. Difi vedtar hvilke standarder som skal være anbefalte og regjeringen vedtar hvilke standarder som skal være obligatoriske.

Standardiseringsrådet er et bredt sammensatt råd, bestående av medlemmer fra ulike offentlige virksomheter. Rådet leverer forslag til Difi om behov for justeringer i forskrift/referansekatalog. Justeringene kan være forslag til nytt innhold eller justering av eksisterende innhold i forskrift/referansekatalog. Alle utredninger Difi gjør på standardiseringsområdet, går gjennom rådet for å sikre en faglig kvalitet, bred støtte for vurderingene og relevans i forhold til virksomhetenes behov. Et godt fungerende Standardiseringsråd er en forutsetning for at Difi skal kunne gjennomføre det fagansvaret de har på standardiseringsområdet.

Det er Difi som etter samråd med Standardiseringsrådet leverer utredede og hørte forslag til nye versjoner av Forskrift om IT-standarder i forvaltningen til KMD, for beslutning i regjeringen.

Hvem som helst kan sende inn forslag om nye eller revisjon av eksisterende anvendelsesområder via forslagsskjema på Standardiseringsportalen. I tillegg har Difi en årlig vurdering av behovet for å revidere gjeldende krav.

I en revisjonsgjennomgang vurderes følgende: • Har det kommet nye versjoner av standardene som bør vurderes? • Har det kommet nye standarder på anvendelsesområdene som bør vurderes? • Har det kommet ny teknologi på områdene som fører til behov for alternative standarder? • Er det endrede behov i offentlige virksomheter, som får følger for gjeldende anbefalinger?

Ved utredning av et nytt område eller ved revisjon av et tidligere krav benyttes utredningsmetodikken.

2.2.1 Utredningsmetodikk Alle forslag som kommer inn vurderes etter følgende prosessmodell, uavhengig av om det er et forslag om revisjon eller nytt innhold.

Når et anvendelsesområde skal utredes i henhold til fase 3 i overordnet prosessmodell går man gjennom syv steg, som vist i figuren under. Stegene er behov, avgrense, kartlegge, evaluere,

Forslag Prioritering Utredning Behandling Beslutning Forvaltning

7 av 62

http://www.standard.difi.no/index.html


alternativer, valg og konsekvensvurdering. Utredningen gjennomføres av Standardiseringsrådets sekretariat, men deler av utredningen kan også settes ut til underleverandører. Noen ganger vil foreløpige vurderinger høres i en to ukers periode mellom fasene, for å få tilbakemeldinger så tidlig i prosessen som mulig.

Denne rapporten er utformet i tråd med de underliggende fasene i utredningsprosessen.

Utkast til rapporter tilgjengeliggjøres på Standardiseringsportalen for kommentarer underveis i prosessen, for kommentarer. Noen ganger legges utkast ut i flere omganger, men som et minimum legges ferdig rapport ut for kommentarer i tre uker i forkant av standardiseringsrådsmøtet, som skal behandle rapporten.

I tillegg legges nye versjoner av referansekatalogen, med ytterligere anbefalte standarder, ut på offentlig høring i minimum 5 uker i forkant av beslutning.

I tillegg legges nye versjoner av Forskrift om IT-standarder, med ytterligere obligatoriske krav, ut på 3 måneders høring i forkant av beslutning.

2.2.2 Anbefalte eller obligatoriske krav Når det er funnet frem til hvilken standard(er) som er best egnet for å være en forvaltningsstandard på et spesifikt anvendelsesområde, skal det vurderes om standarden(e) skal være anbefalte eller obligatoriske å følge for offentlige virksomheter, og de som kommuniserer med offentlig sektor. Følgende kriterier benyttes for å vurdere om en standard skal være anbefalt eller obligatorisk:

• En standard bør være obligatorisk, hvis pålegg om bruk av standarden er nødvendig for å tilfredsstille norske lover, regler eller politiske målsetninger

• En standard bør være obligatorisk, hvis det gir klare økonomiske, kvalitetsmessige eller sikkerhetsmessige fordeler at offentlig sektor konverterer til standarden samtidig og/eller på en koordinert måte

Behov •Behov er å definere de behov offentlig sektor har på et anvendelsesområde.

Avgrense

•Avgrense er å få oversikt over anvendelsesområdet, og presisere hva utredningen skal dekke/ ikke dekke.

Kartlegge

•Kartlegge er å få oversikt over hva som finnes av relevante standarder på anvendelsesområdet og deres knytning mot andre standarder og anvendelsesområder.

Evaluere •Evaluere er å finne ut om standarden er egnet som en forvaltningsstandard.

Alternativer

•Alternativer er å vurdere forskjellige sammensetninger av standarder som kan anbefales på anvendelsesområdet.

Valg •Valg er å velge et spesifikt alternativ og begrunne valget.

Konsekvens-vurdere

•Konsekvensvurdere er å beregne de kvalitative og kvantitative effektene i offentlig sektor av å gjennomføre valget som er tatt over

8 av 62


• En standard trenger ikke være obligatorisk hvis offentlige virksomheter tar dem i bruk av seg selv eller fordi de støttes i de fleste produkter

• Rask endring innen området kan tilsi at standardene på dette området bør være anbefalt fremfor obligatorisk.

9 av 62


3 Anvendelsesområde

3.1 Innledning I forprosjektrapporten «Standarder for nettleserbaserte tjenester» er det identifisert ulike delområder innen området nettleserbaserte tjenester. Figuren under er basert på den rapporten og gir et eksempel på hvordan et oppsett for å levere nettleserbaserte tjenester kan være. Her synliggjøres ulike delområder hvor det kan være aktuelt å sette anbefalte eller obligatoriske krav til bruk av standarder for offentlige virksomheter.

Figur 1 – Eksempel på arkitektur og formater for digitale løsninger der bruker bekrefter eller leverer informasjon via nettlesere

3.2 Omfang og Avgrensning I denne utredningen tar vi for oss delområdet publisering, det vil si formatet som benyttes for å tilgjengeliggjøre tjenesten i nettlesere. Dette er illustrert i figuren under. Vi tilstreber å ta høyde for behov fra andre delområder som også setter krav til de standardene som anbefales på området publisering. Det vil si at vi i denne rapporten for eksempel ikke vil diskutere overordnet arkitektur eller standarder for integrasjon, men det vil søkes å finne en standard for publisering som understøtter de krav mulige overordnede arkitekturer og automatisk integrasjon i bakkant vil gi.

10 av 62


Figur 1 – Eksempelarkitektur for nettleserbaserte tjenester og avgrensning

Utredningen vil anbefale hvilket format nettleserbaserte tjenester publiseres på, sett i lys av hvordan informasjonen fra innbyggeren behandles av virksomhetene. For eksempel er det mulig at en nettleserbasert tjeneste som skal publiseres for utskrift og manuell innsending bør ha et annet publiseringsformat enn en tjeneste hvor informasjonen skal håndteres og behandles elektronisk.

I og med at det her fokuseres på nettleserbaserte tjenester, vil standarder knyttet til tjenester levert gjennom «App-er» ikke favnes av denne utredningen. Tydelig og samordnet begrepsbruk er også viktig for gode nettleserbaserte tjenester, men dette ligger også utenfor denne utredningen.

3.3 Formål Det overordnede formålet med å publisere tjenester på nett er vist i figuren under. Her har vi beskrevet hva drivkreftene er, hva som er hovedmålet, hva som er delmålene og hvilke effekter man kan oppnå ut fra målet.

Figur 2 – Oversikt over drivkrefter, hovedmål, delmål og effekter

11 av 62


Offentlig sektor har som hovedmål å levere enkle og brukervennlige tjenester sett fra brukers ståsted, samtidig som rettssikkerheten ivaretas. I tillegg skal tjenestene leveres så effektivt som mulig.

Dette innebærer følgende:

• Selvforklarende og enkelt brukergrensesnitt • Tilgjengelighet til tjenestene på det utstyret brukeren har tilgjengelig og til det

tidspunktet som passer brukeren, samtidig som informasjonssikkerheten ivaretas. • Gjenbruk av informasjon offentlige virksomheter allerede har om brukeren (for

eksempel inntekt) og gjenbruk av prosesser andre etater allerede har realisert. • Høy automatiseringsgrad i saksbehandling, samtidig som mulighet for å vise skjønn ved

behov og hensynet til brukere med manglende digital kompetanse blir ivaretatt.

Informasjonen som fremkommer i brukerdialogen, bør ha tilstrekkelig grad av struktur, slik at den kan tas rett inn i korrekt fagsystem. Slik kan vedtak i størst mulig grad fattes basert på et forhåndsbestemt regelsett. I de tilfellene der det er behov for å vise skjønn må sakene automatisk kunne tildeles tilgjengelige saksbehandlere for manuell behandling. Automatisk integrasjon mot bakenforliggende systemer, fjerner forsinkelser i saksbehandlingstiden knyttet til manuelle rutiner for sending og registrering av innkommende og utgående informasjon. Automatisk regelstyrt behandling av saker der skjønn ikke er påkrevet, vil gi raskere saksbehandlingstid og frigjøre ressurser til andre oppgaver, og kan gi økt likebehandling og rettsikkerhet.

3.4 Tidligere utredninger på området Det er tidligere skrevet flere rapporter som grenser til dette området. Det gjelder rapporter knyttet utredning og revisjon av standarder for publisering av tekstdokumenter på offentlige nettsider. På høyre siden under anvendelsesområde på Standardiseringsportalen finnes en oversikt over forslag, pågående utredninger og historikk om tidligere utredninger. Se mer på http://standard.difi.no.

På området standarder for nettleserbaserte tjenester, er det skrevet en forprosjektrapport, for å identifisere og prioritere delområder, hvor det kan besluttes å fastsettes anbefalte og obligatoriske forvaltningsstandarder. Denne forprosjektrapporten identifiserte standarder for publisering av nettleserbaserte tjenester som det høyest prioriterte delområdet. Denne utredningen finnes også på Standardiseringsportalen: http://standard.difi.no/forslag-og-saker/saker/utredning-skjemastandarder.

12 av 62

http://standard.difi.no/

http://standard.difi.no/forslag-og-saker/saker/utredning-skjemastandarder

http://standard.difi.no/forslag-og-saker/saker/utredning-skjemastandarder


4 Behov

4.1 Bakgrunn Anvendelsesområdet i denne utredningen er publisering av nettleserbaserte tjenester. I regjeringens digitaliseringsprogram som ble lagt frem i april 2012 satte regjeringen seg som mål at forvaltningens kommunikasjon med innbyggere og næringsliv skal være nettbasert. På kort sikt skal virksomheten som et minimum tilgjengeliggjøre for eksterne brukere «alle relevante søknader, skjemaer og rapporteringer for digital utfylling og digital innsending.

Når vi i denne utredningen tar for oss behov ser vi det både fra offentlig sektors behov ved publisering av nettleserbaserte tjenester, og brukerens behov for at tjenesten er tilgjengelig og brukervennlig.

I kartleggingen av behov har Difi tatt utgangspunkt i nåsituasjonen slik den fremkommer gjennom intervjuer og andre kilder, og videre sammen med offentlige virksomheter sett på hvilke behov innbyggere, næringsliv og forvaltning vil ha fremover.

4.2 Nåsituasjon Difi har sett nærmere på ulike undersøkelser som måler nordmenns IKT-brukog IKT- ferdigheter. Når de eldste innbyggerne tas med i estimatene, anslår Difi at over 900 000 innbyggere kan ha utfordringer med å bruke offentlige digitale tjenester. Det er derfor viktig at tjenestene er tilpasset ulike brukeres teknologiske ferdigheter.

Difi har derfor i forbindelse med denne utredningen analysert hvilke grader av automatisering man grovt sett kan dele dagens publisering av nettleserbaserte tjenester inn i:

1. Skjema publisert på nett for utskrift, utfylling for hånd og innsending på papir rett til saksbehandlende enhet. Tastes inn lokalt i fagsystem.

2. Skjema publisert på nett, utfylling på skjerm (deler kan være pre-utfylt) med mulighet for midlertidig lagring lokalt, utskrift for så å sendes inn på papir til saksbehandlende enhet. Informasjonen kan tastes inn lokalt i fagsystem eller skannes. Innskannet dokument kan delvis struktureres ved hjelp av programvare som tolker innhold.

3. Skjema publisert på nett, utfylling på skjerm (deler kan være pre-utfylt) med mulighet for midlertidig lagring lokalt, så lastes det opp og sendes inn. Opplastede dokumenter kan være i ulike ustrukturerte formater, som for eksempel pdf, jpg og gif. Den elektroniske filen skannes ved mottak. Innskannet dokument kan delvis struktureres ved hjelp av programvare som tolker innhold. Her har vi samme mulighet for automatisering.

4. Skjema publisert på nett, fylles ut på skjerm (deler kan være pre-utfylt) med mulighet for midlertidig lagring lokalt, validering og umiddelbart resultat. Utfylt informasjon behandles på strukturert format (f.eks. XML). Informasjonen kan legges rett i fagsystem for full automatisk håndtering i etterkant.

5. Informasjon fremkommer via en dynamisk brukerdialog, der bruker får nye spørsmål avhengig av hva bruker allerede har svart, informasjonen kan lagres midlertidig og kan være delvis preutfylt. Informasjonen er strukturert. Mulighet for validering og umiddelbare resultater og tilbakemelding.

Det finnes altså ulike grader av automatisering i dag, og selv om skjemaer blir digitalisert som blant annet nettleserbaserte tjenester, er det fortsatt behov for et format som muliggjør utskrift dersom

13 av 62




man skal videreføre prosessen som beskrives i punkt 1 over. Punkt 2 og 3 kan innebære manuell håndtering av informasjonen av virksomhetene, og for tjenester med et visst volum vil dette kunne medføre større kostnader enn ved elektronisk innsending. Det er i offentlig sektor forholdsvis stor utbredelse av løsninger i kategoriene 1-3 over.

Virksomhetene har et behov for å lage og drifte kostnadseffektive og brukervennlige tjenester. I dette behovet ligger en balanse mellom brukervennlighet og effektivitet oppnådd gjennom avhengigheter og kompleksitet i bakenforliggende systemer og brukervennlighet og effektivitet oppnådd gjennom enkle og fleksible løsninger.

Difis kartlegging av behov bekrefter andre rapporters konklusjoner om at innbyggere opplever at offentlige virksomheter i for stor grad ber om den samme informasjonen som innbyggerne har oppgitt til andre virksomheter, eller informasjon som forvaltningen via ulike kanaler allerede har om innbyggerne. Med preutfylling blir brukeren presentert for informasjon om seg selv, og bekrefter denne informasjonen. Mellom tjenester internt i virksomhetene brukes preutfylling til en viss grad hos de fleste virksomhetene Difi har intervjuet.

Felles for alle elektroniske tjenester er at man må ha en mulighet for eventuelle avvik, som for eksempel nedetid. Hva skal brukerne gjøre hvis tjenesten ikke er tilgjengelig? Virksomhetene må definere hvilke frister som skal gjelde under normale omstendigheter, og hva som skal gjelde ved krisesituasjoner.

4.3 Ønsket situasjon Offentlig sektor har som hovedmål å levere enkle og brukervennlige tjenester sett fra brukers ståsted, samtidig som rettssikkerhet og personvern ivaretas. I tillegg skal tjenestene leveres så effektivt som mulig.

Kort oppsummert kan dette omfatte følgende hovedpunkter:

• Bruk av et selvforklarende og enkelt brukergrensesnitt

• Tilgjengelighet til tjenestene på det utstyret brukeren har, og til det tidspunktet som passer brukeren, samtidig som informasjonssikkerheten ivaretas.

• Gjenbruk av informasjon offentlige virksomheter allerede har om brukeren (for eksempel inntekt innhentet automatisk, eller informasjon brukeren selv har oppgitt tidligere), og gjenbruk av prosesser andre virksomheter allerede har realisert.

• Høy automatiseringsgrad i saksbehandling, samtidig som mulighet for å vise skjønn ved behov og hensynet til brukere med manglende digital kompetanse blir ivaretatt.

Det er viktig at offentlig sektor publiserer nettleserbaserte tjenester på et format og på en måte som gjør at de er tilgjengelig og brukervennlige for alle. Dette innebærer ikke bare at brukerne settes i sentrum når man designer tjenestene, men også at tjenestene er universelt utformet. For nye IKT-løsninger gjelder kravet om universell utforming fra 1. juli 2014. IKT-løsninger som er kjøpt eller bestilt etter denne datoen skal være universelt utformet fra lansering.

Valg av programvare/programvareplattform hos brukeren bør ikke få konsekvenser for tilgjengeligheten på de nettleserbaserte tjenestene. I dagens digitale samfunn bruker stadig flere

14 av 62


mobile enheter i tillegg til datamaskin. Det er viktig for brukeren at de nettleserbaserte tjenestene er tilgjengelige både på pc, lesebrett og mobil. Det er like viktig for offentlige virksomheter at deres løsninger når ut til innbyggere og næringsliv på alle disse plattformene, slik at flest mulig velger den digitale kanalen. Valg av et publiseringsformat som sikrer tilgjengelighet på tvers av plattformer og programvare er derfor sentralt for både innbyggere, næringsliv og offentlig forvaltning.

Som beskrevet i delkapittelet om nåsituasjonen opplever innbyggere at offentlige virksomheter ber om den samme informasjonen som offentlig sektor har fra før. Offentlig sektor har etterhvert mye informasjon om den enkelte innbygger, og flere informanter har påpekt at forvaltningen bør bruke denne informasjonen ved at enhver prosess starter med å presentere relevant informasjon forvaltningen allerede har og be om bekreftelse på at denne er riktig. Når det er gjort, kan man be om de ekstra opplysningene det er behov for.

Dersom man skal legge til rette for et mål om deling av data og prosesser på tvers av tjenester, kreves også standardisering av andre delområder, som for eksempel standarder for integrasjon. Valg av en standard for publisering av nettleserbaserte tjenester vil ikke løse dette, men det er viktig at en standard for nettleserbaserte tjenester ikke er til hinder for slik utveksling av informasjon på tvers av virksomheter.

Difi har intervjuet ulike virksomheter om bruk av ulike formater for publisering av skjema. Flere virksomheter formidlet at de ønsker å gå bort fra publisering i PDF-format og over til en elektronisk dialog hvor den nettleserbaserte tjenesten i større grad tilpasser seg hver enkelt bruker og dennes livssituasjon. Difi har også sammen med ulike virksomheter identifisert ulike muligheter som kan være relevante for et format for publisering av nettleserbaserte tjenester:

• Mulighet for å hente strukturert informasjon fra flere kilder, før og underveis (preutfylling, strukturert informasjonsinnhenting etc)

• Mulighet for sporvalg (at man får tjenesten tilpasset etterhvert som man svarer)

• Mulighet for å tilpasse tjeneste et sett med brukerpreferanser (f.eks. presentasjon på preferert målform eller sending av kvitteringer til valgt digital postboks)

• Mulighet til å lagre data og fortsette senere

• Mulighet for å sette tjenestene inn i en samhandlingsløsning

• Mulighet for å ivareta informasjonssikkerhet (tilgjengelighet, integritet og konfidensialitet)

• Mulighet for å skrive ut/ laste ned, fylle ut og sende inn for hånd

• Mulighet for innsyn i tidligere innsendt materiale og benytte som mal for ny innsending

• Mulighet for å få kvittering

• Mulighet for å validere at innholdet i et felt er av riktig type, før det sendes inn

• Mulighet for å håndtere ulike integrasjons- og innsendingsmåter

15 av 62


Disse mulighetene, og de ulike behovene som er identifisert, vil bli behandlet nærmere i evalueringen av de aktuelle standardene.

5 Kartlegging

5.1 Identifiserte standarder Difi har identifisert aktuelle standardene på området. Under følger en kort beskrivelse av disse, samt en oversikt over hvilke versjoner vi har sett på i denne utredningen:

HTML/XHTML HTML (HyperText Markup Language) er et markeringsspråk for formatering av nettsider med hypertekst og annen informasjon som kan vises i en nettleser. HTML benyttes til å strukturere informasjon og i noen grad utseende og semantikk i et dokument. XHTML er et eget språk som i utgangspunktet var en reformulering av HTML 4.01 ved bruk av XML (eXtensible Markup Language). Blant annet har XHTML strengere syntaksregler enn HTML. HTML/XHTML spesifikasjonene forvaltes av World Wide Web Consortium (W3C). Følgende aktuelle versjoner: HTML 4.01 og HTML 5.0, XHTML 1.0 og XHTML 1.1.

ePub ePub er en fri og åpen ebok-standard. Tekst i ePub-dokument er designet for å beholde leservennlighet uavhengig av skjerm og tilpasse seg skjermer med forskjellig orientering, skjermstørrelse og skjermoppløsning. Standarden forvaltes av International Digital Publishing Forum (IDPF) ePub er hovedsakelig beregnet for lesing, så dette formatet vil vi ikke evaluere nærmere da det ikke er egnet til formålet publisering av nettleserbaserte tjenester. Er nå i versjon 3.0

XForms Et XML format for å samle inn input fra webskjemaer. Dette formatet vil vi ikke evaluere nærmere da det ikke er egnet til formålet publisering av nettleserbaserte tjenester.

PDF Portable Document Format (PDF) er et åpent digitalt dokumentformat utviklet av Adobe Systems. Formatet viser filene i samme form på skjermen som når de printes ut. PDF er hovedsakelig et distribusjonsformat for visning på skjerm, utskrift og trykk. Kommer i mange versjoner. De eldre mest brukte og de nye er: 1.3, 1.4, 1.5, 1.6 og 1,7 samt PDF A1, A2 og A3.

ODF Open Document Format for Office Application (ODF) er et åpent XML-basert filformat for tekstdokumenter, regneark, diagrammer osv. ODF utvikles og vedlikeholdes av OASIS (Organization for the Advancement of Structured Information Standards). Enkelte versjoner av formatet har blitt fremmet og vedtatt som ISO-standarder. Finnes i versjon 1.0, 1.1 og 1.2.

OOXML Office Open XML (OOXML) er en betegnelse på et XML-basert filformat utviklet av Microsoft for å gi ett fritt og åpent alternativ til det tidligere binære Microsoft Office filformat. Dette formatet ble først vedtatt av ECMA og senere som en ISO standard. (MS doc er det tidligere binære Microsoft formatet for et format for tekstdokumenter. Formatet har etter utbredt prøving og feiling fått god interoperabilitet i ulike brukerprogramvare, men det er en proprietær standard som ikke vil bli

16 av 62


evaluert her.) Finnes i ECMA 376 og i senere versjon som ISO/IEC 29500 Transitional, and ISO/IEC 29500 Strict. Der Transitional har støtte for tidligere binære versjoner, mens Strict ikke har det. Tilstøtende standarder:

CSS Cascading Style Sheet (CSS) er et språk som benyttes til å definere formatering og utseende på filer i skrevet i HTML eller XML. CSS beskriver oppsett, farger og annen stilinformasjon. Fra og med versjon 2 er det mulig å definere ulik stil for det samme dokumentet avhengig av hvor og hvordan det blir brukt. (mobil/PC/utskrift/visning på storskjerm). Det finnes ulike versjoner av CSS, versjon 1, 2, 2.1 og 3.

ECMAScript (JavaScript) ECMAScript er et komplett programmeringsspråk som kan kjøres i alle nettlesere. ECMAScript gjør det blant annet mulig å tilføre dynamiske elementer til nettsider. Vanlige bruksområder er å bytte ut, fjerne eller legge inn tekst, skifte fokus i et skjema, og å åpne pop-up-vinduer. De fleste nettlesere har gjennomført tester og støtter ECMAScript 5.1. W3C DOM Document Object Model er en beskrivelse av hvordan en HTML eller XML struktur er representert. Vi peker her på W3C versjonen av DOM.

JQuery jQuery er et JavaScript-bibliotek utviklet for å forenkle klientskripting av HTML. Det er fri, åpen programvare, og det mest populære JavaScript-biblioteket i bruk.

“Feature detection”, “Graceful degradation” og “Progressive enhancement” «Feature detection» er en funksjon som tester nettleseren brukeren er på, og rapporterer tilbake om hva leseren er og ikke er i stand til. Som utvikler kan man bruke denne informasjonen til å tilpasse nettstedet deretter. Man kan for eksempel få vite at den besøkendes nettleser ikke støtter visse CSS3 funksjoner. «Graceful degradation» og «Progressive enhancement» er to hovedkategorier av tilnærminger som brukes for å støtte de ulike typene enheter (pc, mobil, lesebrett) og nettlesere. Dette kan være nyttige funksjoner, men vi vil foreløpig ikke få videre for å standardisere på noe av dette.

17 av 62


6 Evaluering Dette kapittelet er en kort oppsummering av formatene i lys av den evalueringen som er gjort i vedlegg 1, i henhold til de kriterier som er definert i arbeidsmetoden.

6.1 HTML HTML er et fleksibelt format som gjør det mulig å lage gode universelt utformede nettsider, med all den funksjonalitet man trenger. Formatet gjør det mulig å hoppe helt over de tingene som ikke skal besvares av brukeren. Formatet gjør det mulig med pre-utfylling, og kan hente opp informasjon underveis i dialogen. Ved bruk av CSS er det også mulig å lage løsninger som i stor grad understøtter utskrift med ønsket format, men dette kan også løses i form av parallell-publisering i PDF. HTML kan konverteres til PDF også direkte i nettleser ved hjelp av HTML5 og scripts, som for eksempel illustrert her: http://mrrio.github.io/jsPDF/ .

HTML har fleksible måter å legge inn ulike valgmuligheter og kan tilby hjelpetekster uten at disse trenger å forstyrre dialogen når det ikke er behov. Formatet er klart best egnet i forhold til å tilpasse seg ulike skjermstørrelser. HTML er støttet på de aller fleste plattformer både på utviklingssiden og bruker siden.

HTML er et format som er modent og har satt seg over lang tid, men er nå i en ny fase med HTML5, CSS og Javascript. Utfordringen er at HTML5 foreløpig ikke er vedtatt. WhatWG som jobber med utvikling av HTML5 inkluderer alle nettleser-utviklerne, og standarden er derfor implementert selv om den ikke er ferdig utviklet. Det at den er implementert i alle nettlesere betyr derimot ikke at den er implementert overalt, det er kontorstøtteprogramvare, konverteringsverktøy og støtteverktøy for funksjonshemmede. Slik type programvare er ikke nødvendigvis tilpasset HTML5 enda. Det er derimot mulig å benytte HTML5 innenfor de rammer HTML4.01 gir og det åpner for en glidende overgang.

Egnet som forvaltningsstandard på området

6.2 PDF PDF har mye funksjonalitet som gjør at det også benyttes som publiseringsformat til nettleserbaserte tjenester. I PDF vil derimot det meste være synlig. Man kan ha sporvalg, hjelpetekster og ulike menyer for valgmuligheter, men man har ikke mulighet til å skjule for eksempel de spørsmålene som ikke er relevante for brukeren. Det er også muligheter for pre-utfylling i PDF, men her er det større begrensninger enn det man har i HTML. PDF kan gi samme mulighet til å strukturere data som en tjeneste publisert i HTML gir, og informasjonen kan også høstes inn automatisk, men dette er mer krevende for en tjeneste publisert i PDF enn i HTML. PDF er laget for å ta vare på formatet og egner seg veldig godt for publisering av informasjon som skal skrives ut. PDF har klare svakheter i forhold til ulike mobile enheter med forskjellig skjermstørrelse.

Delvis egnet som forvaltningsstandard på området

6.3 ODF Dette er et format som er laget for redigerbare dokumenter og som slik sett er egnet til å fylle ut. Formatet understøtter derimot ikke den samme fleksibiliteten når det gjelder funksjonalitet som det

18 av 62

http://mrrio.github.io/jsPDF/


HTML gjør. Her kan ikke hjelpetekster, valgmuligheter og sporvalg styres like fleksibelt som i HTML, og man har ikke de samme enkle mulighetene til å konvertere til ulike formater i bakkant.

ODF tar ikke vare på formateringen på samme måte som f.eks. PDF, og egner seg slik sett dårlig for utskrift. ODF har mer begrenset støtte i ulike verktøy for generering og har dårligere støtte ute i brukerprogramvare, særlig på nye typer mobile enheter. Det er også utfordringer knyttet til forskjellige implementasjoner av standarden, som gjør at det kan bli feil når det skrives i en kontorstøtteprogramvare og leses i en annen.

Ikke egnet som forvaltningsstandard på området

6.4 OOXML OOXML er et format med større funksjonalitet og flere muligheter enn det som finnes i ODF. OOXML har derimot mange av de samme begrensningene som ODF i forhold til bruk for nettleserbaserte tjenester, både når det gjelder utskrift og utbredelse i ulik programvare og på ulike plattformer.

Ikke egnet som forvaltningsstandard på området

19 av 62


7 Ulike alternativer Difi mener at følgende sammensetninger av standarder er de fem mest aktuelle på området publisering av nettleserbaserte tjenester.

1. Ingen krav 2. Valgfritt format PDF eller HTML utifra modenhet og behov 3. HTML, med obligatorisk utskrifts- og nedlastingsmulighet, ved bruk av CSS eller PDF. 4. HTML, med valgfri utskrifts- og nedlastingsmulighet, ved bruk av CSS eller PDF. 5. HTML, uten mulighet for manuell innsending.

Regjeringen ønsker flere og bedre elektroniske tjenester til innbyggere og næringsliv, og elektroniske tjenester som frigjør ressurser i tjenesteleveransene. Hvilket alternativ understøtter dette best?

7.1 Alternativ 1 – ingen krav Mange offentlige virksomheter mangler gode beskrivelser av arbeidsrutinene sine og jobber ikke systematisk med forbedring av rutinene. Mange av tjenestene de leverer er ikke elektroniske eller baserer seg på elektroniske løsninger som ikke er optimale. Noen har derimot kommet langt i forvaltningsutviklingsarbeidet og vist hvordan man kan oppnå store forbedringer ved rett bruk av den nye teknologien. Våre vurderinger baserer seg mye på disse foregangsetatenes erfaringer.

HTML kombinert med CSS og script har bredere funksjonalitet og er mer fleksibelt enn de løsninger mange offentlige virksomheter benytter i dag, men bruk av HTML krever sannsynligvis også mer av virksomhetene som bygger tjenester. Difi er av den oppfatning at det å lage brukervennlige og gode elektroniske tjenester er et viktig virkemiddel for å fornye offentlig sektor. Nettopp det å benytte ekstra ressurser på å dokumentere arbeidsrutiner og forbedre dem på bakgrunn av nye behov og ny tilgjengelig teknologi er nettopp det som skal til for å skape den fornyelsen vi trenger. Det er derimot viktig og ikke sette krav som gjør at virksomhetene velger «å sette strøm» på dagens løsninger i stedet for å gjennomføre fornuftig forvaltningsutvikling. Vi tror at ved å stille krav til et egnet publiseringsformat kan Difi bidra til at offentlig sektors beveger seg i riktig retning. Alternativ 1 – ingen krav anses derfor som lite aktuelt.

7.2 Alternativ 2 Dette alternativet er fleksibelt i forhold til offentlige virksomheters modenhet. Ikke alle er like modne når det gjelder å lage elektroniske tjenester til brukerne, og alternativet åpner for at man kan velge format ut i fra hvor moden virksomheten er.

I dette alternativet kan virksomhetene selv velge om de ønsker å publisere hver enkelt tjeneste på PDF eller HTML-format kombinert med CSS og scripts. For eksempel kan man se for seg at enkelte virksomheter kan ønske å publisere tjenester med svært få brukere på PDF-format istedenfor HTML. Ved at virksomhetene selv kan velge å benytte PDF- eller HTML-formatet, i de tilfellene de selv finner det hensiktsmessig, kan man unngå at tjenester med svært få brukere ikke tilgjengeliggjøres elektronisk i det hele tatt fordi de finner det kostnadskrevende å gjøre det på HTML-formatet. På den annen side vil kanskje enkelte virksomheter i større grad benytte PDF til «å sette strøm» på dagens skjema og det er ikke ønskelig. Forskjellen mellom Alternativ 1 og Alternativ 2 er ikke så stor, siden de fleste virksomheter bruker enten PDF eller HTML i dag. Ved å gå for dette alternativet vil vi ikke oppnå et trykk for gjennomføre en ordentlig forvaltningsutviklingsprosess, der offentlige virksomheter går gjennom og forbedrer rutinene sine i stedet for å legge ut eksisterende

20 av 62


papirskjema på PDF-format. Alternativ 2 vil således gi lite retning på digitaliseringsarbeidet, og anses derfor ikke som aktuelt.

7.3 Alternativ 3 I dette alternativet er det et krav om at alle digitale tjenester skal publiseres på HTML-formatet. Det er også et krav at brukeren skal ha nedlastings- og utskriftsmulighet på PDF eller CSS.

I møte med private aktører fikk Difi informasjon om en brukertest som viste at brukere som først begynner å ta i bruk tjenester publisert på HTML, gjerne fortsetter med dette fremfor PDF. HTML-formatet gir tjenesteeiere og leverandører større funksjonalitet til å designe brukervennlige og tilpassede tjenester enn hva PDF-formatet gir. I tillegg er tjenester tilgjengeliggjort på HTML tilgjengelig på mer brukerutstyr og på en bedre måte på mer brukerutstyr enn det PDF er. Ved i tillegg å kreve utskrift- og nedlastningsmulighet på PDF eller CSS er tanken at man også ivaretar behovene til de brukerne som av ulike årsaker ønsker å samhandle med forvaltningen med manuelle metoder. Det vil gi ekstrakostnader og måtte tilrettelegge for utskrift/ nedlasting på denne måten. Dette er et godt alternativ.

7.4 Alternativ 4 I dette alternativet skal også alle digitale tjenester publiseres på HTML-formatet. Det er imidlertid ikke et krav om nedlastings- og utskriftsmulighet på PDF eller CSS, men en valgmulighet. Det er fortsatt mange innbyggere i Norge som har lavere digital kompetanse, og disse må også kunne samhandle med forvaltningen. Spørsmålet er om disse brukerne vil benytte seg av utskriftsmuligheten, og om det å tilrettelegge en slik løsning er det beste tiltaket for å hjelpe de med lavere digital kompetanse. Kanskje er personlig oppmøte og veiledning et bedre alternativ for noen, og virksomhetene slipper å ha parallelle løsninger der de ikke ønsker dette. I tillegg har ELMER, som allerede er en forvaltningsstandard, ikke lenger inkludert utskriftsmulighet i sin standard. Alternativ 4 er således mer i tråd med ELMER enn Alternativ 3. Alternativ 4 overlater til virksomhetene selv å analysere behovene til sine brukergrupper når det kommer til nedlastings- og utskrift. Dette er et godt alternativ.

7.5 Alternativ 5 Dette alternativet stiller krav til at de digitale tjenestene skal være publisert kun på HTML-format. Det å redesigne og utvikle alle tjenester for å kunne publisere dem som HTML kan ha en høy kostnad for mange virksomheter og kan innebære en videreutvikling av arbeidsrutiner. Det kan derfor være nødvendig å gjøre dette arbeidet over litt tid. Helintegrerte løsninger, som er enklere å få til med HTML, vil gi bedre datakvalitet og vil åpne for større automatiseringsgrad og dermed bidra til å redusere behovet for saksbehandlingsressurser i offentlig sektor.

Bruk av PDF som publiseringsformat på nettleserbaserte tjenester vil også kunne gi gevinster, spesielt for brukerne. En overgang fra papirbaserte tjenester til bruk av PDF-baserte tjenester vil også gi raskere saksbehandlingstid. Dersom flere tjenester kan gjøres del-automatiserte raskere, fordi Difi også åpner for å publisere på PDF-formatet, så vil dette være en fordel for offentlig sektor. Det kan derimot også bli et fordyrende mellomledd i utviklingen.

Skal vi over tid få de beste elektroniske løsningene, trenger vi offentlige virksomheter som har kompetanse på tjenesteutvikling ved bruk av HTML kombinert med CSS og scripts, og som tilrettelegger for hel-automatiske tjenester (med mulighet for å sile ut saker med behov for

21 av 62


skjønnsvurderinger). Ved å sette krav til at man bare kan bruke HTML, og at man ikke kan sende inn besvarte skjemaer til forvaltningen per post eller epost, vil denne prosessen fremskyndes. I tillegg vil en ren HTML-løsning sette sterke krav til brukervennlighet for å favne alle, noe som kan være en fordel, fremfor å lage en særløsning for de med mindre digital kompetanse. Alternativet er et godt alternativ.

22 av 62


8 Konklusjon Regjeringen ønsker flere og bedre elektroniske tjenester til innbyggere og næringsliv, og elektroniske tjenester som frigjør ressurser i tjenesteleveransene.

Difi er av den oppfatning at det å lage brukervennlige og gode tjenester elektronisk er et viktig virkemiddel for å fornye offentlig sektor. Ved å stille krav til et egnet publiseringsformat kan Difi bidra til at offentlig sektors elektroniske tjenester beveger seg i riktig retning. Både alternativ 3, 4 og 5 stiller krav til at HTML alltid skal brukes. HTML har bredere funksjonalitet og er mer fleksibelt enn PDF, men bruk av HTML krever sannsynligvis også mer av virksomheter som bygger tjenester. Skal vi over tid få de beste elektroniske løsningene, trenger vi imidlertid offentlige virksomheter som har kompetanse på tjenesteutvikling ved bruk av HTML, og som tilrettelegger for automatisering av tjenester og tilpasset samhandling med brukerne.

Alternativ 1 og 2 anses i denne sammenhengen som lite aktuelt, siden alternativene innebærer liten endring i forhold til dagens praksis. Det kan argumenteres med at alle virksomheter trenger å gå steget om PDF-tjenester, men det er en høy og unødvendig kostnad å lage PDF-løsninger på veien mot bedre og mer tilgjengelige tjenester i HTML. En forvaltningsutviklingsprosess, som vi antar i større grad vil vurderes som nødvendig ved en overgang til HTML, vil også i mange tilfeller kunne fjerne unødvendig byråkrati. Brønnøysund registrene har for eksempel i en av sine fornyingsprosesser, forenklet en tjeneste fra over 60 skjema til 2. Dette viser nytten av å gå gjennom en grundig forvaltningsutviklingsprosess i stedet for «å sette strøm» på over 60 papirskjema, for deretter på et senere tidspunkt å gjennomføre forvaltningsutviklingsprosessen (Erfaring tilsier at flere av de som velger å lage PDF-løsninger enn de som lager HTML-løsninger «setter strøm på» eksisterende skjema). Difi mener det er behov for fornying nå, og at det er behov for å gi retning i de anbefalinger/krav som skal gis. Alternativene 1 og 2 bør derfor ikke velges.

Forskjellen på alternativ 3 og 4 er kravet om utskrifts- og nedlastingsmulighet. I alternativ 4 er dette kun en anbefaling. Alternativ 5 åpner ikke for muligheten til å skrive ut/ laste ned spørsmålene fra den nettleserbaserte tjenesten, besvare dem og sende dem inn verken per post eller epost. Difi er av den oppfatning at virksomhetene selv kjenner sine brukergruppers behov for utskrift og nedlasting best. I tillegg kan det være vel så hensiktsmessig å tilby de med manglende digital kompetanse bedre veiledning gjennom telefon/ chat eller ved personlig oppmøte i stedet for å tilrettelegge for manuell innsending. Dette krever derimot modenhet av virksomheten og den vet de best selv om er til stede. Difi vurderer derfor alternativ 4 som det mest hensiktsmessige av disse tre alternativene. Men ønsker å gå i retning av alternativ 5.

Kort oppsummert er hovedargumentene for alternativ 4 som følger: 1. HTML kombinert med CSS og script har best støtte på ulikt brukerutstyr 2. HTML kombinert med CSS og scripts har best støtte for funksjonaliteten offentlig sektor trenger 3. HTML er formatet som i størst mulig grad bidrar til at offentlige virksomheter utvikler tjenester i

riktig retning, og med integrasjon mot bakenforliggende systemer 4. Bruk av HTML underbygger den samhandlingsarkitekturen det er lagt opp til i offentlig sektor

med HTML som sikker kanal inn, og digital postkasse tjeneste som digital ut kanal 5. Det er fortsatt er et stort antall brukere som har lavere digital kompetanse, så muligheten til å

henvende seg ikke-digitalt eller via alternative kanaler bør være der

Difi vurderer derfor alternativ 4 til å være best egnet.

23 av 62


9 Anbefalt versus obligatorisk Vurdering av om standarder på anvendelsesområdet publisering av nettleserbaserte tjenester skal være anbefalt eller obligatorisk gjøres etter kriteriene beskrevet i kapittel 2.3.2.

En felles standard for publisering vil bidra til å gi riktig retning på digitaliseringen i offentlig sektor. Rett krav vil bidra til mer tilgjengelige tjenester fra offentlig sektor som vil fungere på ulikt brukerutstyr. Digitale tjenester som er mer brukervennlige, personalisert og hvor informasjon offentlig sektor allerede besitter lettere kan gjenbrukes. Bruk av HTML understøtter politiske målsetninger om mer og bedre samhandling. Det å sette et obligatorisk krav vil derfor understøtte politikken om å fornye og avbyråkratisere offentlig sektor.

En felles standard for publisering vil legge til rette for automatisering og effektivisering av tjenesteproduksjonen. Noe som vil gi store samfunnsøkonomiske besparelser. Det er viktig å unngå krav som gjør det enkelt å gjenskape dagens rutiner i ny teknologi, men heller sette krav som oppfordrer til at virksomhetene utnytter den nye teknologiens muligheter til å fornye offentlig sektor. Rett krav til publiseringsstandard for nettleserbaserte tjenester kan etter Difi sin oppfatning bidra til økte samfunnsøkonomiske besparelser, selv om kravet alene ikke er nok til å skape forandring.

Alternativ 4 bør gjøres obligatorisk for i så stor grad som mulig å underbygge de politiske målsetninger og for å sikre flest mulig samfunnsøkonomiske besparelser.

24 av 62


10 Økonomiske og administrative konsekvenser Hovedgevinsten ved å bli digital er i hovedsak knyttet til forvaltningsutvikling og er fristilt fra standardiseringen. Den standarden som her foreslås vil derimot tilrettelegge og i en viss grad legge press på virksomhetene til å gjennomføre forvaltningsutvikling. Andre gevinster ved å standardisere som foreslått, vil være å tilrettelegge for økt brukervennlighet, økt mulighet for automatisering og økt gjenbruk av informasjon. Standardisering av publiseringsformat for nettleserbaserte tjenester vil kunne gi større mulighet for å bruke tjenester på alle typer utstyr.

Kostnadene ved å implementere en ny digital tjeneste på en spesifikk standard vil først og fremst være knyttet til prosessen med å planlegge, designe, utvikle, tilgjengeliggjøre og drifte tjenester digitalt. Kostnadene knyttet til dette vil kunne være avhengig av hva som velges som publiseringsstandard. Sentrale kostnadselementer i digitaliseringen og standardiseringen vil kunne være:

• Behov for kompetanseheving av ansatte • Gjennomgang av dagens rutiner, forbedringer og prosessmodellering av nye rutiner • Implementering av nye rutiner i tjenester • Kostnader til drift og vedlikehold

Besparelsene vil kunne være: • Lavere porto- og utskriftskostnader • Raskere saksbehandlingstid • Raskere saksbehandling ved færre feil og mindre behov for å sende frem og tilbake • Økt automatisering med påfølgende ressursbesparelser i manuell behandling • Mer brukervennlige tjenester, tilgjengelig for brukeren på det utstyret brukeren har og på

det tidspunktet brukeren ønsker å ta i bruk tjenesten. • Enklere offentlig sektor gjennom økt gjenbruk av informasjon som allerede er innsendt.

Her synliggjøres kost/ nytte elementer for digitalisering av offentlige tjenester. En kost/ nytte som antas å være svært positiv. Det er vanskelig å peke på hvor stor effekt den ekstra funksjonaliteten og den ekstra tilgjengeligheten man oppnår ved å velge rett standard vil utgjøre, men den vil bidra på en positiv måte og gi retning på det arbeidet offentlig sektor skal gjøre.

Den helt konkrete forskjellen på å utvikle en tjeneste på rett måte i PDF og HTML er vanskelig å anslå. Trolig krever det forholdsvis lik kompetanseutvikling i en virksomhet skal man lage gode tjenester i både PDF og HTML. De som lager tjenester i PDF i dag, gjør ofte dette med begrenset funksjonalitet og derfor med begrenset kompetanse, med noen få unntak. Årsaken til at virksomheter har hatt behov for kompetanseheving ved overgang til HTML-tjenester, er i hovedsak fordi de i den sammenheng har begynt å lage mer avanserte tjenester. Vi har ikke noe grunnlag for å slå fast at det ene formatet gir billigere eller dyrere drift av en tjeneste, men antar at HTML vil gi noe mer fleksibilitet og skalerbarhet enn PDF. Hovedforskjellen mellom de to formatene vil ligge i tilgjengeligheten for brukerne som gir gevinst for dem, og den ekstra funksjonaliteten som gjør det enklere å utvikle avanserte tjenester og integrere dem mot bakenforliggende system.

25 av 62


Appendiks A – revisjon av formater for nettleserbaserte tjenester

1 Appendiks A: Evaluering av identifiserte format Dette vedlegget evaluerer de formatene som er funnet interessante å gå videre med i kapittel 5, kartlegging, i hoveddokumentet. Evalueringen skjer iht. kriterielisten i kapittel 5.2 i Standardiseringsrådets arbeidsmetodikk, som beskriver hva som skal til for å utrede en ny forvaltningsstandard.

Følgende liste av formater blir evaluert i dette vedlegget:

• PDF 1.7 • PDF/A-1 • PDF/A-2 • PDF/A-3 • HTML 4.01 (W3C 1999) • XHTML 1.0 (W3C 2000) • XHTML 1.1 • HTML 5.0

1.1 HTML 4.01 (W3C 1999), XHTML 1.0 (W3C 2000), XHTML 1.1 og HTML5

1.1.1 Hva er formålet med standardene?

1.1.1.1 Hva er hensikten ved å ta standarden i bruk? HTML, HyperText Markup Language, er et åpent, avgiftsfritt formateringsspråk benyttet for å strukturere informasjon som tekst og bilder på nettsider. HTML gir funksjoner, struktur og rekkefølge til en tekst, det vil si om det er en overskrift, et vanlig tekstavsnitt, en tabell, en punktliste eller en lenke til en annen tekst. HTML-tagger for tekstens funksjon refererer til der selve utseende styres, det avgjør egenskaper som skrifttype, størrelse, justeringer, farge og så videre. Dette skillet mellom funksjon og utforming er spesielt viktig der man ønsker frihet til å bytte utseende uten å endre på hva som skal være overskrift og hva som skal være vanlig tekst, eller sørge for at hypertekst opprinnelig laget med tanke på pc-er også skal være leselig på enheter med andre typer skjermer, som nettbrett og mobiltelefoner.

Per i dag er det versjon 4.01 av HTML som er siste vedtatte standard hos W3C, men HTML 5, vil trolig bli vedtatt i løpet av året. Mens HTML 4.01 ble utviklet i en tid med fokus på statisk informasjon, er HTML5 utviklet med fokus på interaksjon og multimediainnhold. HTML5 blir nå utviklet av WHATWG, med fokus på å utvide HTML for å kunne lage applikasjoner i nettleser. Dette forutsetter samspill med CSS og Scriptspråk (for eksempel ECMAScript). HTML har blitt utviklet kontinuerlig siden lansering tidlig på 90-tallet. Imidlertid gir ikke HTML4 i følge W3C nok informasjon til dagens behov for samhandling. Arbeidet med den nye HTML spesifikasjonen (W3C HTML5 specification, W3C HTML5.1 specification, og WHATWG HTML standarden) ble påstartet i 2004, og W3C oppsummerer på nettsiden http://www.w3.org/TR/html5-diff/#history følgende hovedelelementer:

26 av 62

http://www.w3.org/TR/html5-diff/%23history


1. Definerer ett språk (HTML) som kan skrives med både HTML syntaks og XML syntaks. 2. Definerer detaljerte metoder for prosessering for økt interoperabilitet 3. Forbedrer markup for dokumenter 4. Introduserer markup og APIer for blant annet nettapplikasjoner

1.1.1.2 Hvilket nedslagsfelt/bruksområde har standarden? For publisering av innhold på nett er per i dag HTML det mest tilgjengelige og utbredte formatet.

I henhold til forskrift er det obligatorisk for alle offentlige virksomheter i Norge å benytte HTML 4.01 (W3C 1999) eller XHTML 1 (W3C 2000) som primærformat ved publisering av dokumenter med tekstlig innhold på offentlige nettsteder1. I tillegg er det i revisjonsnotat foreslått å godkjenne XHTML 1.1.

XHTML ble innført for å følge de mer stringente XML reglene, for å gjøre det enklere å behandle og prosessere innholdet. Det har man derimot gått bort i fra igjen, fordi det bryter med det grunnleggende prinsipp på Internett om å være så fleksibel som mulig og i størst mulig grad forsøke å vise alle sider.

HTML5 er i hovedsak utviklet for å fornye internettstandarden med mer støtte for interaksjon og multimediainnhold. Standarden er laget for å understøtte Internett 2.0 og den økende utviklingen av nye IT-løsninger.

Nedslagsfeltet for standarden er hele verden.

1.1.2 Prosessen rundt utvikling og forvaltning av standarden

1.1.2.1 Har utviklingen av standarden vært en åpen prosess der alle interessenter har kunnet delta på en ikke diskriminerende måte?

HTML-standarden er utviklet av IETF(Internet Engineering Task Force), som utvikler og promoterer internettstandarder, i nært samarbeid med W3C og standardiseringsorganisasjonene ISO og IEC. Siden har HTML-spesifikasjonene blitt opprettholdt av W3C og standarden er nå en internasjonal standard (ISO/IEC 15445:2000).

Videreutviklingen av HTML standarden i W3C har gått noe tregt og mange av aktørene har ønsket økt tempo i utviklingsarbeidet. På bakgrunn av dette ble det etablert en ny arbeidsgruppe kalt WHATWG (Web Hypertext Application Technology Working Group). Denne gruppen består i hovedsak av nettleserleverandører. Gruppen har utviklet HTML5 kontinuerlig. Her blir nye elementer testet underveis av en rekke leverandører og man forsikrer seg om at spesifikasjonen fungerer i praksis, før den blir lagt inn i standarden.

W3C har annonsert «last call» for den eksisterende versjonen av HTML 5, 17. juni 2014 med frist 15. juli 2014. Det forventes at standarden skal bli godkjent som en endelig Recomandation i løpet av året.

HTML 4.01 har dannet en plattform for innovasjon, men det har kommet mange tilleggskrav til plattformen som nå trengs å fylles. Når vi skriver denne utredningen er HTML5 fortsatt ikke definert som en ferdig standard.

1 Varianten strict bør benyttes av tilgjengelighetsårsaker.

27 av 62


Det har også vært to ulike tilnærminger til utviklingen av Internett; XHTML (Extensible HyperText Markup Language) -miljøet har ønsket en streng måte å håndtere standarden, med fokus på at alt på nettsiden skal være korrekt implementert for å bli forstått og at feil skal gi en forståelig feilmelding. Den mer tradisjonelle filosofien bak utviklingen av Internett er knyttet til at man i størst mulig grad skal forsøke å forstå den implementasjonen som er gjort.

1.1.2.2 Standarden er anerkjent og vil bli vedlikeholdt av en ikke-kommersiell organisasjon. Det løpende utviklingsarbeidet foregår på basis av en beslutningsprosess som er åpen for alle interesserte parter på en ikke-diskriminerende måte (kan være konsensus drevet, basert på flertallsavgjørelser osv).

HTML 4.01 er anerkjent av ISO2 og vedlikeholdes av W3C3. W3C inviterer publikum til å delta i W3C via diskusjonslister, arrangementer, blogger, oversettelser, og andre virkemidler. Deltakelse i samfunns- og næringsgrupper er åpent for alle. Deltakelse i W3C arbeidsgrupper er åpent for medlemmer i W3C og andre inviterte parter. Utviklingsarbeidet er derfor åpent for alle interesserte parter på en ikke-diskriminerende måte.

HTML5 vedlikeholdes av W3C4 og WHATWG. Slik sammensetningen av WHATWG er vil vi anta at nettleserleverandørene får mer å si for utviklingen av standarden enn andre. Men disse står også for en meget viktig del av standardiseringsarbeidet. I W3C-prosessen har alle mulighet til å delta.

De aller fleste nettleserleverandørene støtter HTML5 i sine nyeste produkter. Det er derimot ønskelig at brukere skal kunne fortsette å benytte eldre nettlesere. Det betyr at en offentlig virksomhet må lage HTML5 sider på en måte som gjør at HTML 4.01 nettlesere er i stand til å lese HTML filene som blir mottatt en stund til.

1.1.2.3 Har beslutningsprosesser i standardiseringsorganisasjonen vært slik at alle parter har hatt likeverdig og nødvendig innflytelse?

Alle deltagende grupper innenfor utviklings- og vedlikeholdsgruppene har likeverdig og nødvendig innflytelse.

1.1.2.4 Er standardiseringsorganisasjonen en ikke-kommersiell organisasjon? Ja, både W3C, ISO og WHATWG er ikke-kommersielle organisasjoner.

1.1.2.5 Har beslutningsprosessen vært åpen og transparent slik at alle har fått ta del i prosessen og kan se hvilket beslutningsgrunnlag som ligger bak standarden?

Utviklingen har skjedd gjennom en åpen, transparent og ikke-diskriminerende prosess. HTML-spesifikasjonen utvikles i offentlige fora ved W3C. Organisasjonen består av representanter fra forskjellige selskaper, som alle publiserer innholdet eller utvikler programvare som brukes på internett. Spesifikasjonen for HTML legges ut i flere skisser før den endelig vedtas, og diskuteres grundig av alle interesserte.

2 ISO/IEC 15948:2004 3 http://www.w3.org/ 4 http://www.w3.org/

28 av 62

http://www.w3.org/

http://www.w3.org/


1.1.2.6 Er standarden publisert og dokumentasjon er tilgjengelig enten gratis eller til en ubetydelig avgift? Er det tillatt for alle å kopiere, distribuere og bruke standarden gratis eller for en ubetydelig avgift?

Standarddokumentene er gratis tilgjengelige, og kan videreformidles.

1.1.2.7 Er intellektuelle rettigheter knyttet til standarden (for eksempel patenter) gjort ugjenkallelig? Er standarden tilgjengelig uten royalties?

HTML er ikke omfattet av patenter

1.1.2.8 Er det noen som helst forbehold knyttet til standarden som for eksempel i tilknytning til gjenbruk?

Nei, ingen slike forbehold er knyttet til standarden.

1.1.2.9 Hvilket nedslagsfelt har standardiseringsorganisasjonen (nasjonalt, europeisk, amerikansk, etc.)?

W3C, ISO og WHATWG, er internasjonale standardiseringsorganisasjoner som er engasjert i internett og World Wide Web. Formålet er å utvikle åpne standarder slik at World Wide Web kan utvikle seg i én felles retning i stedet for å bli splittet mellom flere konkurrerende retninger. W3C har ansvaret for viktige standarder som f.eks. HTTP, XML, CSS og HTML.

1.1.2.10 Hvilket kontaktpunkt i Norge har standardiseringsorganisasjonen? W3C har ikke noe kontaktpunkt i Norge, men Standard Norge er kontaktpunktet til ISO i Norge. WHATWG har et styre hvor nordmannen Håkon Wium Lie sitter.

1.1.3 Standardens aksept og utbredelse i markedet

1.1.3.1 Standardens modenhet, er den utprøvd, har den vært gjennom flere revisjoner, er den implementert i reelle løsninger?

HTML 4.01 er velprøvd og nyter høy grad av modenhet.

Det samme gjelder HTML5. Nettleserleverandørene jobber med implementering av standarden i parallell med utviklingen av den, noe som bør sikre at den er godt implementert i nyere løsninger når standarden endelig blir vedtatt.

1.1.3.2 Er tilstøtende områder, som må benyttes for å ta i bruk standarden, også standardisert? Ingen tilstøtende områder nødvendig for anvendelse, da flertallet av programmer og operativsystem støtter HTML. Men det finnes en rekke tilleggsstandarder som utfyller HTML og som gir økt funksjonalitet på hver sin måte. Eksempler på sike standarder er CSS, Javascript og W3C DOM.

1.1.3.3 Adopsjon i markedet - hvor utbredt er standarden i tjenester, løsninger og produkter tilgjengelig i markedet?

HTML er meget utbredt og ble definert allerede i 1989. HTML er nå en internasjnal standard (ISO/IEC 15445:2000). HTML-spesifikasjonene blir opprettholdt av W3C. Standarden støttes av alle nettlesere. Siste ferdige standard er HTML 4.01.

HTML5, så langt de har kommet i utviklingen, er støttet i de aller fleste nye nettlesere, og standarden utvikles og implementeres kontinuerlig hos nettleserleverandørene. En god del nettsider har derfor også kommet med HTML5 funksjonalitet. Skal eldre lesere forstå HTML5 sidene må de utvikles nennsomt, for å sikre bakover-kompatibilitet.

29 av 62


1.1.3.4 Benytter de fleste samme versjon av standarden? W3C anbefaler at man i dag baserer seg på HTML 4.01, XHTML 1.0 eller XHTML 1.1. Nettsider benytter disse standardene om hverandre. I tillegg har en rekke nettsider tatt i bruk HTML 5, som foreløpig ikke er vedtatt. På grunn av den kontinuerlige implementeringen i parallell med utviklingen av standarden er mange nye nettsider utviklet i HTML 5. Difi har for publisering av tekstdokumenter anbefalt å benytte HTML på en måte som sikrer at eldre nettlesere vil kunne lese nettsiden.

1.1.3.5 I hvilken grad er standarden bakover og forover kompatibel? HTML 4.01 er delvis bakover- og foroverkompatibel. Bakoverkompatibel er ikke lengre av betydning da standarden har eksistert lenge og er adoptert overalt. Når det gjelder foroverkompatibilitet så er det gjort en del endringer. Skal HTML5 sider forstås av eldre nettlesere må man følge en rekke forhåndsregler. Det finnes mange tips om hvordan dette kan gjøres på Internett.

HTML5 er delvis bakoverkompatibel, men ikke fullt ut. Vi antar at alle nettlesere vil støtte HTML 4.01 i en god stund fremover.

1.1.3.6 Kan standarden uproblematisk konverteres til andre standarder/formater (parallelle standarder)?

De fleste kontorstøtteprogram har mulighet til å lagre som HTML. Det finnes også løsninger for å konvertere HTML til andre format. Flere etater melder at de har løsninger som blant annet konverterer fra HTML 4.01 til blant PDF.

Når det gjelder konvertering fra andre format til HTML5, er ikke dette like utbredt enda.

Hvor mange parallelle standarder finnes det på området? Deres styrker og svakheter i forhold til hverandre? Er de dekkende, egner de seg for forskjellige anvendelsesområder?

De ulike standardene på området er HTML, PDF, ODF og OOXML.

I utgangspunktet er de to sistnevnte formatene laget for å være redigerbare tekstformat. De har mulighet for å legge inn bilder og også lyd og film, men sistnevnte er vel forholdsvis uvanlig. I tillegg har man muligheter for å legge inn logikk som sjekk av input i felt og noe annet, men har ikke samme funksjonaliteten som det man finner i HTML. Det er også betraktelig mindre erfaring i offentlige virksomheter og hos rådgivere og system leverandører på å utvikle slikt i ODF og OOXML. Det er også en utfordring at disse formatene ikke fungerer like godt i alt brukerutstyr og på all programvare. Jo mer avansert bruk jo dårligere kompatibilitet med ulikt utstyr og programvare.

Når det gjelder PDF så er det i utgangspunktet laget som et utskriftsformat. I de senere versjoner har det kommet inn stadig økt mulighet for multimedia og interaktivitet. PDF har blitt brukt i mange skjemaløsninger opp gjennom årene og funksjonalitet for å støtte dette har blitt bygd inn. PDF-er har derimot en tendens til å bli store og tunge, hvis mye logikk skal legges inn. I tillegg er PDF mindre fleksibel og har mindre funksjonalitet. Eksempler er mulighet for å kunne skjule sporvalg, eller det å kalle en web-service for å hente inn informasjon underveis i utfyllingen.

HTML har bedre funksjonalitet og er mer fleksibel enn sine konkurrerende standarder på området. HTML er i utgangspunktet laget for mer statisk tekst og mindre interaktivitet. Det har derimot kommet tillegg som har muliggjort en del ting i eksisterende versjon av HTML. Nå kommer HTML 5,

30 av 62


som er laget for å kunne håndtere de nye behovene som har dukket opp med større grad av interaktivitet, bruk av video og sosiale medier etc.

1.1.4 Tilfredsstiller standarden offentlige virksomheter og deres brukeres behov?

1.1.4.1 Løser standarden et problem for offentlig sektor? Har offentlig sektor behov for den funksjonaliteten standarden understøtter?

HTML er den standarden som er best i stand til å løse de behov offentlig sektor har på området. I tillegg er HTML standarden de fleste ser til for å realisere digitale tjenester på nett. Det gjør at HTML er standarden som vil bli videreutviklet for å kunne levere ny funksjonalitet i fremtiden.

Konkurrentene til HTML er egentlig ikke innen samme område, men innenfor et annet. Skal man se etter utfordrere til standarder for å realisere tjenester på nett, må man se på de ulike mobilplattformene for å lage «App-er». Foreløpig dekker disse et utfyllende behov og selv om enkelte tjenester leveres på begge plattformer, er det ingen fare for at den mobile plattformen skal utkonkurrere nettleserbaserte løsninger med det aller første.

1.1.4.2 Har hver offentlig virksomhet behov for standarden internt, eller er dette noe som løser utfordringene ved samhandling?

Dette er en standard man i utgangspunktet benytter for samhandling, både i forhold til samhandling ved å levere tjenester til innbyggere og næringsliv, men også delvis i forhold til samhandling mellom offentlige virksomheter for deling av informasjon seg i mellom.

1.1.4.3 Har standarden nødvendige kvalitet – løser den nok, er den entydig nok? Standarden er av de beste innen sitt område når det gjelder publisering av nettleserbaserte tjenester. Beskrivelsen av standarden er klar og entydig. Standarden løser en god del av det offentlig sektor har behov for.

HTML 4.01 er laget med formål å presentere statisk informasjon, og mangler derfor noe funksjonalitet som kommer med HTML5, blant annet for å få bedre støtte for multimediainnhold. HTML5 er laget for å ha bedre støtte for dette, samt interaktive funksjoner, noe som gjør at den løser stadig mer av offentlig sektors krav til blant annet tilgjengelighet. Både HTML 4.01 og HTML5 har blitt utvidet med tilleggsstandarder som CSS (Cascading Style Sheet). Mens HTML spesifiserer struktur, spesifiserer CSS utseende på siden. Full funksjonalitet særlig knyttet til interaktive funksjoner forutsetter bruk av tilliggende standarder som scriptspråk (For eksempel ECMAscript).

HTML har ikke definert opp funksjonalitet for å redigere dokumenter med merknader og sporing av endringer. Standarden har heller ikke samme evne som PDF til å ta vare på formatering. HTML sammen med CSS, kan derimot delvis erstatte PDF når det kommer til å ivareta formatteringen i et dokument. For eksempel med HTML5 og JSPDF kan man enkelt generere en PDF av HTML: http://mrrio.github.io/jsPDF/

1.1.4.4 Legger standarden begrensninger på offentlig sektor? Bruk av standarden legger ingen begrensninger på offentlig sektor. Men i enkelte virksomheter har man nok mer erfaring med bruk av PDF for å lage nettleserbaserte tjenester for skjema enn man har knyttet til HTML, så det kan kreve noe kompetanseheving. En kompetanseheving vi i Difi ser på som fremtidsrettet og en god investering.

31 av 62



1.1.4.5 Følger standarden krav i tilknytning til universell utforming? Så lenge kravene i WCAG følges er HTML-formatet godt egnet med tanke på kravene til universell utforming. HTML5 er på dette området bedre enn HTML 4.01.

1.1.4.6 Passer standarden inn i forhold til overordnede arkitektoniske prinsipper i offentlig sektor?

Arkitekturprinsippene i offentlig sektor er; tjenesteorientering, interoperabilitet, tilgjengelighet, sikkerhet, åpenhet, fleksibilitet og skalerbarhet.

HTML understøtter alle arkitekturprinsippene, men på noen områder tilfredsstilles prinsippene i samarbeid med andre standarder, som f.eks. TLS (Transport Layer Security) på sikkerhet.

HTML brukes også mye som grensesnitt for brukere av fagsystem i offentlig sektor. Felles teknologivalg for integrasjon og tjenester som går mot fagsystemenes grensesnitt kan være hensiktsmessig.

1.1.4.7 I hvor stor utstrekning har offentlig sektor behov for standarden? Hvor mange offentlige virksomheter benytter standarden i dag? Hvor mange vil ha behov for den i fremtiden (1-2 år og 3-5 år)?

Standarden er svært godt egnet for publisering av nettleserbaserte tjenester. Formatet er svært utbredt. Det antas at alle offentlige virksomheter benytter HTML i dag, og at alle vil ha behov for det også i fremtiden. Men det vil komme en gradvis overgang fra HTML 4.01 til HTML5.

1.1.4.8 Hvilket volum har anvendelsen hos de offentlige virksomheter som benytter standarden?

Det publiseres enorme mengder informasjon fra offentlig sektor, og en god del av denne informasjonen publiseres på HTML. I tillegg tilgjengeliggjøres det stadig flere nettleserbaserte tjenester.

1.1.4.9 Forutsetter standarden et visst funksjonsnivå(tolkes som brukerens funksjon - handicap)?

Standarden underbygger universell utforming på en meget god måte.

1.1.4.10 Krever bruken av standarden samme verktøy hos begge parter? Nei. HTML har bred verktøystøtte.

1.1.4.11 Hvilken bevaringsevne har standarden (jf. arkivlovgivning osv.)? HTML er et egnet format for arkivering om benyttet rett, men HTML er per i dag ikke et lovlig dokumentformat for langtidsbevaring jf. arkivloven. Det finnes god støtte for konvertering fra HTML til PDF/A, som er standard format for arkivering.

1.1.5 Hvilke konsekvenser vil en anbefaling av standarden gi?

1.1.5.1 I hvilken grad bidrar standarden til interoperabilitet? Standardisering av dette formatet vil bidra til større interoperabilitet, fordi dette er et anerkjent format med stor utbredelse og fordi det ikke foreligger noen økonomiske eller juridiske begrensninger for samhandlingen.

32 av 62


1.1.5.2 Hvordan bidrar standarden til fleksibel anvendelse på tvers av flere OS-plattformer? Standarden stiller ikke krav til brukerens operativsystem, da formatet støttes av alle operativsystemer og fungerer på alle typer brukerutstyr (pc, nettbrett, mobil)

1.1.5.3 I hvilken grad vil en anbefaling av denne standarden, som forvaltningsstandard, bidra til bedre samhandling i offentlig sektor?

HTML er en standard alle bruker, derfor bidrar den til bedre samhandling i offentlig sektor.

1.1.5.4 I hvilken grad vil standarden bidra til å øke kvaliteten i offentlig sektors tjenestetilbud til brukere og samarbeidsparter?

Bruk av HTML-standarden kan i høy grad bidra til å øke kvaliteten i offentlig sektors tjenestetilbud til brukere og samarbeidsparter. HTML er selve ryggraden i alle nettsider, og ny funksjonalitet i standarden og tilstøtende standarder åpner opp for nye og bedre interaktive tjenester.

Bruk av HTML i nettleserbaserte tjenester vil være bedre for universell utforming. Ved utfylling i HTML vil det være mulighet for lagring underveis i prosessen. Dette vil gi bedre kvalitet for brukeren som skal fylle inn informasjon i for eksempel et skjema. Etter at skjemaet er fylt ut, vil man så kunne sende det inn som PDF eller XML.

HTML bidrar til at alle kan ta i bruk nettleserbaserte tjenester fra alle sitt brukerutstyr. I tillegg åpner funksjonaliteten i HTML for å lage nye og bedre tjenester gjennom aktivt fornyingsarbeid.

1.1.5.5 I hvilken grad vil standarden bidra til å effektivisere offentlig sektors tjenestetilbud? Bruk av standarden gjør det enklere å effektivisere offentlig sektors tjenestetilbud. Elektronisk tilrettelegging sparer offentlig sektor for betydelig kundestøtte. Selvbetjening og publisering ved HTML kan gjøre at de data brukeren skriver inn kan gjenbrukes direkte, og gjennom enklere integrasjon mot bakenforliggende systemer, unngår man at informasjonen må tastes inn på nytt. I tillegg kan en automatisere en god del tjenester, når beslutningsgrunnlaget kommer inn elektronisk.

HTML med tilliggende standarder bidrar med funksjonalitet som blant annet gjør det enklere å validere inputdata før innsending, gjør det enklere å hente opp informasjon fra andre kilder underveis i prosessen, gjør det enklere å veilede og støtte brukeren av tjenesten underveis i prosessen, gjør det enklere for alle brukere å ta i bruk tjenesten uavhengig av brukerutstyr, etc. Denne standarden bidrar til at man kan levere nettleserbaserte tjenester på en måte som er mer kostnadseffektivt enn alternativene. For enkelte virksomheter vil mangel på kompetanse og økt mulighetsrom gi økte kostnader i starten. Dette er et forbigående problem, etter hvert som de får kompetanse vil denne ulempen forsvinne og utnytte av den nye funksjonaliteten vil bidra til effektivisering i prosessene.

1.1.5.6 I hvilken grad vil standarden gi IT-arkitektoniske og systemtekniske konsekvenser? Offentlig sektor har i hovedsak tatt i bruk HTML og tilliggende standarder for å publisere statisk informasjon. Etter hvert kan vi også tilby interaktive tjenester, integrasjon mot produksjonssystemer og samhandling mot andre offentlige virksomheter for å tilby helhetlige tjenester og effektiv utnyttelse av beslutningsgrunnlaget offentlig sektor besitter som helhet. Når vi tar de neste stegene vil dette få betydelige konsekvenser for IT-arkitekturen i offentlig sektor. Vi ser allerede en trend der eksisterende produksjonssystemer endrer seg i retning av å bli stadig mer nettorientert.

33 av 62


1.1.5.7 Hvilke økonomiske konsekvenser vil det få å anbefale denne standarden for offentlig sektor?

Det vil komme ekstrakostnader i opplæring av IT-personell som foreløpig ikke har mye er faring med bruk av HTML og den funksjonaliteten som tilbys gjennom standarden. Det vil komme innsparinger ved at flere kan ta i bruk digitale tjenester, fordi standarden er støttet på mer brukerutstyr enn alternative standarder. Det vil komme innsparinger ved at man kan levere enklere og bedre brukerstøtte ved bruk av standarden. Det vil komme innsparinger, fordi standarden i større grad understøtter integrasjon mot bakenforliggende systemer, enn det tilsvarende standarder gjør. Det vil komme innsparinger fordi standarden understøtter sjekking av input data på en måte som vi tror vil gi økt datakvalitet. Det vil komme innsparinger fordi standarden understøtter funksjonalitet som kan gjøre det enklere å gjenbruke informasjon fra andre etater, som kreves i tjenestene.

1.1.5.8 Hvilke konkurransepolitiske konsekvenser vil det få å anbefale denne standarden for offentlig sektor?

Internett og HTML har gitt en felles plattform som gir gode muligheter for små innovative selskap å nå ut til store brukermasser. Det gir en mye tøffere konkurranse i markedet. Det er mulig at HTML og nye måter å jobbe på, vil bryte opp noen av de midlertidige «monopolene» vi har i IT-markedet i dag. Å løfte frem HTML ytterligere vil kunne forsterke denne utviklingen.

Adobe har nok hatt noen fordeler i markedet ved at de har hatt best støtte av PDF standarden til nå. Større bruk av HTML vil senke bruken av PDF og således fjerne noe av den fordelen Adobe har hatt i markedet til nå.

1.1.5.9 Hvilke økonomiske konsekvenser vil det få å anbefale denne standarden for brukere av offentlige tjenester og samarbeidspartnere?

En anbefaling av standarden vil ikke gi noen betydelige økonomiske konsekvenser for brukere av offentlige tjenester og samarbeidspartnere. HTML fremvises i alle nettlesere. En økt fokusering på HTML og nettleserbaserte tjenester vil kunne bidra til flere og bedre elektroniske tjenester i tiden som kommer. I tillegg vil den gjøre tjenestene tilgjengelig på mer brukerutstyr enn tjenestene har vært tilgjengelig på til nå. Dette kan til en viss grad senke kostnadene for brukerne, fordi de ikke nødvendigvis trenger en PC, men kan greie seg med et nettbrett eller en mobil for å ta i bruk offentlige tjenester.

1.1.5.10 Vil det få konsekvenser for konkurransen i markedet at offentlig sektor velger denne standarden?

En anbefaling av standarden vil bidra til å forsterke trenden som går fra tradisjonelle IT-systemer mot webbaserte IT-systemer og etter hvert sky-tjenester. Dette vil få konsekvenser for konkurransen i markedet. Nye leverandører vil kunne komme på banen og utfordre de tradisjonelle leverandørene. Vi ser derimot at de tradisjonelle leverandørene også greier å fornye seg, men møter sunn konkurranse, som fordrer god kvalitet og kundeorientering.

34 av 62


1.1.5.11 I hvilken grad vil standarden bidra til innovasjon? En anbefaling av standarden vil forsterke innovasjonen vi har sett på Internett de siste 20 årene. Offentlig sektor har fått ut mye statisk informasjon, men står i startgropen for en mer helhetlig digitalisering av offentlig sektors tjenestetilbud. Det å peke på denne standarden er en liten brikke i denne overgangen.

1.1.5.12 Hvilken miljøeffekt vil bruk av standarden gi, sett i forhold til avfall, transport, forbruk og økt forbruk?

Bruk av standarden vil etter vår oppfatning være med på å legge til rette for å fremskynde utviklingen av gode elektroniske tjenester. En digitalisering vil senke bruk av papir, transport og søppelhåndtering. Dermed vil bruk av standarden gi stor positiv miljøeffekt.

35 av 62


1.2 PDF (PDF 1.7, PDF/A-1, PDF/A-2, PDF/A-3)

1.2.1 Hva er formålet med standarden?

1.2.1.1 Hva er hensikten ved å ta standarden i bruk? I det innledende delkapittelet Formål, ble drivkrefter, effekter og delmål for digitale tjenester beskrevet. Følgende delmål ble presentert:

• Informasjon som utveksles og som fremkommer fra brukerdialogen har tilstrekkelig grad av struktur for automatisering

• Tilstrekkelig informasjonssikkerhet for elektronisk innsending • Tilgjengelighet til tjenester uavhengig av teknisk kompetanse og utstyr • Brukervennlige tjenester • Gjenbruk av informasjon

Hensikten ved å ta PDF i bruk som publiseringsformat på nettleserbaserte tjenester som forvaltningsstandard, er først og fremst å tilgjengeliggjøre tjenester som i dag ikke er tilgjengelig digitalt på nett. I tillegg bidrar standarden til at alle brukere skal kunne benytte seg av digitale tjenester uavhengig av teknisk kompetanse og type utstyr. PDF egner seg også til utskrift og nedlasting, og det kan være aktuelt å konvertere HTML til PDF og gi kvittering på PDF.

Standarden anses å ikke være så godt egnet til en del av de mer avanserte behovene som er omtalt i denne utredningen. PDF er blant annet mindre fleksibelt enn HTML i forhold til utforming av brukergrensesnitt, og gir færre muligheter til å lede brukeren interaktivt gjennom tjenesten. Sammenlignet med HTML er PDF også vanskeligere å integrere inn mot bakenforliggende systemer, siden informasjonen som er fremkommet er i form av et dokument og ikke som strukturerte data.

Videre er PDF 1.4-1.7 trolig mer beregnet for generell distribusjon, mens PDF/A versjonene er beregnet og lovpålagt format for langtidslagring i arkiv.

Med noen av HTML5 sine nye muligheter, kombinert med scripting, kan man konvertere HTML til PDF i nettleseren, se for eksempel: http://mrrio.github.io/jsPDF/. Dette kan være nyttig hvis brukeren skal ta en utskrift av skjemaet eller den nettleserbaserte tjenesten, både før og etter utfylling. Der hvor spørsmålene i tjenesten er dynamiske må det kanskje også fremgå hvilke felter som brukeren ble presentert for og hvilke som ble skjult i en sporvalgsak.

1.2.1.2 Hvilket nedslagsfelt, bruksområde har standarden? PDF benyttes først og fremst som et distribusjonsformat over ulike digitale kanaler, for hos mottaker å bli vist på skjerm, skrevet ut eller benyttet i trykking.

Standarden benyttes i hele verden og i alle sektorer.

PDF/A, er i tillegg til overnevnte bruksområde også format for arkivering av formaterte dokumenter og skjema med tekst og bilder. Skanning kan i stigende grad også foretas direkte til PDF/A. Det er også en fordel å publisere på PDF/A format, så lenge man ikke har behov for den ekstra funksjonaliteten som har kommet i etterkant. Bruk av PDF/A ved publisering gjør det overflødig å konvertere ved senere arkivering.

36 av 62



Formålet med PDF/A er å sikre de arkiverte dokumentenes lesbarhet og tilgjengelighet over tid ved å eliminere avhengigheten av eksterne ressurser og teknologielementer.



Både PDF 1.4, 1.5, 1.6 og 1.7 er utviklet av Adobe, men kun 1.7 er senere spilt inn som en ferdig standard, godkjent av ISO. PDF 1.7 har dermed hatt en lukket prosess ved utviklingen av standarden, men en åpen prosess for beslutning av standarden.

PDF/A og PDF/A2er utviklet av ISO basert på Adobes PDF 1.4 og PDF 1.6 respektivt. Det har vært en åpen prosess i forhold til å velge profil av den Adobe utviklede PDF 1.4. Beslutningsprosessen har vært åpen, og det har vært mulig å komme med innspill til hvordan profilen skulle utformes underveis.


Standarden er anerkjent, og vedlikeholdes nå av en ikke-kommersiell organisasjon (ISO). Adobe har i etterkant kommet med noen utvidelser(extensions) til standarden, men fremtidige versjoner vil være fullt og helt ISO styrte versjoner av standarden.

Når ISO utvikler en standard blir den utviklet av et ekspertpanel innenfor en teknisk komité. De møtes for å diskutere og forhandle et utkast til standarden. Når utkastet er ferdig blir det delt med ISOs medlemmer som blir bedt om å kommentere og gi tilbakemelding på standarden. Hvis det er enighet blir det en ISO-standard, hvis ikke går det tilbake til den tekniske komiteen for ytterlige endringer og for videre utvikling. Slik forgår prosessen til de er enig og standarden blir godkjent. Alle medlemmer får på denne måten mulighet til å delta i både utviklings og beslutningsprosessen.


Versjonene 1.4-1.6 av PDF ble utviklet og besluttet av Adobe alene og er proprietære standarder. Beslutningsprosessen for PDF 1.7, PDF/A og PDF/A-2 har vært åpen, transparent og ikke-diskriminerende.

1.2.2.4 Er standardiseringsorganisasjonen en ikke-kommersiell organisasjon? Standarden er anerkjent, og vedlikeholdes av en ikke-kommersiell organisasjon (ISO). Når ISO utvikler en standard blir den utviklet av et ekspertpanel innenfor en teknisk komité. De møtes for å diskutere og forhandle et utkast til standarden. Når utkastet er ferdig blir det delt med ISOs medlemmer som blir bedt om å kommentere og gi tilbakemelding på standarden. Hvis det er enighet blir det en ISO-standard, hvis ikke går det tilbake til den tekniske komiteen for ytterlige endringer og for videre utvikling. Slik forgår prosessen til de er enig og standarden blir godkjent. Alle medlemmer får på denne måten mulighet til å delta i beslutningsprosessen.

37 av 62



Det er kun de som er meldt seg inn i den tekniske komiteen som får se hvilke innspill som har kommet og hvordan de er behandlet underveis i prosessen. Slik informasjon gjøres ikke åpent tilgjengelig for alle i etterkant.


De offisielle standarddokumentene er tilgjengelige mot avgift, og kan ikke fritt videreformidles. ISO får inn penger på salg av standarddokumentene. ISO 32000-1:2008 tilsvarer Adobe PDF 1.7, og er derfor tilgjengelig fra Adobe5.


Det er ikke knyttet noen lisensavgifter eller royalties til bruk av formatet. Alle patenter er ugjenkallelig frigjort og tilgjengelig uten royalty-betaling.


Nei, ingen slike forbehold er knyttet til standarden.


ISO (International Organization for Standardization) er en internasjonal standardiseringsorganisasjon.

1.2.2.10 Hvilket kontaktpunkt i Norge har standardiseringsorganisasjonen? Standard Norge er en norsk privat medlemsorganisasjon, med støtte fra NFD, som har ansvar for standardiseringsoppgaver på alle områder unntatt elektro og telestandardisering. Standard Norge har enerett på å fastsette og utgi Norsk Standard, og er det norske medlemmet i standardiseringsorganisasjonen ISO.



PDF har lenge vært et proprietært format, revidert gjennom en rekke versjoner, og ble i 2008 gjort til en åpen ISO-standard. Den nye ISO-standarden, ISO 32000-1, Document management – Portable document format – Part 1: PDF 1.7 er basert på Adobes PDF versjon 1.7, men skal inkludere vesentlig informasjon til utviklere av programvare som oppretter, skriver eller leser PDF-filer og eventuelt tolker innholdet for visning. Framtidige versjoner av formatet vil bli utgitt som etterfølgende deler av standarden. Standarden er svært utbredt, etablert og moden. Den har vært gjennom flere revisjoner.

5 http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf

38 av 62

http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf


PDF/A er basert på PDF 1.4 som har vært gjennom flere revisjoner som proprietær standard. PDF/A-2 er en videreutvikling av PDF 1.6 som har vært gjennom ytterligere revisjoner. Det forventes at Riksarkivaren vil godkjenne PDF/A-2 som arkivformat.

1.2.3.2 Er tilstøtende områder, som må benyttes for å ta i bruk standarden, også standardisert? Det er ingen spesifikke områder som krever standardisering, for at PDF standarden skal tas i bruk.


Standarden er meget utbredt. Store mengder informasjon på Internett er på ulike versjoner av PDF formatet. Det benyttes også i en del nettleserbaserte tjenester som elektroniske skjema. PDF er også et veldig utbredt langtidslagringsformat.

I publiserings-, konverterings- og arkiveringsløsninger, har man ofte implementert nyere løsninger av PDF, men i mer generell programvare henger man litt etter. Eksempler er MS-office for Mac, som kun støtter PDF 1.3 og MS-office på PC som støtter PDF 1.5 og PDF/A. Foreløpig er utbredelsen av løsninger med støtte for PDF/A-2 formatet beskjedent.

Det er ulik bruk av PDF, som gjør at det er naturlig å se på utbredelse i 3 kategorier.

Verktøy for publisering og automatisk dokumenthåndtering

De fleste som jobber aktivt med publisering har tilgang til en PDF generator, som er et program med full støtte for redigering i PDF. De fleste slike program har i følge ekspertuttalelser Difi har innhentet støtte for alle versjoner av PDF.

Det finnet også en del løsninger som gjør det mulig for systemer og automatisk konvertere dokumenter til PDF når de er merket ferdig/ til ekspedering/ sluttført eller lignende. Slike løsninger har ofte moduler i seg, som genererer eldre versjoner av PDF. Det skal imidlertid være mulig å få tak i nyere versjoner som kan håndtere alle versjoner av PDF (dette gjelder ikke alle løsninger).

Arkivløsninger som finnes i dag støtter alle PDF/A, fordi dette har vært lovfestet i Arkivforskriften siden 2009. Foreløpig er det et stykke igjen før alle disse støtter PDF/A-2.

Kontorstøtteprogramvare for vanlige saksbehandlere i offentlig sektor

De fleste saksbehandlere i offentlig sektor produserer dokumentene sine i en tekstbehandler tilknyttet kontorstøtteprogramvaren sin. De fleste i offentlig sektor benytter en eller annen versjon av MS Office, Open Office, Libre Office eller Google docs på Windows, Mac eller Linux. Undersøkelser i ulike versjoner av denne programvare viser at de fleste støtter PDF 1.4, mens MS Office i de fleste tilfeller støtter PDF 1.5. En del løsninger har mulighet til å si at dokumentet skal tagges og noen kan sette lagringsformatet til å være PDF/A. De fleste MS Office løsninger for Mac støtter kun PDF 1.3. Foreløpig ingen støtte for PDF/A-2.

PDF leser tilgjengelig for allmennheten

Difi har søkt på nett og forespurt de mest brukte PDF-leserne. Det virker som de fleste har støtte for alle versjoner av PDF. Acrobat Reader, som er den mest utbredte har hatt støtte for PDF 1.7 siden Acrobat Reader 8.0, som kom allerede i november 2006.

39 av 62


Ikke alle konkurrenter til Adobe Reader har like god støtte, særlig gjelder dette mer spesiell funksjonalitet som signering etc.

Det er også gjort noen tester med å lese dokumenter i PDF format på nettbrett og smarttelefon. Dokumentet kunne leses greit på testobjektene. Testen ble derimot gjennomført på et svært begrenset utvalg av brukerutstyr, og med et tekstdokument som var forholdsvis enkelt (inkluderte ikke all mulig funksjonalitet i standarden).

De fleste kan dermed lese PDF/A-2, selv om det ikke er så mange som har mulighet til å produsere dokumenter på dette formatet enda. Det er utifra dette kriteriet derfor rimelig å peke på standarden, så lenge produsentene har alternative versjoner å velge fra.

1.2.3.4 Benytter de fleste samme versjon av standarden? Det finnes mange ulike versjoner av standarden6. I dag støtter de fleste løsninger PDF 1.3 eller nyere. Det er stor variasjon i hvilken versjon som støttes og tilgjengelige PDF dokumenter lokalt og på internett er derfor på mange ulike versjoner. Fordelen er at de aller fleste lesere har mulighet til å lese alle versjoner av standarden. Det finnes to ulike profiler av PDF/A-1. PDF/A-1b er lagd for å opprettholde dokumentets utseende. PDF/A-1a er mer krevende, og støttes foreløpig ikke av alle tilbydere av PDF/A-konverteringsverktøy. Dette alternativet produserer ”taggede” dokumenter, hvor logisk struktur og tekstinnhold bevares i naturlig leseorden. Teksten vil dermed gjengis riktig på alle typer utstyr (også på mobiltelefon og PDA) selv om den f.eks. skulle være oppdelt i spalter. Det er et viktig poeng at PDF/A-1a - til forskjell fra PDF/A-1b - oppfyller kravene til universell utforming. Riksarkivaren gir derimot ikke nærmere bestemmelser om bruken av de to PDF/A-alternativene. Arkivskaperene står fritt til å velge mellom dem, også eventuelt til å bruke dem om hverandre.

1.2.3.5 I hvilken grad er standarden bakover og forover kompatibel? Formatet er i stor grad forover- og bakoverkompatibelt. PDF 1.7 inkluderer all funksjonalitet fra PDF 1.0 til 1.6. Men ulike profiler kan ha ulike restriksjoner knyttet til seg for å være spesielt egnet for sitt spesielle område (Det finnes egne versjoner av PDF for ulike formål som engineering etc.).


I 2007 gjennomførte FAD tester, der det ble tatt utgangspunkt i 100 dokumenter som i snitt var mer avanserte enn gjennomsnittlig dokumenter i Buskerud fylkeskommune. Testen viste at det var liten endring av dokumentene og at det i utgangspunktet ikke var behov for å gå inn å justere dokumentene etter konvertering til PDF standarden. (?)

Det kan være mer problematisk å konvertere fra PDF til andre formater. Det fungerer blant annet å lagre filer som OOXML fra Adobe Acrobat, men det er ikke gjennomført noen kartlegging som viser at det finnes en rekke verktøy som har slik funksjonalitet.

6 http://en.wikipedia.org/wiki/Portable_document_format

40 av 62

http://en.wikipedia.org/wiki/Portable_document_format


1.2.3.7 Hvor mange parallelle standarder finnes det på området? Deres styrker og svakheter i forhold til hverandre? Er de dekkende, egner de seg for forskjellige anvendelsesområder?

Det finnes mange parallelle standarder på området. Her henviser vi til kapittel 5, kartlegging, i hoveddokumentet. Styrker og svakheter ved de ulike formatene finner du under hvert enkelt format.

Styrken ved PDF er at standarden har meget stor utbredelse, tar godt vare på formatering også på tvers av plattformer og det er mulig å konvertere til PDF fra mange andre format. Formatet har også en del avansert funksjonalitet som «låsing» av innhold, metadata, signering, etc. som enkelte virksomheter ønsker å ta i bruk.

En svakhet med PDF er at den kan være vanskelig å kopiere fra, særlig i tilfeller med mye strukturelle elementer. F.eks. kan det være vanskelig å kopiere i tilfeller med mange kolonner og tabeller. Da får man ikke med formattering på en god måte over til de vanlige kontorstøtteprogrammene. En annen ulempe er at dokumenter ofte tar mye større plass når de konverteres fra de vanligste internformatene til kontorstøtteprogramvare til PDF.

Ved innsending av elektronisk skjema på PDF må man være sikker på at det som blir fylt inn i skjemaet også blir sendt. Det har vist seg at minst en PDF leser gir inntrykk av at dokumentet er sendt når det er signert. Dette kan være forvirrende for brukeren og føre til at de faktisk ikke sender inn dokumentet etter signering.

PDF mangler en del av den funksjonaliteten HTML har i forhold til å skjule spørsmål som ikke gjelder brukeren, mulighet til å gi hjelp mer interaktivt, mulighet til å hente ned informasjon underveis i prosessen, etc.

Selv om PDF dokumentet er strukturert, så er det strukturert på en måte best egnet for mennesker. Skal PDF dokumenter benyttes i integrasjon mot bakenforliggende system, kreves en større jobb for å tolke dokumentet elektronisk, for å få ut strukturert informasjon som kan legges automatisk inn i fagsystemene bak.



PDF er lite brukt og ikke spesielt godt egnet format for daglig dokumentproduksjon i en kontorstøtteprogramvare. Men slike dokumenter kan enkelt konverteres til PDF i etterkant.

PDF formatet egner seg godt til nettleserbaserte tjenester hvor informasjonen skal skrives ut eller trykkes uten at formatteringen endrer seg. Formatet fungerer ikke like godt på alle typer mobile enheter med mindre skjermstørrelse.

PDF mangler litt av den fleksibiliteten HTML gir, med skjuling av sporvalg, enkel sjekk av format på input data, mulighet til å hente ned informasjon underveis i prosessen, sammenkobling av ulike tjenester som hører sammen, etc.

Når det gjelder en del av den grunnleggende funksjonaliteten kan PDF levere noe av det:

41 av 62


Behov – ønsket situasjon Støttes av PDF?

Mulighet for preutfylling Ja Mulighet for strukturert informasjonsinnhenting Ja, men kan være krevende å

implementere Mulighet for innhenting av informasjon underveis i prosessen

Nei

Mulighet for sporvalg Ja Mulighet for å tilpasse tjeneste et sett med brukerpreferanser

Nei

Mulighet til å lagre data og fortsette senere Avhengig av oppsett Mulighet for å sette tjenestene inn i en samhandlingsløsning og benytte eksterne tjenester som for eksempel kart- eller søketjenester

Nei

Mulighet for å ivareta informasjonssikkerhet (tilgjengelighet, integritet og konfidensialitet)

Delvis

Mulighet for å skrive ut/ laste ned og sende inn for hånd

Ja

Mulighet for innsyn i tidligere innsendt materiale og benytte som mal for ny innsending

Nei

Mulighet for kvittering Ja


Formatet er i hovedsak egnet for utveksling av ferdigestilte dokumenter med andre, og for langtidslagring. Derfor løser den både interne utfordringer, samt utfordringer knyttet til samhandling med andre.

1.2.4.3 Har standarden nødvendige kvalitet – løser den nok, er den entydig nok? Standarden er en av de beste innen sitt område. Vi har ikke funnet tegn på misnøye knyttet til at standarden ikke er komplett spesifisert eller ved at den ikke er entydig nok. Få og små feil ved konvertering til PDF viser at standarden har god kvalitet og er enkel å implementere på en entydig måte.

Før var dokumenter mer fokusert mot statiske sider, mens nå er innholdet generelt blitt mer interaktivt og fullt av multimedia. PDF/A-1 har noen mangler når det gjelder blant annet multimediainnhold, siden den er basert på PDF 1.4. De nyere arkiv standardene PDF/A-2 og PDF/A-3 er basert på PDF 1.6 og er bedre på dette.

1.2.4.4 Legger standarden begrensninger på offentlig sektor?

Ja, publisering av nettleserbaserte tjenester i PDF gjør det vanskeligere å konvertere til andre formater, og å automatisere informasjonsflyt og –behandling i baksystemene i IT-løsningen. PDF tilbyr mindre funksjonalitet i tjenesten og har ikke samme mulighet for å hente ned informasjon underveis.

PDF er imidlertid godt egnet i kombinasjon med HTML, som utskrifts- og nedlastingsformat.

42 av 62


1.2.4.5 Følger standarden krav i tilknytning til universell utforming? PDF-standarden har nødvendig funksjonalitet og kan brukes til universell utforming. Hvordan dette best gjøres, er beskrevet i PDF/UA. Riktig bruk av tagging og metadata er viktig for universell utforming og dette støtter PDF-standarden.

Det er derimot en utfordring at tilleggsprogramvare for de med nedsatt funksjonsevne i hovedsak er tilpasset MS-formatene og ikke PDF, på grunn av deres markedsposisjonen.

I forhold til universell utforming bør det utredes i hvilken grad PDF/UA bør gjøres til en anbefalt eller obligatorisk forvaltningsstandard.


De arkitektoniske prinsipper i offentlig sektor er; tjenesteorientering, interoperabilitet, tilgjengelighet, sikkerhet, åpenhet, fleksibilitet og skalerbarhet.

PDF er en åpen standard, som bidrar til interoperabilitet mellom løsninger som benytter standarden, tilgjengelighet til informasjon som blir tilgjengeliggjort og legger således til rette for mer åpenhet.

I tillegg er det støtte for funksjonalitet i standarden knyttet til sikkerhet, men det går på signering av hele PDF dokumentet, og ikke hvert enkelt datafelt.

PDF har en dokumentstruktur som ikke er spesielt godt egnet for å trekke ut strukturerte data for å legge dem inn i bakenforliggende system. Det er mulig, men krever noe mer avansert programvare i bakenforliggende system.


Tilnærmet alle offentlige virksomheter benytter standarden i dag, og det antas at de også vil ha behov for å bruke den i fremtiden. Spesielt sannsynlig er det at PDF vil benyttes til arkivering. Men i løpet av denne perioden vil vi nok se et skifte mot nyere versjoner av arkivstandarden, selv om det fortsatt vil være en rekke dokumenter som ikke krever mer enn PDF/A-1 versjonen.


PDF benyttes i stor grad i dag i alle offentlige virksomheter.

For publisering av nettleserbaserte tjenester er det utstrakt bruk av PDF i dag. På arkivområdet vil bruken av PDF være økende, etter hvert som flere og flere legger om til elektronisk arkiv.

1.2.4.9 Forutsetter standarden et visst funksjonsnivå (tolkes som brukerens funksjon - handicap)?

I utgangspunktet er det funksjonalitet i standarden, som gjør det mulig å lage dokumenter som ikke krever noe spesielt funksjonsnivå. Men i praksis benyttes ikke funksjonaliteten fullt ut og ikke all programvare greier å utnytte funksjonaliteten og presentere dokumentene på en egnet måte for alle brukere.

43 av 62


1.2.4.10 Krever bruken av standarden samme verktøy hos begge parter? Nei, det finnes mange verktøy som er tilpasset standarden.

1.2.4.11 Hvilken bevaringsevne har standarden (jf. arkivlovgivning osv.)? Vanlig PDF er ikke lenger et godkjent arkivformat i følge Forskrift om utfyllende tekniske og arkivfaglige bestemmelser om behandling av offentlige arkiver § 8-17. Vanlig PDF kan ikke brukes ved arkivering etter 1. januar 2009. Vanlig PDF er erstattet med krav om bruk av PDF/A.

I følge Forskrift om utfyllende tekniske og arkivfaglige bestemmelser som behandler offentlige arkiver § 8-17 kan elektroniske dokumenter med tekst og bilde eller grafikkobjekter være lagret i PDF/A – ISO 19005-1:2005, versjon 1a eller 1b, ved avlevering og deponering. Det forventes at Riksarkivaren vil godkjenne PDF/A-2 som arkivformat ved neste revisjon av forskriften.


1.2.5.1 I hvilken grad bidrar standarden til interoperabilitet?

Nettleserbaserte tjenester publisert som PDF er ikke så enkelt å integrere opp mot bakenforliggende systemer. I den grad man ønsker at informasjonen som fylles inn av brukeren skal håndteres som strukturerte data hvor tjenestene er integrert mot bakenforliggende systemer er HTML å anbefale. Sett fra et sluttbrukerståsted bidrar standarden til interoperabilitet ved utveksling av ferdigstilt informasjon mellom brukere som benytter PC. Når det gjelder ulikt brukerutstyret, er PDF mindre egnet på mobiltelefon. På bakgrunn av dette vurderes standarden til i noen grad å bidra til interoperabilitet.

1.2.5.2 Hvordan bidrar standarden til fleksibel anvendelse på tvers av flere OS-plattformer?

Standarden stiller ikke krav til brukerens operativsystem, da formatet støttes i programvare på de aller fleste operativsystemer; Windows, Mac OS X, Linux og Unix. Men formatet fungerer ikke like godt på mobile løsninger.


Standarden vil i bidra til bedre samhandling, særlig knyttet til utveksling av ferdigstilt informasjon. Standarden gir offentlige virksomheter større frihet til å velge egen programvare for produksjon av dokumenter.

Når det gjelder publisering av nettleserbaserte tjenester gir PDF samhandling men ikke i den grad HTML gjør. HTML har større funksjonalitet og fungerer på flere typer brukerutstyr.


Generelt vil nettleserbaserte tjenester publisert på HTML oppfattes som mer tilgjengelig og bedre enn tjenester publisert på PDF.

Det har vært og er en utfordring at informasjon fra offentlig sektor gjøres tilgjengelig på formater brukere ikke har støtte for. PDF har bred støtte hos de aller fleste og vil således bedre tilgangen til informasjonen. Bruk av en åpen standard vil også fjerne presset for at brukere av offentlige tjenester

44 av 62


skal måtte velge samme programvare som offentlig sektor. PDF vil derfor bidra til noe bedre kvalitet i det offentlige tjenestetilbudet i de tilfeller hvor man i dag ikke bruker hverken PDF eller HTML.

I dag er det en betydelig andel brukere av offentlige tjenester og samarbeidsparter til offentlig sektor som baserer seg på alternativ programvare til MS-Office som er den markedsdominerende kontorstøtteprogramvaren i offentlig sektor i dag. Ved å publisere og sende dokumenter som PDF/A i stedet for doc, ODF og OOXML vil dette bidra til færre feil i dokumentene som sendes over. En forutsigbarhet i forhold til format og bruk av et format som er bredt støttet vil gi en økt brukeropplevelse for brukere av offentlige tjenester.

PDF/A kan i tilfeller med behov for å ivareta formatet på det som sendes oppfattes som bedre kvalitet enn HTML.

1.2.5.5 I hvilken grad vil standarden bidra til å effektivisere offentlig sektors tjenestetilbud? Bruk av en åpen standard vil gjøre offentlig informasjon mer tilgjengelig. Det vil igjen føre til mindre manuell brukerhåndtering, som vil spare offentlig sektor for utgifter.

Bruk av den åpne PDF-standarden ved publisering av nettleserbaserte tjenester vil kanskje kunne øke andelen som tar i bruk elektroniske tjenester, sammenlignet med tjenester publisert på ODF og OOXML. Sammenlignet med HTML vil PDF bidra negativt. Selv om det er enkelt å lage mindre kompliserte nettleserbaserte tjenester i PDF, så vil tjenestene kunne få miindre funksjonalitet, bli mindre tilgjengelig og i mindre grad bidra til effektivisering gjennom automatisering i bakkant. En overgang fra manuelle til automatiske tjenester vil kunne gi forbedringer både ved effektivisering og ved mer brukervennlige tjenester.

De nyere versjonene av PDF (f.eks. PDF 1.7 og PDF/A2) har større funksjonalitet og fleksibilitet enn de eldre versjonene (f.eks. PDF 1.4 og PDF/A).

1.2.5.6 I hvilken grad vil standarden gi IT-arkitektoniske og systemtekniske konsekvenser?

Bruk av PDF til publisering av nettleserbaserte tjenester vil trolig begrense integrasjon mot bakenforliggende systemer.

1.2.5.7 Hvilke økonomiske konsekvenser vil det gi å anbefale denne standarden for offentlig sektor?

Offentlig sektor har kanskje et potensiale for å jobbe mer aktivt med forbedring av arbeidsprosesser. En anbefaling om å endre publiseringsformat kan fremme nye arbeidsrutiner med nye underliggende tekniske systemer, som kanskje utnytter IKT på en bedre måte og dermed bidrar til betraktelig bedre samhandling og effektivisering. I den forbindelse vil trolig ikke PDF som publiseringsformat gjøre så stor forskjell, siden gevinsten stort sett vil være relatert til sluttbrukernes tilgjengelighet til tjenesten og interoperabilitet mellom nettleser og tjeneste.

• Nytte o Økt tilgjengelighet for de med nedsatt funksjonsevne. Det forventes at de som lager

spesialtilpasset programvare over tid vil tilpasse seg PDF og dermed vil tilgjengeligheten bedre seg. Midlertidig vil den gå ned, fordi mange har god tilgang i dag gjennom MS sine produktgrensesnitt.

45 av 62


o Økt kvalitet på tjenester, flere kan bruke elektroniske tjenester – besparelser ved mindre manuell behandling

o Mindre behov for konvertering til arkivformat • Ulemper

o Dårligere funksjonalitet og mindre egnet for integrasjon mot bakenforliggende systemer

Totalt sett anslås det å peke på standarden til å ha små økonomiske effekter. De viktigste effektene er kvalitative, ved at man slipper å skaffe egen tilleggsprogramvare for å benytte offentlige tjenester, utover PDF plug-in til nettleseren som uansett de fleste har.


Det å peke på den åpne standarden PDF vil kunne bidra til å øke konkurransen i programvaremarkedet. I dag blir enkelte brukere presset til å velge MS Office, fordi enkelte offentlige virksomheter tilgjengeliggjør informasjon og tjenester på MS format. Det å peke på PDF vil fjerne den årsaken, men det er bare en av mange årsaker og den vil derfor ha begrenset effekt. Vi tror derfor den konkurransepolitiske effekten vil bli liten.


En anbefaling av standarden vil gi ingen eller svært begrensede økonomiske konsekvenser. De nødvendige verktøy for visning av PDF-dokumenter er fritt tilgjengelige, og PDF-standarden er utbredt. Det vil trolig være begrensede kostnader knyttet til selve publiseringen, men muligheten for å effektivisere i bakenforliggende systemer og rutiner vurderes som lavere med PDF sammenlignet med HTML.

Hovedkostnaden vil ligge i den forvaltningsutviklingen hver offentlig virksomhet må gjennom for å tilgjengeliggjøre tjenester på nett. Det vil nok være større press for å gjennomføre en grundig forvaltningsutvikling ved en overgang til HTML enn PDF. Det vil gjøre at det å ta i bruk HTML-standarden for utvikling av elektroniske tjenester vil bli dyrere i utvinklingssammenheng, men vil gjøre at besparelsene i etterkant blir betraktelig større.


Ja, det antas å få noen konsekvenser i markedet ut i fra hva ulike leverandører har valgt å spesialisere seg på i dag, men konsekvensene anslås å være små.

1.2.5.11 I hvilken grad vil standarden bidra til innovasjon? Det å fornye arbeidsprosessene og publisere nettleserbaserte tjenester vil bidra til innovasjon. Det å ta i bruk nettleserbaserte tjenester åpner for nye funksjoner arbeidsmåter og stor innovasjon i offentlig tjenesteproduksjon. Standardene vil i ulik grad bidra til innovasjon avhengig av hvilken funksjonalitet de støtter. HTML vil bidra med størst innovasjon, fordi standarden har best funksjonalitet.

46 av 62



Økt bruk av elektroniske kanaler vil føre til mindre bruk av papir og mindre reising. Dette vil kunne gi en positiv effekt på miljøet. Elektroniske tjenester krever på den annen side infrastruktur og elektronisk utstyr, og innebærer muligens økt strømforbruk.

47 av 62


1.3 ODF


1.3.1.1 Hva er hensikten ved å ta standarden i bruk? Hensikten med ODF er å lage en åpen XML-basert filformatspesifikasjon for kontorprogramvare. Filformatet gjør transformasjoner til andre formater enkle ved å utnytte og gjenbruke eksisterende standarder der det er mulig.

Formålet er å lage en standard som underbygger behovet i en kontorstøtteprogramvare. Det krever funksjonalitet for teksthåndtering, regneark og presentasjons funksjonaltet.

1.3.1.2 Hvilket nedslagsfelt, bruksområde har standarden? Nedslagsfeltet til denne standarden er de som skal implementere løsninger som produserer og leser dokumenter produsert i denne standarden. Andre som vil lese og bruke denne standarden er de som må utvikle løsninger som integrerer med og som vil bruke dokumenter beskrevet i forhold til standarden. Leverandører av fagsystemer som skal produsere eller lese dokumenter produsert med denne standarden er også del av målgruppen. Forventet målgruppe for standarden er:

• Skaperne av kontorapplikasjoner • Skaperne av XML, dokumentbehandling eller redigeringsløsninger • Ledere og arkivarer som bruker kontordokumentformater for langsiktig digital bevaring • Representanter av andre Office-dokument tilfeller • Andre spesifikasjons forfattere som trenger kontordokumentinnhold eller deler av det



Arbeidet med utviklingen av ODF foregår i OASIS (http://www.oasis-open.org) sin arbeidsgruppe for dokumentformater. Denne arbeidsgruppen har blant annet medlemmer fra Google Inc., IBM, Intel Corporation, Microsoft Corporation, Nokia Corporation, Novell, Sun Microsystems, The Boeing Company. Alle medlemmer av OASIS har mulighet til å kommentere og stemme over endringer og komme med forslag til endringer til standarden.

Det er i tillegg flere arbeidsgrupper som arbeider med forskjellige områder innenfor standarden som f.eks. tilgjengelighet, metadata, formler i regneark osv.

Etter avtale med ISO/IEC JTC1 skjer arbeidet med utviklingen av ODF i OASIS, og når ny versjon er vedtatt av OASIS blir denne oversendt ISO/IEC, for egen behandling her (fas track).


OASIS vedlikeholder og videreutvikler ODF som standard. Alle dokumenter og diskusjoner er fritt tilgjengelig for alle på http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

48 av 62

http://www.oasis-open.org/

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office


Avgjørelser og arbeidet utføres av medlemmer av arbeidsgruppen og de relevante undergruppene.


Hvert medlem som deltar aktivt i OASIS kan stemme. Det er bestemte kriterier som gjelder for å bli definert som en aktiv deltaker. Det er fritt fram for alle å melde seg inn i OASIS, deltakeravgiften er avhengig av størrelsen på organisasjonen.

1.3.2.4 Er standardiseringsorganisasjonen en ikke-kommersiell organisasjon? OASIS er en non-profit organisasjon, hvor medlemmer betaler avgift for å delta, OASIS er avhengig av betalende medlemmer for å drive sin virksomhet.


Det forutsettes at medlemmer i det tekniske arbeidet deltar aktivt. Aktive medlemmer kan stemme og derved beslutte hvilke endringer som kommer med.

Epostlister og dokumenter som produseres ligger fritt tilgjengelig på: http://lists.oasis-open.org/archives/office-comment/ og http://www.oasis-open.org/committees/documents.php?wg_abbrev=office

De enkelte undergrupper har også fritt tilgjengelige epostlister og dokumenter. Hvordan de enkelte medlemmene har stemt til forskjellige forslag er også fritt tilgjengelig.


Standarden er fritt tilgjengelig uten kostnad på: http://www.oasis-open.org/specs/index.php#opendocument


Ja, standarden er tilgjengelig og kan implementeres uten royalties, da alle rettigheter er ugjenkallelig tilbaketrukket.


Nei, det er ingen forbehold knyttet til standarden.


OASIS er en internasjonal organisasjon.

1.3.2.10 Hvilket kontaktpunkt i Norge har standardiseringsorganisasjonen? Hans A. Aanesen har ved flere anledninger representert OASIS i Norge.

49 av 62

http://lists.oasis-open.org/archives/office-comment/

http://lists.oasis-open.org/archives/office-comment/

http://www.oasis-open.org/committees/documents.php?wg_abbrev=office

http://www.oasis-open.org/committees/documents.php?wg_abbrev=office

http://www.oasis-open.org/specs/index.php%23opendocument

http://www.oasis-open.org/specs/index.php%23opendocument




ISO/IEC 26300:2006 ble en internasjonal standard i 2006. Arbeidet med ODF ble startet i 2002.

Siden ISO/IEC 26300 ble ferdigstilt har ODF gjennomgått flere revisjoner. Open Document 1.2 ble godkjent som en OASIS-standard 29.09.2011. I 2013 har medlemmene i OASIS Open Documents tekniske komité bedt om at OASIS sender ODF 1.2 til ISO/ECT JTC1 for godkjenning som et forslag til internasjonal standard i henhold til JTC’s "Publicly Available Specification" (PAS)» sin innarbeidede rutine. ODF 1.2 er allerede implementert av Open Office.

I dag er standarden implementert av Microsoft Office (krever installering av fritt tilleggsprogram), Open Office og Lotus Symphony. Open Office og lotus Symphony går på alle Windows plattformer, Linux og MacOSX.

1.3.3.2 Er tilstøtende områder, som må benyttes for å ta i bruk standarden, også standardisert? Ikke en relevant problemstilling for denne standarden.


Open Office og Lotus Symphony har implementer ODF standard for Windows, MacOSX og Linux plattformene.

Microsoft inkluderer støtte for ODF 1.1 i Microsoft Excel 2010, Microsoft Word 2010 og Microsoft PowerPoint 2010. Microsoft Office støtter nå ODF, slik at brukere av Microsoft Office kan lagre dokumenter i ODF-format. Det er ikke interoperabilitet mellom ODF og OOXML på deler av standardene.

1.3.3.4 Benytter de fleste samme versjon av standarden? Forskjellige leverandører implementerer forskjellige versjoner, men siden ODF 1.2 ble offentliggjort er den allerede implementert i OpenOffice. IBM gikk ut med versjon 3.0 av Lotus Symphony i 2010, som ga støtte for ODF 1.2.

1.3.3.5 I hvilken grad er standarden bakover og forover kompatibel? ODF er en standard som har som utgangspunkt å møte de behov som finnes til formater for kontorprogramvare. ODF har tatt dokumentet som utgangspunkt og hadde derfor ingen binding til tidligere versjoner eller bestemt programvare og denne programvare sin måte å beskrive informasjon.

1.3.3.6 Kan standarden uproblematisk konverteres til andre standarder/formater (parallelle standarder)

ODF kan uproblematisk konverteres til PDF og også delvis HTML. Konvertering til OOXML er mer komplisert og volder utfordringer knyttet til ulik funksjonalitet.


Det finnes mange standarder for å beskrive dokumentformater, en av de mest kjente i dag er HTML.

50 av 62


Det er utviklet mange forskjellige standarder for å beskrive både generelle og mer spesielle dokumentstrukturer, fellestrekk mellom alle disse standardene er at de bygger på prinsipper fra ISO 8879 (SGML) som senere er videreført i XML og tilstøtende standarder som Xlink, Xpointer, XSL og XSLT. Som eksempel kan nevnes ISO/IEC 12083 som beskriver bøker, artikler og serier. Et generelt prinsipp som ligger til grunn for mange av disse formatene og som er avgjørende for deres anvendelsesområde er separasjon mellom innholdet/semantikken og hvordan denne skal presenteres. ISO/IEC 29500 og ISO/IEC 26300 prøver å følge disse prinsippene.

Det er noen forskjeller i den bakenforliggende arkitektur som brukes for å beskrive informasjonsmodellen mellom ISO/IEC 29500 og ISO/IEC 26300 og HTML.

Basert på vår forståelse av ODF og ISO/IEC 29500:2008 vil vi hevde at de er overlappende og dekker de samme behov. ODF er mer lettvekteren for de fleste, mens OOXML inkluderer mye mer funksjonalitet som er mer nødvendig for de med spesielt avanserte behov.

Styrken til ODF er at den følger en informasjonsarkitektur som er mer lik andre formater og derfor vil være lettere å transformere mellom ODF og disse. Det vil også være lettere å produsere ODF-dokumenter fra andre verktøy.



Ja, standarden svarer på behovet for å sikre langtidslagring og tilgang til et lettere tilgjengelig dokumentformat for generell kontorprogramvare. Langtidslagring er sikret ved at formatet som bruker for å beskrive informasjon i disse standardene er baser på XML. Siden XML er tekstbaser, kan alle verktøy som kan åpen og lese tekst filer også åpne og lese de XML filer som produseres. Noe som kan være vanskelig for dokumenter som er basert på ren binær representasjon.


Standarden møter de behov offentlig virksomhet har internt.

Standarden løser mange av de utfordringer ved samhandling mellom offentlig sektor og borgere, og mellom offentlig sektor og næringslivet. Standarden løser også utfordringer med samhandling mellom næringslivet og borgere.

1.3.4.3 Har standarden nødvendige kvalitet – løser den nok, er den entydig nok? Innen sitt funksjonsområde har standarden tilstrekkelig kvalitet. Den mangler en del funksjonalitet sammenlignet med OOXML, hvis man ser på det å håndtere redigerbare dokumenter. Når det gjelder publisering av nettleserbaserte tjenester, ser vi at bruk av skjema/ maler i formatet kan tilby en del interessant funksjonalitet, men ikke mer funksjonalitet enn det som er mulig å lage i HTML.

Det er også en utfordring at bruk av ODF setter krav til programvare på begge sider i tillegg til nettleser og web-server. Det er også slik at begge formatene blir implementert på så ulik måte i ulik programvare at det ikke oppnås god interoperabilitet. Det kan derfor stilles spørsmål om standardene er entydig nok, eller om det er en ønsket situasjon fra applikasjonstilbyderne.

51 av 62


1.3.4.4 Legger standarden begrensninger på offentlig sektor? Det å benytte standarden begrenser til en viss grad funksjonaliteten og kompliserer integrasjon mot bakenforliggende system.

1.3.4.5 Følger standarden krav i tilknytning til universell utforming? Det er «tilgjengelighets»-elementer som kan brukes for å gi mer informasjon til brukere med spesielle behov. Hvordan støtteteknologi gis tilgang til denne informasjonen er avhengig av den plattform og det verktøy som brukes for å lese informasjonen. ODF har fokusert mye på behov for å støtte hjelpemidler som kan brukes av store brukergrupper. Siden XML er brukt som format for å beskrive innholdet vil graden av tilgjengelighet til informasjonen være avhengig av hvor mye tilgjengelighetsinformasjon som kan representeres i XML formatene. ODF 1.2 har et relativt rikt sett av muligheter for å beskrive tilgjengeligheten til bilder, illustrasjoner, tabeller osv.

Tidligere undersøkelser har vist at selve formatet ODF i hovedsak har den funksjonaliteten som det er behov for, men at mange programmer som benytter ODF ikke har tatt denne funksjonaliteten i bruk.


Standarden passe godt inn i overordnede arkitektoniske prinsipper for offentlig sektor.

1. Tjenesteorientering: Siden denne standarden er basert på XML vil det være mulig å utvikle tjenester som kan prosessere og hente ut relevant informasjon direkte fra dokumentene. Men det er til en viss grad mer komplisert enn å gjøre dette via HTML.

2. Interoperabilitet: Siden denne standarden er basert på XML vil det være mulig å utveksle informasjon mellom systemer som implementerer denne standarden, det vil også være mulig å transformere dokumenter basert på dette formatet over til andre formater. Men i praksis ser vi at det er utfordringer knyttet til dette.

3. Tilgjengelighet: Siden denne standarden er basert på XML, kan informasjonen behandles av alle verktøy som kan lese XML filer, dette sikrer en relativt høy grad av tilgjengelighet. Hvor stor del av informasjonen som er tilgjengelig er avhengig av dokumentformatets mulighet til å beskrive tilgjengelighetsinformasjon.

4. sikkerhet: Sikkerhet til denne standarden ivaretas av de verktøy som implementerer standarden.

5. Åpenhet: Siden dette er standardiserte dokumentformater er de åpne for alle. 6. Fleksibilitet: Siden dette er en standard som beskriver format på dokumenter som

produseres, er ikke standarden avhengig av ett bestemt verktøy eller en bestemt plattform, dette sikrer fleksibilitet.

7. Skalerbarhet: Det er ingen begrensninger på størrelsen av de dokumentene som kan produseres i henhold til denne standarden.

8. Enhetlig brukergrensesnitt: Brukergrensesnittet er ivaretatt av de verktøy som implementerer denne standarden.

52 av 62



Offentlig sektor har behov for å håndtere redigerbare dokumenter og å publisere nettleserbaserte tjenester. Denne standarden kan benyttes på begge områder. Alle offentlige virksomheter vil ha tilsvarende behov også i fremtiden.

De offentlige virksomheter som i dag bruker Open Office eller Lotus Symphony benytter i dag ODF standarden i dag. Enkelte brukere av MS-Office benytter også ODF.


De som benytter standarden bruker den til intern dokumentproduksjon og i svært liten grad til publisering av nettleserbaserte tjenester.


Utover forskjellen mellom de operativsystemer som brukes og verktøyene for produksjon av innhold i ODF kreves det ikke et spesielt funksjonsnivå for å utnytte og produsere informasjon i forhold til denne standarden.

1.3.4.10 Krever bruken av standarden samme verktøy hos begge parter? I utgangspunktet er standarden støttet i en rekke ulik programvare, med interoperabilitetsutfordringer gjør at man ved bruk av en del funksjonalitet med fordel bør bruke samme verktøy hos begge parter for å få samhandlingen til å fungere.

1.3.4.11 Hvilken bevaringsevne har standarden (jf. arkivlovgivning osv.)? I følge Forskrift om utfyllende tekniske og arkivfaglige bestemmelser som behandler offentlige arkiver § 8-17: Godkjente dokumentformater ved avlevering og deponering, er ikke ODF nevnt som et godkjent dokumentformat ved avlevering og deponering for elektroniske dokumenter med tekst og bilde.


1.3.5.1 I hvilken grad bidrar standarden til interoperabilitet? Det å peke på standarden vil ikke være fordelaktig, fordi standarden er best egnet for et annet anvendelsesområde, og fordi standarden har interoperabilitetsutfordringer knyttet til seg.

1.3.5.2 Hvordan bidrar standarden til fleksibel anvendelse på tvers av flere OS-plattformer? Standarden fungerer på tvers av ulike operativsystem.


Det å peke på ODF for nettleserbaserte tjenester vil bidra til betraktelig dårligere samhandling enn å peke på alternative standarder, som HTML og PDF.

53 av 62



Bruken av standarden vil ikke øke kvaliteten på offentlige nettleserbaserte tjenester, sammenlignet med bruk av alternative standard som HTML.

1.3.5.5 I hvilken grad vil standarden bidra til å effektivisere offentlig sektors tjenestetilbud? Standarden kan bidra til å effektivisere offentlig sektors tjenestetilbud, men ikke like mye som alternative valg.

1.3.5.6 I hvilken grad vil standarden gi IT-arkitektoniske og systemtekniske konsekvenser? Bruk av standarden gir IT-arkitektoniske konsekvenser. Integrasjoner må skje basert på dokument formatet, eller det må etableres parallelle standarder, noe som de fleste kontorstøtteprogramvarer har gjort for integrasjon mot for eksempel fagsystem. Dette er også gjort for å oppnå mer funksjonalitet enn det som oppnås gjennom dokumentformatet alene.


De store økonomiske følgende er knyttet til arbeidet med forvaltningsutvikling. Om tjenestene baserer seg på den ene standarden eller den andre har ikke så mye å si, men det krever nok noe mer omskolering av offentlig ansatte, hvis man skal basere seg på ODF. De store effektene er avhengig av funksjonalitet og tilgjengelighet på tjenestene. Alternative standarder vil score bedre på disse områdene.


Siden mange av driverne bak ODF standarden tilhører miljøer som jobber med friprogramvare, vil en anbefaling av ODF kunne gi disse miljøer større legitimitet.

Dette kan føre til at det offentlige i større grad begynner å bruke løsninger basert på friprogramvare. Dette kan åpne opp for innovasjon og nye markeder for bedrifter som jobber med friprogramvare. Alternative standard som HTML vil gi samme effekten, men det vil ikke oppnås ved å velge alternative standard som OOXML eller PDF.


Økonomiske konsekvenser for brukere av offentlig sektor er knyttet til bruk av programvare og brukerutstyr. ODF setter høyere krav til brukerutstyr og programvare enn det HTML gjør. Det vil slik sett ha en økonomisk konsekvens, fordi det begrenser muligheten til å gjøre tjenester på hvilket som helst utstyr, og dermed også mulighet til å utføre tjenestene til alle ønskelige tidspunkt og steder.


Vi tror at det å velge ODF ikke vil påvirke markedet i større grad, annet en å sende et positivt signal til de som er opptatt av fri programvare. Det vil være bedre for markedet om vi peker på en alternativ standard som er bedre egnet for formålet.

1.3.5.11 I hvilken grad vil standarden bidra til innovasjon? I liten grad vil standarden bidra til innovasjon.

54 av 62



Elektronisk tilrettelegging av informasjon sparer bruk av papir, transport og søppelhåndtering. Dermed vil bruk av standarden gi stor positiv miljøeffekt.

55 av 62


1.4 ISO/IEC 29500:2008 (OOXML)


1.4.1.1 Hva er hensikten ved å ta standarden i bruk? ISO/IEC 29500 definerer et sett med XML elementer for representasjon av tekstbehandler, regneark og presentasjons dokumenter. På den ene siden er målet med ISO/IEC 29500 på en troverdig måte å representere eksisterende base av tekstbehandling, regneark og presentasjons dokumenter produsert av Microsoft Office (fra Microsoft Office 97 til og med Microsoft Office 98) fram til etablering av ISO/IEC 29500. Standarden spesifiserer også krav til Office Open XML lesere og produsenter. På den andre siden, er målet å fasilitere utvidelser og interoperabilitet ved å muliggjøre implementering av mange leverandører på mange forskjellige plattformer.7

1.4.1.2 Hvilket nedslagsfelt, bruksområde har standarden? Nedslagsfeltet til denne standarden er de som skal implementere løsninger som produserer og leser dokumenter produsert i denne standarden. Andre som vil lese og bruke denne standarden er de som må utvikle løsninger som integrerer med og som vil bruke dokumenter beskrevet i forhold til standarden. Leverandører av fagsystemer som skal produsere eller lese dokumenter produsert med denne standarden er også del av målgruppen.



Standarden er i utgangspunktet utviklet av Microsoft og deretter presentert for internasjonal standardisering. Standarden ble først gjort til en ECMA standard i ECMA-376. ECMA-376 benyttet seg av ISO/IEC sin Fast Track prosess for å gjøre ECMA-376 til en ISO-standard. Her ble alle medlemsland av ISO/IEC JTC1/SC 34 gitt mulighet til å komme med forslag til endringer og forbedringer. Det kom inn over 3.522 forslag til forbedringer hvor 1027 var «unike» forskal til endringer av ECMA-376. ISO/IEC 29500:2008 er et resultat av de endringer det ble enighet om i BRM-møtet hvor endringsforslagene ble diskutert. Det forventes at ISO-prosedyrene når det gjelder åpenhet og deltagelse vil følges under videreutviklingen av ISO/IEC 29500.

Gitt utviklingen av standarden og fast-track løpet må det sies at det har vært begrenset mulighet for å påvirke utviklingen av standarden.


ISO/IEC 29500:2008 blir vedlikehold av ISO/IEC JTC1/SC 34/WG4 som en åpen for alle nasjonale eksperter nominert av nasjonal standardiseringsorganer. I Norge blir eksperter til denne arbeidsgruppen nominert av Standard Norge.

7 Fritt oversatt fra «1. Scope» delen av ISO/IEC 29500-1:2008

56 av 62


Prosessen i komiteene er demokratiske og åpen for alle nominerte nasjonale eksperter. Ved avstemning har hvert land 1 – en – stemme.


Alle som bidrar og som er nominert av nasjonale standardiseringsorganer for deltakelse på møte i ISO/IEC JTC1/SC 34 hvor ISO/IEC 29500 blir diskutert har lik innflytelse på prosessen og resultatet som blir vedtatt i disse møtene. Alle dokumenter som produseres rundt diskusjoner og avgjørelser er tilgjengelig for alle deltakerne.

1.4.2.4 Er standardiseringsorganisasjonen en ikke-kommersiell organisasjon? Ja, ISO regnes som en ikke-kommersiell organisasjon.


Beslutningsprosessen i ISO/IEC JTC1 er åpen og transparent for alle deltagere som har tilgang til den enkelte komites dokumentregister. Alle nominerte eksperter og deltagere i nasjonale og eller internasjonale aktiviteter i forhold til disse komiteene har tilgang til alle dokumenter og alle vedtak og beslutninger som ligger til grunn for standarden.

I forhold til ISO/IEC 29500:2008 er informasjon om alle endringer og beslutninger rundt disse veldokumenterte og tilgjengelig for alle. Bakgrunnen og rasjonale for mange av de valg som ligger til grunn og ISO/IEC 29500:2008 er ikke tilgjengelig siden det var en PAS prosess fra ECMA.


Standarden er fritt tilgjengelig uten kostnad på: http://standards.iso.org/ittf/PubliclyAvailableStandards/


Ja, standarden er ugjenkallelig og er tilgjengelig uten royalties.


Nei, det er ingen forbehold knyttet til denne standarden.


ISO/IEC JTC1 er en internasjonal organisasjon.

1.4.2.10 Hvilket kontaktpunkt i Norge har standardiseringsorganisasjonen? Standard Norge er norsk kontaktpunkt for ISO ISO/IEC JTC1.

57 av 62

http://standards.iso.org/ittf/PubliclyAvailableStandards/




ISO/IEC 29500:2008 er et resultat av ECMA-376 og noen av de over 3.000 kommentarene som ble behandlet under BRM møtet våren 2008. Siden det ble foreslått over 1.000 endringer og hvor mange av disse enda ikke er en del av ISO/IEC 29500:2008 er det litt uklart hvor stabil standarden er. Det er kommet flere tekniske korrigeringer, og det er under behandling flere tillegg til standarden. Det forventes at det komme nye revisjoner av standarden hvert år framover. Det forventes at flere store internasjonale leverandører kommer til å implementere standarden og de endringer som kommer. Selve omfanget av standarden har fått kritikk på at den er vanskelig å implementere da den er på over 6000 sider.

1.4.3.2 Er tilstøtende områder, som må benyttes for å ta i bruk standarden, også standardisert? Ikke en relevant problemstilling for denne standarden.


Microsoft Office 2010 støtter standarden. Selv om de eldre binære formatene (.DOC, XLS, og .PPT) fortsatt blir støttet av Microsoft, er det OOXML som nå er standardformatet for alle Microsoft Office-dokumenter (.Docx, Xlsx og .Pptx)

1.4.3.4 Benytter de fleste samme versjon av standarden? Det er stadig flere programmer som støtter standarden, men interoperabilitetstester vi har utført viser at det er utfordringer ved samhandling mellom ulik programvare som tar standarden i bruk. Dette gjelder også i en viss grad ulike MS-office implementasjoner.

1.4.3.5 I hvilken grad er standarden bakover og forover kompatibel? ISO/IEC 29500:2008 er basert på ECMA-376 og det kan hevdes at den er bakover kompatibel med kontorstøtteformater brukt av Microsoft Office 97 og fram til i dag.


Det er forholdsvis uproblematisk å konvertere fra OOXML til PDF eller HTML. Det er derimot utfordringer knyttet til konvertering til ODF, ikke så lenge man holder seg til samme programvare, men når det konverterte dokumentet skal benyttes av annen programvare. Utfordringene er større når det gjelder konvertering til ODF, fordi man skal beholde mer funksjonalitet enn når man konverterer til andre format.


Det finnes mange standarder for å beskrive dokumentformater, en av de mest kjente i dag er HTML.

Det er utviklet mange forskjellige standarder for å beskrive både generelle og mer spesielle dokumentstrukturer, fellestrekk mellom alle disse standarder er at de bygger på prinsipper fra ISO 8879 (SGML) som senere er videreført i XML og tilstøtende standarder som Xlink og Xpointer, XSL og XSLT. Som eksempel kan nevnes ISO/IEC 12083 som beskriver bøker, artikler og serier. Et generelt

58 av 62


prinsipp som ligger til grunn for mange av disse formatene og som er avgjørende for deres anvendelsesområde er separasjoner mellom innhodet/semantikken og hvordan denne skal presenteres. ISO/IEC 29500 og ISO/IEC 26300 og HTML.

Basert på var forståelse av ODF og ISO/IEC 29500:2008 vil vi hevde at de er overlappende og dekker samme behov.

Stryken til ISO/IEC 29500:2008 er at denne beskriver filformater til Microsoft på en troverdig måte, noe som også sikrer konvertering av dokumenter fra Microsoft Office 97 og fram til i dag.



Offentlige virksomheter har behov for å håndtere redigerbare dokumenter og å publisere nettleserbaserte tjenester. OOXML kan benyttes til begge deler, men er best egnet som et redigerbart dokumentformat.


Dette er både interne og eksterne behov.

1.4.4.3 Har standarden nødvendige kvalitet – løser den nok, er den entydig nok? Standarden har meget god kvalitet knyttet til å være et redigerbart dokumentformat. Det er ikke like godt egnet som et format for nettleserbaserte tjenester. Her tilbyr formatet mindre funksjonalitet og fleksibilitet enn HTML.

1.4.4.4 Legger standarden begrensninger på offentlig sektor? Standarden legger begrensninger på offentlig sektor ved at den setter større krav til programvare og programvareplattform enn det bruk av for eksempel HTML gjør. I tillegg legger bruk av formatet noen begrensninger i forhold til funksjonalitet i nettleserbaserte tjenester sammenlignet med HTML.

1.4.4.5 Følger standarden krav i tilknytning til universell utforming? Det er «tilgjengelighets»-elementer som kan brukes for å gi mer informasjon til brukere med spesielle behov. Hvordan støtteteknologi gis tilgang til denne informasjonen er avhengig av den plattform og det verktøy som brukes for å lese informasjonen. Det er gjort forbedringer fra ECMA-376 til ISO/IEC 29500:2008 ned tanke på informasjon som kan legges inn for å gjøre informasjon mer tilgjengelig.

Tester som er utført viser at OOXML på lik linje med andre standarder har funksjonalitet for å tilby tilgjengelighet, men ikke all programvare som benytter standarden har implementert funksjonaliteten på like god måte.


Standarden passe godt inn i overordnede arkitektoniske prinsipper for offentlig sektor.

59 av 62


1. Tjenesteorientering: Siden denne standarden er basert på XML vil det være mulig å utvikle tjenester som kan prosessere og hente ut relevant informasjon direkte fra dokumentene. I praksis er vel standarden mindre egnet for dette sammenlignet med HTML.

2. Interoperabilitet: Siden denne standarden er basert på XML vil det være mulig å utveksle informasjon mellom systemer som implementerer denne standarden, det vil også være mulig å transformere dokumenter basert på dette formatet over til andre formater. I praksis viser det seg at det er interoperabilitetsutfordringer mellom ulik programvare som implementerer standarden.

3. Tilgjengelighet: Siden denne standarden er basert på XML, kan informasjonen behandles av alle verktøy som kan lese XML filer, dette sikrer en relativt høy grad av tilgjengelighet. Hvor stor del av informasjonen som er tilgjengelig er avhengig av dokumentformatets mulighet til å beskrive tilgjengelighetsinformasjon.

4. sikkerhet: Sikkerhet til denne standarden ivaretas av de verktøy som implementerer standarden.

5. Åpenhet: Siden dette er standardiserte dokumentformater er de åpne for alle. 6. Fleksibilitet: Siden dette er en standard som beskriver format på dokumenter som

produseres, er ikke standarden avhengig av ett bestemt verktøy eller en bestemt plattform, dette sikrer fleksibilitet.

7. Skalerbarhet: Det er ingen begrensninger på størrelsen av de dokumentene som kan produseres i henhold til denne standarden.

8. Enhetlig brukergrensesnitt: Brukergrensesnittet er ivaretatt av de verktøy som implementerer denne standarden.


Offentlig sektor har et behov for en standardisert beskrivelse av sine dokumentformater, hvor dokumentformatene er basert på åpne standarder. Denne standarden møter dette behovet.

De virksomheter som i dag benytter Microsoft Office av nyere versjon, eller hvor det er installert ett programvaretillegg for lesing og skriver av doxc filer, benytter i dag ECMA-376 standarden.


Standarden har meget stor utbredelse blant offentlige virksomheter når det gjelder håndtering av redigerbare dokumenter. Standarden har noe utbredelse når det gjelder tilgjengeliggjøring av nettleserbaserte tjenester.


Utover forskjellen mellom de operativsystemer som brukes og verktøyene for produksjon av innhold i ISO/IEC 29500:2008 kreves det ikke et spesielt funksjonsnivå for å utnytte og produsere informasjon i forhold til denne standarden.

1.4.4.10 Krever bruken av standarden samme verktøy hos begge parter? Bruken av standarden krever at du har en kontorstøtteprogramvare eller annen programvare med støtte for OOXML.

60 av 62


1.4.4.11 Hvilken bevaringsevne har standarden (jf. arkivlovgivning osv.)? I følge Forskrift om utfyllende tekniske og arkivfaglige bestemmelser som behandler offentlige arkiver § 8-17: Godkjente dokumentformater ved avlevering og deponering, er ikke OOXML nevnt som et godkjent dokumentformat ved avlevering og deponering for elektroniske dokumenter med tekst og bilde.


1.4.5.1 I hvilken grad bidrar standarden til interoperabilitet? ISO/IEC 29500:2008 bidrar til økt interoperabilitet mellom kontorstøtteprogrammer og fagsystemer, og til økt utveksling av informasjon mellom disse. Når det gjelder nettleserbaserte tjenester har standarden begrenset utbredelse særlig på mobile plattformer. Det er også interoperabilitetsutfordringer mellom ulik implementering av standarden.

1.4.5.2 Hvordan bidrar standarden til fleksibel anvendelse på tvers av flere OS-plattformer? Det finnes implementasjon av standarden på ulike operativsystem. Vi er usikre på utbredelsen knyttet til linux-løsninger.


OOXML vil ikke gi dårligere samhandling enn bruk av alternativet HTML.


OOXML har utsøkt kvalitet når det gjelder funksjonalitet for redigerbare dokumenter, men når det kommer til funksjonalitet for nettleserbaserte tjenester er nok HTML bedre. I tillegg gir HTML bedre utbredelse og tilgjengelighet.

1.4.5.5 I hvilken grad vil standarden bidra til å effektivisere offentlig sektors tjenestetilbud? Standarden vil ikke kunne bidra til effektivisering av offentlig sektor i like stor grad som HTML.

1.4.5.6 I hvilken grad vil standarden gi IT-arkitektoniske og systemtekniske konsekvenser? Bruk av standarden gir IT-arkitektoniske konsekvenser. Integrasjoner må skje basert på dokument formatet, eller det må etableres parallelle standarder, noe som de fleste kontorstøtteprogramvarer har gjort for integrasjon mot for eksempel fagsystem. Dette er også gjort for å oppnå mer funksjonalitet enn det som oppnås gjennom dokumentformatet alene.


De store økonomiske følgende er knyttet til arbeidet med forvaltningsutvikling. Om tjenestene baserer seg på den ene standarden eller den andre har ikke så mye å si, men det krever nok noe mer omskolering av offentlig ansatte, hvis man skal basere seg på OOXML enn HTML. De store effektene er avhengig av funksjonalitet og tilgjengelighet på tjenestene. Alternative standarder vil score bedre på disse områdene.


Det å peke på denne standarden vil nok styrke Microsoft sin markedsposisjon til en viss grad, både på kontorstøtteprogramvare og på mobile løsninger. Men den vil også bidra til å pushe leverandører

61 av 62


til å ta i bruk dette åpne formatet også i andre løsninger, noe som vil bidra til bedre konkurranse på andre områder.

Når det gjelder nettleserbaserte tjenester, vil de fleste som har kompetanse på området stille noenlunde likt. HTML vil derimot være et bedre valg for markedsutviklingen på området.


Bruk av standarden vil kreve støtte for formatet i brukerutstyr og programvare. Ikke alle har det i dag, og det vil gjøre at enkelte må anskaffe dette. Det vil derfor bli en ekstrakostnad for en god del brukere, hvis man peker på OOXML. I tillegg vil tjenester bli mindre tilgjengelig på alle typer brukerutstyr, noe som igjen vil ha en kostnad fordi man ikke kan gjøre tjenestene på det utstyret man ønsker til den tiden man ønsker.


Ja, Microsoft vil få en styrket stilling på kontorstøtteprogramvaremarkedet og på mobilmarkedet. I tillegg vil det trolig styrke Microsoft sitt partnerprogram. Det vil også gi en dreining vekk fra nye innovative løsninger på HTML.

1.4.5.11 I hvilken grad vil standarden bidra til innovasjon? Standarden vil bidra til innovasjon, men i mindre grad enn HTML.


Elektronisk tilrettelegging av informasjon sparer bruk av papir, transport og søppelhåndtering. Dermed vil bruk av standarden gi stor positiv miljøeffekt.

62 av 62