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

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat. Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012

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

ABM standard arbejdsgruppen nedsat af Statens Arkiver, Biblioteksstyrelsen og Kulturarvsstyrelsen

ABM standard arbejdsgruppen nedsat af Statens Arkiver, Biblioteksstyrelsen og Kulturarvsstyrelsen nedsat af Statens Arkiver, Biblioteksstyrelsen og Kulturarvsstyrelsen Titel : Transport af ABM data Dato : 2007-10-15 Status : Gældende ABM-specifikation Sekretariat: Publicering: Kulturarvsstyrelsen ved

Læs mere

A 18 Validering af dataleverancer ifm. Ældredokumentationsprojektet

A 18 Validering af dataleverancer ifm. Ældredokumentationsprojektet Danmarks Statistik, IT-Center 27. mar. 2009 Jbb/Flj A 18 Validering af dataleverancer ifm. Ældredokumentationsprojektet Indhold: 1. Indledning...2 2. Validering med XML-skemaer i udviklingsfasen...3 3.

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

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

Generelt Internationalisering

Generelt Internationalisering Bekendtgørelse om krav til anvendelse af Informations- og Side 1 af 7 Generelt Digital Konvergens samarbejdet, har i sit hidtidige arbejde fokuseret på at implementere vindende, digitale standarder, der

Læs mere

Anvendelsesvejledning for entydig identifikation af målesteder i naturgas distribution ved hjælp af EAN-systemet.

Anvendelsesvejledning for entydig identifikation af målesteder i naturgas distribution ved hjælp af EAN-systemet. Anvendelsesvejledning for entydig identifikation af målesteder i naturgas distribution ved hjælp af EAN-systemet. Version: 1.0, maj 2003 Indholdsfortegnelse: 1. Baggrund... 2 2. Mål... 2 3. Definition

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

BILAG 1 GENERELLE BETINGELSER INTERN (VERSION 1.0 AF 31. MAJ 2005) (I DET FØLGENDE KALDET GENERELLE BETINGELSER) OIO STANDARDAFTALE FOR WEB SERVICES

BILAG 1 GENERELLE BETINGELSER INTERN (VERSION 1.0 AF 31. MAJ 2005) (I DET FØLGENDE KALDET GENERELLE BETINGELSER) OIO STANDARDAFTALE FOR WEB SERVICES BILAG 1 GENERELLE BETINGELSER INTERN (VERSION 1.0 AF 31. MAJ 2005) (I DET FØLGENDE KALDET GENERELLE BETINGELSER) OIO STANDARDAFTALE FOR WEB SERVICES INDHOLDSFORTEGNELSE 1. Anvendelsesområde... 3 2. Definitioner...

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

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

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

OBJECT IDENTIFICERES OID PHMR

OBJECT IDENTIFICERES OID PHMR OBJECT IDENTIFICERES OID PHMR MedCom. Odense d. 27. feb. 2014 Thor Schliemann OID OG INTEROPERABILITET OID er et omdrejningspunktet for interoperabilitet I både teknisk og semantisk interoperabilitet er

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

BILAG A KØBENHAVNS UNIVERSITET IKT-TEKNISK KOMMUNIKATIONSSPECIFIKATION

BILAG A KØBENHAVNS UNIVERSITET IKT-TEKNISK KOMMUNIKATIONSSPECIFIKATION KØBENHAVNS UNIVERSITET BILAG A IKT-TEKNISK KOMMUNIKATIONSSPECIFIKATION PROJEKT ID: KU_xxx_xx_xx_xxxx (se bilag G, pkt. 0.0) PROJEKTNAVN: xxx DATO: xx.xx.xxxx VERSION: 1.1 VERSIONSDATO: 28.03.2014 02 BILAG

Læs mere

Namespaces. Vi kan kvalificere elementer på denne måde:

Namespaces. Vi kan kvalificere elementer på denne måde: <?xml version=1.0 encoding=iso-8859-1?> Namespaces...1 Default namespace:...6 Præfiks:...7 To slags navne i XML:...11 Standard namespaces:...14 RDF Resource Description Framework:...18 Attributter:...19 DTD skemaer og namespaces:...21 Namespaces.

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

