Regelsamling for udvikling af XML Schemaer

Størrelse: px
Starte visningen fra side:

Download "Regelsamling for udvikling af XML Schemaer"

Transkript

1 Regelsamling for udvikling af XML Schemaer XML Schema kogebogen Udgivet af den fælles offentlige XML komité Version: LO

2 Af Mikkel Hippe Brun, Integrator Uniware NS Regelsamling for udvikling af XML Schemaer Abstrakt 4 Introduktion 4 Formål 4 Infostrukturbasen og overvejelser omkring løsningen 5 Regelsamlingens relation til Infostrukturbasen 5 Afgrænsn ing 5 Fremtidige versioner afregelsamlingen 6 Regelsamlingens målgruppe 6 Schema Design principper Schema-standard 6 Erklær schemaer i XML Schema Definition Language 6 Schema-varianter i Infostrukturbasen 7 Erklæring afcentrale typer og elementer 7 Erklær centrale typer og elementer i selvstændige schemaer 7 Dokumentér centrale typer og elementer 8 Strukturering afet XML Schema 8 Anvend Venetian Blind -modellen til strukturering af schemaer 8 Erklær typer globalt 9 Erklær kun elementer globalt, hvis de skal kunne genbruges 9 Begræns brugen af attributter til metadata 9 Definér attributter lokalt 9 Lav referencer til eksisterende erklæringer af elementer og typer 9 Brug kun den blandede indholdsmodel (mixed content) til dokumentorienterede schemaer 10 Gør regulære udtryk læsbare 11 Tilføj xs:restriction, der sikrer, at et element indeholder data til obligatoriske elementer 11 Udvid eller begræns eksisterende typer, hvis de ikke lever op til specifikke krav 11 Brug documentation-elementet til kommentarer 12 elementformdefault og attributeformdefault skal altid være qualified 12 Navngivning aftyper, elementer, attributter mv 12 Opbyg navne efter modellen: ObjektBeskrivelseKlassiflkation 12 Navngiv typer med klassifikationen, Type, som suffix 12 Undgå forkortelser og akronymer 12 Benyt unikke navne for centrale typer og elementer 13 Benyt unikke navne for globalt erklærede elementer og typer 13 Navngiv på engelsk 13 Brug UpperCamelCase til navngivning af typer og elementer 13 Brug lowercamelcase til navngivning af attributter 13 Brug lille bogstav ved erklæring af værdier i værdilister (enumerated values) 14 Navngivning afxml Schemaer 14 2

3 Benyt type-/element eller attributnavn som filnavn for centrale typer og elementer 14 Benyt Interface-klassifikationen ved navngivning af komplekse schemaer 14 Navngivning afnamespaces 14 Navngiv offentlige myndigheders namespaces efter modellen: 14 Navngiv private virksomheders namespaces efter modellen: 15 Versionering afschemaer, elementer og typer 15 Benyt versionering baseret på erklæring af nye element- og typenavne ved mindre ændringer 16 Benyt versionering baseret på navngivning afnamespace ved større realeases 16 Anvend version-attributten efter modellen: Release.RevisionDraft 16 Processen 17 Schemaudvikling via Infostrukturbasen 17 Afsøg nationale og internationale schema-databaser før erklæring af elementer, typer eller komplekse schemaer 17 Godkendelse afxml Sche,naer 17 Bilag 1: Skabelon for centrale elementer og typer... 3

4 Abstrakt Med henblik på at skabe let og billig adgang til offentlige data, blev der i regi af Finansministeriet i efteråret 2000 nedsat et udvalg om digital forvaltning. Udvalget vurderede, at der burde igangsættes konkrete initiativer vedrørende standarciisering af dataudveksling. Sådanne initiativer vil ifølge udvalget mindske udgifterne ved og lette adgangen til irtegration og udveksling af data. Det blev endvidere, besluttet, at den konkrete udmøntning skulle foregå i regi af IT- og Forskningsministenet og baseres på XML-teknologi. Ministeriet for Videnskab, Teknologi og Udvikling har i samarbejde med det Koordinerende Informationsudvalg (KIU), relevante offentlige myndigheder, KL og Amtsrådsforeningen samt private leverandører udarbejdet en strategi, der i al væsentlighed omhandler implementenngen af XML som standard for udveksling af data i den offentlige sektor og mellem den offentlige sektor og private virksomheder. Det Koordinerende lnformationsudvalg (KIU) har nedsat en XML-komité, der koordinerer og samordner anvendelsen af XML til informationsudveksling. Regelsamlingen giver entydige opskrifter på udformningen af XML Schemaer til dataudveksling i den offentlige sektor, men reglerne vil også med fordel kunne anvendes i den private sektor. XML-kommiteen anvender denne regelsamling, som redskab til at afgøre om et schema kan godkendes. Introduktion Formål Sigtet med denne regelsamling er at opstille en række forskrifter for udarbejdelse og anvendelse af XML Schemaer, der udvikles med henblik på standardisering og dataudveksling i offentligt såvel som i privat regi. Med faste regler for strukturering, navngivning og genbrug af schemaer og schema-komponenter, vil dataudveksling og dataintegralion blive lettet i både den offentlige og private sektor. Dette vil øge læsbarheden og lette fortolkningen af de data, der udveksles. Schema udviklere vil ved genbrug af eksisterende standardiserede schema-komponenter og ved overholdelse af regelsamlingens regler, kunne udvikle nye schemaer, der let kan gøres til genstand for standardisering. Regelsamlingen er udarbejdet på foranledning af den fællesoffentlige XML-komité. Bag projektet står Bestyrelsen for projekt digital forvaltning, samt Det koordinerende lnformationsudvalg (KIU). I såvel Bestyrelsen som Det Koordinerende Informationsudvalg er der stor opbakning til at anbefale XML som fælles offentlig standard for datakommunikation. Set i det lys nedsatte KIU en egentlig XML-komité, der har til opgave at sikre sammenhæng og fremdrift i standardisenngen af XML baserede grænseflader. Regelsamlingenen er et vigtigt instrument i XML-komiteens standardiseringsarbejde. Målsætningen med regelsamlingen er, at det ud fra dens retningslinier skal være muligt, at afgøre om et schema kan godkendes, ved at undersøge om schemaet overholder regelsamlingens regler. Yderligere oplysning om XML projektet og dets organisering kan findes på netstedet om Offentlig Information Online på 4

5 Infostrukturbasen og oven,ejelser omkiing løsnbigen Ministeriet for Videnskab, Teknologi og Udvikling (Videnskabsministenet) har, ultimo 2001, i samarbejde med XML-komiteen taget initiativ til etablering af en såkaldt Infostrukturbase. Infostrukturbasen vil blive gjort tilgængelig via internettet, og vil stille værktøjer til rådighed, der understøtter schema-udvikling og standardisering af XML-grænseflacier. Derudover vil basen indeholde et katalog med schemaer, schemafragmenter, grænsefladebesknvelser og procesbeskiivelser mv. Formålet er at tilvejebringe et værktøj, der kan være med til at realisere målsætningen om at skabe let og billig adgang til offentlige data. lnfostrukturbasen skal med andre ord understøtte samarbejdet omkring udvikling af schemaer og grænsefladebesknvelser til dataudveksling samt standardiseringsprocessen. Løsningen vil blive specificeret og udviklet i samarbejde med den valgte leverandør. Første fase i implementenngen er leveringen af en brugbar prototype. Prototypen forventes leveret medio 2002, mens en færdig løsning vil se dagens lys ultimo 2002/primo De formulerede ønsker og krav til Infostrukturbasen bunder i en række antagelser. Fundamentalt for visionen ligger den antagelse, at XML er et velegnet format til strukturering og udveksling af data. Den næste antagelse er, at XML Schema-standarden er velegnet til at udtrykke struktur og semantik for de XML-data der udveksles. Det er uomtvisteligt, at XML-standarden er kommet for at blive. XML Schema-standarden er et anden generation schema-sprog, hvor schemaer udtrykt som Document Type Deflnitions (DTD) var den første generation. XML Schema-standarden har så klare forbedringer i forhold til DTD-standarden, at en standardiseringsproces kan baseres på denne. Valget af XML Schema er fundamentalt for den måde, hvormed standardisenngsprocessen vil forløbe. Med XML Schema er det muligt, at genbruge Schema fragmenter på tværs af æhemaer. F.eks. kan erklæringen af en adresse-struktur genbruges i en lang række sdhemaer. Denne mulighed har været styrende for de visioner, der ligger til grund for Infostrukturbasen. Filosofien i den danske standardisenngsproces er i første omgang at standardisere de basale datatyper, elementer og schemaer, som benyttes på tværs af den offentlige og private sektor. For at sætte skub i denne udvikling har XML-komiteen nedsat en Nøgledata-arbejdsgrupp&, der netop har fået til opgave at identificere og udvikle schemaer for de centrale databaser, Iwis data bliver brugt overalt i den offentlige forvaltning. Med et standardiseret sæt af datatyper, elementer og schema-fragmenter vil XML-komiteen i kraft af denne regelsamling kræve, at disse benyttes som grundlag for ethvert schema, der ønskes godkendt af XML-komiteen. Det er nu op til de enkelte myndigheder, at udvikle schemaer eller skemafragmenter baseret på regelsamlingens anvisninger. RciGlsamlinaens relation til Infostnikturbasen Afgrænsning Regelsamlingen skal i sine regler og anvisninger afspejle vifteii af værktøjer som lnfostrukturbasen stiller til rådighed. Regelsamlingen vil, i takt med Inforstrukturbasens implementenng, blive revideret således at den afspejler denne udvikling. Et vigtigt aspekt ved regelsamlingen og Infostrukturbasen er procedurer og værktøjer til understøttelse af standardiseringprocessen. Indtil lnfostrukturbasen er implernenteret, og regelsamlingen er tilpasset lnfostrukturbasen, vil procedurebeskrivelseme relatere sig til en standardisenngsproces, hvor lnfostrukturbasen ikke er tilgængelig. Indtil dette er tilfældet vil de nævnte dokumenttyper, som Infostrukturbasen skal indeholde blive gjort tilgængelige under Dokumentet er ikke ment som en lærebog i rammerne af en kortfattet regelsamling. XML eller schema-design, da dette ligger udenfor 5

