It- og Telestyrelsen lemper på OIOXML-krav til dataudveksling

Det er ikke længere et krav, at al OIOXML-kode skal genbruges i nyudvikling af it-systemer i det offentlige. It- og Telestyrelsen lemper på dets fortolkning, så færre dele skal genbruges.

Kravene til udveksling af data mellem offentlige it-systemer bliver nu lempet. Det oplyser It- og Telestyrelsen.

Dataudveksling skal foregå via OIOXML, og det har hidtil været et krav, at al OIOXML-kode skulle genbruges, når der skulle udvikles nye systemer. Den fortolkning af aftalen om åbne offentlige standarder ændrer It- og Telestyrelsen nu.

I stedet for at genbruge al OIOXML-kode, så bliver det fremover kun et krav at genbruge kernekomponenter og domænestandarder.

De to områder er ifølge It- og Telestyrelsen de væsentligste elementer i snitfladerne mellem programmerne. It- og Telestyrelsen understreger, at det dog stadig er en god idé at genbruge så meget som muligt, men det er altså ikke længere et krav.

Lempelsen af kravene kommer efter, at der ifølge styrelsen nu er mange års gode erfaringer med OIOXML som standard for systematisk dataudveksling. Samtidig er de offentlige systemer blevet mere modne, og derfor er der mindre behov for stramme regler for syntaksen. Derfor skal indsatsen fokuseres på de områder, hvor det giver størst værdi.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Anonym

Data vs. præsentation - suk.

Prøv nu - for helvede (undskyld udtrykket) - at skelne mellem data og præsentation.

Data kan sagtens præsenteret uden formattering, og stadig bevare betydningen.

Eet af mine metiere er finans, så lad mig komme med et eksempel:

Du har gennemført følgende transaktion: Saldo: 1000 Hævet: 100 Ny saldo: 900

Mere information behøver man ikke, og den bliver hverken mere eller mindre rigtig af, at man pakker det ind i 'blip og båt'.

Ganske få bytes, og hvilken merværdi giver det at 'pakke det ind i vat og bomuld?'

  • 0
  • 0
#3 Christian Kaab Hesselholdt

Ja det er rigtigt ærgerligt, at hele OIO er bygget op om præsentation i stedet for indholdet.

Hvis den offentlige sektor havde haft modet til at definere en fast standard for fakturaer baseret på data, havde det virkelig gjort en forskel for den måde fakturaer udveksles på. Bogholderne ville foretrække ensartethed.

Når EDI går i kludder, så er det fordi der er for mange kokke, der skal have en finger med i spillet.

Jeg forstår ikke hvordan noget så simpelt som en faktura kan gøres så svært.

  • 0
  • 0
#4 Adam Arndt

@Christian: Det, du skriver handler vist om den gamle eFaktura, også kaldet OIOXML Elektronisk Regning?

I så fald bør jeg vel gøre dig opmærksom på, at denne nyhed ikke handler om eFaktura, men om de generelle retningslinjer for dataudveksling i XML mellem offentlige myndigheder.

Praksisændringen har ikke noget med den gamle eFaktura (som jo for øvrigt er ved at blive udfaset) eller for den sags skyld med OIOUBL at gøre, og da jeg selv kun perifert arbejder med nemHandel bør jeg være forsigtig med at svare på dine kommentarer.

Dog kan jeg ikke undlade at undre mig over, at du kritiserer eFaktura for at have for meget præsentationsindhold, da disse standarder mig bekendt netop er udviklet til at kunne sende data uafhængigt af præsentationen af dem.

Derudover deler jeg ikke din opfattelse af, at fakturaer er simple - tværtimod har jeg med meget begrænset indsats kunnet konstatere en imponerende kompleksitet i forretningsbehovene til indhold og struktur i en faktura.

Med venlig hilsen

Adam Arndt Center for Digitalisering, IT- og Telestyrelsen

  • 0
  • 0
#5 Christian Kaab Hesselholdt