OIO står for Offentlig Information Online og er det offentliges fællesbetegnelse for it-arkitektur, it-standarder og digital forvaltning.

OIO står for Offentlig Information Online og er det offentliges fællesbetegnelse for it-arkitektur, it-standarder og digital forvaltning. 1 af 6 30-01-2009 12:42 Vejledning Brugervejledning for OIO-katalog over offentlige it-standarder Version 2.0 - April 2008 INDHOLDSFORTEGNELSE Indledning OIO på nettet Standarder og standardisering Offentlig

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

DKAL Snitflader REST Register

DKAL Snitflader REST Register DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4

Læs mere

Uniq.Survey-Xact.DK. Vejledning. Rambøll Management Olof Palmes Allé 20 DK-8200 Århus N Denmark. Tlf: 8944 7800 www.ramboll-management.

Uniq.Survey-Xact.DK. Vejledning. Rambøll Management Olof Palmes Allé 20 DK-8200 Århus N Denmark. Tlf: 8944 7800 www.ramboll-management. Uniq.Survey-Xact.DK Vejledning Rambøll Management Olof Palmes Allé 20 DK-8200 Århus N Denmark Tlf: 8944 7800 www.ramboll-management.dk TU1.UT TUIndledningUT TU2.UT TUKlargøring TU3.UT TUOprettelse TU4.UT

Læs mere

Nedenstående oversigt viser elementerne i den meddelelse, der skal overføres fra fødeafdeling til kirkekontor/sogn.

Nedenstående oversigt viser elementerne i den meddelelse, der skal overføres fra fødeafdeling til kirkekontor/sogn. Teknisk oversigt over elementer i fødselsanmeldelsen Nedenstående oversigt viser elementerne i den meddelelse, der skal overføres fra fødeafdeling til kirkekontor/sogn. Der anvendes XML. Denne version

Læs mere

Webservice til upload af produktionstilladelser

Webservice til upload af produktionstilladelser BILAG 1 Webservice til upload af produktionstilladelser Indhold og anvendelse Denne web-service gør det muligt for 3. parts programmer i kommuner og amter at Uploade og registrere kommunale produktionstilladelser

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

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

OIOXML, XML-komitéens arbejde og igangsatte projekter

OIOXML, XML-komitéens arbejde og igangsatte projekter OIOXML, XML-komitéens arbejde og igangsatte projekter Præsentation ved EPJ-Observatoriets konference d. 28. oktober 2003 Ved René Løhde rel@itst.dk Min dagsorden XML-komitéen På vej ind i en ny fase Status

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

Internt notat 202542 2

Internt notat 202542 2 Internt notat Arbejdspapir Systemdesign Dato: 6. september 2004 Sagsnr.: 5564 Dok.nr.: 202542 v2 Reference: PMO/PMO Beskrivelse af Eltra XML-struktur 1. Indhold Dette er beskrivelsen af den XML-struktur,

Læs mere

Digital signatur og XML. Karsten Munk, Videnskabsministeriet

Digital signatur og XML. Karsten Munk, Videnskabsministeriet Digital signatur og XML Karsten Munk, Videnskabsministeriet Indledning Ministeriet for Videnskab, Teknologi og Udvikling tidligere IT- og Forskningsministeriet + universiteterne + innovationspolitikken

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

Krav i Leverancekontrakt Bilag 2 krav lyder (jf. ændringsforslag 18) således:

Krav i Leverancekontrakt Bilag 2 krav lyder (jf. ændringsforslag 18) således: Indholdsfortegnelse Bevis for krav 19.12...1 Indledning...1 Metode...1 Resultater...2 Søgning på fanebladet Bygning og boliger...2 Skærmbilledet Grund...3 Skærmbilledet Bygningsamurai...4 Søgning på fanebladet

Læs mere

IKT TEKNISK KOMMUNIKATIONS- SPECIFIKATION

