Dagsorden, OIO-komitéens møde den 29. januar, 2009 Dagsorden OIO- Komitéens 5. møde d. 29. januar, 2009 Mødet afholdes d. 29. januar, 2009 fra kl. 13 i Direktionens mødelokale, 4 sal, IT- og Telestyrelsen, Holsteinsgade 63. Dagsorden 1. Velkomst 2. Godkendelse af dagsorden, referat fra mødet d. 9. oktober 2008 samt beslutningsnotat fra den skriftlige høring af komitéen 12.-18. december 2008 (Bilag 1a og 1b) (B) 3. Meddelelser 4. Top-ontologi for Det Nationale Begrebsarbejde for Sundhedsvæsenet (Bilag 2) (O) 5. Samarbejde om identitetsbaserede webservices (Bilag 3) (D) 6. Web 2.0 erfaringer og anbefalinger (Bilag 4) (D) 7. Repræsentation af OIO og det fællesoffentlige på Digitalisér.dk (Bilag 5) (B) 8. NDR 3.2 (Bilag 6) (B) 9. Emner til næste møde 10. Eventuelt 25. januar 2009 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade 63 2100 København Ø Telefon 3545 0000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Per de Place Bjørn Telefon 3545 0175 E-post ppb@itst.dk Punkter mærket B, D, E, O er til henholdsvis (B) Beslutning (D) Drøftelse (E) Efterretning (O) Orientering Dagsordenen er vedlagt en opdateret liste over standarder under behandling i OIO-Sekretariatet.
BILAG 1 a Referat, OIO-komitéens møde den 9. oktober 2008 Referat, OIO-komitéens 4. møde, den 9. oktober 2008 Mødet afholdtes d. 9. oktober 2008 fra kl. 13 15:30 i Mødelokale B, 4 sal, ITog Telestyrelsen, Holsteinsgade 63. Til stede: Per Schultz Eeg, ITST, Formand Peter Thrane, KL Palle Røgilds Scheef, Region Nordjylland Mette Jørgensen (EOGS), Erhvervs- og Selskabsstyrelsen Anders Bo Nielsen, Rigsarkivet Frank Carvalho, SKAT Jesper Nielsen, Velfærdsministeriet Thomas Andersen, Beskæftigelsesministeriet Flemming Nissen, KMS Torben Sløk, Vejdirektoratet Mogens Pedersen, Integrationsministeriet Linda Szkotak Rasmussen, Politiet Adam Arndt, ITST Søren Klostergaard Pedersen, ITST Thomas Pilegaard Maarup, ITST Thomas Wulff, ITST Per de Place Bjørn, ITST, referat 25. januar 2009 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade 63 2100 København Ø Telefon 3545 0000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Per de Place Bjørn Telefon 3545 0175 E-post ppb@itst.dk Dagsorden 1. Velkomst 2. Godkendelse af dagsorden og referat (B) Jesper Nielsen, Velfærdsministeriet, var til stede ved sidste møde, men var ikke nævnt i referatets deltagerliste. Beslutning: Med denne korrektion godkendes referatet.
Referat, OIO-komitéens møde den 9. oktober 2008 3. Meddelelser (O) Per Shultz Eeg orienterede om reorganiseringen af kontorer i IT- og Telestyrelsen, hvor IT-Arkitekturkontoret og Datastandardiseringskontoret er blevet erstattet af én samlet afdeling med to kontorer: Kontor for it-infrastruktur og implementering (KIP) og Kontor for standardiserings- og arkitekturpolitik (KAP). Målet med reorganiseringen er, at ITST i endnu højere grad fokuserer på, hvordan IT kan skabe merværdi for forretningen. Fokus er således på anvendelsen af IT. Formandskabet for OIO-komitéen varetages af kontorchefen for KAP. Det meddeles, at Statens IT nu er medlem af komitéen repræsenteret ved Povl Scheel-Bech. 4. Præsentation af Digitalisér.dk (O) Thomas Pilegaard Maarup orienterede om Digitalisér.dk Én indgang til digitalisering af Danmark. Digitalisér.dk skal afløse OIO-kataloget, Servicekataloget og Infostrukturbasen, og vil gradvist blive udbygget til at være en samlende platform for al offentlig digitalisering. Thomas Pilegaard Maarup orienterede om udviklingsarbejdet, den nuværende funktionalitet ved ibrugtagningen den 1. oktober, planerne for migrering af indholdet fra ISB til Digitalisér.dk samt tidsplanen for kommende versioner af Digitalisér.dk. Komitéen stillede opklarende spørgsmål hvortil svarene var som følger: Termen Ressource betegner enhver af de objekter, som håndteres af Digitalisér.dk, for eksempel standarder, servicespecifikationer, datadefinitioner, XML-skemaer. Genkendelige klasser af ressourcer vil blive udstyret med specielle ikoner/tags for at lette navigationen. Der vil fremover blive arbejdet med at finde frem til den bedste måde at håndtere versionering af ressourcer NDR4 (som forventes pr 1. februar) vil indeholde retningslinier for versionering af datadefinitioner. Diskussioner vil fortrinsvis komme til at foregå i grupper på Digitalisér.dk grupper kan oprettes omkring et givent emne (for eksempel arkitekturkrav eller standardisering i INSPIRE regi), og kan være private eller offentligt tilgængelige. Tagging af ressourcer foregår, når de uploades Digitalisér.dk skal kunne medvirke aktivet med intelligente forslag til tags, baseret på kontekst og ressourcetype. Der ud over skal brugerne kunne oprette nye tags og styre taggingen af deres egne ressourcer. Det er endnu ikke muligt at uploade semantik (ud over hvad der er specificeret i NDR3) for datadefinitioner dette vil have fokus i den nærmeste fremtid. 25. januar 2009 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade 63 2100 København Ø Telefon 3545 0000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Per de Place Bjørn Telefon 3545 0175 E-post ppb@itst.dk
Referat, OIO-komitéens møde den 9. oktober 2008 InfoStrukturBasen er stadig åben for upload, indtil den endelige migrering foretages 22. oktober. Der ud over bidrog komitéen med en række kommentarer: Det vil være godt, om der bliver linket flittigt til eksterne web-sites. Når søgefunktionaliteten har høj prioritet som adgangsvej for brugeren, bør der sættes ekstra grafisk fokus på søgning se for eksempel Vejportalen.dk. Det er vigtigt, at opretholde rep.oio.dk, da mange ressourcer på Digitalisér.dk henviser til denne adresse. Thomas Pilegaard Maarup orienterede om tidsplanen for den kommen de udvikling af Digitalisér.dk: Pr 1. november kan man oprette brugere og grupper Version 1 forventes pr. 1. februar NDR4 kommer i høring medio november, til godkendelse i komitéen ultimo januar Se i øvrigt http://itst.dk/nyt-oio/milepaele Handling: Thomas Pilegaard Maarup uddelte version 0.9 af dokumentet Beskrivelse af godkendelsesprocessen (vedlagt), og bad om kommentarer til dette. Handling: Ligeledes bedes medlemmerne undersøge, om alt relevant indhold er migreret fra ISB til Digitalisér.dk. 5. Arkitekturkravsprojektet: Drøftelse af 15 skarpe og 10 principper (B) Thomas Wulff, ITST, orienterede indledningsvist om arkitekturkravsprojektet: OIO-komitéen har tidligere været inddraget i projektet i flere omgange: Sagen har været behandlet på OIO-komitémøder i foråret og der er gennemført workshops om potentielle arkitekturkrav på baggrund af en indsamling af og analyse af ønsker til it-arkitekturkrav. OIO-komitéen og IT- og Telestyrelsen fokuserede på seneste workshop på, at arkitekturkrav skulle være konkret anvendelige og tilføre konkret forretningsmæssig værdi ved deres anvendelse. Dette har ført til, at IT- og Telestyrelsen efter sommerferien har opereret med et sæt overordnede principper og et sæt bedste praksis anbefalinger. Dermed opstilles der ikke hårde krav. Thomas Wulff nævnte, at det er tilstræbt at anbefalinger er aktuelle lige nu (men måske ikke om 3 år), mens principperne har en længerevarende karakter. IT- og Telestyrelsen har betonet koblingen til de forretningsnære behov og værdien i den konkrete kontekst. Såvel principper som de 15 skarpe praksisanbefalinger er formuleret som korte sætninger, der så vidt muligt er holdt konkrete og koncise og med henvisninger til yderligere oplysninger. 25. januar 2009 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade 63 2100 København Ø Telefon 3545 0000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Per de Place Bjørn Telefon 3545 0175 E-post ppb@itst.dk
Referat, OIO-komitéens møde den 9. oktober 2008 Komitéens kommentarer til arkitekturprincipperne: Palle Røgilds Scheef, Region Nordjylland, nævnte, at der kunne være interesse i, at IT- og Telestyrelsen træffer valg om standarder og stiller egentlige hårde krav om overholdelse heraf. Frank Cavalho, SKAT, fandt omvendt, at anvendelsen af konkrete specifikationer ikke skulle være for stramt formuleret. Thomas Wulff nævnte, at digitalisér.dk var tænkt som et forum, hvor de itansvarlige og andre interessenter kunne drøfte behovet for fodslag vedrørende valg af standarder og mønstre, og at OIO-komitéen vil have mulighed for at ophøje standarder og mønstre til at være fælles, hvorefter de påfører et mærke herom på digitalisér.dk. Formanden supplerede, at relevante mønstre kan standardiseres på relevant niveau, men at specifikke løsninger ikke altid bør ophøjes til standarder. Princip 3: Processer skal optimeres før digitalisering kan have mere fokus på optimering, da modelleringen ofte er målrettet efter specifikke løsninger, eller begrænset af organisatoriske skel. Princip 4 og 8: Data skal have entydigt ejerskab og skal genbruges kunne med fordel udvides til Data og tjenester skal have entydigt ejerskab. Samtidig bør princip 8 præcisere alt, der skal genbruges. Princip 5: Åbenhed skal sikre konkurrence og innovation kan skærpes som: It-arkitekturen skal sikre åbenhed og dermed styrke konkurrence og innovation Princip 6: Løsninger skal være løst koblede kan udbygges med mere fokus på tjeneste-begrebet. Princip 7: Løsninger skal være agile. Her kunne fleksible eventuelt erstatte agile. Princip 9: Informationssikkerhed fra start til slut skal udbygges med Offentlige it-systemer skal beskytte information og funktionalitet, så uvedkommende ikke kan tilgå disse. Komitéens kommentarer til de 15 skarpe: De 15 skarpe er ikke rettet mod det samme forretningsniveau. Formanden: De skarpe kan organiseres efter forretningsniveau på Digitaliser.dk; pjecerne lavet for at kunne formidle principper og anbefalinger bredest muligt. Enkelte af arkitekturprincipperne slår ikke tilstrækkeligt godt igennem i de 15 anbefalinger for eksempel kunne princip 2: Borgere og virksomheder skal sættes i centrum være bedre repræsenteret. Der kunne opstilles anbefalinger om samarbejde frem for siloer, at tjenester skal være lette at finde for brugerne, samt at services skal være tværgående. Formanden: Tages til efterretning. 25. januar 2009 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade 63 2100 København Ø Telefon 3545 0000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Per de Place Bjørn Telefon 3545 0175 E-post ppb@itst.dk
Referat, OIO-komitéens møde den 9. oktober 2008 Anbefaling 2 og 11 kan opfattes som identiske. Formanden: Anbefaling 2 refererer til FORM og anbefaling 11 refererer specifikt til ESDH referencearkitekturen. Da begge disse er aktuelle i øjeblikket er de medtaget som specifikke anbefalinger. Per Schultz Eeg tilkendegav, at principper og anbefalinger vil blive efterset i lyset af de indkomne bemærkninger, og opfordrede til, at bemærkninger og bidrag til relevante eksempler fremsendes til IT- og Telestyrelsen. Handling: Bemærkninger til dokumenterne modtages snarest og senest 27. oktober. Beslutning: Komitéen godkender indstillingen; tager den justerede projekttilgang til efterretning med kommentar om, at der er efterspørgsel efter flere normative standarder inden for arkitektur, og indstiller principper og anbefalinger til godkendelse i STS. ITST gav i øvrigt tilsagn om at beskrive relationerne mellem OIO-EA, Arkitekturprincipperne og de 15 skarpe anbefalinger. 6. Målgruppe OIO-udvalget for Social og Omsorg (B) Jesper Nielsen, Velfærdsministeriet, orienterede om Domænet for Social og Omsorgs standardisering af målgruppedefinition. OIO-udvalget for Social og Omsorg har godkendt standardens semantik og det tilknyttede OIOXML-skema er blevet godkendt i OIO-sekretariatet. Standarden har været i høring og høringssvarene er blevet indarbejdet. Beslutning: Komitéen godkender standarden. 7. Semantikdefinitioner for OIOXML-kerneskemaer (B) Adam Arndt, ITST, orienterede om udarbejdelsen af semantikdefinitioner til eksisterende kernekomponenter. ITST har udarbejdet udkast til semantikdefinitioner som derefter har været diskuteret i kernekomponent-arbejdsgruppen. Endelig har semantikdefinitionerne været i offentlig høring og høringssvarene er blevet indarbejdet. En enkelt definition (AdressePunktId) manglede i mødematerialet. Definitionerne udgør primært en konvertering af kernekomponenternes eksisterende metadata, og må betragtes som et oplæg til videre raffinement. Peter Thrane, KL, opfordrede til, at ISO standarder for semantik tages i betragtning ved OIO-semantikdefinitioner. Jesper Nielsen, Velfærdsministeriet, viderebragte sit baglands bekymring i forhold til den proces der har frembragt semantikdefinitionerne, og påpegede samtidig at der i flere tilfælde mangler over- og underbegreber. Jesper Nielsen foreslog en fornyet proces til at klarlægge om der er et reelt problem. 25. januar 2009 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade 63 2100 København Ø Telefon 3545 0000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Per de Place Bjørn Telefon 3545 0175 E-post ppb@itst.dk
Referat, OIO-komitéens møde den 9. oktober 2008 Beslutning: Efter formandens indstilling beslutter komitéen at bibeholde de eksisterende semantikdefinitioner på Digitaliser.dk, men uden at markere dem som godkendte. ITST indkalder herefter relevante aktører til en proces, der skal sikre kvaliteten af semantikdefinitionerne. 8. Ledelsesinformation FESD (B) Per de Place Bjørn, ITST, fremlagde kort materialet. Komitéen havde ingen bemærkninger. Beslutning: Komitéen godkender standarden. Mogens Pedersen, Integrationsministeriet spurgte om der findes krav til, hvornår en godkendt FESD standard skal være implementeret. Formanden: Der er en forståelse mellem Økonomistyrelsen, leverandørerne og ITST om, at standarderne skal være implementerede senest 9 måneder efter godkendelse. 9. WS I-SD standard for integrationsmønstre (B) Per Schultz Eeg, ITST, orienterede om projektet Web Service Integration mellem Sager og Dokumenter (WS I-SD), hvor høring af standard for hændelse resulterede i, at ITST foreslår at iværksætte en åben OIO-proces for standard for hændelse, ligesom ITST foreslår, at tre kontekstspecifikke mønstre for integration på tværs af systemer ophøjes til standard. Beslutning: Komitéen tilslutter sig indstillingen om at iværksætte proces for standardisering af hændelse samt at de tre kontekstspecifikke mønstre for integration på tværs af systemer ophøjes til standard. 25. januar 2009 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade 63 2100 København Ø Telefon 3545 0000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Per de Place Bjørn Telefon 3545 0175 E-post ppb@itst.dk 10. Standarder for procesbeskrivelse (B) Søren Klostergaard Pedersen, ITST, orienterede om forslaget om optagelse af tre standarder for procesbeskrivelse præsentationen er vedlagt. Forslaget har været i høring, og høringssvar er indarbejdet i vejledningen til anvendelse af standarderne. Anders Bo Nielsen, Rigsarkivet, bemærkede, at der er et behov for praktisk vejledning i anvendelse af standarderne. Palle Røgilds Scheef, Region Nordjylland, nævnte, at Sundhedsstyrelsen har udarbejdet dokumenter om arbejdsgangsbeskrivelse. Formanden henledte der ud over opmærksomheden på, at KL har skrevet en god vejledning i modellering med BPMN. Beslutning: Komitéen godkender standarderne.
Referat, OIO-komitéens møde den 9. oktober 2008 11. Eventuelt Per Schultz Eeg, ITST, orienterede om, at ITST agter at sende FESD standarder for GIS2 og Konsolideret Datamodel i skriftlig høring blandt komitéens medlemmer i indeværende år. 12. Punkter til næste møde samt mødedatoer i 2009 (D) Sekretariatet foreslår følgende mødedatoer i første halvdel af 2009: 29. januar, 6. marts, 23. april, 4. juni og 20. august. Næste møde i komitéen er 5. november 2008 Forslag til emner til de kommende møder: Den offentlige blanketserver SDSDs arbejde med generelle begreber Standardisering af Webservice profiler samarbejde mellem terminologer og mo- Erfaringer fra DUBU-projektet dellører. SKATs erfaringer med standardisering. 25. januar 2009 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade 63 2100 København Ø Telefon 3545 0000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Per de Place Bjørn Telefon 3545 0175 E-post ppb@itst.dk
BILAG 1 b Beslutningsnotat; skriftlig høring af OIO-komitéen, 12. december 2008 Beslutningsnotat; Skriftlig høring af OIO- Komitéen d. 12. december 2008 De følgende emner sendtes i skriftlig høring med svarfrist den 18. december 2008: Emner 1. Revideret kommissorium for OIO-udvalg for fødevaresektoren 2. FESD standard: GIS-integrationsmodel Version 2.0 25. januar 2009 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade 63 2100 København Ø Telefon 3545 0000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Resultat: Ved svarfristens udløb var udelukkende indkommet tilkendegivelser, der støttede indstillingerne, eller som udtrykte ingen kommentarer. Sagsbehandler Per de Place Bjørn Telefon 3545 0175 E-post ppb@itst.dk Dermed kan komitéen følge indstillingerne til begge emner, hvorfor 1. det reviderede kommissorium for OIO-udvalg for fødevaresektoren er godkendt af komitéen 2. standarden FESD GIS-integrationsmodel Version 2.0 er godkendt af komitéen.
Bilag 2 Dagsordenspunkt 4 Præsentation af top- ontologi for Det Nationale Begrebsarbejde for Sundhedsvæsenet v/terminolog Camilla Wiberg Danielsen, Digital Sundhed Dato: 19. januar 2009 Projektnavn: Ansvarlig: cwd Tel. 2510 7541 Email: cwd@sdsd.dk Siden 2004 har sundhedsvæsenet arbejdet med begrebsafklaring i regi af Det Nationale Begrebsarbejde for Sundhedsvæsenet (NBS). Arbejdet omfatter nu ca. 500 centrale begreber, som er relevante for sundhedsdomænet. Begreberne findes i én sammenhængende ontologi, der består af tre lag: Et lag der omtales som topontologien Et lag der omfatter sundhedsfagligt generelle begreber Et lag der udgøres af ni delontologier vedr. sub-domæner. Til forskel fra delontologierne, som beskæftiger sig med sundhedsfaglige begreber omfatter topontologien helt generelle begreber som fx objekt, aktivitet og proces. Topontologien omfatter p.t. ca. 45 begreber, som er identificeret og indsamlet i forbindelse med arbejdet med sub-domænerne og dernæst bearbejdet af en særlig arbejdsgruppe. I 2009 vil NBS gennemføre en revision af topontologien med henblik på at tilføje eksempler og kommentarer og at oversætte topontologien til engelsk, således at det bliver muligt at bruge den i forbindelse med det internationale arbejde, der foregår på sundhedsområdet herunder udvikling af sundhedsterminologi. Præsentationen af NBS-topontologien sigter mod at vise, at den kan anvendes som et udgangspunkt for en fælles, offentlig topontologi, som sub-domæner fra andre fagområder vil kunne hæftes på.
BILAG 3 Cover Dagsordenspunkt 5, OIO- komitéen, 29. januar, 2009 Drøftelse Samarbejdet mellem Digital Sundhed og IT- og Telestyrelsen om anvendelse af fælles infrastruktur (identitetsbaserede services) Resumé Digital Sundhed og IT og Telestyrelsen har i længere tid samarbejdet omkring udvikling af nationale og internationale standarder for webservices, der kan lave opslag og opdateringer med en konkret brugers identitet. Digital Sundhed vil orientere komiteen om baggrund, resultater og planer i forbindelse med dette samarbejde. Orientering vil inkludere følgende punkter: - De forretningsmæssige behov for identitetsbaserede webservices på sundhedsområdet - Sundhedsområdets initiativer med serviceorienteret system integration (SOSI) og den god webservice (DGWS) - Samarbejdet med ITST omkring udvikling af national standard med international forankring - Planer for migrering til national OIO standard- Motivationen, målene, og status På mødet orienterer Konsulent Kåre Kjeldstrøm, SDSD. Indstilling Det indstilles, at OIO-komiteen drøfter perspektiverne i fælles infrastruktur og identitetsbaserede services. 25. januar 2009 IT- og Telestyrelsen Kontor for It-infrastruktur og Implementering (KIP) Holsteinsgade 63 2100 København Ø Telefon 35450000 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Søren Peter Nielsen Telefon 2567 0783 Telefax 3337 9299 E-post spn@itst.dk
BILAG 4 Cover Dagsordenspunkt 6, OIO- komitéen, 29. januar 2009 Drøftelse Web 2.0 erfaringer og anbefalinger Resumé ITST ønsker at sætte fokus på offentlig og privat brug af web 2.0 teknologier. Det er tanken at det i første omgang skal ske ved via digitaliser.dk - at samle erfaringer, skabe debat udkrystallisere nogle best practise anbefalinger evt. en form som en ny skarp best practise anbefaling. Sagsfremstilling Formålet er at facilitere videndeling og at give anbefalinger om brug af web 2.0 koncepter og løsninger. Både generelt og specielt i forbindelse med offentlig forvaltning, men også omfattende fx foreninger, virksomheder og private. Anbefalingerne skal bygge på konkrete erfaringer. Fokus skal være værdiskabelse via borger/brugerdialog & -deltagelse, fællesskab og gensidig hjælp fx mellem borgere eller mellem myndigheder gennem brug af web 2.0 teknologier, løsninger og tjenester. Som eksempler på kendte web 2.0 succeser kan nævnes Wikipedia, Facebook, Myspace, Youtube, Flickr og et utal af blogs og rss feeds. I den offentlige sektor er erfaringerne endnu begrænsede men fx har Anders Fogh Rasmussen brugt Facebook i forbindelse med en valgkamp, Finansministeriet har brugt en wiki i forbindelse med udvikling af integrationsmodel for portaler, ITST har lanceret digitaliser.dk som støtte for deling af og debat om ressourcer i forbindelse med it-projekter og standardisering, Frederikshavn har sat web 2.0 højt på dagsordenen for 2009 osv. 25. januar 2009 IT- og Telestyrelsen Kontoret for Standardiserings- og arkitekturpolitik (KAP) Holsteinsgade 63 2100 København Ø Telefon 3337 9137 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Michael Bang Kjeldgaard Telefon 33379115 Telefax 3337 9299 E-post mbk@itst.dk I udlandet findes der mange eksempler på http://government20bestpractices.pbwiki.com/ http://www.socialtext.net/wiki-government-anddemocracy/index.cgi?gov_2_0_resource_center http://www.appsfordemocracy.com http://www.showusabetterway.com/ Idéen med projektet er at samle viden og erfaringer for dernæst at skabe grundlag for at kunne give best practise anbefalinger. I første omgang er der oprettet en gruppe på digitaliser.dk - http://digitaliser.dk/group/41674.aspx - hvor alle inviteres til at deltage i debatten med eksempler, erfaringer, idéer og gode råd. Det kan fx være i forhold til spørgsmål som:
Hvilke web 2.0 teknologier og løsninger er modne? Hvilke er umodne? Kender du til gode, gratis open source komponenter eller gratis tjenester, der kan integreres lokalt og som er lige til at tage i brug? Hvordan får man web 2.0 til at give værdi? Hvilke typer værdi? Hvordan høstes værdien? Hvordan kan web 2.0 bruges til digital forvaltning (gov 2.0)? Hvilke krav stiller web 2.0 til organisationen i form af ressourcer og modenhed? Komitéens medlemmer opfordres til at deltage aktivt med at formidle og debattere idéer og erfaringer. Indstilling Det indstilles, at OIO komitéen drøfter projektforslaget, og at komitéens medlemmer bidrager med egne erfaringer og overvejelser på digitaliser.dk. 2
BILAG 5 Cover Dagsordenspunkt 7, OIO- komitéen, 29. januar, 2009 Beslutning OIO og det fællesoffentlige på Digitalisér.dk Resumé Synligheden af det fællesoffentlige OIO-samarbejde kan styrkes gennem forskellige måder at udvikle Digitalisér.dk. Oplægget skitserer forskellige veje og efterspørger komitéens holdning. Sagsfremstilling Et grundlæggende designprincip i udviklingen af Digitalisér.dk er, at indholdet, det vil sige uploadede digitaliseringsartefakter eller ressourcer, bliver præsenteret på en værdineutral, demokratisk måde. På den måde har man tilstræbt at gøre platformen tilgængelig for alle, at give alle brugere indtryk af, at de kan bidrage på lige fod, at alles bidrag er gode og kan bruges af andre. Denne tilgang til præsentation af ressourcerne medfører naturligt, at - for eksempel - ressourcer fra ministerielle deltagere eller artefakter udviklet af store tværoffentlige projekter ikke fremhæves redaktionelt frem for ressourcer leveret af private selskaber. Dette betyder, at det tværoffentlige samarbejde omkring OIO, som OIO-komitéen er anker for, risikerer at drukne i massen af artefakter, som kun har et begrænset anvendelsesområde. Det betyder også, at der ikke længere er et dedikeret netsted, der fremhæver det fællesoffentlige samarbejde om digitalisering. Når en ressource er fremfundet på Digitalisér.dk, vil det ved hjælp af tags og klassifikationer fremgå, at ressourcen er knyttet til det tværoffentlige samarbejde. Dette svarer til den funktionalitet der i øjeblikket er implementeret. OIOsamarbejdet kan fremhæves yderligere på Digitalisér.dk på en række forskellige måder med forskelligt niveau af synlighed som vil blive fremlagt på mødet som baggrund for diskussion af behov og anbefaling. 25. januar 2009 IT- og Telestyrelsen Kontoret for standardiserings- og arkitekturpolitik Holsteinsgade 63 2100 København Ø Telefon 3337 9137 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Per de Place Bjørn Telefon 3545 0175 Telefax 3337 9299 E-post ppb@itst.dk Tre niveauer af synlighed kan skitseres: 1. Aktiv udnyttelse af OIO-tag: Tværoffentlige projekter og OIO-komiteen er selv ansvarlig for at levere aktivitet og relevant indhold og at markere det som OIO-indhold. Fordel: Udiskriminerende for alle brugere og uden redaktionel belastning. Kræver ikke yderligere udvikling af digitaliser.dk. Ulempe: lav grad af synlighed af det fællesoffentlige samarbejde 2. Synlighed ved hjælp af en (permanent) forside-kampagne: På forsiden af Digitalisér.dk placeres et eller flere kampagne-felter, som reklamerer for og giver brugeren adgang til nyheder eller ressourcer med særlig aktualitet og relevans for det tværoffentlige samarbejde. Eksempelvis Kernekomponenterne, De 15 skarpe arkitekturanbefalinger, B103 obligatoriske standarder.
Fordel: Høj grad af synlighed uden væsentlige omkostninger. Ulempe: Ingen væsentlige ulemper 3. Synlighed som separat web-site: Der udvikles en hjemmeside som med et karakteristisk layout og logo signalerer det fællesoffentliges kvalitet og integritet. Et redaktions-team sørger for tematiseret indhold, hvor de fællesoffentlige projekter kommunikeres på både forsamlingshus-niveau og på teknisk/samfundsøkonomisk fyldestgørende niveau. Hjemmesiden kunne indeholde journalistisk materiale som fx interviews med brugere og opdragsgivere. Samtidig skal hjemmesiden kunne navigeres med for eksempel FORM og KLE som vejvisere til relevante projekter og deres ressourcer. Fordel: Fuld kontrol over kommunikationen fra det fællesoffentlige samarbejde. Ulempe: IT- og Telestyrelsen har ikke budget til dette. Hjemmesiden vil skulle linke til digitaliser.dk, da det er her standarder og arkitekturdokumenter ligger. Fuldmægtig Thomas Pilegaard Maarup, ITST KAP, orienterer på mødet. Indstilling Det indstilles, at komitéen diskuterer behovet for synlighed og midlerne til at opnå denne, samt derpå giver anbefaling om hvilken vej, udviklingen af Digitalisér.dk skal tage. 2
BILAG 6 Cover Dagsordenspunkt 8, OIO-komitéen, 29. januar 2009 Beslutning OIOXML Navngivnings- og Designregler (NDR) 3.2 25. januar 2009 Resumé Alle godkendte OIOXML-skemaer i InfoStrukturBasen (ISB en) er godkendt efter den til enhver tid gældende version af OIOXML Navngivnings- og Designregler (NDR). Pga. at InfoStrukturBasen blev nedlagt 31. oktober 2008, og dens rolle efterfølgende er overtaget af Digitalisér.dk, er det nødvendigt med en mindre opdatering af OIO NDR fra NDR 3.1R2 til NDR 3.2, så reglerne stemmer overens med skiftet af platform. Sagsfremstilling NDR 3.2 opdateringen er påkrævet, da ordet "InfoStrukturBasen" er indskrevet i flere regler. Dette giver ikke længere nogen mening pga. skiftet til Digitalisér.dk. Der er derudover blevet samlet flere brugerønsker ind til en ny version af NDR. Nogle få af disse vil også blive tilgodeset her i NDR 3.2. Den kommende NDR 4.0 vil imødekomme langt flere ønsker og vil i øvrigt være en mere fundamental ændring af OIOXML-konceptet. NDR 3.2 træder i kraft umiddelbart efter OIO-komitéens godkendelsen. IT- og Telestyrelsen Datastandardiseringskontoret Holsteinsgade 63 2100 København Ø Telefon 3337 9137 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Jan Brown Telefon 3337 9239 Telefax 3337 9299 E-post jbr@itst.dk Vedlagte bilag gennemgår alle NDR 3.2 regelændringer. Da der dels er tale om en justering i forhold til skift af platform til Digitalisér.dk, dels er tale om en lempelse af de eksisterende regler, anmodes OIO-komitéen om, at vedlagte regelændringer godkendes uden en høring for at få så hurtig en proces som mulig. Indstilling: Det indstilles, at komiteen godkender alle NDR 3.2 regelændringer uden en høring.
BILAG 6 Notat Dagsordenspunkt 8, OIO-komitéen, 29. januar 2009 Beslutning OIOXML Navngivnings- og Designregler (NDR) 3.2 25. januar 2009 Publikationen OIO Navngivnings- og Design Regler (engelsk: OIO Naming and Design Rules), også kort betegnet OIO-NDR eller bare NDR, definerer de regler, som et XML-skema skal overholde for at kunne blive godkendt som et OIOXML-skema til anvendelse indenfor OIOXML-regi. Godkendte OIOXMLskemaer er baseret på W3C XML Schema anbefalingen. Dette dokument indeholder alle de regelændringer, der er blevet foretaget for at løfte den gældende OIO-NDR 3.1R2 til OIO-NDR 3.2. Rationalet for disse regelændringer er: platformskift fra InfoStrukturBasen (ISB) til Digitalisér.dk ny fortolkning af nøgleordene BØR og BØR IKKE anvendt i reglerne ny opbygning af et OIO-namespace med versioneringsangivelse via namespacet samt ændring fra URL- til URN-format IT- og Telestyrelsen Datastandardiseringskontoret Holsteinsgade 63 2100 København Ø Telefon 3337 9137 Telefax 3545 0010 E-post itst@itst.dk Netsted www.itst.dk CVR-nr. 2676 9388 Sagsbehandler Jan Brown Telefon 3337 9239 Telefax 3337 9299 E-post jbr@itst.dk Platformskift fra ISB til Digitalisér.dk ISB'en blev lukket d. 31. oktober 2008 og er nu overtaget af det nye Digitalisér.dk. Da termen "InfoStrukturBasen" indgår som tekst i en del NDR-regler, er det nødvendigt at opdatere disse regler, så de reflekterer skiftet til Digitalisér.dk. Ændret fortolkning af nøgleordene BØR og BØR IKKE NDR-reglernes vægtning er gradueret med nøgleordene "SKAL", "MÅ IKKE", "BØR", "BØR IKKE" og "MÅ" og er i NDR 3.2 bragt i overensstemmelse med anbefalingerne i Internet Engineering Task Force RFC 2119 Key words for use in RFCs to Indicate Requirement Levels [http://www.ietf.org/rfc/rfc2119.txt]. I NDR 3.2 er specielt fortolkningen af BØR og BØR IKKE ændret i forhold til tidligere praksis. Ændringerne er markeret i nedenstående tabel med gråt og kursiv. Nøgleord NDR 3.2 NDR 3.1R2 SKAL Dette ord betyder, at det definerede er et absolut krav. Dette ord betyder, at det definerede er et absolut krav. MÅ IKKE Denne frase betyder, at det definerede er fuldstændig forbudt. Denne frase betyder, at det definerede er fuldstændig for-
BØR BØR IKKE MÅ, KAN Dette ord betyder, at der kan findes vægtige grunde til at se bort fra det definerede, men de fulde konsekvenser skal være forstået og nøje overvejet, før man vælger den vej. Denne frase betyder, at der kan findes vægtige grunde, hvor det, som defineres som frarådeligt, er acceptabelt eller sågar nyttigt, men de fulde konsekvenser skal være forstået og nøje overvejet, før man vælger den vej. Disse ord betyder, at det definerede er valgfrit. budt. Dette ord betyder, at det definerede er et krav. Kun hvis der findes vægtige grunde (der skal accepteres som gyldige), hvor de fulde konsekvenser skal være forstået og nøje overvejet, kan man se bort fra det definerede. Denne frase betyder, at det definerede forbydes. Kun hvis der findes vægtige grunde (der skal accepteres som gyldige), hvor de fulde konsekvenser skal være forstået og nøje overvejet og hvor det som defineres som frarådeligt, er acceptabelt eller sågar nyttigt, kan man anvende det definerede. Disse ord betyder, at det definerede er valgfrit. Denne ændring betyder i praksis, at nøgleordene BØR eller BØR IKKE ikke længere fortolkes som deciderede krav eller forbud, dvs. som SKAL og MÅ IKKE med mulighed for dispensation. Konsekvensen er også, at kun SKAL-regler fremover vil blive sagsbehandlet og krævet overholdt; BØR-regler vil ikke blive krævet overholdt. F.eks. vil konsekvensen være, at det kun er påkrævet at genbruge OIOXMLskemaer (tilhørende enten NDR-klassen eller Adoptionsklassen), hvis de samtidigt er klassificerede som Kerne- eller Domæneskemaer (se OIO-1). Hvis et OIOXML-skema ikke er klassificeret som et Kerne- eller Domæneskema, er der ikke længere krav om, at det skal genbruges, kun at det bør genbruges (se OIO- 2). Udover ændret fortolkning, er visse NDR-regler ændrede i NDR 3.2 pga. denne nye fortolkning af BØR og BØR IKKE. Bl.a. er: nogle dublet-regler slået sammen pga. ny fortolkning af BØR, f.eks. OIO-6 og OIO-7 slås sammen til kun én regel OIO-6. Det samme sker for GTD-2 og GTD-3 samt ELD-1 og ELD-2. GNR-2 ændres fra BØR til SKAL. Namespaceopbygning og versionering Et OIO-namespace har indtil nu været opbygget som en URL, som angav en fysisk placering af et XML-skema på InfoStrukturBasen. Dette giver ikke længere mening, da XML-skemaer på Digitalisér.dk ikke placeres i en folderstruktur. Af den grund ændres namespacet fra at være opbygget som en URL til at være opbygget som en URN (Uniform Resource Name - se http://en.wikipedia.org/wiki/uniform_resource_name ). Dette er tillige en har- 2
monisering med international opbygning af namespaces (bl.a. i UN/CEFACTregi). Versionering i den nuværende NDR 3.1R2 udføres vha. skemafilnavnet. Da netop håndtering af skemafilnavne er helt ændrede på Digitalisér.dk er det ikke længere muligt at opretholde versionering på denne måde. Der er også andre praktiske grunde til at ændre versioneringshåndteringen. Versionering vil fremover i NDR 3.2 (og senere versioner af OIO-NDR) blive håndteret udelukkende via skemaets namespace. Konsekvensen af at flytte versionering fra filnavn til namespace, påvirker en del regler (bl.a. FNR-1, VER-1, VER-2, VER-3). Regelændringer i OIOXML NDR 3.2 regelsættet I det følgende gennemgås alle regelændringer i NDR 3.2 i forhold til den nuværende NDR 3.1R2. Følgende ordliste er en normativ definition af centrale termer anvendt i NDRregelsættet. Adoptionsklasse Domæneklasse Kerneklasse Metadatafil NDR-klasse Adoptionsklassen er den grundlæggende OIOXMLklasse indeholdende internationalt udviklede XMLskemaer, der er optaget under OIOXML; disse betegnes Adoptionsskemaer. Et Adoptionsskema kan, hvis ønsket, samtidigt tilhøre enten Kerne- eller Domæneklassen (se disse). Domæneklassen indeholder skemaer, som, når det er muligt, specielt skal genbruges inden for et bestemt anvendelsesområde. Domæneklassen skal understøtte OIOXML-paradigmets genbrugstanke i så stor udstrækning, som det er muligt. Kerneklassen indeholder helt generelt genanvendelige skemaer, som, når det er muligt, skal genbruges af alle OIOXML-skemaer uafhængigt af deres klasse og uafhængigt om disse er specifikke for et bestemt anvendelsesområde eller ej. Kerneklassen skal understøtte OIOXML-paradigmets genbrugstanke i så stor udstrækning, som det er muligt. Betegner den XML-fil, som følger ethvert OIOXMLskema, og som indeholder OIOXML-skemaets metadata. NDR-klassen er den grundlæggende OIOXML-klasse indeholdende nationalt udviklede OIOXML-skemaer, betegnet NDR-skemaer. Et NDR-skema kan, hvis ønsket, samtidigt tilhøre enten Kerne- eller Domæneklassen (se disse). 3
OIOXML-klasse OIO-komitéen OIO-namespace OIO-udvalg Et udvalg godkendt af OIO-komitéen til at godkende områdespecifikke OIOXML-skemaer angivet i Domæneklassen. OIOXMLaflevering OIOXML-skema Støttetype Target namespace Fællesbetegnelse for NDR-klassen, Adoptionsklassen, Kerneklassen og Domæneklassen. Betegner det fællesoffentlige organ, som samlet udarbejder OIO-retningslinier og -metoder, samt godkender åbne OIO-standarder, såsom datastandarder og tekniske standarder. Er tæt koblet til OIO-udvalg, som er OIO-komitéens "forlængede arm" i de forskellige fagområder. Betegner et namespace som det anvendes inden for OIO-regi, dvs. hvis opbygning overholder de regler som er angivet i OIO-NDR. Et sæt af XML-skemaer, som hver kandiderer til at blive OIO-godkendt i en af OIO-klasserne. Et OIO-godkendt XML-skema, der overholder alle NDR-regler, er klassificeret via OIO-klasserne samt placeret på Digitaliser.dk En støttetype angiver en speciel type i OIOsammenhæng, som anvendes hvis det i et OIOXMLskema er nødvendigt at definere mere end én type. Den anvendes primært til at definere typer for lokalt erklærede attributter. Betegner det namespace som tildeles alle globalt erklærede og definerede komponenter, elementer, attributter og typer, i et XML-skema. I tabellen nedenfor er der i første kolonne angivet et NDR 3.2 ; i anden kolonne det tilsvarende NDR 3.1R2 (kun hvis nummeret har ændret sig i NDR 3.2); i tredje kolonne den nye NDR 3.2 regelformulering; og i fjerde kolonne NDR 3.1R2 regelformuleringen (hvis formuleringen har ændret sig). NDR 3.2 OIOXML regler OIO-1 NDR 3.1R2 NDR 3.2 formulering Et OIOXML-skema SKAL genbruge eksisterende elementer eller typer fra Kerneklassen og Domæneklassen. NDR 3.1R2 formulering 4
NDR 3.2 OIO-2 OIO-3 OIO-4 OIO-5 OIO-6 NDR 3.1R2 NDR 3.2 formulering 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 repræsentere den samme type. 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. NDR 3.1R2 formulering Et OIOXML-skema SKAL genbruge de indbyggede simple typer i XML Schema anbefalingen frem for at definere egne typer til at repræsentere den samme information. Et OIOXML-skema tilhørende Kerneklassen eller Domæneklassen 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. Udgår OIO-7 Et OIOXML-skema tilhørende NDR-klassen BØR 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. 5
NDR 3.2 NDR 3.1R2 NDR 3.2 formulering OIO-7 OIO-8 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. OIO-8 OIO-9 Et OIOXML-skema SKAL placeres på Digitalisér.dk. OIO-9 OIO-10 Et OIOXML-skema MÅ IKKE i dets udformning være influeret af begrænsninger i et bagvedliggende fagsystem. NDR 3.1R2 formulering En OIOXML-skemaaflevering SKAL i dets enkelte skemaer altid referere enten til godkendte OIOXML-skemaer i InfoStruktur- Basen eller til skemaer indeholdt i selve skemaafleveringen. Et OIOXML-skema SKAL placeres i InfoStrukturBasen. Et OIOXML-skema tilhørende Kerneklassen eller Domæneklassen MÅ IKKE i dets udformning være influeret af begrænsninger i et bagvedliggende fagsystem. Udgår OIO-11 Et OIOXML-skema tilhørende NDR-klassen BØR IKKE i dets udformning være influeret af begrænsninger i et bagvedliggende fagsystem. OIO-10 OIO-12 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 referere til et andet OIOXML skema, der anvender samme namespace, som skemaet der refereres fra. Et OIOXML-skema SKAL tilknyttes et namespace. 6
NDR 3.2 GXS-6 GXS-7 GXS-8 GXS-9 NDR 3.1R2 Generelle navngivningsregler GNR-1 GNR-2 GNR-2a GNR-2b GNR-2c NDR 3.2 formulering 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. 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. NDR 3.1R2 formulering Et OIOXML-skema SKAL angive alle dets schemalocationattributter med en absolut og gyldig URL til det refererede OIOXMLskemas placering i InfoStrukturBasen. Et OIOXML-skema BØR navngive alle dets globalt og lokalt erklærede komponenter (elementer, attributter samt typer) efter ObjektEgenskabRepræsentation navngivningsmodellen, som specificeret i følgende underregler. 7
NDR 3.2 GNR-2d (listen over repr.termer er placeret sidst i dette notat) GNR-2e GNR-2f GNR-2g GNR-2h GNR-2i NDR 3.1R2 NDR 3.2 formulering Engelsk/dansk sprogvalg i navngivning LNR-1 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. 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 (_). 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 OIOXML-skema, og et OIOXML skema med komponenter navngivet på dansk betegnes et dansk OIOXML-skema. NDR 3.1R2 formulering Et navn BØR IKKE benytte forkortelser og akronymer. 8
NDR 3.2 LNR-2 LNR-3 LNR-4 LNR-5 Navngivning af typer TPN-1 TPN-2 TPN-3 NDR 3.1R2 NDR 3.2 formulering 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 OIOudvalget, hvorvidt OIOXMLskemaet 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 Å. 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. NDR 3.1R2 formulering 9
NDR 3.2 TPN-4 TPN-5 TPN-6 NDR 3.1R2 Navngivning af elementer ELN-1 ELN-2 Navngivning af attributter ATN-1 NDR 3.2 formulering Navngivning af skema- og metadatafiler Et OIOXML-skema SKAL i dets Egenskab term i typenavnet for en kompleks type have værdien Collection i et engelsk OIOXML-skema 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. 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. Et OIOXML-skema SKAL navngive dets attributter med lower- CamelCase. NDR 3.1R2 formulering 10
NDR 3.2 FNR-1 NDR 3.1R2 NDR 3.2 formulering 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å den definerede type uden dets suffiks Type. NDR 3.1R2 formulering Et OIOXML-skema SKAL specificere dets filnavn <skemafilnavn> efter navngivningsmodellen: <elementnavn>+ _ +<version>+.xsd. Udgår FNR-1a Et OIOXML-skemas filnavn SKAL i dets <elementnavn>-term angive navnet på det i skemaet erklærede element, eller, hvis skemaet indeholder en abstrakt typedefinition, navnet på den definerede type uden dets suffiks Type. Udgår FNR-1b Et OIOXML-skemas filnavn SKAL i dets <version>-term benytte en gyldig datoangivelse i formattet ÅÅÅÅMMDD, hvor ÅÅÅÅ angiver et 4-cifret årstal, MM en 2-cifret månedsangivelse (01-12) og DD en 2-cifret dagsangivelse (01-31). FNR-2 Generelle regler for typedefinitioner GTD-1 GTD-2 Et OIOXML-skema SKAL navngive dets metadatafil efter modellen: <skemafilnavn>+.meta.xml. 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 tilhørende Kerneklassen eller Domæneklassen SKAL definere alle dets simple og komplekse typer globalt. Udgår GTD-3 Et OIOXML-skema tilhørende NDR-klassen BØR definere alle dets simple eller komplekse typer globalt. GTD-3 GTD-4 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. 11
NDR 3.2 NDR 3.1R2 NDR 3.2 formulering GTD-4 GTD-5 Et OIOXML-skema MÅ IKKE genbruge de indbyggede ur-typer anytype og anysimpletype. GTD-5 GTD-6 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, NMTO- KENS (afledt af den simple indbyggede type string). GTD-6 GTD-7 Et OIOXML-skema BØR benytte de indbyggede simple typer anyu- RI eller base64binary til at håndtere binært indhold. GTD-7 GTD-8 Et OIOXML-skema KAN benytte attributten abstract i simple og komplekse typedefinitioner til at definere abstrakte typer. GTD-8 GTD-9 Et OIOXML-skema BØR IKKE begrænse typeafledninger, dvs. attributterne finaldefault og block- Default i rodelementet schema, attributten final i simple typedefinitioner samt attributterne block og final i komplekse typedefinitioner BØR IKKE benyttes. GTD-9 GTD-10 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. GTD-10 GTD-11 Et OIOXML-skema SKAL definere dets støttetyper som simple typer. Regler for simple typedefinitioner STD-1 STD-2 Et OIOXML-skema MÅ IKKE benytte konstruktionen list. Et OIOXML-skema MÅ IKKE benytte konstruktionen union. NDR 3.1R2 formulering 12