6 Vejledningen vil i den foreliggende form primært være velegnet til beskrivelsen af XML-baserede snitfiader mellem klassiske database-funderede systemer som f.eks. CPR-, CVR- og BBR-data. Til standardisering af udvekslingen af metadata for dokumenter og blanketter vil standardisenngsarbejdet i højere grad være dikteret af eksisterende standarder, der ikke nødvendigvis ligger i tråd med anbefalingeme i dette dokument. EksempeMs vil DokForm arbejdsgruppen under XML-komiteen muligvis udarbejde en Metadata-regelsamling med anvisninger for tilknytning af metadata i forbindelse med udveksling af data mellem konventionelle dokumenthåndtenngssystemer (EDI-l-systemer), såvel som systemer til elektronisk sags- og dokumenthåndtenng (ESDH-systemer) samt retningslinier for udvikling af dokument- og blanketstandarder. Ved at fokusere på XML-grænseflader mellem systemer, udtrykt i XML Schema, ses der bort fra en evt, forudgående datamodellenng. Vejledningen forudsætter, at mere komplekse interaktioner er blevet modelleret i f.eks. UML. Konkrete snitfiader mellem komponenter, der er kommet til udtryk ved en modellenng, kan efterfølgende omsættes til XML Schemaer efter retningslinieme i dette dokument. Fremtidige versioner af regelsamlingen Regelsamlingen vil blive suppleret af en vejledning, der er kendetegnet ved et mere forklarende og diskuterende indhold. Med vejledningen er det ambitionen, at det skal være muligt at forstå rationalet bag regelsamlingens regler. Denne opsplitning skyldes et ønske om at adskille hårde regler fra blød vejledning. Regelsamlingen vil blive revideret i takt med Infostrukturbasens implementering og i takt med, at der høstes erfaringer fra standardisenngsarbejdet baseret på regelsamlingen. Kommentarer, spørgsmål og forslag til forbedringer bedes rettet til Thomas Vinther i Videnskabsministeriet Regelsamlingens målgruppe Regelsamlingen henvender sig til de personer, som får til opgave at udvikle og standardisere grænseflader mellem informations-systemer. Vejledningen forudsætter et vist kendskab til lt, XML, XML Schema og de begreber og standarder, der knytter sig til behandling, beskrivelse, udveksling og manipulation af XML data. For baggrundsinformation omkring XML henvises til Schema Design principper Etidær schemaer i XML Schema Definition Language Grænseflader til udveksling af data skal udvikles som et antal XML Schemaer. Et XML Scherna udtrykkes i XML Schema Definition Language Q(ML Schema). XML Schemaer skal overholde W3C s anbefaling af XML Schema af 2. maj (http://www.w3.org/xmljschema). XML Schema er et meget fleksibelt sprog, men med fleksibiliteten øges risikoen for at det endelige schema ikke i tilstrækkeligt omfang kan genbruges i andre sammenhænge, og bliver ulæseligt for 6

7 andre end schema-designeren. De efterfølgende regler skal biddrage til at sikre en ensartet og genkennelig struktur på tværs af den offentlige og private sektor. Schema-vananter i Infostnikturbasen Det må forventes, at der under udviklingen af schemaer vil være stor variation i schema udvikles efter. I Infostrukturbasen vil de mest almindelige varianter være: de formål, et 1) Centrale typer. Schemaer med fælles datatyper og værdilister, som anvendes overalt i den offentlige og private sektor. F.eks. går brugen af efternavn, en virksomheds CVR nummer eller en adresse igen i et utal af sammenhænge. Disse mini-schemaer og datatyper skal anvendes som komponenter i en sammenhængende informations-arkitektur. 2) Centrale elementer. Schemaer med centrale element- og attributerklænnger, benyttes til at ensrette elementnavngivningen af hyppigt forekommende elementer og attributter. En elementerklænng skal som hovedregel tage udgangspunkt i en erklæring af en tilhørende datatype. For ekserrpel kunne erklæringen af elementet, CivilRegistrationNumber, være baseret på typen, CivilRegistrationNumberType. 3) Komplekse schemaer. Komplekse schemaer beskriver en grænseflade mellem 2 systemer og er typisk sammensat af andre schema-fragmenter (centrale typer og centrale elementer) Der er intet til hinder for, at et komplekst schema selv kan indgå som fragment i definitionen af et andet komplekst schema. Grænsen mellem schemaer, der blot er fragmenter i en datamodel, og schemaer, der beskriver en konkret grænsfiade kan være flydende. Det bærende hovedprincip er, at udviklingen af et schema, i størst muligt omfang, skal basere sig på genbrug af eksisterende erklæringer af typer og elementer. Eridæring af centrale typer og elementer Erldær centrale typer og elementer I selvstændige schemaer For at sikre genbrug mellem schemaer skal alle centrale type- og elementerklæringer erklæres i selvstændige schemaer. Om en type eller et element er centralt beror på en vurdering af om andre schemadesignere kan tænkes at skulle oprette schemaer, hvor den samme type indgår. Nedenstående eksempel illustrerer hvordan et CPRnummer kunne erklæres. <?xml version= l.o encoding= UTF-B?> <xs : schema targetnamespace= xmlns= xmlns:xs= elementformdefault= qualifled attributeformdefault= quallfled verslon= l.0 > element name= CivilRegistrationNumber type= CivilRegistrationNumberType I> <xs : simpletype name= CivilRegistrationNumberType > <xs restrict ion base= xs : string > <xs:pattern value= [0-9]{l0} /> </XS: restriction> </XS : simpletype> 7

8 <Ixs:schema> Dokumentér centrale typer og elementer Erklæringer af centrale typer og elementer skal dokumenteres med udfyldelsen af Skabelon for centrale elementer og typer som findes i bilag i til dette dokument. Yderligere metadata kan tilknyttes, hvis der er behov for det. Strukturenng at et XML Schema Anvend Venetian Blind -modellen til strukturenng at schemaer For at sikre genbrug af schema-fragmenter skal schemaet struktureres modulæri, under anvendelse af navngivne typer og med referenng af elementer og typer. Denne model omtales i litteraturen som Venetian Blind -modellen. Alle elementer og typer, der har relevans uden for schemaet erklæres i schemaets rod (dvs, som erklæringer, der hierarkisk er placeret umiddelbart under <xs:schema...). Erklæringer af globale variable i gængse programmeringssprog giver tilsvarende synlighed af variable på tværs af procedurer. Betegnelsen globalt erklæret vil derfor blive brugt om erklæringer af elementer i schemaets rod, der kan refereres i andre schemaer. <?xml version l.o encoding= UTF-8?> <xs:schema targetnamespace= xmlns:xs= xmlns= http: //oio. dk/xmlc.dk/xml/schemas/2002/05 elementformflefault= qualified attributeformdefault= qualified version= l. 0> <xs : element name= PersonName type= PersonNameType /> <xs : complextype name= PersonNameType > <XS: Seql.leflce> <xs : element ref= FirstName /> <xs : element name= LastName type= LastNameType /> </xs : SegUenCe> </xs complextype> <xs : element name= FirstNam& type= FirstNameType /> <xs simpletype name= FirstNameType> <xs : restriction base= XS : string > <xs :minlength value=hllth/> <xs :maxlength value= 70 /> </XS : restrict ion> </xs simpletype> <XS : simpletype name= LastNameType > <xs restrict ion base= xs string > <xs :minlength value= l /> <xs :maxlength value= 35 /> </XS : restriction> </xs : simpletype> 8