IKT TEKNISK KOMMUNIKATIONS- SPECIFIKATION DATO DOKUMENT SAGSBEHANDLER MAIL TELEFON 5. december 2016 16/10604-1 Tina Jonsen tjon@vd.dk +45 7244 2220 IKT TEKNISK KOMMUNIKATIONS- SPECIFIKATION Thomas Helsteds Vej 11 8660 Skanderborg vd@vd.dk EAN

Læs mere

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring Version 1.0 Vilkår for brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT

Læs mere

Boligportal.dk s kravspecifikation til XML-feed

Boligportal.dk s kravspecifikation til XML-feed Boligportal.dk s kravspecifikation til XML-feed Introduktion I forbindelse med automatisk import af lejeboliger til Boligportal.dk skal der udarbejdes en XML-feed, som Boligportal.dk kan hente på en URL.

Læs mere

For den særligt interesserede skal det bemærkes, at vejledningsmateriale til kravene allerede foreligger i udkast på

For den særligt interesserede skal det bemærkes, at vejledningsmateriale til kravene allerede foreligger i udkast på 8. maj 2006 2006-309/3024-37/nic Notat om høring af bygherrekrav Som led i regeringsinitiativet Det Digitale Byggeri vil de statslige bygherrer i sager vedr. nybyggeri fra 1. januar 2007 stille krav til

Læs mere

ELEKTRONISK INDBERETNING ABORT 23/5 2007 VERSION 1.1

ELEKTRONISK INDBERETNING ABORT 23/5 2007 VERSION 1.1 ELEKTRONISK INDBERETNING ABORT 23/5 2007 VERSION 1.1 Indhold Indhold... 2 Introduktion... 3 Datamodel... 4 Abort XML Schema... 4 Abort Beskrivelse... 5 Abort_Grundoplysninger... 5 Abort_Besog... 6 Abort_Indgreb...

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

Resumé NSI har udviklet en funktionel prototype med en visuel brugergrænseflade, der giver ikke-teknikere mulighed for at tilgå adviseringsservicen.

Resumé NSI har udviklet en funktionel prototype med en visuel brugergrænseflade, der giver ikke-teknikere mulighed for at tilgå adviseringsservicen. Fælles testmiljøer Statens Serum Institut Sektor for National Sundheds-it - Anvenderguide: Visuel adviseringsklient, en funktionel prototype Artillerivej 5 2300 København S Dato: 12.12.2013 Version: 1.0

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

ELEKTRONISK INDBERETNING POST 23/8 2007 VERSION 1.13

ELEKTRONISK INDBERETNING POST 23/8 2007 VERSION 1.13 ELEKTRONISK INDBERETNING POST 23/8 2007 VERSION 1.13 Indhold Indhold... 2 Introduktion... 3 dk.hob.ei.general.plugin... 4 Metoder... 4 GetPrivateMail... 4 GetPrivateMailNext... 7 DeletePrivateMailEx...

Læs mere

1. Tidsplan og deadlines... 1

1. Tidsplan og deadlines... 1 November 2015 Vejledning Processen fra invitation til kontraktforhandling til kontraktindgåelse Projekter som i starten af november 2015 har fået invitation til kontraktforhandlinger om en investering

Læs mere

Brugervejledning til registrant

Brugervejledning til registrant Brugervejledning til registrant Når man logger på kommer man ind på en side der ser ud som nedenfor. På siden optræder alle de metadatabeskrivelser som man har rettigheder over. 1 2 3 4 5 6 7 8 9 10 11

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

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

Vilkår for Dialogintegration

Vilkår for Dialogintegration Vilkår for Dialogintegration KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/8 Dokumenthistorik Dato Version Ansvarlig Kommentar til ændringer

Læs mere

Høringssvar vedr. Serviceinterface for Person

Høringssvar vedr. Serviceinterface for Person Høringssvar vedr. Serviceinterface for Person 1. Indledning... 3 1.1 Arkitekturmæssige overvejelser... 3 2. Konkrete ændringsforslag... 5 2.1 Variable attributnavne... 5 2.2 Registeroplysninger fra akkreditiv...

Læs mere

Underbilag 2O Beskedkuvert Version 2.0