Tak for din rettelse, hvis jeg har gjort mig skyldig i kommentere på et forkert format. Mín indgang til OIOXML er som administrationschef i en mellemstor håndværsvirksomhed. Jeg ville meget gerne have haft det gamle eFaktura til at virke, men ingen af vore leverandører var med på ideen. Så fik vi besked fra staten om, at vi alle skulle kunne danne OIOXML-fakturaer, hvis vi ville handle med offentlige virksomheder. Jeg fik oprettet et ean-nummer og købte en oversætter, så vi kunne begynde at registrere alle vore fakturaer ind. Når grosisterne var nødt til at arbejde efter et fast defineret format, kunne de jo lige så godt sende fakturaer til os i det format også. Men ak, der var mere end en mulighed for at forveksle ordrenumre, sagsnumre bestiller og så videre. Så vi måtte alligevel foretage tilretninger for hver enkelt afsender. Afgifter bliver specificeret skiftevis med og uden moms. Det er selvfølgelig en leverandørfejl, men hvordan har leverandøren kunne få godkendt sit format, uden at bruge det rigtigt. Vi læser fakturaer ind fra en halv snes leverandører nu, men ville meget gerne videre. Der er mange penge at spare ved at få overført fakturaer frem for at taste dem ind med håndkraft. Men så skal formatet være entydigt. Så jeg må svare både ja og nej fakturaer er komplicerede, men de er ikke mere komplicerede end man gør dem til. Jeg var tidligere med til at læse fakturaer ind ved det gammeldags edifakt tror jeg det hed. Men der var også for mange valgmuligheder, således at hver enkelt ny leverandør krævede ny programmering. Jeg mener stadig, at den offentlige sektor har forspildt en chance for at definere en entydig standard. Jeg skal som "lægmand eller selvlært programmør" selvfølgelig være forsigtig med at kritisere eksperterne. Men det er altså mig, der sidder med hænderne nede i suppen til daglig, og ser mulighederne gå tabt. Ikke primært fra IT-siden men mere fra den administrative og økonomiske vinkel.

Med venlig hilsen Christian Kaab Hesselholdt Administrationschef Malerselskabet SBM A/S

  • 0
  • 0
#6 Morten Hattesen

En mindre justering m.h.t. krav om genbrug af NDR skemaer (som jeg forstår at historien handler om), er ganske fint.

<SurtOpstød>Hvis der så også kunne blive ryddet op i reglerne for versionering af XML Schemaer/typer som har ændret sig fundamentalt tre gange i OIOXML's levetid, og få NDR reglerne publiceret i deres helhed i stedet for addendums der ændrer på addendums, der ændrer på ... så man kan læse reglerne i ET dokument, så ville livet blive lidt lettere for udviklerne. Men det er nok for meget at håbe på.</surtOpstød>

  • 0
  • 0
#7 Adam Arndt

Jeg kan ikke helt se, hvad det er for en "oprydning" i versioneringsreglerne, du efterlyser - især ikke, når du samtidig kritiserer, at de er blevet ændret?

Det gældende regelsæt (NDR 3.2) er kun publiceret som et helt, sammenhængende dokument. Det kan læses på Digitalisér.dk (http://digitaliser.dk/resource/56357) og www.itst.dk (http://www.itst.dk/it-arkitektur-og-standarder/standardisering/datastand...).

  • 0
  • 0
#8 Anonym

Adam, Christian

I har fat i et af de helt store problemer i digitaliseringen.

Christian sidder på bunden af en lille kasse og tager udgangspunkt i hvad der er lettest for ham. "At indrette alle efter den samme standard".

Adam sidder med problemet at verden på ingen måde er hverken homogen eller uforanderlig.

Det giver et dobbeltproblem. a) Man kan ikke standardisere i en simpel faktura så alle kan passe ind i Christians model.

b) Man har behov for at gøre det nemt for den enkelte virksomhed.