9 </xs schema> I eksemplet er elementet PersonName, PersoriNameType, FirstName, FirstNameType Og LastNameType erklæret globalt, og kan genbruges i andre schemaer. Eridær typer globalt Datatyper skal erklæres globalt (dvs, i schemaets rod), uanset om de har elevans udenfor det aktuelle schema. Globalt erklærede typer gør strukturen mere forståelig, og eventuelt lange typenavne bliver ikke brugt i konkrete XML-instanser. Eridær kun elementer globalt, hvis de skal kunne genbruges Det er kun et krav at elementer erklæres globalt, hvis erklæringen kan genbruges enten inden for det samme schema eller på tværs af schemaer. Dette tillader brugen af simple elementnavne uden risiko for navnesamrnerifakj. Der vil forekomme schemaer, hvis indre indhold ikke har relevans i andre sammenhænge. Et eksempel kunne være en grænseflade mellem informationssystemer internt i en organisation. I ovenstående eksempel er LastName, for eksemplets skyld, erklæret lokalt. Begræns brugen af attribufter til metadata Som hovedregel skal man anvende elementer som hovedholder af data, og brugen af attnbutter skal begrænses, da attributter ikke kan drage nytte af XML Schema-standardens restriction- og extension-erklænnger. Brugen af attnbutter begrænser dermed fleksibiliteten og mulighederne for genbrug. Attributter skal reserveres til metadata, dvs, data som yderligere beskriver hoveddata. I følgende eksempler er det på sin plads at anvende attributter, fordi attnbutteme kvalificerer elementerne ved f.eks. at angive en enhed: <Weight measureunit= kg >230</Weight> <DateOfBirth verifiedby= CPR > </lJateOfBirth> Ved anvendelse af attiibutter bør værdierne være korte (i overensstemmelse med Name Tokens datatypen) og værdierne må gerne være tal. Definer atbutter lekalt Det er generelt mere sikkert at give attributter en lokal rækkevidde ved at definere dem indenfor konteksten af det element de tilhører. Lav referencer til eksisterende erklæringer af elementer og typer Det er aldrig god praksis, at kopiere eksisterende erklæringer fra et schema til et andet, da dette undgåeligt fører til uoverensstemmelser. Infostrukturbasen vil understøtte at brugere kan foretage konsekvens-analyser ved opdatenng af centrale typer og elementer. Analysen sker ved at undersøge schema-referencer (include og import) til det schema der skal opdateres. 9

10 Brug kun den blandede indhoidsmodel (mixed content) til Den blandede indholdsmodel tillader elementer at indeholde både data og andre elementer. Tekst baserede dokumenter kræver en sådan model, men til modellenng af dataorienterede grænseflader skal man afholde sig fra formen, cia den gør det vanskeligt at manipulere de modellerede data. Det følgende eksempel illustrerer en dataorienter XML-instans, der er defineret i forhold til en bandet indholdsmodel. <?xml version= l.o encoding= iso-8859-l?> <CategoryList> <Category>Værktøj <Category>Elektrisk værktøj <Category>Boremaskiner</Category> <Category>S1 ibemaskiner< /Category> </Category> <Category>Håndværktøj <Category>Høvle< /Category> <Category>Skrutrækkere< /Category> </Category> </Category> </CategoryList> I HTML optræder den blandede indhoidsmodel hyppigt. Nedenfor ses et eksempel på en XHTML instans, hvor elementet p er defineret med en blandet indholdsmodel: <?xml version= l.o encoding= UTF-8?> <It)OCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN > <html xmlns= http: //www.w3.org/1999/xhtml > <head> <title>blandet indholdsmodel</title> </head> <body> <p>ljen blandede indhoidsmodel må <em>kun</em> anvendes dokumenter< /p> </body> </html> til Det følgende eksempel illustrerer den samme kategonstruktur erklæret i forhold til en normal indholdsmodel: <?xml version= l.o encoding= iso-8859-l?> <CategoryList> <Category name= Værktøj > <Category name= Elektrisk værktøj > <Category name= Boremaskiner!> <Category name= Slibemaskiner /> </Category> <Category name= Håndværktøj > <Category name= Høvle I> <Category natne= Skrutrækkere /> </Category> 10

11 </Category> </CategoryList> Gør regulære udtryk læsbare Gør regulære udtryk så læsbare, som man kan. I stedet for at skrive at et tegn kan være et tal mellem 0 og 9 med koden Id, benyttes den den mere besknvende syntaks [0-9]. <xs : simpletype name= CivilRegistrationNumberType > <xs : restriction base= xs : string > <xs:pattern value= [0-9] {io} /> </xs : restrict ion> </XS simpletype> Tilføj xsrestriction, der sikrer, at et element indeholder data til obligatoriske Hvis et element er obligatorisk, er der en god chance for, at dokumentets forretningsregler kræver, at det indeholder data. Hvis det er tilfældet, så skal den relevante XML Schema mekanisme tages i brug for at sikre dette. En streng kan f.eks. være defineret med en minlength facet for at sikre at elementet er udfyldt. <xs : simpletype name= CivilRegistrationNumberType > <xs : restriction base= xs : string > <Xs : minlength value= 1!> <xs:pattern value= [0-9] {io} /> </XS restriction> </xs : simpletype> Udvid eller begræns eksisterende typer, hvis de ikke lever op til specifikke krav Hvis en type ikke lever op til et præcist krav, kan man gøre brug af XSDL arve-mekanismeme XS : extension og XS : restriction til at definere en ny datatype baseret på en allerede eksisterende datatype. Dette kunne for eksempel være relevant ved udvidelse af en adressedefinition som i nedenstående eksempel: <xs :complextype name= BasicAddressType > <XS : sequence> <xs:element name= Street type= xs:string /> </XS : seguence> </XS : complextype> <xs :complextype name= StandardAddressType > <XS complexcontent> <xs :extensiori base= BasicAddressType > <xs seguence> <xs:element name= PostalCode type= xs:string /> </XS sequence> </XS extens ion> </XS complexcontent> </XS complextype> 11

12 Bnig docimentation-eiementet til kommentarer Som hjælp til at dokumentere et schema kan man bruge sub-elementet, documeritat ion, til elementet annotat ion. Man skal være klar over, at det giver ekstra arbejde til XML processoren, så det skal kun bruges som hjælp til ovennævnte. elementfomidefault og atùihuteformdefault skal altid være qualified I forbindelse med deklarenng af target namespace, kan man definere om man ønsker, at de lokalt definerede elementer og attributter skal være unqualitied eller qualified. Det betyder, at man skal vælge om man ønsker, at elementer og typer i et instansdokument skal have tilføjet præfiks eller ej. Attnbutterne skal altid være sat til qualified. elementformdefault= qualified attributeformdefault= qual ified Navngivning af typer, elementer, attributter mv. Opbyg navne efter modellen: Navne på typer eller elementer skal opbygges som en kombination af tre nøgleord. OBJEKT BESKRIVELSE KLASSIFIKATION OBJEKT er et nøgleord, som beskriver det objekt I den enhed I det koncept, som det centrale data element eller type relaterer til, f.eks. Bank, Person, Building, Driver, I tilfælde hvor elementet I typens navn i sig selv er sigende nok, eller hvis objektet er givet ved den kontekst, som elementet I typen erklæres i, udelades dette præfiks. BESKRIVELSEN er et eller flere kvalificerende ord, som beskriver elementet I typen unikt. Hvis der er flere ord, skal hver enkelt være af betydning for elementet I typen, som bliver beskrevet. Ordenes rækkefølge går fra højre mod venstre, hvor deres vigtighed går fra venstre mod højre. Eksempler er Account som i BankAccountNumber, Birth som i PersonBirthDate eller Exit som i BuildingExitQuantity. KLASSIFIKATION er et nøgleord, som tildeler den klasse eller kategori, som data elementet I typen tilhører. Hvis navnet på data elementet I typen består af flere ord, tilføjes klassifikation. Eksempler er Number som i BankAccountNumber, Date som i PersonBirthDate eller Quantity som i BuildingExitQuantity. Typisk brugte klassifikationer er Code, Descnption, Number, Quantity, Rate og Text. Navngiv typer med klassiflkationen, Type, som suffix Navnene på datatyper bør slutte med tekststrengen Type. Undgå denne endelse på elementnavne. I tilfælde hvor et almindelig brugt navn slutter med Type, som f.eks. AddressType, kan man give XML-elementet et altemativt navn, som f.eks. AddressQualif jer og have en simpel datatype AddressQualifierType. Undgå forkoitelser og akronymer Undgå forkortelser og akronymer hvis muligt, da de hæmmer læsebarheden. Hvis der er behov for at lave forkortelser, skal det ske efter følgende regler: 12

