OIOXML skema regelsamlingen

Størrelse: px
Starte visningen fra side:

Download "OIOXML skema regelsamlingen"

Transkript

1 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 Høringssvar sendes til XML-komitéens sekretariat enten via adressen eller med post til "XML-sekretariatet, IT Strategisk kontor, IT- og Telestyrelsen, Holsteinsgade 63, 2100 København Ø. Elektronisk udgave kan findes på IT og Telestyrelsen, april 2004

2 Indholdsfortegnelse Forord...v 1. Formål...v 2. Målgruppe...v 3. Afgrænsning...v 4. OIOXML paradigmet...v 1. Vigtige begreber og terminologi OIOXML begreber og terminologi Infostrukturbasen OIOXML klasser Skemamoduler En OIOXML aflevering Dokumentorienterede og dataorienterede skemaer Beskrivelse af reglerne Klassifikation af regler Regelprefix værdier OIOXML regler Genbrug af eksisterende OIOXML typer og elementer [OIO-1,OIO-2] Genbrug af element fremfor type [OIO-3] Opdeling i skemamoduler [OIO-4,OIO-5] Placering af skemamoduler [OIO-6] Generelle XML skema regler Valg af skemasprog [GXS-1] Version af XML [GXS-2] Valg af encoding scheme [GXS-3] Tilknytning til namespace [GXS-4] Referencer via include og import [GXS-5] Anvendelse af redefine [GXS-6] Anvendelse af notation [GXS-7] Anvendelse af schemalocation [GXS-8] Navngivning Generelle navngivningsregler Navngiv på engelsk [GNR-1] Unik navngivning [GNR-2] Entalsform af navne [GNR-3] Anvendelse af UpperCamelCase [GNR-4] Forkortelser og akronymer [GNR-5] Bindeord med mere [GNR-6] Anvendelse af tegn i navne [GNR-7] Navngivningsmodellen for elementer og typer [GNR-8,GNR-8a til GNR-8f] Termen Objekt [GNR-8a] Termen Egenskab [GNR-8b] Termen Repræsentation [GNR-8c] Navne for komplekse typer [GNR-8d] Identiske eller enslydende fraser [GNR-8e] Navngivning af typer Type suffix [TPN-1]...16 ii

3 OIOXML skema regelsamlingen 4.3. Navngivning af elementer Sammenhæng mellem element- og typenavn [ELN-1] Navngivning af attributter Anvendelse af lowercamelcase [ATN-1] Navngivning af skema moduler Et skemamodul filnavn [FNR-1] Navngivning af metadata fil [FNR-2] Regler for typedefinitioner Generelle regler for typedefinitioner Stærke datatyper [GTD-1] Globale typedefinitioner [GTD-2a,GTD-2b] Omdøbning af en eksisterende type [GTD-3] anytype og anysimpletype [GTD-4] Håndtering af binært indhold [GTD-5] Abstrakte typer [GTD-6] Kontrol af typeafledninger [GTD-7] Regler for simple typedefinitioner Anvendelse af list [STD-1] Anvendelse af union [STD-2] Længden af string [STD-3] Repræsentation af kodelister [STD-4] Værdier i enumerationer [STD-5] Anvendelse af whitespace facetten og dertil koblede typer [STD-6] Regler for komplekse typedefinitioner Definition af komplekse typer ved aggregering [CTD-1a,CTD-1b] Definition af komplekse typer ved afledning [CTD-2a,CTD-2b] Anvendelse af blandet indholdsmodel [CTD-3] Anvendelse af tom indholdsmodel [CTD-4] Anvendelse af any [CTD-5] Anvendelse af anyattribute [CTD-6] Regler for element- og attributerklæringer Regler for elementerklæringer Globale elementerklæringer [ELD-1a,ELD-1b] Namespace for elementer [ELD-2] Anvendelse af substitution groups [ELD-3] Anvendelse af nillable [ELD-4] Default- og konstantværdier [ELD-5,ELD-6] Regler for attributerklæringer Anvendelsen af attributter [ATD-1] Attributter og namespaces [ATD-2] Default- og konstantværdier [ATD-3,ATD-4] Versionerings- og namespaceregler Namespaceversionering [VER-1] Frysning af skemamodul [VER-2] Bagudkompatible udvidelser [VER-3] Anvendelse af attributten version [VER-4] Namespace repræsentation [NMS-1] Navngivning af prefix i namespaceerklæringer [NMS-2] Dokumentation og metadata Dokumentation af skemamoduler [DOC-1] Metadata elementer Dokumentation af typer, elementer og attributter [DOC-2]...31 iii

4 OIOXML skema regelsamlingen 8.3. Anvendelse af appinfo [DOC-3] Dokumentation af kodeliste [DOC4] Afleveringsdokument [DOC5]...31 A. OIOXML NDR Quick Reference...32 iv