En løsning er meta-standardisering kombineret med en modelbaseret implementering, dvs. at man løfter selve standarden op i abstraktion og undgå at eliminere frihedsgrader samtidig med at man variabelt arbejder med implementeringer indenfor rummet som modelbeskriver sig op mod meta-standarden, dvs. man undgår at fastlåse noget i selve standarden ud over det allermest nødvendige for til gengæld at kunne udskifte.

XML-standardiering går i den retning, men slet ikke langt nok.

Uden at gøre mig specielt klog på de mange varianter af fakturaer, så er f.eks. identitet et område som klart har behov for en langt mere fleksibel tilgang.

Vi kan end ikke være sikker på at der skal cvr-nummer på en faktura (og 100% sikker på at der ikke skal cpr-nummer) fordi det lækker leverandør id (og kundeid) til serviceproviders og skaber dermed alvorlige datasikkerhedsproblemer hvis fakturaservices skal understøttes af cloudservices.

Det helt store problem er mellemmænds interesse i at profilering af kunder og leverandører. Fordi disse har en kommerciel interesse i at svække deres relationers sikkerhed og forhandlingsposition - hvem et går værst ud over afhænger af forretningsmodellen - mob-sourcing favoriserer kunde mod leverandørens bekostning, kundeprofilering favoriserer udbyder på kundens bekostning. Fælles er at de favoriserer gatekeeperen på markedets bekostning.

Men det er både for nemt at sidde på bunden af en kasse og bede om en fastlåst enhedsstandard og samtidig fair at man beder om en standard så man kan kommunikere uden unødvendig manuel involvering.

Den store øvelse - som man på ingen måder kommer uden om - er "drivere" eller "modelbeskrivelsen" som muliggøre at ellers uforenelige "fakturaformater" kan oversættes via metastandarden.

Og ja - man mister potentielt semantisk information som kunne være undgået ved en mere rigid standardisering, men det gavner ikke at eliminere frihedsgraderne, når vi taler standarder, kritiske mellemprodukter og kommunikationsknudepunkter. Det ødelægger konkurrence og innovation.

  • 0
  • 0
#9 Christian Kaab Hesselholdt

Ja selvfølgelig ser jeg tingene ud fra mit udgangspunkt. Men så snæver er min kasse heller ikke. I et bogholderi sidder man hver dag med kunder der skal behandles individuelt.

Og jeg er godt klar over at der er kommercielle interesser i at tingene ikke er for enkle.

Jeg ville syntes det var fint med 2 standarder, en enkel standard, der dækkede 95 % af alle fakturaer, og så et ekspertformat til dem der alligevel skal behandles manuelt.

  • 0
  • 0
#10 Anonym

Christian

Det er ikke 2 standarder, men en standard i 2 lag - et meta-lag og et "instanslag" eller "løsningslag", Sidstnævnte er bare en konkret implementering, men den skal være interoperabel med de fleste andre implementeringer via en modelbeskrivelse mod meta-laget.

Det betyder at nogen vil gå videre end din (f.eks. branchespecifik EDI) og nogen vil ikke gå så langt (kontantfaktura).

Du kan se det lidt ligesom printerdrivere - for 20 år siden var printere et helvede. Så meta-standardiserede man printere og brugte drivere til at modelbeskrive. Det betyder ikke at alle printere kan det samme (farver, dobbeltsiden, skaleret, opløsning, direkte netværksopkobling, storage/printserver, sortering, hæftning, sikkerhed, økonomi, rapportere mangel på tonere etc. etc) - men de fleste printere kan printe et standarddokument.

  • 0
  • 0
#11 Christian Kaab Hesselholdt

Jeg kan godt huske printerproblemerne i "the ugly old days".

Da man opfandt damptoget, opfyldte det et stort behov. Men det opfyldte ikke alle behov. Der er stadig plads til busser, biler og cykler.

Men det kunne godt betale sig at lægge sin virksomhed ud til jernbanelinien.

Hvis jeg vil have rationaliseringsgevinsten, må jeg også indrette min virksomhed efter det.