Underbilag 2O Beskedkuvert Version 2.0 Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...

Læs mere

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø EG Data Inform Byggebasen WCF og webservices Jens Karsø 10 Indholdsfortegnelse Byggebasen Services indledning... 2 Målsætning... 2 Valg af teknologier... 3 Kommunikationsmodel for byggebasen... 3 Services.byggebasen.dk...

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

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Dokument Reference UBL 2.0 Document Reference G21 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen

Læs mere

DKAL Snitflader Masseforsendelse

DKAL Snitflader Masseforsendelse DKAL Snitflader Masseforsendelse 1 C.1 Indholdsfortegnelse C.1 INDHOLDSFORTEGNELSE... 2 C.2 LÆSEVEJLEDNING... 3 C.3 TILMELDINGSLISTE... 4 C.3.1 RECORD-STRUKTUR... 4 C.3.2 OIOXML-STRUKTUR... 5 C.4 MATERIALE-INDLÆSNING...6

Læs mere

http://sonderborg.planvis.dk/search

http://sonderborg.planvis.dk/search Vejledning til søgning i digital byggesagssagsarkiv, Sønderborg Kommune http://sonderborg.planvis.dk/search Er hjemmeside portal for tilgængeliggørelse af digitaliserede byggesager fra Sønderborg Kommune

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

Uddybende vejledning til UTS Forsyningsspecifikation i OIOUBL

Uddybende vejledning til UTS Forsyningsspecifikation i OIOUBL Uddybende vejledning til UTS Forsyningsspecifikation i OIOUBL 4. januar 2013 Indhold UTS og forskellen i forhold til det gamle format...2 Udfordringer med UTS...2 Tiltag med henblik på at afhjælpe udfordringerne...3

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

OPBYGNING AF INSTRUMENTER. Online Designeren Record ID Felttyper Validering og variabelnavne

OPBYGNING AF INSTRUMENTER. Online Designeren Record ID Felttyper Validering og variabelnavne OPBYGNING AF INSTRUMENTER Online Designeren Record ID Felttyper Validering og variabelnavne Online Designer Online designeren er det primære værktøj til at opbygge skemaet til dataindsamling. I REDCap

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

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

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

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt

Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Udvalget for Videnskab og Teknologi B 103 - Svar på Spørgsmål 1 Offentligt Bilag 1 Vurdering af økonomiske konsekvenser af beslutningsforslag B 103 1. Indhold i beslutningsforslag B 103 Det overordnede

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

Forslag til indsatsområde

Forslag til indsatsområde D EN INTERNATIONALE D I MENSION I FOLKESKO L EN Forslag til indsatsområde Netværk om den internationale dimension er et initiativ under Partnerskab om Folkeskolen. Formålet med netværket er at skabe større

Læs mere

ABM standard arbejdsgruppen nedsat af Statens Arkiver, Styrelsen for Bibliotek og Medier og Kulturarvsstyrelsen

ABM standard arbejdsgruppen nedsat af Statens Arkiver, Styrelsen for Bibliotek og Medier og Kulturarvsstyrelsen nedsat af Statens Arkiver, Styrelsen for Bibliotek og Medier og Kulturarvsstyrelsen Titel : Transport af ABM data Dato : 2009-08-20 Status : Gældende ABM-specifikation Sekretariat: Publicering: Kulturarvsstyrelsen

Læs mere

REDCAPS DATADICTIONARY. Ekport og overblik over datadictionary Redigering af instrumenter via datadictionary Import a datadictionary

REDCAPS DATADICTIONARY. Ekport og overblik over datadictionary Redigering af instrumenter via datadictionary Import a datadictionary REDCAPS DATADICTIONARY Ekport og overblik over datadictionary Redigering af instrumenter via datadictionary Import a datadictionary Datadictionary Den komplette samling af opbyggede instrumenter, felter,

Læs mere

Grunddataprogrammet. Side 1 af 11. Aftale om styringsrammer for grunddatamodellen