13 Kun ord på mere en 8 tegn eller flere bør forkortes. Brug så vidt muligt eksisterende forkortelser. Hvis der ikke eksisterer en almindelig brugt forkortelse, så find på én, som dog skal give mening og være utvetydig. Forkortelser bør generelt skrives med store bogstaver. Hvis det er nødvendigt at skabe en ny forkortelse, så start med at Ijeme alle ordets okaler, og fjern så konsonanter en efter en fra midten af ordet og ud. Benyt unikke navne for centrale typer og elementer Centrale typer og elementer bliver brugt på tværs af schemaer i den offentlige og private sektor. Ved navngivning skal man sikre sig, at der ikke er erklæret elementer eller typer med samme navn. Benyt unikke navne for globalt etklærede elementer og typer Ved navngivningen af elementer og typer under et givet namespace skal der anvendes unikke navne for globale erklæinger. Ved globale erklæringer forstås erklæringer af typer eller elementer, der erklæret i roden af et schema, og dermed kan anvendes som komponent i andre schemaer. Navngiv på engelsk Type-, attnbut- og elementnavne skal som hovedregel erklæres på engelsk men suppleres med en dansk forklaring. Kun hvor det deta, der skal repræsenteres, alene har relevans i dansk sammenhæng, kan det forsvares at navngive på dansk. F.eks. kan det være svært at finde et dækkende engelsk ord for KommunalEj erlaugskode. Erklæringen skal naturligvis suppleres med en engelsk forklaring, selv om der er anvendt et dansk navn. Bnig UpperCameiCase til navngivning af typer og elementer Navne for typer og elementer skal begynde med et stort bogstav, herefter begynder hvert nyt ord med et stort bogstav. Hvor en forkortelse bestående udelukkende af store bogstaver, som f.eks. DK, bør det efterfølgende ord starte med et lille bogstav. F.eks. DKaddress, men DanishAddress. <XS element narne= l)anishaddress type= DanishAddressType /> Bnig lowercameicase til navngivning af attributter Navne for attnbutter skal begynde med lille bogstav, herefter begynder hvert nyt ord med et stort bogstav. <XS : complextype name= CustomerType > <XS : seguence> <XS:element name= FirstName type= XS:stririg /> </XS : sequence> <XS:attribute name= customerllj type= XS:integer /> <XS : attribute name= customerrating type= XS: iriteger /> </XS : complextype> 13

14 Brug lille bogstav ved erklænng af værdier i værdilister (enumerated values) En værdiliste definerer et udfaldsrum for et dement. Et eksempel på en værdiliste er definitionen af dage i en uge: monday, tuesday, wednesday, thursday etc. Værdierne i værdilisten skrives udelukkende med små bogstaver, med mindre det er værdier, som reelt begynder med stort bogstav (f.eks. egenavne). <XS : simpletype name= ClothesSizeType > <XS:restriction base=txs:string> <XS : enumeration value=ttlargef/> <XS : enumeration va1ue= medium /> <XS : enumeration value= small /> <XS: enumeration value= extra large /> </XS :restriction> </XS simpletype> Navngivning af XML Schemaer Anvendelse af beskrivende navne er ikke alene vigtigt internt i et schema, men giver også konsistens og sammenhæng ved navngivning af XML Schemaer og andre typer af XML dokumenter. Benyt type-lelement eller att,ibutnavn som filnavn for centrale typer og elementer Eksempler: CivilRegistratioriNumberType. xsd CivilRegistratioriNumber. xsd TelephorieNumberType. xsd HomeTelephoneNumber. xsd WorkTelephoneNumber. xsd Benyt Interface-Idassifikationen ved navngivning af komplekse schemaer Schemaer, der er udviklet som konkrete grænseflader mellem systemer skal navngives med endelsen, Interface. For eksempel: CompanyLegalUnitlnterface. xsd TaxReturnlnterface. xsd PurchaseOrderlnterface. xsd Navngivning af namespaces Navngiv offentlige myndi9heders namespaces efter modellen: Filosofien ved den valgte namespace navngivningsstrategi er, at namespacet på trods af, at det blot er en globalt unik identifikation, også skal rumme versionenng og yderligere være en valid URL, der ved opslag i en browser lister alle de schemaer, der er erklæret under det givne namespace. Et eksempel på en offentlig virksomhed kunne være følgende: http: //oio.dk/cpr. dk/xml/schemas/2002/05 14

15 Navnv pdvate onihede,s nænespaces efter modehe http/ilntemetdonaænebcml/schemas/arstal/månedldag! Det står private virksomheder frit for at erklære deres namespace uden at anvende oio.dk som prefix. Et eksempel kunne være: http : //virksomhed.dk/xml/schemas/2002/05 Der gøres opmærksom på, at den endelige administration af namespaces kan ændre sig, når Infostrukturbasen er endeligt implementeret. Versionenng af schemaer, elementer og typer I et hvert schema vil der før eller siden ske ændringer. Det er derfor nødvendigt med en stærk versionenngsstrategi. XML Schema-standarden har kun i ringe omfang taget højde for versionenngsproblematikken. Til schema-elementet er der en version-attribut, men standarden understøtter ikke, at man refererer til en bestemt version af et schema indenfor et givent namespace. En reference til et element sker i tre skridt: Det namespace som elementet tilhører skal associeres med et prefix (xmlns:bbr= ). Efterfølgende importeres den schema-fil som indeholder det ønskede element. Importen involverer, at man dels fortæller hvilket namespace schema-fllen er erklæret under, og dels fortæller, hvor schemaet er placeret. Dernæst refereres det berørte element ved at anvende det prefix, som det angivne namespace er associeret med. Eksempel: <?xml version= l.o?> xsd:schema targetnamespace= xmlns= http: //oio. dk/cvr. dk/xml/schemas/2002/05 xmlns :xsdhttp://www.w3.org/2001/xmlschema xrnlns:bbr= elementformdefault= qualified attributeformdefault= qualified > <xsd:import namespace= schemalocation= Address.xsd I> <xsd:element name= OfficialAddress type= bbr : OfficialAddressStructure I> </xsd: schema> Som det fremgår af eksemplet, er der ingen mulighed for at angive hvilken version af OfficialAddressStructure, elementet Off icialaddress skal basere sig på. Versionen er alene bestemt af kombinationen af namespace og det refererede element-/typenavn. Vi kan med andre ord indikere en versionsændring af et element eller en type på to måder: 15

16 Ved at deilnere et nyt namespace, hvor A lader en versionenngskonvention indgå i namespace-erklænngen. F.eks. kunne man ændre targetnamespace fra httd:iloio.dklcvr.dklxmllschemasl2002lo5 til (ændring af måned). Altemativet ved at erklære en ny type, som i realiteten er en ny version af en anden type. F.eks. Address findes nu i en ny Address2-udgave. Begge versioneringsmodeller har ulemper. Ændring af namespace kan i værste fald kræve kopiering af en stor mængde schemaer og manuel opdatering af targetnamespace. Versionering baseret på erklæring af nye element- og typenavne, der i navngivningen tilføjer et ciffer til eksisterende element-/typenavne er heller ikke tiltalende, da relationen mellem typerne går tabt. Nærværende regler må imidlertid tage højde for begrænsningen indtil der foreligger en ny udgave af XML Schema-standarden. Benyt versionenng baseret på erklæring af nye element- og typenavne ved mindre ændnnger Erklæring af nye versioner af elementer og typer sker ved at kopiere den gamle erklæring og tilføje et fortløbende ciffer til det nye navn, I nedenstående eksempel optræder der to versioner af Las tnametype. Ændringen består i, at der er afsat plads til længere eftemavne. <XS: simpietype name= LastNameType <xs : restriction base= xs string > <xs :minlength vaiue= i /> T> <xs :maxlength vaiue=35tt/> </XS : restriction> </XS : simpietype> simpietype narne= LastNameType2 > <xs: restriction base= xs : stririg > <xs :minlength vaiue= i /> <xs :maxlength vaiue= 70 /> </X5 : restriction> </XS simpietype> Benyt versionering baseret på navngivning af namespace ved større realeases I namespaces, hvor der løbende sker ændringer og tilføjelser, bør der ved passende intervaller erklæres et nyt namespace. Dette involverer, at alle schemaer under namespacet skal kopieres og det nye namespace skal indsættes som targetnamespace. Samtidig hermed slettes alle tidligere versioner af erklærede elementer og typer. I eksemplet fra før med LastNameType, orndøbes LastNameType2 til LastNameType, og den oprindelige erklæring af LastNameType slettes. Anvend version-attributten efter modellen: Release.Revisionøraft Selve schema-filen gennemgår ruturligvis også et antal versioner. For at indikere, at filen har ændret sig, skal versiori-attributten under schema-elementet anvendes efter følgende fremgangsmåde: 16