Hvis du har for mange valgmuligheder, vil du også få mange fejl.

  • 0
  • 0
#12 Anonym

Christian

Det er ikke et enten / eller,

Problemet er at dette forbudssamfund har en rigtigt grim tendens til at diktere planøkonomisk top-down standardisering. Det er selve hovedårsagen til at Danmark går i stå.

Gevinsten i integrationen mere end ædes op af stive og ufleksible strukturer som ikke kan tilpasse sig.

Skal du planlægge en rejse fra a til b så KAN du gå gennem forskelle "legs", men disse legs blander sig ikke i indholdet i andet end de ydre rammer. En container "pakkes" ind.

Udfordringen er at vi her taler om hvad der sker når vi skal skal "pakke ud", dvs. få systemer udviklet til meget forskellige formål til at tale sammen. Det er jo ikke bare ERP-system til ERP- system, men både reskontosystemer med meget specialiserede produktbehov i den ene yderlighed og manuelle rutiner i den anden yderlighed.

jeg vil ikke gå videre her - blot påpege at one-size-fits.-all oftest fører til one-size-fits-nothing.

  • 0
  • 0
#13 Anonym

Adam, jeg tager hatten af for din observation, uagtet jeg ikke er sikker på du forstår impacten af din udtalelse:

Derudover deler jeg ikke din opfattelse af, at fakturaer er simple - tværtimod har jeg med meget begrænset indsats kunnet konstatere en imponerende kompleksitet i forretningsbehovene til indhold og struktur i en faktura.

Jo, du har helt ret - en faktura er ikke en faktura, men indeholder også flere neveauer af oplysningger.

Jeg har selv lavet systemer, hvor vi opererede i 3 niveauer: 1) Fakturamodtager Altså der hvor økonomien er. 2) Ansvarlig. Dvs. hvem står for indkøbet 3) Leveringssted. Ja, det er vel nærmest logik for burhøns - der hvor varen bliver afleveret.

Ja, ja, nu vil du nok forsvare OIOXML, men jeg var selv med til at give impulser, og kender ganske udemærket personkredsen.

Jeg har jo tavshedspligt, så jeg kan ikke udtale mig, men nogle gange fristes man til at genbruge det gamle udtryk: "Det er ikke gravitationskraften fra studenterhuen, der trykker folk platfodet".

Ingen nævnt, ingen glemt - seek for yourself...

  • 0
  • 0
#14 Morten Hattesen

Jeg kan ikke helt se, hvad det er for en "oprydning" i versioneringsreglerne, du efterlyser - især ikke, når du samtidig kritiserer, at de er blevet ændret?

Det gældende regelsæt (NDR 3.2) er kun publiceret som et helt, sammenhængende dokument. Det kan læses på Digitalisér.dk

Og, så lad mig skrive i detaljer, hvad jeg mener:

Versioneringsreglerne er blevet vendt på hovedet af to omgange (NDR 3.0->3.1->3.2), uden at bagrunden for beslutningen er beskrevet, eller der er skrevet nogen dokumentation der beskriver reglerne i detaljer.

De links du henviser til er IKKE den samlede beskrivelse af reglerne. Det er "referencelisten". Det fulde dokument, hvor der forklares hvorfor reglerne er, som de er, og som indeholder eksempler og forklaringer er ikke blevet publiceret sidenNDR version 3.0 (så vidt jeg husker). Ligeledes er reglerne FX "OIO-6" blevet om-nummereret (helt håbløst efter min mening at omnummerere regler mellem to revisioner (3.0->3.1->3.2)). Dette gør det fuldstændigt umuligt at benytte den gamle "fulde" regelsamling.