Grunddataprogrammet. Side 1 af 11. Aftale om styringsrammer for grunddatamodellen Grunddataprogrammet Side 1 af 11 Aftale om styringsrammer for grunddatamodellen Side 1 af 11 11. oktober 2013 SAR Aftale om styringsrammer for grunddatamodellen Formål Formålet med aftalen er at sikre

Læs mere

Manual til opsætning af Jit-klient version 1.0. Opsætning. Copyright Jit-Danmark Aps 2006. Find mere information på www.jitbesked.

Manual til opsætning af Jit-klient version 1.0. Opsætning. Copyright Jit-Danmark Aps 2006. Find mere information på www.jitbesked. Opsætning Indholdsfortegnelse Sådan finder du indstillingerne...3 Muligheder og begrænsninger...6 Hvilke søgeord skal jeg bruge?...6 Ting man skal passe på...6 Tilføjning/nedlægning af søgeord...6 Ændring

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

bips F104, Dokumenthåndtering

bips F104, Dokumenthåndtering bips F104, Dokumenthåndtering af Gunnar Friborg & Charlotte Lund Poulsen Disposition Introduktion Tidsforløb og historik Hvad erstatter anvisningen? Baggrund Struktur og tankesæt Dokumenthåndtering Genfinding

Læs mere

DataHub Forbrugeradgangsløsning Spørgsmål og svar

DataHub Forbrugeradgangsløsning Spørgsmål og svar 9. Januar 2013 MEH/MHC DataHub Forbrugeradgangsløsning Spørgsmål og svar Dok 75938-12_v2, Sag 10/3365 1/7 1. Generelt 1.1 I hvilket omfang yder Energinet.dk support til elleverandørerne? Forretningskonceptet

Læs mere

Dansk kvalitetsmodel på det sociale område. Regionale retningslinjer for kvalitetsmodellens standard for indflydelse på eget liv

Dansk kvalitetsmodel på det sociale område. Regionale retningslinjer for kvalitetsmodellens standard for indflydelse på eget liv Juli 2016 Dansk kvalitetsmodel på det sociale område Regionale retningslinjer for kvalitetsmodellens standard for indflydelse på eget liv Dansk kvalitetsmodel på det sociale område er igangsat af regionerne

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

KOMMISSORIUM FOR UDARBEJDELSE AF INSTRUKSER. Styregruppe for instrukser i Sundhed og Omsorg. Struer Kommune TÆT PÅ MENNESKER TEKNOLOGI OG NATUR

KOMMISSORIUM FOR UDARBEJDELSE AF INSTRUKSER. Styregruppe for instrukser i Sundhed og Omsorg. Struer Kommune TÆT PÅ MENNESKER TEKNOLOGI OG NATUR KOMMISSORIUM FOR UDARBEJDELSE AF INSTRUKSER Styregruppe for instrukser i Sundhed og Omsorg Struer Kommune TÆT PÅ MENNESKER TEKNOLOGI OG NATUR Baggrund Instrukser er et arbejdsredskab til styrkelse af patientsikkerheden.

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

Notat om cuneco-projekter og sammenhæng til buildingsmart-standarder og -værktøjer 2014-04-24

Notat om cuneco-projekter og sammenhæng til buildingsmart-standarder og -værktøjer 2014-04-24 Notat om cuneco-projekter og sammenhæng til buildingsmart-standarder og -værktøjer 2014-04-24 cuneco buildingsmart Formidling og indarbejdning af cuneco-resultater i buildingsmart International CCS-klassifikation

Læs mere

Definition: unikt beskrivende navn på engelsk, der entydigt refererer til egen- skaben

Definition: unikt beskrivende navn på engelsk, der entydigt refererer til egen- skaben Bilag 1 - Felter i CCS- egenskabstabel - 3. udgave.docx BESKRIVELSE AF FELTNAVNE I CCS EGENSKABSTABEL cuneco en del af bips 21. januar 2014 Projektnr. 12 061 Sign. SSP 1 Indhold 1 Indhold... 1 2 Indledning...

Læs mere

Udgangspunktet for anbefalingerne er de grundlæggende principper for ordningen om vederlagsfri