17 Nuværende praksis inden for W3C er at indikere en schema-version ved brug af attributten, version. Udkommende versioner vil have et versionsnummer af formen Release. Revision (f.eks. 1.2), mens udkast vil have et versionsnummer af formen Release. RevisionDraft (f.eks. i.2b). Det primære frigivelsesnummer (Release) bør ændres, når den tidligere version af schemaet vil forhindre eksisterende dokumenter i at opnå validering. Dette kunne ske, hvis f.eks. et nyt obligatorisk element tilføjes. Det mindre væsentlige versionsnurnmer (Revision) bør opdateres, når ændnng(er) i schemaet resulterer i, at alle eksisterende dokumenter fortsat kan valideres. F.eks. ved tilføjelse af et nyt valgfrit element. Versionsbogstavet (Draft) bør ændres hver gang, et nyt udkast udkommer. I eksemplet ovenfor er version I.2b andet udkast baseret på den anden revision 2 af udgivelse I som vil føre til en ny revision 1.3 eller udgivelsen 2.0. Processen Schemaudvikling via Infostrukturbasen Udarbejdelsen af schemaer skal i det omfang, det er muligt, tage udgangspunkt i de prædefinerede dataelementer, der til enhver tid findes i Infostrukturbasen. Denne base kan fra ultimo 02 findes via Her kan vejledning om udvikling af schemaer ved hjælp af Infostrukturbasen ligeledes findes. Indtil ultimo 02 vil aftalte schemaer være tilgængelige på Afsog nationale og internationale schema-databaser før erklæting at elementer, typer eller komplekse schemaer For at sikre konsistens mellem schemaer nationalt og internationalt, er det afgørende, at elementer, typer eller komplekse schemaer først erklæres i de tilfælde, hvor der ikke i forvejen findes en anerkendt standard på området. Følgende schema-databaser bør afsøges: Godkendelse at XML Schemaer Når XML Schemaet er udviklet, skal det sendes ind til den fællesoffentlige XML komité til godkendelse. Schemaet indsendes via XML komiteen har derefter til opgave at analysere schema forslaget og sikre, at det er i overensstemmelse med de øvrige nationale såvel som internationale standardiseringsinitiativer. Komiteen har mulighed for at nedsætte en arbejdsgruppe, hvis den vurderer, at der er yderligere behov for at undersøge det foreslåede schema. Indtil XML Schemaet er godkendt af XML komiteen er der mulighed for at offentliggøre det i et særligt område af Infostrukturbasen, så andre har mulighed for at se det allerede på et tidligt 17

18 tidspunkt. Det skal dog understreges, at XML komiteens godkendelse er afgørende for fuld implementenng af schemaet i Infostrukturbasen. Som led i XML koniteens godkendelse af et schema vil det blive offentliggjort på Der vil det i minimum 30 dage være muligt for alle til at give kommentarer eller forslag til ændringer af schemaet. Sideløbende vil centrale aktører blive gjort bekendt med at schemaet er blevet offentliggjort og blive inviteret til at give kommentarer. Dette sker for at sikre, at alle interessenter får mulighed for at kommentere et givent schema. Hvis der i løbet af godkendelsesfasen kommer ændringsforslag til XML Schemaet, behandles disse i en arbejdsgruppe og/eller i XML komiteen. Når schemaerne er godkendt og offentliggjort, vil de hele tiden være åbne for kommentarer og ændringsforslag. Hvis XML komiteen vurderer, at et schema er modent til revision, vil de, der har indsendt schemaet, blive anmodet om at opdatere det. Bilag 1: Skabelon for centrale elementer og typer For enhver erklæring af centrale elementer eller typer, skal der udfyldes en skabelon med metadata om typen/elementet. Skabelonen skal udfyldes på engelsk bortset fra den danske definition. Name Navn pä element / data type / specifikke data Required Version Data elementet I typens versionsnummer. Required Namespace Navnet på den namespace, som elementetltypen tilhører Required samt navn på den person som har oprettet namespacen. Kontaktperson Administrator af denne namespace. Required Internal group or Internt navn på gruppe eller element indenfor en Optional element name myndighed. Kan bruges som hjælp ved nye gruppe- I elementnavne. Abstract Resume af definition. Optional Definition En simpel og utvetydig definition af element, data type eller Required specifikke data Definition En simpel og utvetydig definition af element, data type eller Required (dansk) specifikke data. (på dansk) Purpose Til hvilket formål finder elementet I data typen I specifikke Optional data anvendelse. Logical Format Det krævede format set ud fra et logisk perspektiv. Dette Required kan indbefatte det laveste og højeste antal tegn og strukturen af data elementet / data typen / specifikke data, 18

19 f.eks. ser strukturen for et CPR-nummer således ud: NNNNNN-NNNN. N betyder her numensk tegn. XML schema Angivelse af hvor det XML Schema, hvor data elementet I Required typen bruges, er placeret. Usage elsewhere Bruges elementet I data typen I specifikke data af en anden myndighed, men med en anden betydning/udlægning. Optional Validation Valideringsregler, dvs. deklarationer af elementer og typer Optional i schemaet, skal overholdes ved parsing af opmarkerede data. Values Liste over tilladte værdier (f.eks. kvinde, mand). Optional Default Value Den gældende værdi, hvis intet andet er nævnt. Optional Based on Hvilken standard (ISO, W3C, etc.) er dette data element / Opbonal type baseret på. Verification Forholdsregler taget for at sikre korrektheden af element, Opbonal data type eller specifikke data. Venfikation adskiller sig fra validenng ved, at den sikrer et element! en types eksistens, f.eks. ved opslag på en oste. Ved hjælp af et regulært udtryk kan man f.eks. definere et CPR-nummers udseende, men det er nødvendigt, at venficere dets eksistens. Comments Eventuelle bemærkninger. Optional Date Datoen hvorpå denne version blev vedtaget som et Required Offentlig Centralt Data Element eller Type. Examples Eventuelle eksempler hvor element! data type I specifikke Opbonal data indgår. 19

20

Afsnittet er temmelig teoretisk. Er du mere til det praktiske, går du blot til det næste afsnit.

Afsnittet er temmelig teoretisk. Er du mere til det praktiske, går du blot til det næste afsnit. Afsnittet er temmelig teoretisk. Er du mere til det praktiske, går du blot til det næste afsnit. XML (eng. extensible Markup Language) XML er en måde at strukturere data på i tekstform. På samme måde som

Læs mere

Dokumentationsguide for dansk Bankkonto

Dokumentationsguide for dansk Bankkonto Dokumentationsguide for dansk Bankkonto OIOXML dokumentationsguide for dansk Bankkonto Denne guide er udarbejdet af Peter Neergaard Jensen, IT- og Telestyrelsen, i regi af Kernekomponentgruppen under XML-projektet

Læs mere

FESD standardisering Udveksling Version 1.0

FESD standardisering Udveksling Version 1.0 FESD standardisering Udveksling Version 1.0 Kolofon: FESD standardisering. Udveksling Version 1.0 FESD udvekslingspakke Udarbejdet af IT- og Telestyrelsen, IT-strategisk kontor, FESD standardiseringsgruppen

Læs mere

OIOXML skema regelsamlingen

OIOXML skema regelsamlingen OIOXML skema regelsamlingen Navngivnings- og Design Regler (NDR) Høringsversion Høringen forløber fra onsdag den 7. april 2004 indtil til fredag den. 7 maj 2004 kl. 12.00. Høringssvar sendes til XML-komitéens

Læs mere

OIOXML NDR. Navngivnings- og Design Regler. Version 3.0. Dato: 2004-12-15. Publikation: OIO 6 [3:2004] IT- og Telestyrelsen

OIOXML NDR. Navngivnings- og Design Regler. Version 3.0. Dato: 2004-12-15. Publikation: OIO 6 [3:2004] IT- og Telestyrelsen OIOXML NDR Navngivnings- og Design Regler Version 3.0 Dato: 2004-12-15 Publikation: OIO 6 [3:2004] IT- og Telestyrelsen Indholdsfortegnelse Forord...v 1. OIOXML grundlaget...v 2. Denne publikation...v

Læs mere

Særlig service vejvisning

Særlig service vejvisning Særlig service vejvisning Denne dokumentation er udarbejdet af Arbejdsgruppen for standardisering af vejdata (Vejportal) under en domæne-komité for vejsektoren i regi af XML-projektet i Ministeriet for

Læs mere

Guideline. EAN-systemet

Guideline. EAN-systemet Guideline Hammershusgade 17 DK-2100 København Ø Tel: 39 27 85 27 Fax: 39 27 85 10 www.ean.dk for anvendelsen af EAN-systemet til entydig identifikation af målepunkter i EL-forsyningssektoren samt EAN-13

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Udvidelse UBL 2.0 Extension G33 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Udvidelse Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

IKT-teknisk kommunikationsspecifikation

IKT-teknisk kommunikationsspecifikation Bilag til IKT Ydelsesspecifikation Dato 2012-10-01, Revisionsdato: 2013-04-15 Samarbejdsdokument for byggesagens parter Projekt: Byggesag: Projektledelse: IKT Koordinator: Dato: Revision: Revision dato:

Læs mere

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Datatyper UBL 2.0 Datatypes G29 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen E-mail:

Læs mere

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering OI OXML 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

Læs mere

XML webservice for pensionsordninger. Version 1.0 Draft A

XML webservice for pensionsordninger. Version 1.0 Draft A XML webservice for pensionsordninger Version 1.0 Draft A Dokumentoplysninger Titel: Projekt: Webservice for pensionsordninger EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Valutakurser og -koder UBL 2.0 Currency Exchange Rates G18 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Valutakurser og -koder Version

Læs mere

IT- og Telestyrelsen Februar 2007

IT- og Telestyrelsen Februar 2007 OIO-datastandardisering OIO-datastandardisering i sektorerne IT- og Telestyrelsen Februar 2007 Indhold Om denne publikation 5 Introduktion 7 Formål med denne publikation 7 Baggrund 7 Arbejdsmodellen for

Læs mere

Syntaks og struktur i EDI-meddelelser