Og så en lille morsomhed: Efter at have navigeret til den link du sendte: http://digitaliser.dk/resource/56357 forsøgte jeg at finde noget at "klikke på". Efter at have gennesøgt hele siden fandt jeg endelig en lille orange ikon med to nedadvendte pile, uden tool-tip. Det er en link til ressourcen http://digitaliser.dk/resource/56357/artefact/NDR32.htm som ikke serves med MIME type "text/html", hvilket betyder at den ikke er umiddelbart læsbar (i Chrome i hvert fald), men skal en tur rundt om filsystemet. Ikke er skolebogseksempel på brugervenlighed ;-)

Hvis du ønsker flere (konkrete) eksempler står jeg meget gerne til rådighed.

  • 0
  • 0
#15 Morten Hattesen

@Stephan:

Kunne du ikke godt, bare en gang imellem, lade være med at bruge ethvert offentligt standardiseringstiltag eller ethvert debatindlæg der omhandler disse, til at male fanden på væggen, fremture med konspirationsteorier og fremmane spøgelser.

Jo, meget kunne gøres meget bedre, men der må ofte indgås en del kompromiser for at få løsningerne ud til offentligheden, og en lidt pragmatisk holdning får trods alt hjulene til at køre rundt.

  • 0
  • 0
#16 Anonym

@ Morten

Hvor maler jeg fanden på væggen? Fordi jeg taler for fleksibilitet i standardiseringen?

Jeg er dårligt nok kritisk overfor standarden, men påpeger blot modsætningen i 2 andres indlæg og hvordan de kan forenes.

Men bortset herfra, ethvert standardiseringstiltag som umuliggør en sikker handels- eller kommunikationstransaktion er et dårligt standardiseringstiltag. Det gælder specielt enhver standard som tillader sig at antage identifikation.

  • 0
  • 0
#18 Anonym

@ Morten

At bruge udtryk som "paranoid" er ren Ad Hominem - fordi det antyder noget om personen uden at argumentere. Jeg holder mig til det faktuelle og lader andre om det sensationelle.

For det andet er det i givet fald ikke mig som er den paranoide. Det er embedssystemet som konstant antyder at de er "nødt til" at anvende overdreven magt fordi xxx kan ske (sæt selv ind - pædofilli, terror, skattesnyderi, socialt svindel, hastighed, etc.) - dårlige undskyldning med ringe sandsynlighed som misbruges som argument til dårligt teknologidesign.

For det tredje er min primære pointe at den samfundsdestruktive tilgang til digitalisering gør os fattige fordi al den one-size-fits-all hardkodning både ødelægger samfundets konkurrenceevne og sikkerheden, dvs. både samfundsøkonomien og (rets)principperne. Vi har simpelthen ikke råd til at betale for den ineffektivisering som "andengenerations" digitalisering medfører. Man spilder ikke bare investeringen men vores fremtid på gulvet.

For det fjerde kritiserer jeg kilden til problemet i stedet for at spilde andres tid på at tale udenom og fedte rundt i relativt ligegyldige detaljer.

Det er faktuelt at man ikke er opmærksom på at dårlig teknologidesign i dag er værre end dårlig lovgivning. Dårlig lovgivningen kan ignoreres eller omgås. Teknologidesign binder os og bygger legacy, dvs. spilder penge og velfærd.

Problemet er - som jeg ser det - den naive "vi stoler på", men Staten i eksponentielt stigende grad spilder vores skattekroner og konkurrenceevne på bureaukratisme og planøkonomi. Den offentlige sektor bliver angiveligt ca. 1% mindre produktiv år for år - regn lidt på det og husk at gange op med det offentlige forbrug både absolut og relativt til resten af samfundet.

Men hvad er din pointe - at vi bare skal lave gode miner til slet spil, "hvis du ikke er med os så er du imod os" eller at vi bør holde debatten til de ligegyldige detaljer?

  • 0
  • 0
#19 Christian Kaab Hesselholdt

Er der en chance for at denne debat går i løsningsmode, i stedet for at placere fejl ?

Mit argument er at almindelige bogholdere og regnskabschefer går død i de komplicerede filformater og fine tekniske betegnelser. Det skader os alle.

