lfljâçãáí Éå=Ó=a~ÖëçêÇÉå=

Transkript

1 lfljâçãáí Éå=Ó=a~ÖëçêÇÉå= Dagsorden, OIO-komitéens møde den 3. juni 2010 = a~öëçêçéå= lfljhçãáí Éåë=NPK=ã ÇÉ= ÇK=PK=àìåá=OMNM= Mødet afholdes d. 3. juni 2010 fra kl. 13, IT- og Telestyrelsen, Holsteinsgade 63. a~öëçêçéå= = 1. Velkomst 2. Godkendelse af dagsorden og referat (Bilag 1) (B) 3. Meddelelser 4. Orientering om Videncenter for åbne standarder og open source ved Cecile Christensen og Mikkel Leihardt, ITST (O) 5. Fortolkning af OIOXML-reglerne (Bilag 2) (B) 6. Eventuelt Punkter mærket B, D, E, O er til henholdsvis (B) Beslutning (D) Drøftelse (E) Efterretning (O) Orientering = OIO-komitéen for it-arkitektur og standardisering koordinerer offentlige initiativer inden for standardisering og it-arkitektur, og består af repræsentanter fra ministerier, kommuner og regioner. Digitalisér.dk/group/11917

2 lfljâçãáí Éå=Ó=oÉÑÉê~í= Referat, OIO-komitéens møde den 23. april 2010 = oéñéê~íi= lfljhçãáí Éåë=NOK=ã ÇÉ= ÇK=OPK=~éêáä=OMNM= Mødet afholdtes d.23. april fra kl. 13 til 15:30 i Direktionens mødelokale, 4 sal, IT- og Telestyrelsen, Holsteinsgade 63. Til stede: Cecile Christensen, ITST, formand Mikkel Leihardt, ITST, næstformand Søren Peter Nielsen, ITST, fast medlem Peter Falkenberg, KL Benjamin Romney Rasmussen, Erhvervs- og Selskabsstyrelsen Kristian Hjort-Madsen, Den Digitale Task Force Frank Carvalho, SKAT Jesper Nielsen, Indenrigs- og Socialministeriet Jan Hjelmager, KMS Kaspar Didriksen, Miljøstyrelsen Mogens Pedersen, Integrationsministeriet Henriette Traulsen, Direktoratet for Kriminalforsorgen Svend-Åge Westphalen, Servicestyrelsen Jan Brown, ITST Martin Jensen Buch, ITST Peter Gylden Houmann, ITST Per de Place Bjørn, ITST, referat a~öëçêçéå= = 1. Velkomst 2. Godkendelse af dagsorden og referat (B) Dagsorden og referat godkendt uden kommentarer. 3. Meddelelser Mikkel Leihardt præsenteret som ny næstformand. 4. Dokumentboks (O) Anders Find, Økonomistyrelsen holdt oplæg om Dokumentboks (præsentationen er vedlagt) Komitéen stillede spørgsmål om Dokumentboks sikkerhedsløsning; Dokumentboks udveksler meddelelser med certifikatbaseret HTTPS, sådan som beskrevet i OIOREST. Komitéen diskuterede, at Dokumentboks på mange måder er en it-understøttelse af traditionel brevbaseret forvaltningsproces, frem for en egentlig selvbetjeningsløsning. I relation hertil ses OIO-komitéen for it-arkitektur og standardisering koordinerer offentlige initiativer inden for standardisering og it-arkitektur, og består af repræsentanter fra ministerier, kommuner og regioner. Digitalisér.dk/group/11917

3 lfljâçãáí Éå=W=oÉÑÉê~í=W=OMNMMQOP= = der især problemer med at understøtte sagsgange, hvor ikke alle borgere har accepteret modtagelse af dokumenter elektronisk. Her er der altså behov for både breve og Dokmentboksmeddelelser lovændringer kunne være nødvendige for at afskaffe sådanne problemer. Dokumentboks har en specifik berettigelse som opbevaringssted for dokumentation og afgørelser. 5. OIOXML (D) Per de Place Bjørn, ITST, præsenterede ITSTs forslag til omlægning af OIOXMLstandardiseringsparadigmet (præsentationen er vedlagt). ITST vurderer, at OIOXML-baseret datastandardisering ikke har haft tilstrækkelig gennemslagskraft til at realisere eller dokumentere standardiseringsgevinster. For at afhjælpe dette problem, har ITST drevet projektet Modelbaseret Standardisering (MS). MS-projektet har gennemført et vellykket proof of concept forløb med projektet Sag og Dokument, men MS-koncepterne har vist sig meget komplekse. En nødvendig ekstern efterspørgsel efter projektets produkter har af den grund været fraværende, hvorfor ITST vælger ikke at videreudvikle MS-værktøjet på nuværende tidspunkt. Følgende forslag til tiltag blev præsenteret med henblik på drøftelse i komitéen: 1) Snitfladestandardisering med OIOXML bliver gjort valgfrit i forbindelse med nyudvikling OIOXML for kernekomponenter og domænespecifikke standarder fastholdes som obligatoriske. 2) Domænernes mulighed for at sætte standarder styrkes. 3) Der stilles krav om dokumentation af de udviklede snitflader. 4) Vejledningen om anvendelse af OIOXML som åben, obligatorisk standard justeres i overensstemmelse hermed. Komitéens diskussion kan deles i en række temaer; Vil folketingsbeslutning B103 kunne overholdes med de foreslåede ændringer? Det er ITST s klare vurdering, at både folketingsbeslutningen og den efterfølgende aftale om åbne, obligatoriske standarder fortsat overholdes. Intentionen i beslutningen at sikre åbenhed og tilgængelighed styrkes, qua kravet om dokumentation af snitflader. ITST s rolle som normgivende og kontrollerende i forhold til standardisering vil blive savnet Der var en bekymring for at smide barnet ud med badevandet at den forståelse for snitfladestandardisering, som er opnået i det mindste i nogle domæner vil gå tabt, og at myndighederne vil stå uden mulighed for at stille krav til udvikling af it, samt efterfølgende være uden mulighed for at evaluere det leverede vis a vis en standardiseringsdagsorden. Flere medlemmer formulerede et behov fra deres små eller mellemstore myndigheder for, at der fra centralt hold bliver opstillet retningslinjer for hvordan interoperabilitet bedst opnås. ITST udtrykte mild forundring over disse ønsker om centralisering og normsætning, normalt høres kun beklagelser over at der bliver stillet krav, og over udformningen af disse. Flere medlemmer tilbød at bidrage med konkrete eksempler på hvordan OIOXML bidrager og giver værdi i konkrete projekter. 2