Syntaks og struktur i EDI-meddelelser Forskrift F: EDI-kommunikation Bilagsrapport 1: Syntaks og struktur i EDI-meddelelser November 2011 Rev. 2 Dok.løbenr. 79520-07_v2 1/15 Indholdsfortegnelse 1. EDIFACT-syntaks og -struktur... 3 1.1 EDIFACT-struktur

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Kontakt UBL 2.0 Contact G34 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OUOUBL Kontakt Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.

Læs mere

Anvendelse af dobbelthistorik i GD2

Anvendelse af dobbelthistorik i GD2 Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:

Læs mere

Rapport om snitflader til publiceringsagent i Gentofte Kommune

Rapport om snitflader til publiceringsagent i Gentofte Kommune Rapport om snitflader til publiceringsagent i Gentofte Kommune Connecting Business & Technology Devoteam Fischer & Lorenz A/S 2004 Dette dokument er udarbejdet for af Devoteam Fischer & Lorenz A/S. har

Læs mere

FKG datamodellen Version 2.3.1 ArcGIS integration Sidste revisionsdato: 23. maj 2014

FKG datamodellen Version 2.3.1 ArcGIS integration Sidste revisionsdato: 23. maj 2014 FKG datamodellen Version 2.3.1 ArcGIS integration #1 FKG Fælleskommunale Geodatasamarbejde FKG datamodellen Version 2.3.1 ArcGIS integration Sidste revisionsdato: 23. maj 2014 1 FKG datamodellen Version

Læs mere

Professionel Udvælgelse i byggeriet Skabeloner

Professionel Udvælgelse i byggeriet Skabeloner Professionel Udvælgelse i byggeriet Skabeloner Vejledning i anvendelsen af skabeloner til brug for udvælgelse, herunder prækvalifikation i byggeriet Marts 2013 Byggeriets Evaluerings Center SOLIDARISK

Læs mere

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S 24-03-2009 Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S Problemstilling ved DBK integration i BIM Software Domæner og aspekter Det domæne, der primært

Læs mere

UDKAST v.2. Til interessenter i ehandel (udsendes i bred offentlig høring)

UDKAST v.2. Til interessenter i ehandel (udsendes i bred offentlig høring) Sektorstandardiseringsudvalget for ehandel Til interessenter i ehandel (udsendes i bred offentlig høring) UDKAST v.2. Høring over vision, pejlemærker og forretningskrav til ehandel mellem den offentlige

Læs mere

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret Håndbog Til CPR services Bilag 8 GCTP-standard m.m. CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Side 2 af 14 Indholdsfortegnelse

Læs mere

OIOXML dokumentationsguide Person

OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person . Ejerskab Indenrigs og Sundhedsministeriets CPR-kontor i medfør af Bekendtgørelse af lov om Det Centrale Personregister, jf. lov nr.

Læs mere

Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3

Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3 Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3 1 Indholdsfortegnelse INDHOLDSFORTEGNELSE 2 A5.1 INTRODUKTION 4 A5.2 HTTP RETURKODER 4 A5.3 DIGITAL POST FEJLKODER 7 A5.3.1 DIGITAL POST

Læs mere

OIOXML dokumentationsguide. OIOXML dokumentationsguide Person 1

OIOXML dokumentationsguide. OIOXML dokumentationsguide Person 1 OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person 1 Dato Forfatter 24-2-05 Bent Bilstrup Dokument oprettet Teknologisk Institut 25-2-05 Bent Bilstrup Konceptuel model indføjet 28-2-05

Læs mere

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

Læs mere

IKT-teknisk kommunikationsspecifikation

IKT-teknisk kommunikationsspecifikation Bilag til BYGST IKT Ydelsesspecifikation Dato 2013-12-19 Projekt: Byggesag: SDU, NATV2 Dato: 2014.03.25 Projektledelse: Version: Mads Koch, IKT Koordinator: Revision: Thomas Rasmussen, Revision dato: Modtaget:

Læs mere

Guide til integration med NemLog-in / Brugeradministration

Guide til integration med NemLog-in / Brugeradministration Guide til integration med NemLog-in / Brugeradministration Side 1 af 9 21. januar 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør)

Læs mere

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING 2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING Baggrund Udgangspunktet er projekt 2, dvs. en blog om cupcakes, hvor målgruppe, afsender og modtager allerede er defineret. Du bliver nu bedt om at udvikle et

Læs mere

Kulturministeriets it-arkitekturpolitik

Kulturministeriets it-arkitekturpolitik Kulturministeriets Kulturministeriets Januar 2012 Udgivet af Kulturministeriet Udarbejdet af Kulturstyrelsen H.C. Andersens Boulevard 2 1553 København V www.kulturstyrelsen.dk post@kulturstyrelsen.dk Kulturministeriets

Læs mere

Evaluering af Satspuljeprojektet Børne-familiesagkyndige til støtte for børn i familier med alkoholproblemer

Evaluering af Satspuljeprojektet Børne-familiesagkyndige til støtte for børn i familier med alkoholproblemer Sundhedsstyrelsen Evaluering af Satspuljeprojektet Børne-familiesagkyndige til støtte for børn i familier med alkoholproblemer Konklusion og anbefalinger September 2009 Sundhedsstyrelsen Evaluering af

Læs mere

Kontroller af forretningsregler ved indsendelse af digitale årsrapporter

Kontroller af forretningsregler ved indsendelse af digitale årsrapporter Oversigt over: Kontroller af forretningsregler ved indsendelse af digitale årsrapporter Erhvervsstyrelsen, december 201 Version 1.3 Erhvervsstyrelsen, december 201, Version 1.3 Side 1 Forord Dette dokument

Læs mere

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 1 Indholdsfortegnelse B.1. INTRODUKTION... 4 B.1.1. HENVISNINGER... 4 B.1.2. INTEGRATION MED EKSISTERENDE

Læs mere

B 103 - Bilag 6 Offentligt

B 103 - Bilag 6 Offentligt Udvalget for Videnskab og Teknologi B 103 - Bilag 6 Offentligt Ministeren for videnskab, teknologi og udvikling Udvalget for Videnskab og Teknologi Folketinget Christiansborg 1240 København K Hermed fremsendes

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

Implementering af bips A104 hos DTU

Implementering af bips A104 hos DTU Implementering af bips A104 hos DTU Baseret på bips A104 dokumenthåndtering, udgivet juli 2012 Anita Dalgaard BIM koordinator DTU Campus Service anida@dtu.dk bips konference 16. september 2013 Implementering

Læs mere

Finanstilsynets indberetningssystem. Vejledning til Regnearksskabelonerne

Finanstilsynets indberetningssystem. Vejledning til Regnearksskabelonerne Finanstilsynets indberetningssystem Vejledning til Regnearksskabelonerne Finanstilsynet - 2. udgave oktober 2009 Indholdsfortegnelse 1 INDLEDNING... 2 2 FORUDSÆTNINGER... 3 3 TRIN FOR TRIN... 4 3.1 Hent

Læs mere

Integration af DocuBizz og Helios

Integration af DocuBizz og Helios Integration af DocuBizz og Helios v. 0.2 Side 1 af 7 Integration af DocuBizz og Helios 1 Overordnet beskrivelse... 1 2 Format for de overførte data... 1 3 Overførsel af stamdata fra Helios til DocuBizz...

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL UUID UBL 2.0 UUID G32 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL UUID Version 1.1 Side 1 Kolofon Kontakt: IT- & Telestyrelsen E-mail:

Læs mere

Tilslutning til ecomone Basis (OIO Faktura)

Tilslutning til ecomone Basis (OIO Faktura) Tilslutning til ecomone Basis (OIO Faktura) 1. november 2009, Version 1.1 1. POST DANMARKS ECOMONE BASIS (OIO FAKTURA)... 3 1.1 BEGREBER... 3 2 KANALER... 3 3 MODEL FOR DATAUDVEKSLING... 4 4 KOMMUNIKATION...

Læs mere

Oktober 2013 HLG/XIGA. Opstartsvejledning ATS Engros 1/12

Oktober 2013 HLG/XIGA. Opstartsvejledning ATS Engros 1/12 Oktober 2013 HLG/XIGA Opstartsvejledning ATS Engros 1/12 1. ATS Engros vejledning for aktører Formålet med dette dokument er at beskrive, hvordan du kommer i gang med at anvende ATS til test af certifikat

Læs mere

Bilag 2 og 3 og værktøjer

Bilag 2 og 3 og værktøjer Bilag 2 og 3 og værktøjer Lars Erik Storgaard Geodatastyrelsen, laers@gst.dk Program for workshop Geodatastyrelsen Formål hvorfor workshop? Kvalificering af listen over myndigheder Temakammerater Opmærksomhed

Læs mere

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...

Læs mere

Dokumentering af umbraco artikeleksport:

Dokumentering af umbraco artikeleksport: Dokumentering af umbraco artikeleksport: Lav en artikel side 2-3. Installationsguide side 3-5. Opsættelse af databasen og web.config side 5-8. Umbraco: templates side 8. Umbraco: borger.dk tab side 8.