Hvis et format skal kunne dække alt, skal det være fejlfrit, ellers er det bedre at sænke ambitionerne.

Lad os få et simpelt format, der dækker 95 % af alle fakturaer som de ser ud i dag. Og lav så et format til eksperterne, til de sidste 5 % vi alligevel kommer til at bogføre manuelt de næste mange år.

  • 0
  • 0
#21 Adam Arndt

@Morten De to links peger på det fulde regelsæt.

Det er korrekt, at der til NDR 3.2 ikke er udarbejdet eksempler og uddybende forklaringer, men det ændrer ikke ved, at reglerne er dem, der står i dokumentet.

Det er også derfor, at reglerne er omnummereret - for at vise, at der er tale om et komplet sæt af regler i sammenhæng. Det er naturligvis rigtigt, at en bibeholdelse af regel-numrene ville gøre det lettere at sammenligne med baggrundsbeskrivelserne i NDR 3.0 uden at skulle tænke, men da en del af beskrivelserne i NDR 3.0 ikke længere er dækkende eller korrekte, ville det ikke nødvendigvis være nogen udelt fordel alligevel.

http://www.itst.dk/it-arkitektur-og-standarder/standardisering/datastand... er en diff-liste med oplysning om, hvilke regler, der er ændret eller slettet fra version 3.1R2 til 3.2. Herunder begrundelsen for ændring af versionerings- og namespace-reglerne. Jeg har her til morgen også lagt notatet på ressourcen på Digitalisér.dk for at gøre det lettere at finde.

At du ikke kan lide designet på Digitalisér.dk er naturligvis beklageligt. Din konkrete anke om, at HTML-dokumenter ikke åbnes "inline" men prompter om download skyldes, at enhver skal kunne oprette en profil på Digitalisér.dk og lægge ressourcer ind. Dermed er der også risiko for, at der uploades ondsindede scripts, hvorfor sitet er designet til ikke at eksekvere HTML eller andre visse andre typer. Det er naturligvis ærgerligt, men det er et bevidst designvalg for at beskytte brugerne af sitet.

  • 0
  • 0
#22 Morten Hattesen

@Adam:

Det er korrekt, at der til NDR 3.2 ikke er udarbejdet eksempler og uddybende forklaringer, men det ændrer ikke ved, at reglerne er dem, der står i dokumentet.

Vi bliver nok ikke enige her. Den eksisterende "regelsamling" som du refererer til kan IKKE STÅ ALENE. Det er min påstand, at det vil være komplet umuligt for en "ny" person at kunne gennemskue regelsættet uden at have adgang til en person med OIO XML kendskab og/eller at læse det oprindelige NDR 3.0 dokument, der underbyggede regelsættet og leverede eksempler. Så reelt er OIO-XML modellering nu låst til få centrale offentlige aktører og få større konsulenthuse, hvilket jeg mener er et problem.

Det er også derfor, at reglerne er omnummereret - for at vise, at der er tale om et komplet sæt af regler i sammenhæng.

Jeg kan stadig ikke se nødvendigheden i at omdøbe af reglerne mellem revisioner af NDR "OIO-x" -> "OIO-y" for at det skal være et "komplet sæt". Hvorfor skulle fortløbende nummerering (uden "huller) være mere komplet?

At du ikke kan lide designet på Digitalisér.dk er naturligvis beklageligt. Din konkrete anke om, at HTML-dokumenter ikke åbnes "inline" men prompter om download skyldes, at enhver skal kunne oprette en profil på Digitalisér.dk og lægge ressourcer ind.

Det drejer sig ikke om hvorvidt jeg ikke "kan lide" digitaliser.dk (ups, jeg glemte accent-tegnet over e'et) men at det er dybt uprofessionelt set fra et usability synspunkt. At det skal være svært at finde linket til indholdet (gemt bag en minimal grafisk ikon uden tool-tip) er for mig ubegribeligt.

  • 0
  • 0
Log ind eller Opret konto for at kommentere