4 lfljâçãáí Éå=W=oÉÑÉê~í=W=OMNMMQOP= = Standardisering og harmonisering af begreber må ses som et langsigtet samfundsgode, som ikke nødvendigvis kan realiseres inden for en kortsigtet business case baseret arbejdsmetode. Det blev nævnt, at det muligvis var følg eller forklar klausulen på B103, som var en væsentlig grund til, at der ikke kunne spores moment i standardisering at det simpelthen var alt for nemt at lade være. Flere aktører havde oplevet, at der meget hurtigt kan høstes standardiseringsfordele ved gentagelser af arbejdsgange i forbindelse med indkøb. I enkelte domæner har leverandørerne vænnet sig til, at OIOXML standardisering er efterspurgt og kan medføre fordele. Modelbaseret Standardisering Flere medlemmer mente, at Modelbaseret Standardisering indeholdte skridt i den rigtige retning mod en modernisering af standardiseringsmetoderne, men medgav at de ikke havde haft ressourcer til aktivt at støtte projektet. Der var flere tilkendegivelser af, at standardisering nødvendigvis må foregå på begrebsniveau i fremtiden. Dårlig kommunikation/udviklingsmåde fra ITST ITST har i sin tilgang til standardisering haft et for lille fokus på standardisering i praksis. Fokus har været på den teoretiske side af standardisering, med for lidt inddragelse af komitéens medlemmer eller andre standardiseringsaktører. Specifikt har der været savnet kommunikation om standardisering på beslutningstagerniveau. Fremtidig form af et standardiseringsparadigme Der var udbred efterspørgsel efter at blive inddraget i udformningen af et fremtidigt standardiseringsparadigme. Enighed om at en forenkling af de eksisterende regler vil være kærkommen. Flere medlemmer tilsluttede sig, at det eksisterende paradigme muligvis var for tungt, men der var stadig behov for styring fra ITST. Nogle talte for, at OIO-komitéen kunne være en for sluttet kreds til at diskutere snitfladestandardisering; at den i vidt omfang består af repræsentanter for organisationer, som har taget standardisering til sig. I den umiddelbare fremtid vil OIO-sekretariatet fortsætte denne diskussion på Digitalisér.dk, hvorefter komitéen vil blive stillet overfor konkrete ændringsforslag. Der opfordres til, at medlemmerne af OIO-Komitéen deltager i debatten. 6. Standard for netpublikation (B) Peter Gylden Houmann, ITST, præsenterede forslaget om at optage standarden for netpublikation i OIO-kataloget med anbefalelsesgraden anvendelig en statusændring i forhold til dens tidligere status som obligatorisk for netpublikationer med argumenter om, at standarden er dyr at bruge, det er uklart, hvilke typer dokumenter den gælder for, og dens ophæng er uklart. Yderligere har den teknologiske udvikling i et vist omfang overhalet standarden. Komitéen spurgte, om dens anbefalelsesgrad så ikke skulle være lavere end anvendelig. Der findes dog ikke grund til helt at forkaste den, og samtidig promoveres standarden af en række handicaporganisationer. 7. Kommissorium for OIO-udvalg for Stedbestemmende referencedata (B) 3

5 lfljâçãáí Éå=W=oÉÑÉê~í=W=OMNMMQOP= = Kommissoriet blev præsenteret af Jan Hjelmager, KMS og vedtaget uden yderligere kommentarer. 8. Notifikation - metadatastandarder for geodataområdet (E) Jan Hjelmager, KMS, præsenterede metadatastandarderne som vedtaget i OIO-udvalget for Stedbestemmende Referencedata gældende for geodatadomænet. Komitéen tog disse til efterretning. 9. Åbne standarder (O) Martin Jensen Buch, ITST, opsummerede den sidste tids politiske udvikling i diskussionerne om åbne standarder og specielt OIO-komitéens styrkede rolle i forbindelse med udpegelse af standarder for dokumentformater (præsentationen er vedlagt). Komitéen ønskede en uddybning af processen i forbindelse med dens rolle ift. standardisering af dokumentformater: Det er i øjeblikket ikke klarlagt, hvordan komitéen tænkes inddraget, men det bliver snarere som garant for udvælgelsesprocessen end for de konkret tekniske specifikationer af formaterne. ITST vil drøfte inddragelsen med Ekspertudvalget for åbne standarder for dokumentformater. 10. Mødefrekvens der opfordres til diskussion af komitéens fremtidige mødefrekvens (B) Komitéen diskuterede en mulig nedsættelse af mødefrekvensen til for eksempel et møde i kvartalet frem for som nu et møde hver sjette uge. Komitéen fandt den nuværende frekvens formålstjenlig, specielt i forbindelse med de kommende ændringer i OIOXML-paradigmet. Der var enighed om, at der gerne må indkaldes hyppige møder, som så kan aflyses i god tid, hvis der mangler substans at mødes om. 11. Kommissorium for FORVIR som OIO-referencegruppe (Bilag 1) (B) Per de Place Bjørn, ITST, præsenterede forslaget til kommissorium for OIO-referencegruppe for semantik og vidensrepræsentation. Kommissoriet godkendtes med bemærkninger om, at referencegruppen udgjorde en relevant styrkelse af OIO-samarbejdet. Referencegruppen er hermed nedsat. 12. Eventuelt Intet til punktet 13. Punkter til næste møde Der blev efterspurgt et oplæg om STORM og dens anvendelsesmuligheder. Punkter mærket B, D, E, O er til henholdsvis (B) Beslutning (D) Drøftelse (E) Efterretning (O) Orientering 4