Læs mere

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Ministeren for videnskab, teknologi og udvikling Udvalget for Videnskab og Teknologi Folketinget Christiansborg

Læs mere

Overførsler til udlandet

Overførsler til udlandet Danske Bank, Statens Betalinger Overførsler til udlandet Juli 2010 Side 1 Indhold 1 Indledning... 3 2 Krav til STP-betalinger indenfor EU:... 3 3 Krav til STP-betalinger udenfor EU:... 3 4 BIC (SWIFT)...

Læs mere

Kort og godt om test af arkiveringsversioner

Kort og godt om test af arkiveringsversioner Kort og godt om test af arkiveringsversioner Data og dokumenter fra den offentlige forvaltnings it-systemer, som skal bevares for eftertiden, skal afleveres til arkiv i form af arkiveringsversioner. Arkiveringsversioner

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014 2014 Tidsregistrering Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4 Informationsteknologi B Roskilde Tekniske Gymnasium 25-11-2014 Indholdsfortegnelse 1 Indledning... 3 2 User stories... 3 3

Læs mere

Digital Signatur OCES en fælles offentlig certifikat-standard

Digital Signatur OCES en fælles offentlig certifikat-standard Digital Signatur OCES en fælles offentlig certifikat-standard IT- og Telestyrelsen December 2002 Resumé Ministeriet for Videnskab, Teknologi og Udvikling har udarbejdet en ny fælles offentlig standard

Læs mere

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU)

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Foranalyse Projekt: PDM-kerne Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Projektdeltagere: 1. Indledning og baggrund Mogens Sandfær (MS), Danmarks Tekniske Universitet (DTU) Jørgen

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

Kommentar fra KMS til Specifikation af Serviceinterface for Person

Kommentar fra KMS til Specifikation af Serviceinterface for Person Kommentar fra KMS til Specifikation af Serviceinterface for Person Organisation Side Kapitel Afsnit/figur/tabel /note Type af kommentar (generel (G), redaktionel (R), teknisk (T)) Kommentar KMS-1 G Godt

Læs mere

Data lagring. 2. iteration (implement backend)

Data lagring. 2. iteration (implement backend) Data lagring 2. iteration (implement backend) Emner Grundlæggende database begreber. Data definitionskommandoer ER-diagrammer og cardinalitet/relationer mellem tabeller Redundant data og Normalisering

Læs mere

Revision af tekniske standarder i OIO-kataloget 2007

Revision af tekniske standarder i OIO-kataloget 2007 Revision af tekniske standarder i OIO-kataloget 2007 høringssvar Jens Mikael Jensen Document: Høringssvar vedr- revision af tekniske standarder I OIO-kataloget 2007 Page 1 of 5 1. Resumé IT & Telestyrelsen

Læs mere

Effektiv digitalisering. - Digitaliseringsstyrelsens strategi 2012-2015. April 2012

Effektiv digitalisering. - Digitaliseringsstyrelsens strategi 2012-2015. April 2012 April 2012 Effektiv digitalisering - Digitaliseringsstyrelsens strategi 2012-2015 Baggrund Danmark står med væsentlige økonomiske udfordringer og en demografi, der betyder færre på arbejdsmarkedet til

Læs mere

Vejledning til anmodning om driftslignende tilskud fra Undervisningsministeriet

Vejledning til anmodning om driftslignende tilskud fra Undervisningsministeriet Vejledning til anmodning om driftslignende tilskud fra Undervisningsministeriet 1 1. INDLEDNING 3 2. HVEM KAN ANMODE OM DRIFTSLIGNENDE TILSKUD 3 3. KRAV TIL ANMODNINGENS FORM OG INDHOLD 3 4. DET ELEKTRONISKE

Læs mere

KMA-oplysninger. 1 Introduktion

KMA-oplysninger. 1 Introduktion KMA-oplysninger MADS MENU: KODER SYSTEMET KMA-OPLYSNINGER (E.1.1.) Revideret 07-02-2011 1 Introduktion I programmet KMA-oplysninger sættes en række grundlæggende indstillinger for MADS i afdelingen, fx

Læs mere

NemHandel-registret. Hjælpeguide til oprettelse i NemHandel-registret og registrering af profiler. August 2012 Version 1.0

NemHandel-registret. Hjælpeguide til oprettelse i NemHandel-registret og registrering af profiler. August 2012 Version 1.0 NemHandel-registret Hjælpeguide til oprettelse i NemHandel-registret og registrering af profiler. August 2012 Version 1.0 Introduktion Hvis en virksomhed eller en offentlig myndighed ønsker at kunne modtage

Læs mere

Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen

Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen Indhold Ændringer Centrale begreber Generelt Arbejdsgange Vejledningen består af 3 dele, som kan læses hver for sig. Du kan derfor

Læs mere

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER 1 INTRODUKTION 1.1 Formålet med Practitioner-eksamen er at give eksaminanden mulighed for at demonstrere forståelse af PRINCE2. Samtidig skal eksaminanden

Læs mere

Ungebasen. Dokumentation af webservices til udveksling af data mellem Ungebasen og et kommunalt vejledningssystem PUBLICPUBLIC PUBLICPUBLICX

Ungebasen. Dokumentation af webservices til udveksling af data mellem Ungebasen og et kommunalt vejledningssystem PUBLICPUBLIC PUBLICPUBLICX PUBLICPUBLIC PUBLICPUBLICX Ungebasen Dokumentation af webservices til udveksling af data mellem Ungebasen og et kommunalt vejledningssystem 16.06.2014 A414.97.6 [Status] Side 1 af 15 Indhold 1. Indledning...

Læs mere

SAX Simple API for XML.

SAX Simple API for XML. SAX Simple API for XML. En API (Application Programming Interface) et bibliotek eller et sæt af funktioner eller metoder. SAX er et sådant bibliotek af abstrakte metoder som f. eks. startdocument() eller

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel 02. december 2014 Indhold INDHOLD... 1 INDLEDNING... 2 STANDARDER... 4 OIOUBL e-handelsstandard... 4 OIORASP - transportprotokol... 5 BETINGELSER FOR ANVENDELSE AF

Læs mere

Specifikationsdokument for LDAP API

Specifikationsdokument for LDAP API Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Specifikationsdokument for LDAP API DanID A/S 5. juni 2014 Side 1-15

Læs mere

Encoding:...1 Et tegn sæt (character set):...1 UTF-8 og UTF-16 (Unicode):...2

Encoding:...1 Et tegn sæt (character set):...1 UTF-8 og UTF-16 (Unicode):...2 Encoding:...1 Et tegn sæt (character set):...1 UTF-8 og UTF-16 (Unicode):...2 Encoding: Vi har tidligere set på spørgsmålet om et XML dokuments encoding. Det er generelt altid en god ide at gemme et dokument

Læs mere

Administrator v1.0 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk

Administrator v1.0 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk Administrator v1.0 QUICK GUIDE Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk INTRODUKTION TIL REKVI-KONTOR Ideen med Rekvi-Kontor systemet udsprang

Læs mere

Indlæsning af tilskud fra UVM

Indlæsning af tilskud fra UVM Indlæsning af tilskud fra UVM Brugervejledning version 1.0 Side 1 Indholdsfortegnelse Indledning... 3 Download bogføringskladde fra brevportalen... 3 Gem regneark på din arbejdsplads... 3 Bearbejdning

Læs mere

Vejledning til indberetning af gødningsleverancer i Leverandørregisteret

Vejledning til indberetning af gødningsleverancer i Leverandørregisteret Vejledning til indberetning af gødningsleverancer i Leverandørregisteret - Planperioden 2013/2014 Juli 2014 Ministeriet for Fødevarer, Landbrug og Fiskeri NaturErhvervstyrelsen Vejledning til indberetning

Læs mere

TILLÆG TIL MANUAL Excel-indlæsning i Vvskatalogets administrationssystem

TILLÆG TIL MANUAL Excel-indlæsning i Vvskatalogets administrationssystem 3456.78 123456 TILLÆG TIL MANUAL Excel-indlæsning i Vvskatalogets administrationssystem 30. juli 2015 Indhold Indledning Side 3 Sådan kommer du i gang Side 4 Oprette nye varer Side 5 Ændre eksisterende

Læs mere

PHP 3 UGERS FORLØB PHP, MYSQL & SQL

PHP 3 UGERS FORLØB PHP, MYSQL & SQL PHP 3 UGERS FORLØB PHP, MYSQL & SQL Uge 1 & 2 Det basale: Det primære mål efter uge 1 og 2, er at få forståelse for hvordan AMP miljøet fungerer i praksis, og hvordan man bruger PHP kodesproget til at

Læs mere

Semantic Web teknologier. RDF Resource Description Framework. Henrik Hvid Jensen

Semantic Web teknologier. RDF Resource Description Framework. Henrik Hvid Jensen Semantic Web teknologier RDF Resource Description Framework Whitepaper af Henrik Hvid Jensen Vidensleverandør og forfatter SOA Network Henrikhvid@soanetwork.dk November 2004 URI giver mulighed for at vi

Læs mere

Database "opbygning"