5 Forord 1. Formål Denne regelsamling er udarbejdet på foranledning af den fællesoffentlige XML-komité, hvor den er et vigtigt instrument i XML-komitéens standardiseringsarbejde. Regelsamlingen skal bruges til at afgøre om et schema kan godkendes, ved at undersøge om schemaet overholder regelsamlingens regler. Formålet med denne revision af XML Skemaregelsamlingen har været at gøre reglerne så klare og entydige som muligt. Dette skulle gerne gøre det letttere at forstå de enkelte regler og dermed også udviklingen af XML skemaer, der laves med henblik på standardisering og dataudveksling i offentligt såvel som i privat regi. Fælles regler øger læsbarheden og letter fortolkningen af de data, der udveksles, samt hjælpe til at sikre værktøjsunderstøttelse for udviklede skemaer. Udviklere af skemaer vil, ved genbrug af eksisterende standardiserede skemamoduler og ved overholdelse af regelsamlingens regler, kunne udvikle nye skemaer, der let kan gøres til genstand for standardisering. Kommentarer, spørgsmål og forslag til forbedringer bedes rettet til XML-sekretariatet 2. Målgruppe Regelsamlingen henvender sig til de personer, som har til opgave at udvikle og standardisere grænseflader mellem informationssystemer. Læsning forudsætter et vist kendskab til IT, herunder XML og især XML Schema anbefalingen fra W3C. Regelsamlingen er tænkt som et referenceværk for XML skemaudvikleren, der ønsker at udvikle skemaer, der kan indgå i den fællesoffentlig datamodel, baseret på genbrug af eksisterende skemamoduler. Standardisering af XML-baserede grænseflader ved hjælp af Infostrukturbasen er blot et middel til at nå målet om at skabe let og billig adgang til data; At levere et højt serviceniveau mellem alle parter i både den offentlige og private sektor. Realiseringen af målet forudsætter også viden om arkitekturarbejdet, og her en blandt flere publikationer. For yderligere information arkitektur publikationer [http://www.oio.dk/arkitektur/haandboeger]. 3. Afgrænsning Denne regelsamling er ikke tænkt, som en lærebog i XML eller i XML skemadesign, da dette ligger udenfor rammerne af formålet med regelsamlingen. Det skal bemærkes, at de anvendte skemaeksempler i regelsamlingen til dels er taget ud af deres fulde sammenhæng og til tider kan være tilrettede for at fremhæve bestemte træk. Nogle eksempler er opdigtede, fordi det ikke har været muligt at finde et passende eksempel. Regelsamlingen vil i den foreliggende form primært være velegnet som reference for de regler, der skal følges for at leve op til OIOXML paradigmet. 4. OIOXML paradigmet v

6 Forord Idéen bag OIOXML er at udvikle datamodeller, snitflader og webservices efter en fælles koordineret metode. Derved kan der skabes større konsistens på tværs af de mange projekter, som gennemføres i de forskellige myndigheder. Mere overordnet skal dette resultere i: Forbedret udveksling af data internt i den offentlige sektor såvel som mellem den offentlige og private sektor Forbedret databehandling og lettere adgang til allerede indsamlet data og genbrug af disse Lettere implementering af e-services Fleksible og integrerede services. Midlet er at lade XML danne ramme for dataudvekslingen i den offentlige sektor. Langsigtet standardisering af datastrukturer, som skal anvendes i forbindelse med systemintegration imellem offentlige og private organisationer. Standardiseringen skal baseres på bred accept blandt interessenter, så langsigtet brug og genbrug af de standardiserede datastrukturer kan opnås. Godkendelse af skemaer i forhold til, hvor godt de overholder navngivnings- og designreglerne. Det vil typisk være skemaer til en bestemt service, som man ønsker godkendelse af. Det er vigtigt, at godkendelsessagsbehandlingen er hurtig, så igangværende projekter, der skal anvende de godkendte skemaer, ikke forsinkes. Yderligere information og værktøjer: Information om OIOXML Infostrukturbasen (ISB'en) som er det fælles registry og repositry samt værktøj Yderligere værktøjerne er tilgængelige på og vi

7 Kapitel 1. Vigtige begreber og terminologi Dette kapitel beskriver begreber og terminologi, som anvendes i definition af reglerne OIOXML begreber og terminologi Infostrukturbasen Forklar! OIOXML klasser Et XML skemamodul, der lever op til reglerne i denne regelsamling, betegnes et OIOXML skema og opdeles i tre klasser. Klasserne er beskrevet udfra følgende aspekter: en dansk og engelsk titel klassens formål forstået som dens rolle i OIOXML tekniske krav i forhold til det enkelte skemamodul i hvor høj grad det enkelte skemamodul skal genbruge andre skemamoduler hvorvidt der skal foretages en offentlig høring hvem der godkender skemamodulerne hvor lang tid der går fra en aflevering til, at materialet er gennemgået og besvaret med en skriftlig vurdering/anbefaling. OIOXML NDR (Navngivnings- og Designregler) Komponenter Engelsk titel: Kort navn: Formål: Krav: Genbrug: Offentlig høring: Godkendelse: Procestid: OIOXML Naming and Design Rules Compliant Components NDR NDR klassen er den fundamentale klasse af skemaer, som OIOXML skemaer tilhører inklusiv skemaer under CORE og DOMAIN klasserne. Et NDR skema SKAL overholde alle navngivnings- og designregler i denne XML Skemaregelsamling. Et NDR skema SKAL genbruge eksisterende OIOXML skemaer, hvis muligt. Herunder BØR et NDR skema genbruge CORE og DOMAIN skemaer, hvis muligt, og kan, men behøver ikke, genbruge andre NDR skemaer. Valgfrit, ønskes af den indleverende part. Obligatorisk, udføres af XML-sekretariatet. Kort (ca. 1½ uge), hvis ingen høring ønskes. 1

8 Vigtige begreber og terminologi OIOXML Kernekomponenter Engelsk titel: Kort navn: Formål: Krav: Genbrug: Offentlig høring: Godkendelse: Procestid: OIOXML Core Components CORE CORE klassen indeholder helt generelt anvendelige skemaer, som, når det er muligt, skal genbruges af alle OIOXML skemaer uafhængigt af deres klasse og uafhængigt om disse tilhører et domæne eller ej. Denne klasse skal understøtte OIOXML paradigmets genbrugstanke i så stor udstrækning, som det er muligt. Et CORE skema skal, udover at overholde NDR klassens indbyggede krav, være genstand for fælles konsensus om generel anvendelighed, så skemaet egner sig til genbrug i alle OIOXML skemaer på tværs af alle OIOXML klasser. Et CORE skema SKAL genbruges af NDR, CORE og DOMAIN skemaer, hvis muligt. Obligatorisk. Obligatorisk, udføres af XML-komitéen. Lang (ca uger) grundet høring. OIOXML Domænekomponenter Engelsk titel: Kort navn: Formål: Krav Genbrug: Offentlig høring: Godkendelse: Procestid: OIOXML Domain Components DOMAIN DOMAIN klassen indeholder skemaer, som, når det er muligt, specielt skal genbruges indenfor et bestemt domæne. Denne klasse skal understøtte OIOXML paradigmets genbrugstanke i så stor udstrækning, som det er muligt. Et DOMAIN skema skal, udover at overholde NDR klassens indbyggede krav, være genstand for fælles konsensus om anvendelighed indenfor et bestemt domæne, så det egner sig til genbrug i alle OIOXML skemaer i relevante OIOXML klasser. Et DOMAIN skema SKAL genbruges af NDR og DOMAIN skemaer, hvis muligt. Obligatorisk. Obligatorisk, udføres af relevante domænekomitéer eller af XML- Komitéen. Lang (ca. 6 uger) grundet høring. XML komitéen kan vælge at se bort fra reglerne, som er defineret i denne regelsamling, f.eks. ved adoption af en udefra kommende XML standard, som er defineret efter andre regler end 2

9 Vigtige begreber og terminologi OIOXML. I relation til dette er det vigtigt, at elementer, typer eller komplekse skemaer først erklæres i de tilfælde, hvor der ikke i forvejen findes en anerkendt standard på området. Alle XML grænseflader klassificeres som udgangspunkt som NDR, da det vil være undtagelsen, at en hel grænseflade genbruges. Bemærk at en skemaaflevering skal gennemgås og godkendes af XML-sekretariatet, inden afleveringen sendes i offentlig høring Skemamoduler Forklar! En OIOXML aflevering Når man ønsker en OIOXML godkendelse, skal man lave en aflevering til ISBen. En sådan aflevering består af et antal XML skemaer, muligvis fra flere namespaces, og for hvert enkelt skema skal man angive hvilken klasse man ønsker det optaget i. I forbindelse med en aflevering udarbejdes et afleveringsdokument, som et kortfattet tekstdokument, som giver en introduktion til afleveringen. Dette kan eksempelvis indholde følgende punkter: hvad formålet er, herunder hvilken applikation/grænseflade eller hvilket projekt? Angivelse af hvilke namespaces/skemaer der er inkluderet i afleveringen og eventuelle rodelementer, altså de mest overordnede. Angivelse af hvilke klasser de forskellige skemaer ønskes optaget i hvem der har udviklet dem? hvilke XML parsere der er blevet kontrolleret med? Eventuelle UML diagrammer Eventuelle instans dokumenter Dokumentorienterede og dataorienterede skemaer Forklar! 1.2. Beskrivelse af reglerne Klassifikation af regler Reglernes vægtning er gradueret med inspiration fra Internet Engineering Task Force RFC 2119 Key words for use in RFCs to Indicate Requirement Levels [http://www.ietf.org/rfc/rfc2119.txt]. Nøgleordene "SKAL", "MÅ IKKE", "BØR", "BØR IKKE" og "MÅ" skal i definition af reglerne tillægges følgende betydning: 3

10 Vigtige begreber og terminologi SKAL MÅ IKKE BØR BØR IKKE MÅ Dette ord betyder at det definerede er et absolut krav. Denne frase betyder at det definerede er fuldstændig forbudt. Dette ord betyder at der findes gyldige grunde under bestemte omstændigheder hvor det definerede kan ignoreres, men de fulde konsekvenser skal være forstået og nøje overvejet inden beslutningen om en anden måde vælges. Denne frase betyder at findes gyldige grunde under bestemte omstændigheder hvor det som defineres som frarådeligt, er acceptabelt eller sågar nyttigt, men men de fulde konsekvenser skal være forstået og nøje overvejet inden beslutningen om en anden måde vælges. Dette ord, eller ordet "KAN", betyder det definerede er valgfrit Regelprefix værdier Alle reglerne er grupperet og navngivet både med en kode, en tekst og en titel. Navngivning af koderne er baseret på de prefix som anvendes i de Navngivnings- og designregler der er udviklet til Universal Business Language (UBL) [http://www.oasis-open.org/committees/ubl/]). Regelprefix ATD ATN CTD DOC ELD ELN FNR GNR GTD GXS NMS OIO STD TPN VER Regelemne Attributerklæring Attributnavngivning Kompleks typedefinition Dokumentationskrav Element erklæringsregel Element navngivningsregel Fil navngivningsregel Generel navngivningsregel Generel typedefinition Generel XSD regel Namespaceregler OIOXML modelleringsregel Simpel typedefinition Type navngivningsregel Versioneringsregel 4

11 Kapitel 2. OIOXML regler 2.1. Genbrug af eksisterende OIOXML typer og elementer [OIO-1,OIO-2] OIO-1: Man SKAL genbruge eksisterende elementer eller typer fra klasserne OIOXML Core Components og OIOXML Domain Components. Man må med andre ord ikke definere en ny type eller erklære et nyt element, hvis samme funktionalitet allerede eksisterer i OIOXML Core Components eller OIOXML Domain Components. OIO-2: Man BØR genbruge eksisterende elementer eller typer fra klassen OIOXML NDR Components. Man bør også genbruge fra OIOXML NDR Components, men dette er ikke noget krav. Genbrug i eget namespace er dog forventeligt Genbrug af element fremfor type [OIO-3] OIO-3: Man SKAL genbruge et element fremfor dets type, hvis elementets anvendelse er entydig i den konkrete sammenhæng. Genbrug allerede erklærede elementer ved at lave referencer til ved hjælp af attributten ref på element konstruktionen. Genbrug af elementer forudsætter at elementet er entydig i den givne sammenhæng, f.eks. hvis det anvendes ved definition af en kompleks type, vil navnet på det tilknyttede element bestemmer sammenhængen. Hvis dette ikke er tilfældet må genbrug være baseret på typen, via nye elementerklæringer af denne type. Fordelen er at unødvendige reerklæring spares, og beskrivelsen af elementet og det type forbliver uændret og information om dette findes der. Alternativt vil gentagelser af eksisterende erklæringer forekomme og dette vil næsten uundgåeligt fører til uoverensstemmelser. Eksempel Rigtigt: <element name="changedate" type="xsd:date" /> Forkert: <element name="changedate" type="changedatetype" /> ChangeDateType.xsd: <element name="changedatetype" type="xsd:date" /> 5

12 OIOXML regler Før i tiden var al behandling af XML baseret på elementnavnet, dette gælder f.eks. DOM level 1 og 2, XSLT 1.0. XPATH 1.0. Med fremkomsten af XML Schema blev der introduceret stærke datatyper tilknyttet elementer. Værktøjer og specifikationer har siden bevæget sig i retningen af at være mere typebaseret. Et af de seneste eksempler på dette er DOM level 3, XPATH 2.0, XSLT 2.0 og XQUERY 1.0. Der er dog endnu bredest understøttelse for den elementorienterede anvendelse og dette er den ene af grundene bag denne regel. Den anden grund er, at tankerne med den oprindelige type, dets navn og dokumentationen hører sammen, og dette understøttes ved at bruge referencer til et allerede erklæret element. Der er tilfælde, hvor dette ikke kan bruges, da det skal fremgå i hvilken sammenhæng det menes. Da er man nødt til at lave et nyt element, som signalerer dette. Dette kan være, hvis elementet skal forekomme flere gange i samme sammenhæng eller hvis det ikke er tydeligt, hvad der menes. Eksempel: Følgende eksempel drejer sig om definitionen af en persons navne. Først defineres typen og elementet: <complextype name="personnametype"> <annotation> <documentation>type for names of persons.</documentation> </annotation> <sequence> <element ref="dkcc:persongivenname"/> <element ref="dkcc:personmiddlename" minoccurs="0"/> <element ref="dkcc:personsurnamename"/> </sequence> </complextype> <element name="personname" type="vd:personnametype"> <annotation> <documentation>person name including given name, an optional middle name and a surname.</documentation> </annotation> </element> Dernæst anvendes det og da det ikke er brug for at angive en bestemt sammenhæng ud over den som den defineres i: <complextype name="addresseetype"> <annotation> <documentation>type for an addressee on a letter.</documentation> </annotation> <choice> <annotation> <documentation>in case the addressee is a person, use the PersonName element. Otherwise use the CompanyName element.</documentation> </annotation> <element ref="vd:personname"/> <element ref="vd:companyaddressee"/> </choice> </complextype> <element name="addressee" type="vd:addresseetype"> <annotation> <documentation>an addressee, which can be either a private individual or a person in a company.</documentation> </annotation> </element> Det skal dog også bruges i en anden sammenhæng, hvor det er for anonymt blot at anvende 6

13 OIOXML regler elementnavnet PersonName og til dette formål erklæres der et nyt element af samme type <element name="clientname" type="vd:personnametype"> <annotation> <documentation>full name of a client.</documentation> </annotation> </element> <complextype name="digcommenttype"> <sequence> <element ref="vd:clientname" minoccurs="0"/> <element ref="vd:addeddatetime" minoccurs="0"/> <element ref="vd:commenttext"> </element> </sequence> </complextype> Et andet eksempel er hvor den samme type, StreetBuildingIdentifierType, anvendes to gange er: <element name="fromidentifier" type="dkcc:streetbuildingidentifiertype"> <annotation> <documentation>the lowest door or building identifier on the road section.</documentation> </annotation> </element> <element name="toidentifier" type="dkcc:streetbuildingidentifiertype"> <annotation> <documentation>the highest door or building identifier on the road section.</documentation> </annotation> </element> <complextype name="buildingintervaltype"> <sequence> <element ref="vd:fromidentifier"/> <element ref="vd:toidentifier"/> </sequence> </complextype> <element name="buildinginterval" type="vd:buildingintervaltype"/> 2.3. Opdeling i skemamoduler [OIO-4,OIO-5] OIO-4: Hvert element og eventuelt dets tilhørende type fra klasserne OIOXML Core Components eller OIOXML Domain Components SKAL placeres i et selvstændigt skemamodul. OIO-5: Hvert element og eventuelt dets tilhørende type fra klassen OIOXML NDR Components BØR placeres i et selvstændigt skema. Da der kun tilknyttes et sæt metadata per skemamodul, er det vigtigt at skemamodulet ikke dækker over flere begreber. Dette sikrer dels den fulde forståelse af skemamodulet indhold og sikrer fremsøgning i Infostrukturbasen. Derfor skal alle elementerklæringer og de tilhørende typedefinitioner deles op i forskellige skemamoduler. Dette betyder dog ikke, at der altid skal defineres en type, hvis en allerede eksisterende type kan benyttes. Nedenstående eksempel illustrerer det med definitionen af CVR-nummer: <?xml version="1.0" encoding="utf-8"?> 7

14 OIOXML regler <schema targetnamespace="http://rep.oio.dk/cvr.dk/xml/schemas/2002/06/28/" xmlns:cvr="http://rep.oio.dk/cvr.dk/xml/schemas/2002/06/28/" xmlns="http://www.w3.org/2001/xmlschema" elementformdefault="qualified" attributeformdefault="qualified" version="1.1"> <element name="cvrnumber" type="cvr:cvrnumbertype"> <annotation> <documentation>unique and generally usable identifier for all legal units included i CVR.</documentation> </annotation> </element> <simpletype name="cvrnumbertype"> <restriction base="string"> <length value="8"/> </restriction> </simpletype> </schema> 2.4. Placering af skemamoduler [OIO-6] OIO-6: Alle skemamoduler SKAL placeres i Infostrukturbasen. For at sikre en ensartet tilgang til skemaerne og deres metadata skal alle skemaer gemmes i Infostrukturbasen. Hermed har alle fri adgang til både datadefinitioner og databeskrivelser altid. 8

15 Kapitel 3. Generelle XML skema regler 3.1. Valg af skemasprog [GXS-1] GXS-1: OIOXML skemaer SKAL defineres i overensstemmelse med W3C XML Skema anbefalingen af 2. maj 2001: XML Schema Part 1: Structures og XML Schema Part 2: Datatypes. Det er vigtigt at sikre interoperabilitet ved, at alle offentlige systemer bruger samme skemasprog. Ellers vil syntaksspecifikke definitioner af fælleskomponenter ikke kunne genbruges. W3C XML Skema anbefalingen er en de facto standard, som giver mulighed for definition af stærke datatyper, som endvidere bruges i web services (SOAP/WSDL) og som samtidig har meget bred værktøjsunderstøttelse. XML Schemaer skal overholde W3C s anbefaling af XML Schema af 2. maj 2001.http://www.w3.org/XML/Schema Version af XML [GXS-2] GXS-2: Alle XML skemaer SKAL følge version 1.0 af W3C XML anbefalingen af 4. februar 2004 Extensible Markup Language (XML) 1.0 (Third Edition). Alle XML skemaer skal følge XML version 1.0, da den udfylder alle de behov der for OIOXML, som blandt andet er baseret på engelsk navngivning. XML dokumenter der ølger version 1.1 kan desuden give problemer i værktøjer som ikke er forberedt til det, da det stadig er en ret ny anbefaling. Eksempel: <?xml version="1.0" encoding="utf-8"?> 3.3. Valg af encoding scheme [GXS-3] GXS-3: Alle XML skemaer SKAL anvende UTF-8 som encoding scheme. Brug UTF-8 encoding til XML Schema filer og angiv det i XML erklæringen. XML Schema anbefalingen kræver at en XML processor skal kunne UTF-8 eller UTF-16. Disse "encoding schemes" baserer sig på ISO til repræsentation af tegnsæt, som består af et antal "encoding schemes" som f.eks. UCS (Universal Character Set), UTF-8 (UCS Transformation Format) og UTF-16. Af de to skal UTF-8 anvendes da den foretrækkes internationalt og bla. ikke har potentielle problemer med byteordering og fylder mindst. Den udbredte anvendelse af ISO Latin1 (ISO ), som også understøtter danske tegn, må derfor ikke anvendes. Eksempel: 9

16 Generelle XML skema regler <?xml version="1.0" encoding="utf-8"?> 3.4. Tilknytning til namespace [GXS-4] GXS-4: Alle XML skemaer SKAL tilknyttes et namespace. Dette gøres ved hjælp af targetnamespace attributten. Namespaces udgør rygraden i OIOXML versioneringsstrategien og bruges til at adskille institutionselementer og -typer fra hinanden. Dette sikrer dels, at man tydeliggør tilknytningsforholdet for dem samt sikrer sig imod utilsigtet navnekollision Referencer via include og import [GXS-5] GXS-5: Konstruktionen include SKAL benyttes, når der refereres til et skema i samme namespace, ellers SKAL konstruktionen import benyttes. Udover at dette generelt er nødvendigt at følge, så betyder det også at man ikke må anvende import når det er i samme namespace, dels da dette ikke er hensigten og desuden da import håndteres anderledes en include. Eksempel: <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace="http://rep.oio.dk/udlst.dk/xml/schemas/2003/03/19/" xmlns:cpr="http://rep.oio.dk/cpr.dk/xml/schemas/core/2002/06/28/" xmlns:udlst="http://rep.oio.dk/udlst.dk/xml/schemas/2003/03/19/" xmlns:dkcc="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns="http://www.w3.org/2001/xmlschema" elementformdefault="qualified"> <import namespace="http://rep.oio.dk/cpr.dk/xml/schemas/core/2002/06/28/" schemalocation="http://rep.oio.dk/cpr.dk/xml/schemas/core/2002/06/28/cpr_civilregistrationnumber.xsd"/> <import namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" schemalocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/dkcc_persongivenname.xsd"/> <import namespace="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" schemalocation="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/dkcc_personsurnamename.xsd"/> <include schemalocation="http://rep.oio.dk/udlst.dk/xml/schemas/2003/03/19/udlst_package.xsd"/> 3.6. Anvendelse af redefine [GXS-6] GXS-6: Konstruktionen redefine MÅ IKKE benyttes. Anvendelse af redefine bryder med de øvrige regler omkring entydighed af elementer og typer kombineret med deres namespaces og derfor må den ikke benyttes Anvendelse af notation [GXS-7] GXS-7: Konstruktionen notation MÅ IKKE benyttes. Da dette laver applikationsspecifikke bindinger til instanser må det ikke benyttes. Notation er 10

17 Generelle XML skema regler levn fra DTDer, som er forsøgt taget med i XML Schema for bagudkompatible, men er det faktisk ikke. Eksempel: <xsd:notation name="iso-1" public="-//location//en" system="http://www.iso.org/country-codes/ver1" /> <xsd:notation name="iso-2" public="-//location//en" system="http://www.iso.org/country-codes/ver2" /> <xsd:simpletype name="mynotation"> <xsd:restriction base="xsd:notation"> <xsd:enumeration value="iso-1"/> <xsd:enumeration value="iso-2"/> </xsd:restriction> </xsd:simpletype> 3.8. Anvendelse af schemalocation [GXS-8] GXS-8: Alle schemalocation attributter SKAL angives med absolut og gyldig URL til skemamodulets placering i Infostrukturbasen. Selv om schemalocation teknisk set kun er et forslag (eng: hint), skal den anvendes sådan at man sikre sig det fulde skema og dets validitet. Fordelen ved den absolutte URL er, at selv skemamoduler, som er lokaliseret et andet sted end Infostrukturbasen, stadig har korrekte referencer. Dette kræves desuden for, at Infostrukturbasen har en korrekt afdækning af afhængigheder. Se eksempler under regel [GXS-5]. 11

18 Kapitel 4. Navngivning 4.1. Generelle navngivningsregler Navngiv på engelsk [GNR-1] GNR-1: Elementer, attributter og typer SKAL navngives på engelsk som angivet i Oxford English Dictionary eller relevante fagordbøger. Bagrunden er at XML-Komiteen ønsker, at det danske standardiserings-paradigme og danske schemaer skal adopteres af andre lande. De danske schemaer kan dermed potentielt danne skole for standardiseringsinitiativer i EU eller f.eks. OASIS. Derudover har den fordel, at det er nemmere at integrere med andre standarder som f.eks. ebxml, UBL. Den engelske navngivningskonvention blev vedtaget på XML-komiteens møde den 12. februar Unik navngivning [GNR-2] GNR-2: Elementer, attributter og typer SKAL navngives unikt indenfor et skemas namespace og BØR navngives unikt på tværs af alle godkendte skemaers namespaces. Ved navngivningen af elementer og typer under et givet namespace skal der anvendes unikke navne, af den naturlige årsag at to forskellige semantiske begreber ikke skal navngives ens, og for at stimulere genbrug mest mulig Entalsform af navne [GNR-3] GNR-3: Elementer, attributter og typer SKAL navngives med entalsform med mindre navneordet er en flertalsform. Et eksempel på en undtagelse er (f.eks. Goods). Navne skal beskrive enkelte elementer, hvis der er tale om flere forekomster af det samme element skal man følge regl [GNR-8d], som er defineret nedenfor Anvendelse af UpperCamelCase [GNR-4] GNR-4: Elementer og typer SKAL navngives med UpperCamelCase. UpperCamelCase betyder at navnet skal begynde med et stort bogstav, herefter begynder hvert nyt ord med et stort bogstav, et eksempel: <element name="streetbuildingidentifier" type="dkcc:streetbuildingidentifiertype"> Forkortelser og akronymer [GNR-5] 12

19 Navngivning GNR-5: Forkortelser og akronymer BØR IKKE benyttes. Da forkortelser og akronymer hæmmer læsebarheden, bør de ikke benyttes. Hvis der er behov for at lave forkortelser, bør man anvende eksisterende forkortelser. Hvis der ikke eksisterer en almindelig brugt forkortelse, så find på én, som giver mening og er entydig. Forkortelser skal skrives med store bogstaver Bindeord med mere [GNR-6] GNR-6: Navne SKAL opbygges af udsagnsord, navneord og tillægsord. Det er vigtigt at navnene er så præcise som muligt, hvilket kommer af at både semantik og syntaks skal være så præcis som mulig. Det er ikke meningen at navnet skal være en sætning og derfor skal ord som "and", "of" og "the" ikke benyttes Anvendelse af tegn i navne [GNR-7] GNR-7: Understregning (_), punktum (.) og bindestreg (-) MÅ IKKE forekomme i navne. XML anbefalingen tillader disse tegn, men da UpperCamelCase er valgt er der ikke brug for disse tegn Navngivningsmodellen for elementer og typer [GNR-8,GNR-8a til GNR-8f] GNR8: Element- og typenavne BØR navngives efter ObjektEgenskabRepræsentation navngivningsmodellen, som specificeret i nedenstående underregler. Denne navngivningskonventionerne følger de anbefalinger som ebxml har for navngivning, og denne er baseret på på ISO standarden "Information technology Specification and standardization of data elements". Der er meget bred konsensus for denne navngivningskonvention internationalt. ebxmls anvendelse er beskrevet i ebxml TR - Naming Convention for Core Components 10 May Version 1.04 [http://www.ebxml.org/specs/ebccnam.pdf] og ISO standarden er under vidreudvikling, og har nu titlen "Information technology Metadata registries". Den seneste udgaver af dokumenterne kan findes på arbejdsgruppens hjemmeside [http://metadata-stds.org/11179/index.html]. Objekt Egenskab Repræsentation Elementnavn Bank Account Identifier BankAcoountIdentifie r Person Birth Date PersonBirthDate Tax Percentage TaxPercentage Amount Type AmountType 13

20 Navngivning Objekt Egenskab Repræsentation Elementnavn Person Gender Code PersonGenderCode Communication Mode Code CommunicationMode Code Country Code CountryCode Currency Exchange Rate CurrencyExchangeRat e Location Type Code LocationTypeCode Transport Method Code TransportMethodCod e Street Name StreetName OrganizationRegistrat ion Date OrganizationRegistrat iondate Address Type Code AddressTypeCode Termen Objekt [GNR-8a] GNR-8a: Termen Objekt i et element- og typenavn SKAL beskrive det dataobjektet, som elementet og dets type repræsenterer i en bestemt sammenhæng. Termen Objekt er et eller flere nøgleord, som beskriver objektet, enheden eller konceptet, som det centrale data element eller type relaterer til, f.eks. Bank, Person, Building, Country, Organization. I tilfælde hvor elementet eller typen optræder i en kontekst af et objekt, kan Objekt udelades. I følgende eksempel, er det ikke nødvendigt at angive et objekt for FirstName elementet, da elementet optræder i konteksten af Person elementet: <Person> <GivenName>Jon</GivenName> <SurName>Bosak</SurName> </Person> Termen Egenskab [GNR-8b] GNR-8b: Termen Egenskab i et element- og typenavn SKAL ved hjælp af en eller flere kvalificerende ord beskrive en fremtrædende egenskab ved elementet og dets types Objekt term. Termen Egenskab er et eller flere kvalificerende ord, som beskriver en egenskab ved objektet. Hvis der er flere ord, skal hver enkelt være af betydning for objektet, som bliver beskrevet. Eksempler er "Account" som i BankAccountIdentifier, "Birth" som i PersonBirthDate eller "Exit" som i BuildingExitQuantity. Beskrivelsen kan udelades, hvis indholdet i elementet eller typen direkte vedrører objektet og ikke en egenskab ved objektet. 14

21 Navngivning Termen Repræsentation [GNR-8c] GNR-8c: Termen Repræsentation i et element- og typenavn SKAL beskrive elementet og dets types repræsentative kategori og SKAL antage en af værdierne i OIOXML's liste over repræsentationstermer. Termen Repræsentation er et nøgleord, som associerer til en primitiv type. Eksempler er "Identifier" som i BankAccountIdentifier, "Date" som i PersonBirthDate eller "Quantity" som i BuildingExitQuantity. Se følgende tabel for mulige repræsentationer: Repræsentations term Amout Beskrivelse Et antal af monitære enheder specificeret i en møntfod, hvor møntfoden enten er eksplicit eller implicit. Code En karakterstreng der som forkortelse og/eller for at opnå sproguafhængighed kan bruges til at repræsentere eller erstatte en definitiv værdi eller tekst. Koder er normalt vedligeholdt i en kodeliste per type, f.eks. farve. Date En dato indenfor et bestemt kalenderår, baseret på ISO DateAndTime Identifier Reference Indicator Measure Name Percent Quantity Rate Text Et bestemt tidspunkt. En karakterstreng der, indenfor en identifikationsramme, bruges til at identificere og unikt udpege én instans af et objekt blandt alle objekter indenfor samme ramme. En karakterstreng som bruges til at referere til en bestemt objektinstans identificeret med en Identifier (dette er en tilføjelse til de repræsentationstermer, ebxml definerer). En liste af to og kun to værdier, som indikerer en tilstand som f.eks. "on/ off" eller "true/false". Synonymt med "boolean". En numerisk værdi bestemt ved at måle et objekt. Dette mål kan angives med en måleenhed; de mulige måleenheder tages fra UN/ECE Rec. 20. Et ord eller en frase som indeholder den præcise betegnelse for en person, et sted, ting eller koncept. En rate udtrykt som en hundrede-del mellem to værdier med samme måleenhed. Et antal af ikke monitære enheder. Den er associeret med indikationen af objekter. Mængder kan angives med en eksplicit mængdeenhed. En mængde eller et antal målt i forhold til en anden mængde eller antal, eller en fast eller passende ladning, omkostning eller værdi, f.eks. "kroner i timen", "danske kroner per EURO" eller "kilometer per liter". En karakterstreng udtrykt generelt som ord i et sprog. Time Tidspunktet indenfor en ikke specificeret dag. Baseret på ISO 8601: Navne for komplekse typer [GNR-8d] 15

22 Navngivning GNR-8d: En kompleks type MÅ IKKE have termen repræsentation i sit navn. Termen egenskab SKAL være "Collection", hvis typen indeholder præcist ét element og mindst 2 forekomster af dette. Termen repræsentation SKAL enten være "Structure" eller helt undlades, hvis typen er sammensat af 2 eller flere forskellige elementer. [TODO] Identiske eller enslydende fraser [GNR-8e] GNR-8e: Hvis et element- eller typenavn har en frase i termen Egenskab, som er synonymt med en frase i termen Repræsentation, SKAL denne frase fjernes fra Egenskab og bibeholdes i Repræsentation Navngivning af typer Type suffix [TPN-1] TPN-1: Navnet på en simpel eller kompleks type SKAL afsluttes med suffix "Type". Navnene på datatyper bør slutte med tekststrengen "Type", og dette fjernes til det respektive elementnavn se regel [ELN1]. Dette sikrer, at man altid kan kende forskel på typer og elementer Navngivning af elementer Sammenhæng mellem element- og typenavn [ELN-1] ELN-1: Et element BØR have samme navn som dets type dog uden suffix "Type". Grundlæggende skal navnet på elementet direkte afspejle navnet på den brugte type ved at fjerne "Type" fra navnet på typen, se regel [TPN-1] 4.4. Navngivning af attributter Anvendelse af lowercamelcase [ATN-1] ATN-1: Attributter SKAL navngives efter lowercamelcase-reglen. Når man skriver i lowercamelcase skal navnet begynde med lille bogstav, herefter begynder hvert nyt ord med et stort bogstav. <complextype name="customertype"> <sequence> <element name="givenname" type="prefix:givennametype"/>... </sequence> 16

23 Navngivning <attribute name="customeridentifier" type="prefix:customeridentifiertype"/> </complextype> 4.5. Navngivning af skema moduler Et skemamodul filnavn [FNR-1] FNR-1: Skemamodulets filnavn SKAL navngives efter modellen: <namespace prefix med store bogstaver>_<elementnavn>.xsd Anvendelse af beskrivende navne er ikke alene vigtigt internt i et skema, men giver også konsistens og sammenhæng ved navngivning af XML Skemaer og andre typer af XMLdokumenter. Fordelen ved denne navngivningskonvention er, at skemaer er at man umiddelbart fra filnavnet både kan se hvilket overordnet namespace det kommer fra og hvilket element og eventuel tilknytte type der er i skemamodulet. Eksempel: CPR_CivilRegistrationNumber.xsd Navngivning af metadata fil [FNR-2] FNR-2: Metadatafiler SKAL navngives ved at tilføje ".meta.xml" som suffix til skemamodulets filnavn. Denne sikrer at man automatisk kan finde et skemamoduls metadata alene udfra dets filnavn, og blev tidligt valgt som konvention og er implementeret sådan i Inforstrukturbasen 17

24 Kapitel 5. Regler for typedefinitioner 5.1. Generelle regler for typedefinitioner Stærke datatyper [GTD-1] GTD-1: Alle typer SKAL defineres stærkest muligt. XML Schema er valgt netop fordi det giver mulighed for stærke datatyper, altså at man præcist kan beskrive udfaldsrummet af lovlige værdier. Dette giver mulighed for lave validering af instanser inden videre behandling, og reducerer dermed de anstrengelser man ellers vil have med datavalidering i applikationer, som let kan udgøre en større del af behandlingen. Dette gælder simple datatyper, som styrer de tilladte værdier ved hjælp af base typer og facetter på disses, såvel som komplekse typer hvor man skal sikre sig at man anvende netop de elementer og deres kardinaliteten, som præcist afspejler den modellerede datastuktur. Dette hænger intimt sammen med modellering som skal sikre en konsistent model, både logisk og semantisk. I de tilfælde hvor man kan beskrive det samme på flere måder, bør man vælge den som er mest simpel og logisk. Eksemplet nedenfor viser først en for løs og præsentations orienteret definition af temperaturmålingsenheden Celsius. Der er er maksimum på 7 cifre for udfaldsrummet for Celsius hvilket kan være uhensigtsmæssig <simpletype name="celsiustype"> <restriction base="string"> <pattern value="[+-][0-9]{1,7}"/> </restriction> </simpletype> Celsius kunne defineres stærkere og på en måde som er simplere, ved at basere sig på en type der logisk danner baggrund. Der er en klar definition på det minimum, som Celsius kan antage og ingen værdi for maksimum. <simpletype name="celciustype"> <restriction base="decimal"> <minexclusive value="-273"/> </restriction> <simpletype> I følgende eksempel er CivilRegistrationNumberType defineret som 10 tal mellem 0 og 9. <simpletype name="civilregistrationnumbertype"> <restriction base="string"> <pattern value="[0-9]{10}"/> </restriction> </simpletype> Det betyder at CivilRegistrationNumberType bl.a. kan antage værdien Heraf 18

25 Regler for typedefinitioner kan det ses at vedkommende med dette cpr-nummer er født i 13. måned. Dette er som bekendt ikke muligt, men parseren vil ikke fange fejlen. Datatypen er for svag. Nedenstående er et forsøg på at gøre CivilRegistrationNumberType til en stærk datatype. <simpletype name="civilregistrationnumbertype"> <restriction base="string"> <pattern value="(((0[1-9] 1[0-9] 2[0-9] 3[0-9]) ( )) ((0[1-9] 1[0-9] 2[0-9] 30)( )) ((0[1-9] 1[0-9] 2[0-9])(02)))[0-9]{6}"/> </restriction> </simpletype> Ved hjælp af det nye regulære udtryk for CivilRegistrationNumberType er det sikret at kun valide cpr-numre kommer igennem parseren med undtagelse af cpr-numre der indeholder datoen for andet end skudår. I dette tilfælde blev typen mere kompliceret da der ikke er noget alternativ, og da det er vigtigst at gøre typen stærk fremfor letlæselig Globale typedefinitioner [GTD-2a,GTD-2b] GTD-2a: Alle simple og komplekse typer fra klasserne OIOXML Core Components og OIOXML Domain Components SKAL defineres globalt. GTD-2b: Alle simple og komplekse typer fra klassen OIOXML NDR Components BØR defineres globalt. Globale typedefinitioner befordrer genbrug og fjerner mulig redundans, hvilket er et meget vigtigt aspekt af OIOXML. Desuden bliver skemamodulerne mere overskuelige og ensartede, og der sikres imod navnekollision. Dette er ensbetydende med, at typedefinitioner altid skal navngives og anonyme typer ikke er tilladt Omdøbning af en eksisterende type [GTD-3] GTD-3: Man MÅ IKKE definere en ny simpel eller kompleks type identisk med en eksisterende simpel eller kompleks type. Det er vigtigt at syntaks og semantik hænger sammen, så hvis hvis der semantisk er tale om det samme skal det eksisterende type genbruges. Omvendt skal man ikke genanvende blot fordi syntaksen er ens, da dette giver det intryk at uanset om denne eksisterende type er indbygget eller brugerdefineret anytype og anysimpletype [GTD-4] GTD-4: Man MÅ IKKE benytte de indbyggede ur-typer anytype og anysimpletype. Da disse typer er de svagest mulige datatyper må de ikke benyttes. I dokumentorienterede 19

26 Regler for typedefinitioner problemstillinger se regl [CTD-7] Håndtering af binært indhold [GTD-5] GTD-5: Man BØR benytte den simple type anyuri eller base64binary til at håndtere binært indhold. Da xml er karakterbaseret er der ingen mulighed for at indlejre rå binæredata i xml. Dette løses ved enten at referere til det dokument man ønsker at videresende eller ved at formatere dokumentet til base64. <element name="imageuri" type="xsd:anyuri"/> <element name="image" type="xsd:base64binary"/> Man bør definere en attribut som tilkendegive dokumentets type baseret på MimeType Abstrakte typer [GTD-6] GTD-6: Man KAN benytte attributten abstract i simple og komplekse type definitioner. Hvis modelleringen angiver en aflednings struktur, f.eks. med en fælles datatype som ikke skal kunne instntieres kan man anvende attributten abstract Kontrol af typeafledninger [GTD-7] GTD-7: Man BØR IKKE begrænse typeafledninger: attributterne finaldefault og blockdefault i rodelementet schema samt attributterne block og final i simple og komplekse typedefinitioner BØR IKKE benyttes. Genbrug er centralt i OIOXML og derfor bør man ikke begrænse muligheden for typeafledninger Regler for simple typedefinitioner Anvendelse af list [STD-1] STD-1: Konstruktionen list MÅ IKKE benyttes. Da der er en relativ løs kobling mellem indholdet at elementets indhold og typen, bør dette erstattes at sequence af et element der svarer til typen, da dette gør det entydigt Anvendelse af union [STD-2] STD-2: Konstruktionen union MÅ IKKE benyttes. 20

27 Regler for typedefinitioner Union datatypes består af sammentrækninger af to eller flere datatyper i samme element, og gør det dermed uklart hvilken type det egentlig er, og må derfor ikke benyttes. Eksempel: <xsd:element name='size'> <xsd:simpletype> <xsd:union> <xsd:simpletype> <xsd:restriction base='integer'/> </xsd:simpletype> <xsd:simpletype> <xsd:restriction base='string'/> </xsd:simpletype> </xsd:union> </xsd:simpletype> </xsd:element> I forhold til ovenstående eksempel vil det første size element herunder validere som integer og de to øvrige som string. <size>1</size> <size>large</size> <size xsi:type='xsd:string'>1</size> Længden af string [STD-3] STD-3: Man BØR IKKE begrænse længden af string uden begrundelse. Længden af string kan begrænses med facetten maxlength, men dette bør ikke gøres vilkårligt, men kun hvis der er en grund, såsom lovbestemt, direktiv, cirkulære eller en fælles og udbredt praksis for et givent domæne Repræsentation af kodelister [STD-4] STD-4: Kodelister BØR udtrykkes via enumeration konstruktionen. Hvis der findes natulige name token værdier, bør enumeration konstruktionen anvends. Alternativt kan begrænsning af heltal, typisk positive, og mere sjældent patterns anvendes. Det er meningen at det skal forblive en kode og en fuld tekstuel repræsentation. Et godt eksempel er landekoden, hvor værdien næsten er selvsigende, modsat f.eks. et heltal der typisk er blottet for semantik og blot identificere en entydig værdi. Se dokumentationsreglen [DOC4] Værdier i enumerationer [STD-5] STD-5a: Værdier i enumeration konstruktioner BØR udtrykkes udelukkende med små bogstaver. STD-5b: Værdier i enumeration konstruktioner KAN være både dansk eller 21

28 Regler for typedefinitioner engelsk. Udgangspunktet bør være små bogstaver uden mellemrum, med mindre det er værdier, som reelt begynder med stort bogstav (f.eks. egenavne). I det omfang at typen repræsenterer reelle dataværdier bør man bruge dansk som sprog, men mere abstrakte koder bør benytte sig af engelsk. Dersom der indenfor et domæne allerede er defineret udfaldsrum, som falder undenfor ovenstående regel, kan der dispenseres. Et eksempel kunne være et udfaldsrum, der har været anvendt i EDIFACT-baserede meddelelser gennem en årrække. Hvis der er bred enighed blandt domæneeksperter om at bibeholde det eksisterende udfaldsrum kan dette implementeres i OIOXML Anvendelse af whitespace facetten og dertil koblede typer [STD-6] STD-6: Man MÅ IKKE benytte whitespace facetten samt de indbyggede simple typer token og normalizedstring. Da disse konstruktioner i XML Schema forårsager at der er forskel på den umiddelbare instans og den parsede instans, må de ikke bruges Regler for komplekse typedefinitioner Definition af komplekse typer ved aggregering [CTD-1a,CTD-1b] CTD-1a: Man BØR definere en kompleks type ved anvendelse af konstruktionerne sequence og choice. CTD-1b: Man MÅ IKKE definere en kompleks type ved anvendelse af konstruktionen all. Man bør definere nye komplekse typer ved direkte anvendelse af sequence og choice, da disser giver en forudsigelig struktur. All derimod bruges på indholdsmodeller uden krav til rækkefølgen af elementerne, men stiller dog krav til kardinaliteten, hvor hvert element skal være valgfrit (minoccurs=0 og maxoccurs=1).desuden skal all gruppen skal være top level elementet af en type, og den kan kun indeholde individuelle element erklæringer, ikke choice eller sequences Derfor skal sequnce og choice benyttes da der ønskes en klar og explicit model, ikke en rodet og tilfældig. Risikoen for en non-deterministisk indholdsmodel fjernes og værktøjsunderstøttelsen sikres Definition af komplekse typer ved afledning [CTD-2a,CTD-2b] CTD-2a: Man KAN definere en kompleks type via extension konstruktionen. 22

29 Regler for typedefinitioner Ud fra et overordnede designprincip om at gøre tingene så simple som muligt, skal man overveje hvad der er simplest en aggregering eller en extension. Dette har natuligvis afsæt i hvordan datamodellen er konstrueret. CTD-2b: Man MÅ IKKE definere en kompleks type via restriction konstruktionen. Restriction på komplekse typer er muligvis den mest komplicerede konstruktion som findes i XML Schema. Desuden afspejler det ikke noget i den objekt orienterede tankegang og må derfor ikke benyttes Anvendelse af blandet indholdsmodel [CTD-3] CTD-3: Den blandede indholdsmodel (mixed content) BØR kun benyttes til dokumentorienterede strukturer. Den blandede indholdsmodel tillader elementer at indeholde både data og andre elementer. Dokumentorienteret opmærkning kræver en sådan model, i modsætning til dataorienteret opmærkning, hvor den blandede indholdsmodel ikke må forekomme, da den gør det vanskeligt at manipulere de modellerede data Anvendelse af tom indholdsmodel [CTD-4] CTD-4: Den tomme indholdsmodel (empty content) MÅ kun benyttes til dokumentorienterede strukturer. Eksempler er f.eks. <br/> og <hr/> fra XHTML, og dette karakteriserer netop at det har sin anvendelse i dokumentorienterede strukturer. Til dataorienterede strukturer derimod må den ikke benyttes, hvilket vil sige elementer der er baseret på typen string, eller afledte af denne som tillader tomme værdier. Disse bør derfor tilføjes facetten minlength med værdien 1, som sikrer at valide instanser ikke har tomme elementer Anvendelse af any [CTD-5] CTD-5: Konstruktionen any MÅ kun benyttes i indholdsmodellen til dokumentorienterede strukturer. Hvis ikke man har dokumentstrukturen definieret i XML Schema kan man anvende any, men man bør tilstræbe at anvende en defineret struktur, da dette sikrer et validt indhold Anvendelse af anyattribute [CTD-6] CTD-6: Konstruktionen anyattribute MÅ IKKE benyttes i indholdsmodellen. Da attributter kun anvendes til metadata og der ønskes en klar indholdsmodel, må man ikke benytte anyattribute. 23

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

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

Regelsamling for udvikling af XML Schemaer

Regelsamling for udvikling af XML Schemaer Regelsamling for udvikling af XML Schemaer XML Schema kogebogen Udgivet af den fælles offentlige XML komité Version: LO Af Mikkel Hippe Brun, Integrator Uniware NS Regelsamling for udvikling af XML Schemaer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4

Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4 Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4 1 Indholdsfortegnelse G.1 INTRODUKTION 4 G.1.1 OVERBLIK OVER HVORDAN DIGITAL POST KAN TILGÅS 4 G.1.2 FLOW SOM EN DIGITAL

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

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

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

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

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

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

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

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

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

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

Delivery documentation joint reporting of animal husbandry

Delivery documentation joint reporting of animal husbandry Delivery documentation joint reporting of animal husbandry Package delivery information Project Description: Joint reporting of animal husbandry Fælles HusdyrIndberetning Client/user: Ministry of Food

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

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

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

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

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Priser UBL 2.0 Prices G25 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen

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

Projekt SFI-2. Terminologi- og SFI-workshop 2. september 2008. Gert Galster, SundIT http://sundit.dk

Projekt SFI-2. Terminologi- og SFI-workshop 2. september 2008. Gert Galster, SundIT http://sundit.dk Projekt SFI-2 Terminologi- og SFI-workshop 2. september 2008 Gert Galster, SundIT http://sundit.dk SFI-2 - formål At levere et beslutningsgrundlag vedrørende etablering af en it-infrastruktur, så man rationelt

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

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

Om at konvertere PDF - den gode, den dårlige og den forfærdelige metode

Om at konvertere PDF - den gode, den dårlige og den forfærdelige metode Dokumentation Om at konvertere PDF - den gode, den dårlige og den forfærdelige metode Forfatter Leonard Rosenthal PDF Standards Architect, Adobe Inc. Oversættelse Søren Frederiksen / Søren Winsløw DDPFF

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

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh Databasesystemer, forår 2005 IT Universitetet i København Forelæsning 3: E-R modellering 17. februar 2005 Forelæser: Rasmus Pagh Forelæsningen i dag Datamodellering hvad, hvornår, hvorfor og hvordan? Business

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

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

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

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5 Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a:

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

2013 SP1. Konfiguration af koncernindblik. Configuration Guide

2013 SP1. Konfiguration af koncernindblik. Configuration Guide 2013 SP1 Konfiguration af koncernindblik Configuration Guide Intellectual Property Rights This document is the property of ScanJour. The data contained herein, in whole or in part, may not be duplicated,

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

Forord. Versioner. Version Date Description 1.0.0 05/06/2013 Initial version 2.0.0 24/07/2013 URI er ændret

Forord. Versioner. Version Date Description 1.0.0 05/06/2013 Initial version 2.0.0 24/07/2013 URI er ændret APOS2 OIO Services 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

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus

Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus 4. oktober 2006 C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y DEVOTEAM i Danmark og i Europa 2 Devoteam

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

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

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

OIOUBL Intro. OIOUBL Introduktion UBL 2.0 Introduktion I01 Version 1.2. Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.

OIOUBL Intro. OIOUBL Introduktion UBL 2.0 Introduktion I01 Version 1.2. Udgivelsen er beskyttet af Creative Commons license, Navngivning 2. OIOUBL Intro OIOUBL Introduktion UBL 2.0 Introduktion I01 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: IT- og Telestyrelsen E-mail: oioubl@itst.dk OIOUBL

Læs mere

OIOUBL Guideline. OIOUBL Guideline G28. Version 1.3. OIOUBL Totaler. UBL 2.0 Totals

OIOUBL Guideline. OIOUBL Guideline G28. Version 1.3. OIOUBL Totaler. UBL 2.0 Totals OIOUBL Guideline OIOUBL Guideline OIOUBL Totaler UBL 2.0 Totals G28 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen E-mail: support@nemhandel.dk

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

Bringe taksonomier i spil

Bringe taksonomier i spil Bringe taksonomier i spil Frans la Cour Hvem er jeg? Frans la Cour 3 år hos ensight a/s Systemdesign Projektledelse og implementering Undervisning Med udgangspunkt i Veritys værktøjer Vise nogle af de

Læs mere

ectrl vejledning ectrl Opsætning af elektronisk rering

ectrl vejledning ectrl Opsætning af elektronisk rering ectrl vejledning ectrl Opsætning af elektronisk rering Indholdsfortegnelse Opsætning 3 Debitoropsætning 4 Opsætning af afsendelsesmodulet. 6 Check af anden opsætning. 11 Elektronisk fakturering. 13 Opsætning

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

Sådan afleverer du forskningsdata til arkivering

Sådan afleverer du forskningsdata til arkivering Sådan afleverer du forskningsdata til arkivering For at kunne arkivere data på en meningsfuld måde skal Rigsarkivet bede om: 1. Et udfyldt afleveringsskema 2. Projektbeskrivelse i både en dansk og engelsk

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Activity Milestone Artifact Spørgsmål

Læs mere

GeoEnviron Web-løsninger

GeoEnviron Web-løsninger 2012 Troels Kreipke 01-01-2012 Indhold Generelt... 3 Web-løsninger... 3 XML-firewall... 4 GeoEnviron_WebService... 4 Installation af web-løsninger uden brug af GeoEnviron_WebService... 5 GeoEnviron_WebService...

Læs mere

Database kursus Forår 2013

Database kursus Forår 2013 Database kursus Forår 2013 Jacob Aae Mikkelsen Database design og programmering/databaser fra Organisationsorienteret softwareudvikling 1 Praktisk info Lærebog Database Systems: The Complete Book Skema

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 : Fælles ABM indholds- og transportformat Dato : 2009-08-28 Status : Gældende ABM-specifikation Sekretariat: Publicering: Kulturarvsstyrelsen

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

2 Abstrakte datatyper.

2 Abstrakte datatyper. 2 Abstrakte datatyper. Motivere eksempel: top-down udvikling af program 'mini-bank' Strukturering af et program: efter data eller funktion? Definition af en abstrakt datatype og tilknyttede begreber. Fænomener,

Læs mere

OFFENTLIGT KMD A/S EJ 0.0 NUMMERERET SLIDE 1 CCM USER GROUP 20.11.2013. KMD einvoicing. v/ Ole Sixhøi

OFFENTLIGT KMD A/S EJ 0.0 NUMMERERET SLIDE 1 CCM USER GROUP 20.11.2013. KMD einvoicing. v/ Ole Sixhøi OFFENTLIGT SLIDE 1 CCM USER GROUP 20.11.2013 KMD einvoicing v/ Ole Sixhøi AGENDA SLIDE 2 INTRODUKTION KMD einvoicing - Baggrunden - Ydelsen DESIGN OG FUNKTIONALITET LOGISK FLOW ARKITEKTUR KMD E-INVOICING

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

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

4 Basal Objekt-orienteret Programmering I.

4 Basal Objekt-orienteret Programmering I. 4 Basal Objekt-orienteret Programmering I. Klasser i forhold til abstrakte datatyper og record-typer. Variable og operationer. Klasse-interfaces. Klasser og typer. Klasse-instantiering og initialisering.

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

OIOUBL Guideline. OIOUBL Profiler. UBL 2.0 Profiles (UTS) Appendiks til G26. Version 1.3

OIOUBL Guideline. OIOUBL Profiler. UBL 2.0 Profiles (UTS) Appendiks til G26. Version 1.3 OIOUBL Guideline OIOUBL Profiler UBL 2.0 Profiles (UTS) Appendiks til G26 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Profiler (UTS) Version 1.3 Side 2 Kolofon

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

Hvor det er relevant vil vi gennemgå de pågældende kommentarer efterfølgende.

Hvor det er relevant vil vi gennemgå de pågældende kommentarer efterfølgende. OIOXML aflevering Introduktion til aflevering Følgende er dokumentation til afleveringen http://rep.oio.dk/social.dk/common/xml.schema/20071220/ Forud for denne aflevering er der gået 2 andre komplette

Læs mere

Ideerne bag projektet

Ideerne bag projektet Projektledere: Sanne Brønserud Larsen, Konsulent, KL Søren Teglskov, Konsulent, Skolelederforeningen Konsulenter: Andreas Rønne Nielsen, Partner, Wanscher & Nielsen Tore Wanscher, Partner, Wanscher og

Læs mere

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets.

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets. Dagens program Har alle fået? Har nogen betalt for meget? Hav jeres koder klar Domæner change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog Hvad er widgets Hvad er

Læs mere

FAQ OIOXML elektronisk regning

FAQ OIOXML elektronisk regning Side 1 af 24 FAQ OIOXML elektronisk regning 10. september 2012 1 Indledning Denne FAQ samler svarene på de spørgsmål der oftest er blevet stillet i forbindelse med OIOXML elektronisk regning. Alle spørgsmål

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

Referat 9. møde i OIO-udvalget for sags- og dokumentområdet den 21. september 2010

Referat 9. møde i OIO-udvalget for sags- og dokumentområdet den 21. september 2010 Referat af 9. møde i OIO-udvalget for sags- og dokumentområdet 21.09.2010 Referat 9. møde i OIO-udvalget for sags- og dokumentområdet den 21. september 2010 Mødested:, Holsteinsgade 63, 2100 Kbh. Ø, kl.

Læs mere

ER-modellen. Databaser, efterår 2002. Troels Andreasen. Efterår 2002

ER-modellen. Databaser, efterår 2002. Troels Andreasen. Efterår 2002 Databaser, efterår 2002 ER-modellen Troels Andreasen Datalogiafdelingen, hus 42.1 Roskilde Universitetscenter Universitetsvej 1 Postboks 260 4000 Roskilde Telefon: 4674 2000 Fax: 4674 3072 www.dat.ruc.dk

Læs mere

Fælles grundlag for strukturen i EPJ

Fælles grundlag for strukturen i EPJ Fælles grundlag for strukturen i EPJ G-EPJ som standard Gert Galster Sundhedsstyrelsens Enhed for Sundhedsinformatik G-EPJ som standard... for hvad? Der Der findes i i dag dag ingen entydig definition

Læs mere

EDI. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1. Copyright: Naddon version 201010

EDI. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1. Copyright: Naddon version 201010 EDI Microsoft Dynamics NAV 2009 SP1 Klassisk Side 1 Indholdet i dette dokument må på ingen måde gengives helt eller delvist hverken på tryk eller i anden form - uden forudgående skriftlig tilladelse fra

Læs mere

Digital strategi, indsatsområde 1, delprojekt 1, Generiske sagsbehandlingsbegreber

Digital strategi, indsatsområde 1, delprojekt 1, Generiske sagsbehandlingsbegreber HØRINGSDOKUMENT Fra: Til: Resumé: David Rosendahl Høringsparter Arbejdsgruppen har identificeret de overordnede og tværgående begreber i sagsbehandlingsprocessen og struktureret og defineret disse generiske

Læs mere

Datamodeller. 1. Elementerne. Vi betragter E/R-diagrammet, som et diagram over entiteter og relationer Tegneregler: Entitet

Datamodeller. 1. Elementerne. Vi betragter E/R-diagrammet, som et diagram over entiteter og relationer Tegneregler: Entitet Datamodeller I forlængelse af noten om normalisering, følges der her op med redskabet E/R-diagrammer til opstilling af en datamodel, opfat således dette som en alternativ metode mere end endnu et redskab

Læs mere

Danhost Webshop. Bliv fundet på Google

Danhost Webshop. Bliv fundet på Google Danhost Webshop Bliv fundet på Google SEO - Søgemaskineoptimering Når du arbejder med SEO, er det med henblik på, at din hjemmeside eller webshop skal dukke op i søgeresultaterne på f.eks. Google når en

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

Bekendtgørelse om information i OIOXML elektronisk regning til brug for

Bekendtgørelse om information i OIOXML elektronisk regning til brug for K:\Videnskabsministeriet\2004\bekg\530760\530760.fm 12-11-04 12:45 k07 SJ Bekendtgørelse nr. 1075 af 11. november 2004 Bekendtgørelse om information i OIOXML elektronisk regning til brug for elektronisk

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

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

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

Vejledning i projektledelse

Vejledning i projektledelse Dansk standard DS/ISO 21500 2. udgave 2013-09-27 Vejledning i projektledelse Guidance on project management DS/ISO 21500 København DS projekt: M268368 ICS: 03.100.40 Første del af denne publikations betegnelse

Læs mere

Åben uddannelse, Efterår 1996, Oversættere og køretidsomgivelser

Åben uddannelse, Efterår 1996, Oversættere og køretidsomgivelser 3/10/96 Seminaret den 26/10 vil omhandle den sidste fase af analysen og de første skridt i kodegenereringen. Det drejer sig om at finde betydningen af programmet, nu hvor leksikalsk og syntaktisk analyse

Læs mere

Ordliste over anvendt fagterminologi

Ordliste over anvendt fagterminologi Ordliste over anvendt fagterminologi Adjektiv / tillægsord Adverbial / biled Adverbium / biord Akkusativ m. infinitiv Ord, der beskriver eksempelvis en person eller en genstand, f.eks. er stor, god og

Læs mere

DAR OIO vejledning Version 1.2

DAR OIO vejledning Version 1.2 DAR OIO vejledning Version 1.2 Indhold 1 Ændringer i forhold til forrige version... 2 2 Introduktion... 3 2.1 Formål... 3 2.2 Læsevejledning... 3 3 Beskrivelse... 3 3.1 Fælles elementer og strukturer...

Læs mere

Guide til integration med NemLog-in / Signering

Guide til integration med NemLog-in / Signering Guide til integration med NemLog-in / Signering Side 1 af 6 14. november 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør) kan integrere

Læs mere

Indhold. Side 2 af 26

Indhold. Side 2 af 26 Tema Design Design, Programmering og test af Adressebog Fra d. 17 april til 20 april 2012 Vejledere: Gunhild Marie Andersen Kis Boisen Hansen Gruppe B Deltagere Side 1 af 26 Indhold Indledning.... 3 Kodestandard...

Læs mere