6 lfljâçãáí Éå=Ó=`çîÉê= _áä~ö=o OIO-komitéen : 3. juni 2010 : Dagsordenspunkt 5 : Cover Beslutning = cçêíçäâåáåö=~ñ=lflujijêéöäéêåé= oéëìã = OIO-komitéen diskuterede på mødet den 4. april et oplæg fra ITST om ændringer i fortolkningerne af reglerne om OIOXML. På baggrund af medlemmernes indlæg på mødet, og en efterfølgende diskussion afholdt på Digitalisér.dk, fremsætter ITST her et forslag til specifikation af fortolkningerne af OIOXML-reglerne. = p~öëñêéãëíáääáåö= Baggrund: Det har været fremført, at byrden ved udvikling af OIOXML i forbindelse med digitaliseringsprojekter, ikke står i rimeligt forhold til gevinsterne herved. På den anden side har OIO-komitéen påpeget nødvendigheden af, at der fortsat foregår en drift af det fællesoffentlige standardiseringsprojekt, og at det forventes at dette varetages af ITST. 31. maj 2010 Sekretariat: IT- og Telestyrelsen Holsteinsgade København Ø Sagsbehandler Per de Place Bjørn Telefon E-post ppb@itst.dk ITST har, i lyset af dette, gennemgået det eksisterende regelsæt og finder, at man med relativt få ændringer vil kunne tilgodese disse behov at lette standardiseringsprojekter, samtidig med at en robust standardiserings-styring opretholdes../. De to dokumenter, som udstikker rammerne for OIO standardiseringsprojektet er Vejledningen om OIOXML som obligatorisk, åben standard (vedtaget af OIOkomitéen den 9. maj vedlagt) og OIOXML Navngivnings og DesignRegler (NDR) 3.2 (vedtaget af OIO-komitéen 29. januar vedlagt) I korte træk er de aktuelle krav om anvendelse af OIOXML disse: OIOXML skal anvendes i forbindelse med struktureret dataoverførsel til og fra myndigheder At anvende OIOXML vil sige: o Der skal udvikles OIOXML-skemaer for kernekomponenter og for områdespecifikke standarder. Disse skal genbruges. o Der bør udvikles OIOXML-skemaer for data-specifikationer på lavere niveau. OIOXML skal udstilles på Digitalisér.dk ITST har hidtil tilbudt kvalitetssikring af al OIOXML, før det kunne placeres på Digitaliser.dk, idet termen bør har været tolket meget restriktivt som betydende Skal - med mindre der er tungtvejende grunde. OIO-komitéen for it-arkitektur og standardisering koordinerer offentlige initiativer inden for standardisering og it-arkitektur, og består af repræsentanter fra ministerier, kommuner og regioner. Digitalisér.dk/group/11917

7 Med en blødere tolkning af bør (som kan ), indstiller ITST nu kvalitetssikringen af OIOXML på lavere niveau end kerne og område/domæne. Det vil sige, at kvalitetssikringen/sagsbehandlingen af NDR-skemaer bortfalder. Kvalitetssikringen af OIOXML på domæne- og kerneniveau opretholdes. I den forbindelse foreslås mindre justeringer i Vejledningen om OIOXML som obligatorisk, åben standard primært for specificere at kvalitetssikringen kun gælder for kerne- og domæne-skemaer, samt for at bringe den i overensstemmelse med de sidste par års udvikling. Konklusion: Med denne fokusering på kerne- og domænekonteksterne opnås en stærkere styring af den tværoffentlige standardisering, samtidig med en lettelse af udviklingen af de enkelte it-projekter. Det er op til de enkelte domæner, at gennemføre standardiseringen, dels ved at udvikle domænestandarder, dels ved at udvikle retningslinjer for standardisering (for eksempel med OIOXML). ITST vil fortsat vejlede i best practice for standardisering med XML. Samtidig forefindes et værktøj (OIO-check), som gør det muligt at kvalitetssikre OIOXML og uploade til Digitalisér.dk, uden at involvere ITST. Ministeriet for Videnskab, Teknologi og Udvikling fåçëíáääáåö= Det indstilles, at komitéen godkender denne fortolkning af reglerne, samt vedtager de redaktionelle ændringer i Vejledning om OIOXML som obligatorisk, åben standard./../. _áä~ö= Vejledning om OIOXML som obligatorisk, åben standard med forslag til ændringer som +/- tekst OIO-NDR 3.2= = 2

8 OIOXML som obligatorisk, åben standard - uddybende vejledning 1 Om dette dokument Dette dokument beskriver anbefalet praksis for at anvende OIOXML som åben, obligatorisk standard. IT- og Telestyrelsen etablerer pt. én indgang til arkitektur og standardisering (det nye OIO-katalog), som forventes i drift ultimo Samtidig ændres Navngivnings- og DesignReglerne for OIOXML, OIO-NDR, til en nyere version i efteråret Som en følge heraf vil nogle klassifikationer og begreber ændres/udfases, hvilket vil have konsekvenser for denne vejledning. Den til enhver tid gældende vejledning vil være at finde på IT- og Telestyrelsens hjemmeside på 2 Baggrund 2.1 Datastandardisering Standardisering af data tjener en række formål, hvoraf særligt to skal fremhæves i denne sammenhæng: april 2008 IT- og Telestyrelsen Datastandardiseringskontoret Holsteinsgade København Ø Telefon Telefax E-post itst@itst.dk Netsted CVR-nr Sagsbehandler Per de Place Bjørn Telefon Telefax E-post ppb@itst.dk Standardisering kan hjælpe forretningen med at definere sine begreber, således at alle aktører får en fælles opfattelse af, hvordan et bestemt begreb skal forstås. Det er vigtigt, når mange aktører skal modellere komplekse begreber i en fælles lovgivning. Standardisering kan lette udveksling af data, fordi systematisk udveksling af data involverer to systemer, der skal forstå det samme ved de konkrete data for, at dataudvekslingen er succesfuld. Standardisering skal altid tage udgangspunkt i forretningens behov, og god standardisering vil ofte føre til en mere effektiv opgaveløsning. Standardisering kan herudover bidrage til at øge konkurrencen mellem IT-leverandører, bl.a. fordi standardisering gør forretningen mindre afhængig af en bestemt leverandør. Med en god, formaliseret forståelse af processer og begreber er det en forholdsvis enkel teknisk øvelse at standardisere syntaks og semantik for begreberne typisk ved hjælp af datakommunikationssproget XML (extensible Mark-up Language). 2.2 Beslutningen og aftalen om åbne standarder Den 2. juni 2006 vedtog Folketinget folketingsbeslutning B 103 om anvendelse af åbne standarder for software i det offentlige. Folketingsbeslutningen pålægger

9 regeringen at sikre det offentliges brug af informationsteknologi, herunder brug af software, der er baseret på åbne standarder. Et flertal af partierne har lagt til grund, at anvendelsen af åbne, obligatoriske standarder ikke må medføre øgede udgifter for det offentlige. Regeringen, KL og Danske Regioner indgik i oktober 2007 en aftale om anvendelsen af obligatoriske, åbne standarder for software i det offentlige. Aftalen indebærer, at samtlige offentlige myndigheder fra 1. januar 2008 skal anvende syv sæt af åbne standarder i nye IT-løsninger. De offentlige myndigheder skal således sikre sig, at fremtidige IT-løsninger overholder de obligatoriske, åbne standarder. En af disse standarder er OIOXML, som skal anvendes ved dataudveksling mellem offentlige myndigheder. De første spæde erfaringer med OIOXML som åben, obligatorisk standard har vist, at der er et behov for en uddybende vejledning for OIOXML som supplement til den generelle vejledning, som findes på IT- og Telestyrelsen har derfor udarbejdet denne vejledning, som er vedtaget i OIO-komitéen den 16. april 2008[]. Ministeriet for Videnskab, Teknologi og Udvikling 3 OIOXML som obligatorisk standard 3.1 Hvornår skal myndighederne anvende OIOXML? Kravet om at anvende OIOXML gælder, når der foregår regelmæssig og systematisk udveksling af data fra eller til en myndighed. Eksempelvis når en styrelse stiller krav om regelmæssige indberetninger fra kommunale myndigheder. Kravet indebærer, at data skal udveksles i OIOXML og forudsætter, at dataudvekslingen (snitfladen) er OIOXML. Der er derimod ikke krav om, at ITleverandører anvender OIOXML udover til selve dataudvekslingen. Myndighederne opfylder kravet om OIOXML ved at stille krav til deres ITleverandører om, at fremtidige systemer skal udveksle data i OIOXML. 3.2 Følg eller forklar For anvendelsen af obligatoriske, åbne standarder gælder det, at den enkelte myndighed ved eventuelle merudgifter eller andre uhensigtsmæssigheder, herunder i forhold til den pågældende myndigheds IT-sikkerhedsmæssige hensyn, kan undlade at anvende de obligatoriske standarder. Aftalen indeholder derfor et såkaldt følg eller forklar (comply or explain)- princip; dvs., at det er obligatorisk at anvende standarderne, medmindre der er tungtvejende grunde til ikke at gøre det. Myndigheden kan fravige princippet om anvendelse af åbne standarder, hvis det indebærer, at myndigheden skal anskaffe en løsning, der: er væsentligt dyrere, svækker sikkerhedsniveauet, 2

10 medfører væsentlig funktionel forringelse, der er direkte forårsaget af, at den er baseret på de obligatoriske, åbne standarder, øger implementeringstiden markant, medfører konflikt med standarder, der på grund af internationale forpligtelser er gældende inden for enkeltområder. Hvis myndigheder fraviger princippet om anvendelse af åbne standarder, og den tekniske anskaffelses samlede omkostninger ville overstige EU s udbudsgrænse, skal pågældende myndighed offentliggøre deres undtagelsesbestemmelse. Dette kan se ved: at myndigheden sender begrundelserne til IT- og Telestyrelsen i forbindelse med underskrivelse af kontrakten, hvorefter IT- og Telestyrelsen offentliggør begrundelserne, at offentliggøre begrundelserne på myndighedens egen hjemmeside eller at offentliggøre begrundelserne i forbindelse med regnskabsaflæggelse Hvis de samlede omkostninger for en IT-løsning ligger under udbudsgrænsen, er myndigheden ikke forpligtet til at offentliggøre sin begrundelse for at fravige standarderne men myndighederne opfordres til at gøre det. Hvis IT-løsningen er omfattet af Statsministeriets sikkerhedscirkulære, gælder der ingen krav om offentliggørelse. Ministeriet for Videnskab, Teknologi og Udvikling 4 At anvende OIOXML 4.1 Hvad vil det sige at anvende OIOXML? Kravet om anvendelse af OIOXML overholdes ved at udforme standardiserede begreber og egentlige datastandarder i overensstemmelse med de til enhver tid gældende Navngivnings- og DesignRegler (NDR) for OIOXML. I øjeblikket (april 2008juni 2010) anvendes OIO-NDR 3.1.rev.22. Gældende version af OIO-NDR vil altid være at finde på Yderligere skal standarderne være godkendte gennem sagsbehandling i OIOsekretariatet, og være påhæftet godkendelsesmærke. 4.2 Standarden OIOXML I det fællesoffentlige standardiseringsarbejde anvendes standarden OIOXML til beskrivelse og modellering af datakommunikation mellem IT-systemer i form af OIO-datastandarder (eller kort: datastandarder). OIOXML er en dialekt af sproget XML. XML anbefales som standard af organisationen The World Wide Web Consortium ( NDR definerer den grammatik, som gør OIOXML til en særlig dialekt Syntaks og semantik OIOXML-datastandarder består af: en syntaksdefinition, som er udtrykt som et OIOXML-skema, 3

11 en semantikdefinition, som beskrives i en metadata-fil, og er knyttet til hvert OIOXML-skema, en overordnet beskrivelse af OIOXML-skemaernes anvendelse og funktion, som knyttes til indleveringen (ansøgningen) af OIOXML-skemaer til godkendelse Grundklasser og genbrugsklasser Datastandarder kan godkendes i en af grundklasserne NDR-klassen eller Adoptionsklassen. Derudover kan datastandarden godkendes som en områdespecifik datastandard (Domæneklassen) og som en fællesoffentlig datastandard (Kernekomponentklassen): NDR-klassen er beregnet til datastandarder, der overholder NDR i forhold til tekniske krav omkring navngivning og design. De er ledsaget af en dækkende semantikdefinition, som beskriver datastandardens relation med tilgrænsende datastandarder samt datastandardens anvendelse i den sammenhæng, datastandarden er udviklet i. Datastandarden skal stilles frit til rådighed på InfoStrukturBasen (ISB endigitalisér.dk) 1. Ministeriet for Videnskab, Teknologi og Udvikling NDR specificerer, at datastandarder i NDR-klassen BØR genbruges. Aftalen om åbne obligatoriske standarder forpligter således ikke myndighederne til at anvende dem, men myndighederne skal forholde sig til allerede eksisterende datastandarder og må ikke skabe deciderede dubletter af allerede eksisterende datastandarder. Adoptionsklassen er beregnet til internationalt adopterede datastandarder og gennemgås ikke her, da de ikke er underlagt OIO-NDR, men opbygges efter retningslinier, der er internationalt fastlagt. Områdespecifikke datastandarder (Domæneklassen) er beregnet til datastandarder for de mest centrale og mest genbrugte forretningsobjekter inden for et domæne eller et sammenhængende forretningsområde. Kun myndigheder OIO-udvalg og Domænebestyrelser inden for det pågældende domæne/forretningsområde kan anmelde områdespecifikke datastandarder for det domæne/område. Områdespecifikke datastandarder skal i øvrigt overholde de samme krav som datastandarder i NDR-klassen, dvs. at de også skal overholde NDR. Områdespecifikke datastandarder SKAL genbruges inden for domænet/forretningsområdet. Aftalen om åbne obligatoriske standarder forpligter myndighederne til at anvende dem, hvis dataudvekslingen i forvejen er omfattet af aftalen. 1 IT- og Telestyrelsen udvikler p.t. én indgang til arkitektur og standarder i form af det nye OIO-katalog. Det nye OIO-katalog afløser fra 1/ bl.a. den eksisterende InfoStrukturBase og det gamle OIO-katalog. Desuden indarbejdes et katalog over webservices, metadata for registre og arkitekturkrav. Læs mere på 4

12 Fællesoffentlige datastandarder (Kerneklassen) (også kaldet kernekomponenter) er beregnet til datastandarder for de mest centrale forretningsobjekter i den offentlige forvaltning, f.eks. personnummer (CPR), adresse og navn, som bliver udvekslet på tværs af mange forretningsområder. OIO-komitéen kan anmelde standarder i kerneklassen. Kernekomponenter skal ligeledes overholde OIO-NDR. Aftalen om åbne obligatoriske standarder forpligter myndighederne til at anvende dem, hvis dataudvekslingen i forvejen er omfattet af aftalen. 4.3 Resumé Dette vil sige, at når der standardiseres i et domæne/forretningsområde, skal alle relevante kernekomponenter og samtlige relevante områdespecifikke datastandarder anvendes. Desuden bør alle relevante NDR-datastandarder anvendes, hvis NDR-datastandarderne opfylder det forretningsmæssige behov. Ministeriet for Videnskab, Teknologi og Udvikling Fremtidens begreber i datastandardisering: IT- og Telestyrelsen forventer, at næste version af Navngivnings- og Designreglerne (NDR) vil fastlægge to niveauer for datastandardisering: 1.Datastandarder, som er standarder for et bestemt område. Enten hele den offentlige sektor svarende til det, der i dag kaldes kernekomponenter eller et specifikt område svarende til det, der i dag kaldes områdespecifikke standarder (domæneklassen). 2.Datadefinitioner, som ikke er standarder, men kan tjene som inspiration for egentlig standardisering, og som kan anvendes af specifikke ITløsninger. Både datastandarder og datadefinitioner skal overholde den til enhver tid gældende OIO-NDR. Datastandarder skal desuden have været igennem en OIOhøringsproces. Næste version af NDR vil desuden specificere, at datadefinitioner og datastandarder består både af en semantikdefinition og en syntaksdefinition. Kernekomponenter erstattes af datastandarder med gyldighed for hele den offentlige sektor. Områdespecifikke datastandarder erstattes af datastandarder med gyldighed for en del af den offentlige sektor. Standarder i NDR-klassen erstattes af datadefinitioner. Med disse ændringer bliver det tydeligt, at offentlige myndigheder altid skal overholde alle relevante datastandarder, mens datadefinitioner alene tjener til inspiration. 5 Governance for OIOXML og OIO-samarbejdet Det fællesoffentlige standardiseringsarbejde, OIO-standardisering (OIO = Offentlig Information On-line), er forankret i en tobenet organisatorisk struktur, som 5

13 omfatter både det politisk/besluttende og det teknisk/udførende aspekt af standardisering og IT-arkitektur. 5.1 STS og domænebestyrelser Styregruppen for Tværoffentligt Samarbejde (STS) kan nedsætte domænebestyrelser inden for udvalgte domæner (velafgrænsede offentlige forretningsområder). Den fællesoffentlige referencemodel, FORM, giver et overblik over domæner og deres indbyrdes afgrænsning. Se dellen_form/ Domænebestyrelserne skal prioritere og koordinere digitaliseringen inden for domænet. Domænebestyrelserne skal også sikre den overordnede koordinering af standardiseringsarbejdet i den offentlige sektor inden for domænerne. Domænebestyrelser kan vælge at etablere OIO-udvalg eller bestille standardiserings- og arkitektur opgaver hos allerede eksisterende udvalg. Ministeriet for Videnskab, Teknologi og Udvikling 5.2 KIU og OIO-komitéen Det Koordinerende Informationsudvalg (KIU) har nedsat OIO-komitéen for ITarkitektur og standardisering (OIO-komitéen). OIO-komitéen afløser ITarkitekturkomitéen og Datastandardiseringskomitéen og har ansvaret for de fagspecifikke beslutninger i forhold til standardiserings- og arkitekturarbejdet. Ligesom domænebestyrelserne kan OIO-komitéen foreslå oprettelse af OIOudvalg navnlig på områder, hvor en domænebestyrelse ikke findes. OIOkomitéen vedligeholder og godkender ændringer i navngivnings- og designreglerne for OIOXML (NDR). 5.3 OIO-udvalg OIO-udvalg (tidligere: sektorstandardiseringsudvalg) oprettes af organisationerne inden for et domæne/et forretningsområde og arbejder praktisk med standardisering og IT-arkitektur. Udvalget referer til OIO-komitéen i forhold til beslutninger af teknisk/it-faglig karakter og til bestyrelsen/de myndigheder, der har nedsat udvalget, i organisatoriske og faglige spørgsmål. Et OIO-udvalg vil typisk have et eller flere standardiseringsprojekter tilknyttet. 6 Standardiseringsprocessen 6.1 OIO-udvalget udvikler og vedtager standarder De enkelte myndigheder har ansvaret for at standardisere. Det er således myndighedernes ansvar at definere sine begreber og at udarbejde og vedligeholde datastandarder. Standardiseringen kan være koordineret af en domænebestyrelse og udføres ideelt i regi af et OIO-udvalg. Domænebestyrelsen eller OIO-udvalget tager ejerskab til datastandarderne og sikrer, at de dækker forretningsbehovet i forretningsom- 6

14 rådet/domænet. I fraværet af OIO-udvalg eller domænebestyrelser kan de enkelte myndigheder tage ansvar for de indleverede datastandarder. Da domænebestyrelser er tænkt som kortlivede, og da OIO-udvalg også kan opløses, skal det sikres, at ejerskabet kan falde tilbage på en organisation med en mere blivende karakter gerne en myndighed. I praksis gøres det ved at lade en myndighed være indleverende part på vegne af det standardiserende organ. Domænebestyrelsen/OIO-udvalget/myndigheden ejer datastandarderne 2. Det vil sige, at de godkender datastandarderne og træffer beslutning om, hvilket område inden for domænet 3, de gælder for. Datastandarderne placeres på Digitalisér.dk i grupper, som klart tilkendegiver ejerskabet til standarderne. Omkostninger og fordele ved at udarbejde en datastandard indgår som en del af den samlede business case for det relevante digitaliseringsprojekt. 6.2 Datastandarderne behandles i OIO-sekretariatet OIO-processen skal understøtte og facilitere datastandardiseringsarbejdet i OIOudvalg og hos myndigheder. Det sker gennem vejledning og sagsbehandling kvalitetssikring i OIO-sekretariatet og ved at OIO-sekretariatet stiller redskaber til rådighed fx den nuværende InfoStrukturBase (ISB en) og det kommende nye OIO-katalog.- Digitalisér.dk samt vejledninger og værktøjer til udvikling og kvalitetssikring af OIOXML (OIO-check) Ministeriet for Videnskab, Teknologi og Udvikling OIO-sekretariatet er placeret i IT- og Telestyrelsen. Sagsbehandling Kvalitetssikring består af en række adskilte trin og foretages kun for datastandarder i Kerne og Domæen-klassen: IT-faglig vurdering OIO-sekretariatet sagsbehandler de indleverede standarder. Sekretariatet foretager en teknisk validering af OIOXML-skemaer og semantikdefinitioner og sikrer, at datastandarderne overholder OIO-NDR. Sekretariatet sikrer også, at indholdet af standarderne og det område, de gælder for, er klart beskrevet. Dvs., at IT- og Telestyrelsen sikrer, at datastandarderne teknisk set er i orden begreberne er veldefinerede deres kontekst er beskrevet Det er den afleverende domænebestyrelse/oio-udvalges ansvar, at begreberne er i overensstemmelse med forretningens behov. 2 Kernekomponenter ejes af det fællesoffentlige standardiseringsprojekt/oio-komitéen, og varetages typisk af den relevante myndighed 3 Området specificeres ud fra den fællesoffentlige referencemodel, FORM. 7

15 6.2.2 Genbrugsvurdering OIO-sekretariatet vurderer, om de indleverede datastandarder i tilstrækkeligt omfang gør brug af tidligere udviklede datastandarder. NDR specificerer, at hvis et forretningsobjekt allerede er modelleret som OIOXML, skal denne datastandard indgå i fremtidig modellering, hvis datastandarden er relevant for det pågældende område. Det er den part, som indleverer en ny standard, der vurderer, om en eventuelt eksisterende standard er relevant. Godkendes en ny standard, der omhandler samme område som en allerede eksisterende, vil den oprindelige standard blive mærket som forældet. Hermed sikres det, at der aldrig eksisterer konfliktende definitioner af samme begreb på et område Afgrænsning af det område, datastandarden gælder for OIO-sekretariatet undersøger afgrænsningen af datastandardens virkningsområde i forhold til tilgrænsende domæner/forretningsområder for at forhindre eventuelt overlap mellem datastandarder. Ministeriet for Videnskab, Teknologi og Udvikling 6.3 Høring og godkendelse Datastandarder, som alene ønskes optaget i NDR-klassen, dvs. ikke som områdespecifikke standarder (domænestandarder) eller kernekomponenter, godkendes af OIO-sekretariatet. Hvis en standard skal optages som områdespecifik datastandard eller kernekomponent, bringes den efter teknisk vurdering, genbrugsvurdering og afgrænsningsvurdering i offentlig høring. Når høringssvarene er tilfredsstillende indarbejdet, godkendes datastandarderne af OIO-komitéen. Herved sikrer OIO-sekretariatet den formelle validitet af datastandarden. 6.4 Resumé På punktform kan standardiseringsprocessen beskrives således: Et behov for standardisering opstår En organisation (typisk et OIO-udvalg) dannes til at varetage begrebsafklaring og standardisering Organisationen afsøger muligheden for at bruge internationale datastandarder og undersøger, om eksisterende danske datastandarder dækker behovet Omkostninger og fordele ved standardisering indgår i den samlede business case for det relevante digitaliseringsprojekt Organisationen laver begrebsafklaring og baserer datastandarder på de afklarede forretningsbegreber De standardiserede begreber godkendes som datastandarder af det organ, der har ansvaret for standardiseringen i domænet eller forretningsområdet et OIO-udvalg, en domænebestyrelse eller en myndighed 8

16 OIOXML skemaerne for kernekomponenter og områdespecifikke standarder indleveres til OIO-sekretariatet med henblik på optagelse i de relevante OIO-klasser for datastandarder OIO-sekretariatets sagsbehandling tilgodeser, at den indleverede OIOXML: o beskriver syntaks og semantik for de standardiserede begreber i overensstemmelse med de gældende regler o er i overensstemmelse med anden standardisering på området o gennemgår en tværoffentlig høringsproces Efter gennemført sagsbehandling kan OIO-komiteen ophøje datastandarderne til OIO-datastandard i en af standardklasserne. Det er stadig den part, der indleverende datastandarden, som er datastandardens ejer og som vedligeholder den i forhold til forandring i forretningsområdet 7 Eksempler I det følgende beskrives nogle mulige brugssituationer for en myndighed/et OIOudvalg, som udveksler data med andre myndigheder eller private virksomheder, som anvender OIOXML til at definere sine forretningsbegreber. Følg og forklar princippet gælder for alle fem eksempler, jf. afsnit 2.2. Ministeriet for Videnskab, Teknologi og Udvikling 7.1 Eksempel 1: Usystematisk dataudveksling En styrelse sender med ujævne intervaller data til forskellige interessenter i forbindelse med ministerbetjening, aktindsigtssager eller borgerhenvendelser. Denne dataudveksling er ikke omfattet af OIOXML som åben, obligatorisk standard. Det kan dog sagtens være hensigtsmæssigt for parterne at standardisere begreberne. Både for at have styr på forretningen og for at være forberedt på en dataudveksling. Denne standardisering kan med fordel bruge OIOXML til at definere begreberne, fordi OIOXML er det fællesoffentlige redskab netop til dette. Men selve dataudvekslingen er altså ikke omfattet af OIOXML som åben, obligatorisk standard. 7.2 Eksempel 2: Systematisk dataudveksling En myndighed modtager regelmæssigt store mængder data fra andre myndigheder. Dataudvekslingen er omfattet af OIOXML som åben standard. Så længe dataudvekslingen foregår ved hjælp af eksisterende IT-løsninger, behøver myndigheden intet at foretage sig. I forbindelse med udvikling af nye løsning, nyindkøb af IT til en eksisterende løsning eller genforhandling af en eksisterende kontrakt - skal dataudveksling foregå som OIOXML. 9

17 Det anbefales, at myndigheden standardiserer sine begreber og den relevante dataudveksling (snitflade) og anmelder dem som områdespecifikke datastandarder (domæneklassen). Hvis myndigheden mener, at standardiseringen kun omfatter en del af domænet, og at denne del ikke klart kan afgrænses fra resten af domænet, kan datastandarderne anmeldes i NDR-klasssen. Eksempelvis hvis datastandarden kun gælder én IT-løsning og en større standardisering af hele domænet forestår. 7.3 Eksempel 3: Ikke-godkendte skemaer og databeskrivelser En leverandør har uploadet et antal XML-skemaer og et antal systematiske beskrivelser af data til ISB en. XML-skemaerne og databeskrivelserne er ikke godkendt som OIOXML. Et OIO-udvalg ønsker at standardisere begreber, som overlapper med det uploadede. OIO-udvalget bør bruge de eksisterende XML-skemaer og databeskrivelserne som inspiration til at udarbejde standarderne. OIO-udvalget er ikke bundet af materialet. Ministeriet for Videnskab, Teknologi og Udvikling 7.4 Eksempel 4: Godkendte OIOXML-skemaer i NDR-klassen Et OIO-udvalg finder, at der allerede eksisterer OIOXML-skemaer i NDRklassen med gyldighed for udvalgets forretningsområde. OIO-udvalget skal forholde sig til de eksisterende skemaer og definitioner. Hvis definitionerne er fuldt dækkende, skal kan de indarbejdes i udvalgets modellering. Hvis de eksisterende skemaer og definitioner ikke modsvarer forretningsbehovet, skal OIO-udvalget beskrive dette, når de afleverer de nye OIOXML standarder til godkendelse. Hvis de nye datastandarder erstatter hidtidige datastandarder, vil de hidtidige blive opmærket som forældede. 7.5 Eksempel 5: Forretningsafklaring uden dataudveksling Et OIO-udvalg ønsker at definere vigtige forretningsbegreber for at sikre, at aktører inden for domænet får en fælles forståelse af begreberne. OIO-udvalget og de relevante myndigheder kan vælge at forpligte hinanden på, at alle i domænet skal implementere en bestemt datastandard for et forretningsbegreb. Dette ligger uden for OIOXML som åben, obligatorisk standard. OIO-udvalget kan anvende OIOXML til at definere begreberne. Der findes nu to muligheder for at anmelde datastandarderne: 1. OIO-udvalget anmelder datastandarderne til InfoStrukturBasen (ISB enkvalitetssikring) som områdespecifikke datastandarder (Domæneklassen) og beskriver i dokumentationen, hvilket gyldighedsområde datastandarderne har. Foregår der systematisk udveksling af data i domænet, og er betingelserne i eksempel 2 opfyldt, skal datastandarderne anvendes. 10

18 2. OIO-udvalget anmelder uploader datastandarderne til ISB en i NDRklassen Digitalisér.dk og beskriver i dokumentationen, hvilket gyldighedsområde datastandarderne har. Foregår der systematisk udveksling af data i domænet, og er betingelserne i eksempel 2 opfyldt, skal datastandarderne anvendes, hvis de opfylder de forretningsmæssige behov. Ministeriet for Videnskab, Teknologi og Udvikling 11

19 OIO-NDR version 3.2 gældende fra 29. januar Indhold: OIOXML regler Generelle XML skema regler Generelle navngivningsregler Engelsk/dansk sprogvalg i navngivning Navngivning af typer Navngivning af elementer Navngivning af attributter Navngivning af skema- og metadatafiler Generelle regler for typedefinitioner Regler for simple typedefinitioner Regler for komplekse typedefinitioner Regler for elementerklæringer Regler for attributerklæringer Versioneringsregler Namespaceregler Dokumentation af OIOXML skemaer Metadata for OIOXML skemaer Repræsentationstermer NDR 3.2 regelnummer NDR 3.2 formulering _topoioxml regler OIO-1 OIO-2 OIO-3 Et OIOXML-skema SKAL genbruge eksisterende elementer eller typer fra Kerneklassen og Domæneklassen. Et OIOXML-skema BØR genbruge eksisterende elementer eller typer fra NDR-klassen. Et OIOXML-skema SKAL genbruge de indbyggede simple typer i XML Schema anbefalingen frem for at definere egne typer til at

20 NDR 3.2 regelnummer NDR 3.2 formulering repræsentere den samme type. OIO-4 OIO-5 OIO-6 OIO-7 OIO-8 OIO-9 OIO-10 Et OIOXML-skema BØR genbruge et element frem for dets type, hvis elementets navn og anvendelse er entydig i den konkrete sammenhæng. Et OIOXML-skema SKAL genbruge nyeste version af et andet eksisterende OIOXML-skema, hvis dette andet skema forekommer i flere versioner. Et OIOXML-skema SKAL indeholde én elementerklæring og, hvis elementerklæringen ikke genbruger en eksisterende type fra et andet skema, én typedefinition for elementet samt eventuelt en eller flere definitioner af støttetyper nødvendige for etablering af elementets typedefinition. Skemaet må dog ikke indeholde en elementerklæring, hvis den tilstedeværende typedefinition specificerer en abstrakt type. En OIOXML-skemaaflevering SKAL i dets enkelte skemaer altid referere enten til godkendte OIOXML-skemaer på Digitalisér.dk eller til skemaer indeholdt i selve skemaafleveringen. Et OIOXML-skema SKAL placeres på Digitalisér.dk. Et OIOXML-skema MÅ IKKE i dets udformning være influeret af begrænsninger i et bagvedliggende fagsystem. Et OIOXML-skema SKAL designes så enkelt og entydigt som overhovedet muligt uden unødvendig kompleksitet og overflødige konstruktioner. Generelle XML skema regler GXS-1 GXS-2 GXS-3 GXS-4 GXS-5 Et OIOXML-skema SKAL defineres i overensstemmelse med W3C XML Schema anbefalingen (version 1.0) af 2. maj 2001: XML Schema Part 1: Structures og XML Schema Part 2: Datatypes. Et OIOXML-skema SKAL anvende version 1.0 af W3C XML anbefalingen af 4. februar 2004 Extensible Markup Language (XML) 1.0 (Third Edition). Et OIOXML-skema SKAL anvende UTF-8 som encoding scheme. Et OIOXML-skema SKAL have specificeret et target namespace. Et OIOXML-skema MÅ IKKE benytte import-konstruktionen til at

21 NDR 3.2 regelnummer NDR 3.2 formulering referere til et andet OIOXML skema, der anvender samme namespace, som skemaet der refereres fra. GXS-6 GXS-7 GXS-8 GXS-9 Et OIOXML-skema MÅ IKKE benytte redefine-konstruktionen. Et OIOXML-skema MÅ IKKE benytte notation-konstruktionen. Et OIOXML-skema SKAL angive alle dets schemalocationattributter med en gyldig reference til OIOXML-skemaer på Digitalisér.dk. Et OIOXML-skema MÅ IKKE benytte konstruktionerne key, keyref og unique. Generelle navngivningsregler GNR-1 GNR-2 GNR-2a GNR-2b GNR-2c GNR-2d (listen over repræsentationstermer er placeret til sidst i dette dokument) GNR-2e Et OIOXML-skema SKAL navngive alle dets globalt erklærede komponenter (elementer, og typer) unikt indenfor skemaets namespace og BØR navngive unikt på tværs af alle namespaces for godkendte OIOXML-skemaer. Et OIOXML-skema SKAL navngive alle dets globalt og lokalt erklærede komponenter (elementer, attributter samt typer) efter ObjektEgenskabRepræsentation navngivningsmodellen, som specificeret i følgende underregler. Et navn SKAL i dets Objekt term beskrive det dataobjekt, som et element og dets type repræsenterer i en bestemt sammenhæng. Et navn KAN udelade dets Objekt term i det tilfælde, hvor et element og dets type optræder i en kontekst af et objekt eller objektet er ukendt. Et navn SKAL i dets Egenskab term ved hjælp af en eller flere kvalificerende ord beskrive en fremtrædende egenskab ved et elements og dets types Objekt term. Et navn SKAL i dets Repræsentation term beskrive et elements og dets types repræsentative kategori og SKAL antage en af værdierne i OIOXML's liste over repræsentationstermer. Et navn SKAL, hvis det har en frase i termen Egenskab, som er synonymt med en frase i termen Repræsentation, fjerne frasen fra Egenskab og bibeholde den i Repræsentation.

22 NDR 3.2 regelnummer GNR-2f GNR-2g GNR-2h GNR-2i NDR 3.2 formulering Et navn SKAL angives på entalsform, med mindre navneordet er en flertalsform. Et navn MÅ IKKE benytte en forkortelse eller et akronym, hvis ikke forkortelsen eller akronymet er alment kendt. Et navn SKAL opbygges af udsagnsord, navneord og tillægsord. Et navn MÅ IKKE i dets opbygning benytte underscore (_), punktum (.) og bindestreg (-). Undtaget er dog navne for støttetyper, der altid starter med underscore (_). Engelsk/dansk sprogvalg i navngivning LNR-1 LNR-2 LNR-3 LNR-4 LNR-5 Et OIOXML-skema SKAL navngive alle dets globalt og lokalt erklærede komponenter (elementer, attributter samt typer) i ét og samme sprog på enten dansk eller engelsk. Et OIOXML-skema med komponenter navngivet på engelsk betegnes et engelsk OIOXMLskema, og et OIOXML skema med komponenter navngivet på dansk betegnes et dansk OIOXML-skema. Et OIOXML-skema har frit sprogvalg mellem dansk og engelsk med mindre et OIO-udvalg har taget konkret ejerskab af skemaet. I det tilfælde beslutter OIO-udvalget, hvorvidt OIOXML-skemaet skal være dansk eller engelsk. Et dansk OIOXML-skema SKAL tildele attributten xml:lang i rodelementet schema værdien DA. Et engelsk OIOXML skema KAN tildele attributten xml:lang i rodelementet schema værdien EN. Attributten xml:lang MÅ IKKE antage andre værdier end DA og EN og hvis attributten ikke er specificeret, antages værdien at være EN, dvs. skemaet antages at være et engelsk OIOXML skema. Navngivning på engelsk BØR ske i overensstemmelse med Oxford English Dictionary eller relevante fagbøger. Navngivning på dansk BØR ske i overensstemmelse med Dansk Retskrivningsordbog eller relevante fagbøger. Et OIOXML-skema MÅ IKKE anvende de danske specialtegn æ, ø og å samt Æ, Ø, Å på grund af manglende værktøjsunderstøttelse. Som alternativ anvendes i stedet ae for æ, oe for ø og aa for å og tilsvarende Ae for Æ, Oe for Ø og Aa for Å. Navngivning af typer

23 NDR 3.2 regelnummer TPN-1 TPN-2 TPN-3 TPN-4 TPN-5 TPN-6 NDR 3.2 formulering Et OIOXML-skema SKAL afslutte navnet på en simpel eller kompleks type med suffiks Type. Et OIOXML-skema SKAL anvende termen Repræsentation i typenavnet for en simpel type. Et OIOXML-skema MÅ IKKE anvende termen Repræsentation i typenavnet for en kompleks type. Et OIOXML-skema SKAL i dets Egenskab term i typenavnet for en kompleks type have værdien Collection i et engelsk OIOXMLskema og Samling i et dansk OIOXML-skema, hvis indholdsmodellen for skemaets komplekse type indeholder mindst 2 forekomster af præcist ét element (dvs. attributten maxoccurs i elementreferencen er større end eller lig med 2, eller lig med unbounded ). I alle andre tilfælde SKAL termen Egenskab i typenavnet være Structure i et engelsk OIOXML-skema og Struktur i et dansk OIOXML-skema eller helt undlades uanset sprog. Et OIOXML-skema SKAL navngive dets simple og komplekse typer med UpperCamelCase. Et OIOXML-skema SKAL anvende ét underscore (_) som præfiks til en type s navn, hvis typen er en støttetype. Navngivning af elementer ELN-1 ELN-2 Et OIOXML-skema SKAL navngive dets element identisk med elementets type (uden typens Type suffiks), hvis elementerklæring og typedefinition forekommer sammen i skemaet. Et OIOXML-skema SKAL navngive dets element med UpperCamelCase. Navngivning af attributter ATN-1 Et OIOXML-skema SKAL navngive dets attributter med lowercamelcase. Navngivning af skema- og metadatafiler FNR-1 Et OIOXML-skema SKAL specificere dets filnavn <skemafilnavn> efter navngivningsmodellen: <elementnavn> +.xsd, hvor <elementnavn> angiver navnet på det i skemaet erklærede element, eller, hvis skemaet indeholder en abstrakt typedefinition, navnet på

24 NDR 3.2 regelnummer NDR 3.2 formulering den definerede type uden dets suffiks Type. FNR-2 Et OIOXML-skema SKAL navngive dets metadatafil efter modellen: <skemafilnavn>+.meta.xml. Generelle regler for typedefinitioner GTD-1 GTD-2 GTD-3 GTD-4 GTD-5 GTD-6 GTD-7 GTD-8 GTD-9 GTD-10 Et OIOXML-skema SKAL definere alle dets simple og komplekse typer stærkest muligt. Et OIOXML-skema SKAL definere alle dets simple og komplekse typer globalt. Et OIOXML-skema MÅ IKKE definere en ny simpel eller kompleks type identisk med en simpel eller kompleks type fra et andet eksisterende OIOXML-skema. Et OIOXML-skema MÅ IKKE genbruge de indbyggede ur-typer anytype og anysimpletype. Et OIOXML-skema MÅ IKKE genbruge følgende indbyggede simple typer long, int, short, byte, unsignedlong, unsignedint, unsignedshort, unsignedbyte (afledt af den simple indbyggede type decimal) samt normalizedstring, token, language, name, NCName, ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN, NMTOKENS (afledt af den simple indbyggede type string). Et OIOXML-skema BØR benytte de indbyggede simple typer anyuri eller base64binary til at håndtere binært indhold. Et OIOXML-skema KAN benytte attributten abstract i simple og komplekse typedefinitioner til at definere abstrakte typer. Et OIOXML-skema BØR IKKE begrænse typeafledninger, dvs. attributterne finaldefault og blockdefault i rodelementet schema, attributten final i simple typedefinitioner samt attributterne block og final i komplekse typedefinitioner BØR IKKE benyttes. Et OIOXML-skema SKAL anvende dets støttetyper udelukkende som en hjælp til at etablere skemaets ene typedefinition, hvis en sådan defineres i skemaet og ikke kan udtrykkes i en enkelt definition. Et OIOXML-skema SKAL definere dets støttetyper som simple typer.

25 NDR 3.2 regelnummer NDR 3.2 formulering Regler for simple typedefinitioner STD-1 STD-2 STD-3 STD-4 STD-5 Udgår STD-6 Et OIOXML-skema MÅ IKKE benytte konstruktionen list. Et OIOXML-skema MÅ IKKE benytte konstruktionen union. Et OIOXML-skema BØR IKKE begrænse længden af den simple indbyggede type string. Et OIOXML-skema BØR udtrykke kodelister via enumeration konstruktionen. Et OIOXML-skema SKAL udelukkende udtrykke værdier i enumeration konstruktioner med tal, små og store bogstaver, ".", "/" og mellemrum. Et OIOXML-skema KAN udtrykke værdier i enumeration konstruktioner enten på dansk eller engelsk. Et OIOXML-skema MÅ IKKE benytte whitespace-facetten. Regler for komplekse typedefinitioner CTD-1 CTD-2 CTD-3 CTD-4 CTD-5 CTD-6 CTD-7 Et OIOXML-skema SKAL definere en kompleks type ved anvendelse af konstruktionerne sequence og choice. Et OIOXML-skema MÅ IKKE definere en kompleks type ved anvendelse af konstruktionen all. Et OIOXML-skema KAN definere en kompleks type via extension konstruktionen. Et OIOXML-skema MÅ IKKE definere en kompleks type via restriction konstruktionen. Et OIOXML-skema KAN benytte den blandede indholdsmodel (mixed content) til strukturer, hvor tekst og elementer frit kan blandes. Et OIOXML-skema KAN benytte den tomme indholdsmodel (empty content) til strukturer, hvor tekst og elementer frit kan blandes. Et OIOXML-skema KAN benytte any konstruktionen til at binde to relaterede, og eventuelt uafhængige, OIOXML-dialekter sammen.