Database opbygning Database "opbygning" Dette områder falder mest under en DBA's ansvarsområde. Det kan sagtens tænkes at en database udvikler i nogle situationer vil blive nød til at oprette produktions og test) databaser,

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

PROJEKTBESKRIVELSE INFORMATIONER FOR AFLEVERING TIL DRIFT

PROJEKTBESKRIVELSE INFORMATIONER FOR AFLEVERING TIL DRIFT PROJEKTBESKRIVELSE cuneco en del af bips INFORMATIONER FOR AFLEVERING TIL DRIFT Dato 20. marts 2014 Projektnr. 13 031 Sign. SSP 1 Indledning Dette projekt vil have fokus på at specificere de informationer,

Læs mere

Vejledning til indsendelse af artikler via Manuscript Central

Vejledning til indsendelse af artikler via Manuscript Central Vejledning til indsendelse af artikler via Manuscript Central Adgang til Manuscript Central o Login o Har du glemt dit password? o Velkomstsiden o Din forfatterside (Author Dashboard) Krav til manuskriptet

Læs mere

BAAN IVc. Brugervejledning til BAAN Data Navigator

BAAN IVc. Brugervejledning til BAAN Data Navigator BAAN IVc Brugervejledning til BAAN Data Navigator En udgivelse af: Baan Development B.V. P.O.Box 143 3770 AC Barneveld Holland Trykt i Holland Baan Development B.V. 1997. Alle rettigheder forbeholdes.

Læs mere

Rapport Analyse af offentlig-privat samarbejde

Rapport Analyse af offentlig-privat samarbejde Rapport Analyse af offentlig-privat samarbejde Finansministeriet bestilte i begyndelsen af 2014 en rapport om offentlig-privat samarbejde. Formålet med rapporten blev drøftet i pressen i foråret 2014.

Læs mere

ELEKTRONISK INDBERETNING CANCER 10/02 2010 VERSION 1.4

ELEKTRONISK INDBERETNING CANCER 10/02 2010 VERSION 1.4 ELEKTRONISK INDBERETNING CANCER 10/02 2010 VERSION 1.4 Indhold Indhold... 2 Introduktion... 3 Datamodel... 4 XML Schema... 4 Beskrivelse... 5 Skema1... 5 Appendix A Revisioner... 9 2 Introduktion Dette

Læs mere

Synkron Via CMS er en ny generation Content Management System

Synkron Via CMS er en ny generation Content Management System Synkron Via CMS er en ny generation Content Management System De sidste par år er internettet gået fra at være endnu en marketingaktivitet for de fleste organisationer til at blive et strategisk og forretningskritisk

Læs mere

Axapta 3.0 Konverteringsvejledning

Axapta 3.0 Konverteringsvejledning Axapta 3.0 Konverteringsvejledning ectrl Dokumentversion 3.0 Juli 2008 - Datakonvertering 2008 Side 1 af 14 Indholdsfortegnelse DATAKONVERTERINGSVÆRKTØJET:...3 KARTOTEK INFORMATIONSOVERSIGT - FANEBLAD...5

Læs mere

Postnummerkort.dk, version 1.0 officielt postnummerkort

Postnummerkort.dk, version 1.0 officielt postnummerkort Postnummerkort.dk, version 1.0 officielt postnummerkort 1. december 2006 Sag D-4236-6 /mli Version 1.0a 1. Indledning I forbindelse med forberedelsen af kommunalreformen vedtog folketinget i juni 2005

Læs mere

NemHandelsRegistret (NHR)

NemHandelsRegistret (NHR) NemHandelsRegistret (NHR) Hjælpeguide til oprettelse i NemHandelsRegistret og registrering af profiler. Januar 2015 Version 1.1 Introduktion Hvis en virksomhed eller en offentlig myndighed ønsker at kunne

Læs mere

Kontakthierarkier i. Denne vejledning beskriver forskellige måder, man kan præsentere sin myndighed over for borgere og virksomheder

Kontakthierarkier i. Denne vejledning beskriver forskellige måder, man kan præsentere sin myndighed over for borgere og virksomheder Kontakthierarkier i digital post Denne vejledning beskriver forskellige måder, man kan præsentere sin myndighed over for borgere og virksomheder i digital post. Version: 3.0 Udarbejdet: november 2011 Udarbejdet

Læs mere

Casper Fabricius http://casperfabricius.com. ActiveRecord. O/RM i Ruby on Rails

Casper Fabricius http://casperfabricius.com. ActiveRecord. O/RM i Ruby on Rails Casper Fabricius http://casperfabricius.com ActiveRecord O/RM i Ruby on Rails Casper Fabricius Freelance webudvikler - casperfabricius.com 9 års erfaring med webudvikling 6 år med ASP/ASP.NET/C# 3 år med

Læs mere

STINA-vejledning Automatiseret indberetning

STINA-vejledning Automatiseret indberetning DANMARKS NATIONALBANK Statistisk Afdeling Version 2.2 December 2010 STINA-vejledning Automatiseret indberetning 1. Indledning Vejledningen henvender sig til teknikere i virksomheder, der vil automatisere

Læs mere

Roskilde Tekniske Gymnasium. Eksamensprojekt. Programmering C niveau

Roskilde Tekniske Gymnasium. Eksamensprojekt. Programmering C niveau Roskilde Tekniske Gymnasium Eksamensprojekt Programmering C niveau Andreas Sode 09-05-2014 Indhold Eksamensprojekt Programmering C niveau... 2 Forord... 2 Indledning... 2 Problemformulering... 2 Krav til

Læs mere

FairSSL Fair priser fair support

FairSSL Fair priser fair support Exchange 2010 SSL certifikat administration Følgende vejledning beskriver hvordan man vælger hvilke adresser der skal være i ens Exchange 2010 SAN SSL certifikat. Derudover er der tekniske guides til at

Læs mere

Metodeanmeldelse af markedsforskrift F1 - EDIkommunikation

Metodeanmeldelse af markedsforskrift F1 - EDIkommunikation Til Energitilsynet Metodeanmeldelse af markedsforskrift F1 - EDIkommunikation med DataHub'en i elmarkedet 31. januar 2012 HBK/LRP Energinet.dk skal i følge Energistyrelsens bekendtgørelse nr. 1085 af 20.

Læs mere

GLOBETEAM. Central Brugerstyring: Brugervejledning til administrationsløsning. DSML-udtræk fra Active Directory, version 1.21

GLOBETEAM. Central Brugerstyring: Brugervejledning til administrationsløsning. DSML-udtræk fra Active Directory, version 1.21 Central Brugerstyring: Brugervejledning til administrationsløsning DSML-udtræk fra Active Directory, version 1.21 Indledning Dette dokument beskriver, hvordan man etablerer et korrekt DSML-formatteret

Læs mere

Implementeringsvejledning NemKonto-betalinger via Danske Bank Version 1.2

Implementeringsvejledning NemKonto-betalinger via Danske Bank Version 1.2 Implementeringsvejledning NemKonto-betalinger via Danske Bank Version 1.2 NemKonto-betaling Side 1 af 13 Implementeringsvejledning Indholdsfortegnelse Indholdsfortegnelse... 2 Formål... 3 Målgruppe...

Læs mere

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER Kommunernes it-arkitekturråd 8. maj 2014 AGENDA Væsentligste observationer og konklusioner Relevans for kommuner STRATEGI OG ARKITEKTUR Analysen giver et bud

Læs mere

Advanced Word Template Brugermanual

Advanced Word Template Brugermanual Advanced Word Template Brugermanual Forord: Advanced Word Template er et værktøj, der anvendes sammen med Microsoft Word til at opbygge ensartet beskrivelser på en mere intelligent måde end Copy and Paste

Læs mere

FKO Quick Guide. Kom godt igang med FKO Temperaturmåling

FKO Quick Guide. Kom godt igang med FKO Temperaturmåling FKO Quick Guide Kom godt igang med FKO Temperaturmåling FKO GUIDE Temperaturmåling Publikationen er udgivet af Socialstyrelsen Edisonsvej 18, 1. 5000 Odense C Tlf: 72 42 37 00 www.socialstyrelsen.dk Udgivet

Læs mere

Sundhedsstyrelsens vejledning om udarbejdelse og revision af målbeskrivelser i speciallægeuddannelsen

Sundhedsstyrelsens vejledning om udarbejdelse og revision af målbeskrivelser i speciallægeuddannelsen VEJ nr 9005 af 01/01/2012 (Gældende) Udskriftsdato: 19. februar 2015 Ministerium: Ministeriet for Sundhed og Forebyggelse Journalnummer: Sundhedsstyrelsen, j.nr. Senere ændringer til forskriften Ingen

Læs mere

FORSLAG TIL MASSEAFSENDELSE

FORSLAG TIL MASSEAFSENDELSE FORSLAG TIL MASSEAFSENDELSE Digital Post og Fjernprint 2015-03-11 Dagsorden 1. Velkomst 2. Nuværende OIO-rest 3. Udfordringer 4. Afrunding Nuværende OIO-REST løsning Digital post De nuværende Digital Post

Læs mere