Udgangspunktet for anbefalingerne er de grundlæggende principper for ordningen om vederlagsfri Notat Danske Fysioterapeuter Kvalitet i vederlagsfri fysioterapi Grundlæggende skal kvalitet i ordningen om vederlagsfri fysioterapi sikre, at patienten får rette fysioterapeutiske indsats givet på rette

Læs mere

Den danske kvalitetsmodel Individuelle planer i Handicap, psykiatri og udsatte

Den danske kvalitetsmodel Individuelle planer i Handicap, psykiatri og udsatte Den danske kvalitetsmodel Individuelle planer i Handicap, psykiatri og udsatte Dansk Kvalitetsmodel Kort om kvalitetsmodellen Dansk kvalitetsmodel på det sociale område udfoldes i et samarbejde mellem

Læs mere

Indledning... 2 Opbygning... 2 Servicesegmenternes sammenhæng... 3 UNA... 4 UNB... 6 UNH... 10 UNT... 12 UNZ... 14

Indledning... 2 Opbygning... 2 Servicesegmenternes sammenhæng... 3 UNA... 4 UNB... 6 UNH... 10 UNT... 12 UNZ... 14 05.05.2000 5. SERVICESEGMENTER Indholdsfortegnelse Indledning... 2 Opbygning... 2 Servicesegmenternes sammenhæng... 3 UNA... 4 UNB... 6 UNH... 10 UNT... 12 UNZ... 14 Side: 2 Indledning Dette afsnit indeholder

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

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

CCS Identifikation R5, juni 2015

CCS Identifikation R5, juni 2015 CCS Identifikation R5, juni 2015 Kolofon 2015-06-10 < Forrige side CCS Identifikation Produktblad 2 bips Lyskær 1 2730 Herlev Telefon 70 23 22 37 Fax 70 23 42 37 bips@bips.dk bips.dk

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

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

Vejledning i at oprette postkasser i Digital Post. Juli 2016

Vejledning i at oprette postkasser i Digital Post. Juli 2016 Vejledning i at oprette postkasser i Digital Post Juli 2016 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du skal oprette en postkasse og/eller mapper til postkasser. Du skal have

Læs mere

Fra Informationsmodel til en DTD

Fra Informationsmodel til en DTD OpenStax-CNX module: m19608 1 Fra Informationsmodel til en DTD Steen Leo Hansen This work is produced by OpenStax-CNX and licensed under the Creative Commons Attribution License 3.0 Abstract En praf opbygning

Læs mere

Notat om metadata om grunddata

Notat om metadata om grunddata Bilag 16 - Fælles arkitekturramme for GD1-GD2-GD7 Notat om metadata om grunddata 6. december 2013 SAR & PLACE Indledning Metadata data om data betegner ikke en entydig klasse af data. Anvendelsen af betegnelsen

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

Er standardisering en forudsætning for at systemer kan tale sammen?

Er standardisering en forudsætning for at systemer kan tale sammen? HVORFOR STANDARDER? Er standardisering en forudsætning for at systemer kan tale sammen? Nej, men standardisering reducerer den kompleksitet, der er ved at integrere systemer væsentligt. Så i praksis vil

Læs mere

AuthorizationCodeService

AuthorizationCodeService AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark, version 1.1 W 1 AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark version 1.1 Kåre Kjelstrøm Formål... 3 Introduktion...

Læs mere

Introduktion. Jan Brown Maj, 2010

Introduktion. Jan Brown Maj, 2010 Jan Brown Maj, 2010 Introduktion OIOXML har eksisteret som det centrale datastandardiseringsparadigme siden 2002. Til OIOXML-konceptet er der et regelsæt betegnet OIO Navngivnings- og Deignregler (NDR),

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

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

PROJEKTBESKRIVELSE DIGITALE TILBUDSLISTER

PROJEKTBESKRIVELSE DIGITALE TILBUDSLISTER PROJEKTBESKRIVELSE DIGITALE TILBUDSLISTER cuneco en del af bips Dato 20. marts 2012 Projektnr. 14 021 Sign. SSP 1 Indledning cuneco gennemfører et projekt, der skal udvikle en standardiseret struktur og

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

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

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