BÆRUM KOMMUNE BKXML 1.0. Innledning. Versjon 1.0. Dato:

Størrelse: px
Begynne med side:

Download "BÆRUM KOMMUNE BKXML 1.0. Innledning. Versjon 1.0. Dato: 2009-04-17"

Transkript

1 BÆRUM KOMMUNE BKXML 1.0 Innledning Versjon 1.0 Dato:

2 Innholdsfortegnelse Innholdsfortegnelse...2 Innledning...3 Referanser...4 Side 2 av 95

3 Innledning Bærum Kommune har gjennom sitt SOA arbeid sett viktighetene av å standardisere. I den forbindelse har vi utviklet den interne standarden BKXML som består av en samling navngivings- og designregler for hvordan XML Schema 1 og WSDL 2 dokumenter skal bygges opp i Bærum kommune for å sikre utviklingen av interoperabile web services og grensesnittdefinisjoner. BKXML reglene vil også sikre økt lesbarhet og lette fortolkningen av de data som utveksles og hjelpe til med å sikre verktøystøtte for utviklede skjemaer. Typedefinisjonene som inngår i et BKXML grensesnitt skal også utvikles med tanke på gjenbrukbarhet, og skal legges inn i Bærum kommunes informasjonsmodell. Reglene sikrer da at vi hele tiden har en enhetlig informasjonsmodell som gradvis kan bygges etter hvert som nye behov oppstår, for eksempel ved at nye tjenester skal realiseres. Et viktig element i reglene er også at alltid skal gjenbruke eksisterende typer fra den eksisterende informasjonsmodellen hvis de eksisterer, fremfor å utvikle nye. Alle BKXML type- og grensesnittdefinisjonene i Bærum kommune vil bli gjort tilgjengelige i et InfoStrukturBibliotek, slik at eksterne leverandører eller andre som skal utvikle tjenester som skal samhandle med Bærum kommune vil ha tilgang på disse. Også definisjoner utviklet utenfor Bærum kommune kan etter godkjenning legges inn her, og dermed bli en del av informasjonsmodellen I utviklingen av BKXML har vi støttet oss på det arbeidet som Telestyrelsen i Danmark 3 har gjort med OIOXML 4. På bakgrunn av dette laget en begrenset utgave som heter BKXML ut i fra de behov Bærum kommune har på det nåværende tidspunkt. Danmark har benyttet OIOXML som standard for alle offentlige integrasjonsprosjekter siden 2004 og i dag inngår over 25,000 typedefinisjoner i deres InfoStrukturBase 5. BKXML standarden er under stadig utvikling. I de neste fasene vil vi blant annet fokusere mer på regler for å knytte metadata og semantikkdefinisjoner til typedefinisjonene. Det er i tillegg til denne innledningen fire dokumenter som beskriver BKXML versjon 1.0 og de tilhørende reglene. 1. BKXML Navngivings og Design Regler for Felles XML-Skjema i Bærum Kommune Er et rent oppslagsverk hvor alle reglene er listet opp. 2. BKXML Navngivings og Design Regler Veiledning Er en veiledning som inneholder utdypende forklaringer og eksempler til de reglene som omhandler typedefinisjoner og XML Schema. 3. BKWSDL Veiledning Er en veiledning som inneholder utdypende forklaringer og eksempler til de reglene som omhandler grensesnittdefinisjoner og WSDL dokumenter. 4. BKXML 1.0 Miniguide Versjonskontroll Er en veiledning som inneholder utdypende forklaringer og eksempler til de reglene som omhandler versjonskontroll i XML Schema og WSDL dokumenter Side 3 av 95

4 Referanser Alle dokumentene som omhandler BKXML 1.0 og Bærum kommunes navngivnings- og designregler, er laget med utgangspunkt i tilsvarende dokumenter for OIO Navngivnings- og Designregler, utarbeidet av IT- og Telestyrelsen - Ministeriet for Videnskab Teknologi og Udvikling i Danmark. IT- og Telestyrelsen - Ministeriet for Videnskab Teknologi og Udvikling Overhold reglerne (NDR) OIOWSDL: 'Kontrakt Først'-udvikling med OIOXML Bærum kommune vil i løpet av 2009 opprette en side på hvor all informasjon og dokumentasjon tilhørende BKXML vil bli gjort tilgjengelig. Her vil man også kunne få tak i alle de godkjente BKXML XML Schema og WSDL dokumenter som inngår i Bærum kommunes informasjonsmodell. Inntil videre kan spørsmål rettes til spesialkonsulent Øystein Aanrud i Bærum kommune Side 4 av 95

5 BKXML Navngivings og Design Regler for Felles XML-Skjema i Bærum Kommune Versjon 1.0 Dato: Side 5 av 95

6 Innholdsfortegnelse Endringskontroll...7 BKXML 1.0 Referanser...7 BKXML liste over representasjonstermer...12 Toppdomener i tjenestekatalogen...13 Side 6 av 95

7 Endringskontroll Versjon Dato Utført endring Endring ØAa Dokument opprettet ØAa Utkast av regler for skjema komplett ØAa Lagt til utkast av regler for WSDL ØAa Lagt til domenenavn fra arkitekturprinsipper ØAa Lagt til regler for WSDL. Endret rekkefølgen for namespace termer ØAa Rettet skrivefeil ØAa Lagt til felt for regeltittel og tatt inn endringsforslag fra rbr RC ØAa/Lcf Release Candidate ØAa Korreksjoneer - Versjon 1.0 BKXML 1.0 Referanser Alle dokumentene som omhandler BKXML 1.0 og Bærum kommunes navngivnings- og designregler, er laget med utgangspunkt i tilsvarende dokumenter for OIO Navngivnings- og Designregler, utarbeidet av IT- og Telestyrelsen - Ministeriet for Videnskab Teknologi og Udvikling i Danmark. Referanser: IT- og Telestyrelsen - Ministeriet for Videnskab Teknologi og Udvikling Overhold reglerne (NDR) OIOWSDL: 'Kontrakt Først'-udvikling med OIOXML Side 7 av 95

8 Regel Regeltittel Formulering BKXML regler BKXML-1 Gjenbruk av eksisterende BKXML elementer og typer Et BKXML-skjema SKAL, der hvor det er mulig, gjenbruke eksisterende elementer eller typer som allerede er godkjent i BKXML. BKXML-2 Gjenbruk av innebygde enkle typer Et BKXML-skjema SKAL gjenbruke innebygde enkle typer i XML Schema fremfor å definere egne typer til å representere samme informasjon. BKXML-3 Gjenbruk av element fremfor type Et BKXML-skjema BØR gjenbruke et element fremfor dets type hvis elementets navn og anvendelse er entydig i den konkrete sammenheng. BKXML-4 Gjenbruk av seneste skjemaversjon Et BKXML-skjema SKAL gjenbruke nyeste versjon av et annet eksisterende BKXML-skjema, hvis det andre skjema finnes i flere versjoner. BKXML-5 Et BKXML-skjemas innhold Et BKXML-skjema SKAL inneholde èn elementdeklarasjon, og hvis ikke elementet gjenbruker en eksisterende type fra et annet skjema, èn typedefinisjon for elementet. I tillegg kan et skjema inneholde en eller flere definisjoner av støttetyper hvis disse er nødvendige for å etablere elementets type. Hvis et skjema definerer en abstrakt type skal det ikke inneholde en elementdeklarasjon. BKXML-6 Skjemareferanser En BKXML-skjemaavlevering SKAL i sine enkelte skjema alltid referere til, enten allerede godkjente BKXML-skjema, nye skjema tilhørende den nye avleveringen eller til godkjente eksterne skjema i Adopsjonsklassen (for eksempel skjemaer som allerede er etablerte som standard) BKXML-7 BKXML-skjemaer i Et BKXML-skjema SKAL plasseres i InfoStrukturBiblioteket. InfoStrukturBiblioteket BKXML-8 Systemuavhengige BKXMLskjemaer Utformingen av et BKXML-skjema skal ikke være påvirket av struktur eller begrensninger i bakenforliggende fagsystem. BKXML-9 Klare og entydige skjemaer Et BKXML-skjema SKAL designes så enkelt og entydig som mulig, uten unødvendig kompleksitet eller overflødige konstruksjoner. Generelle XML skjema regler BKGXS-1 Valg av skjemaspråk Et BKXML-skjema SKAL defineres i overensstemmelse med W3C XML Schema anbefalingen (versjon 1.0) av 2. mai 2001: XML Schema part 1: Structures og XML Schema Part 2: Datatypes. BKGXS-2 Versjon av XML Et BKXML-skjema SKAL anvende versjon 1.0 av W3C XML anbefalingen av 4. februar 2004: Extensible Markup Language (XML) 1.0 (Third Edition). BKGXS-3 Valg av encoding scheme Et BKXML-skjema SKAL anvende UTF-8 som encoding scheme. BKGXS-4 Tilknytning til namespace Et BKXML-skjema SKAL tilknyttes et namespace. BKGXS-5 Skjemareferanser Et BKXML-skjema SKAL benytte include konstruksjonen for å referere til andre skjema i samme namespace og import konstruksjonen for å referere til skjema i andre namespace enn skjemaets eget targetnamespace. BKGXS-6 Bruk av redefine Et BKXML-skjema SKAL IKKE benytte redefine konstruksjonen. BKGXS-7 Bruk av notation Et BKXML-skjema SKAL IKKE benytte notation konstruksjonen. BKGXS-8 Bruk av schemalocation Et BKXML-skjema SKAL angi alle dets schemalocation attributter med en absolutt og gyldig URL til det refererte skjemas plassering. BKGXS-9 Bruk av key, keyref eller unique Et BKXML-skjema SKAL IKKE benytte konstruksjonene key, keyref eller unique. Generelle navngivigsregler BKGNR-1 Unik navngiving Et BKXML-skjema SKAL navngi alle dets globale elementer og typer unikt innenfor sitt namespace, og BØR navngi unikt også innenfor alle BKXMLskjema. BKGNR-2 Navngivningsmodellen for elementer, attributter og typer Et BKXML-skjema SKAL navngi alle sine globale og lokale elementer, typer og attributter etter ObjektEgenskapRepresentasjon navngivningsmodellen som presiseres i følgende underregler. BKGNR-2a Termen Objekt Et navn SKAL i sin Objekt term beskrive det dataobjekt som et element og dets type representerer i en bestemt sammenheng. BKGNR-2b Utelatelse av termen Objekt Et navn KAN utelate sin Objekt term i de tilfeller hvor et element og dets type opptrer i kontekst av et objekt, eller der objektet er ukjent. BKGNR-2c Termen Egenskap Et navn SKAL i sin Egenskap term, ved hjelp av ett eller flere kvalifiserte ord beskrive en fremtredende egenskap ved et element og dets types Objekt term. BKGNR-2d Termen Representasjon Et navn SKAL i sin Representasjon term beskrive et element og dets types representative kategori. Representasjon termen SKAL anta en av verdiene i BKXML s liste over godkjente representasjonstermer. BKGNR-2e Synonyme termer Et navn SKAL, hvis det har en frase i termen Egenskap som er synonymt med en frase i termen Representasjon, fjerne frasen fra Egenskap og beholde den i Representasjon. BKGNR-2f Entallsform av termer Et navn SKAL angis på entallsform, med mindre navneordet er en flertallsform. BKGNR-2g Forkortelser og akronymer Et navn BØR IKKE benytte forkortelser og akronymer, med mindre disse er de vanligst brukte termer. Side 8 av 95

9 BKGNR-2h Anvendelse av tegn Et navn SKAL IKKE inneholde annet enn bokstaver og tall. Bruk av språk BKLNR-1 Bruk av norsk språk Et BKXML-skjema SKAL navngi alle sine globale og lokale elementer, attributter og typer på norsk bokmål. BKLNR-2 Språkangivelse med xml:lang Et BKXML-skjema SKAL i sitt xml:lang attributt i elementet schema ha verdien NB. BKLNR-3 Ord- og fagbøker Navngiving i et BKXML-skjema SKAL skje i henhold til Norsk rettskrivingsordbok eller relevante fagbøker. BKLNR-4 Bruk av Æ, Ø og Å Et BKXML-skjema SKAL IKKE anvende de norske spesialtegnene æ, ø, å, Æ, Ø eller Å. Som alternativ benyttes i stedet ae for æ, oe for ø, aa for å, Ae for Æ, Oe for Ø og Aa for Å. Navngiving av typer BKTPN-1 Type suffiks Et BKXML-skjema SKAL avslutte navnet til en simpletype eller complextype med suffikset Type. BKTPN-2 Navngiving for simpletype Et BKXML-skjema SKAL benytte termen Representasjon for alle sine simpletype. BKTPN-3 Navngiving for complextype Et BKXML-skjema SKAL i sin Representasjon term i typenavnet for en complextype benytte verdien Liste hvis og bare hvis innholdet er minst to forekomster av nøyaktig ett element (dvs. typen inneholder kun en element deklarasjon, og denne har maxoccurs større eller lik 2 eller lik unbounded ). I alle andre tilfeller hvor konstruksjonen sequence benyttes skal termen Representasjon være Struktur. For alle tilfeller hvor konstruksjonen choice benyttes, skal termen Representasjon være Valg. BKTPN-4 Navngiving av lister Hvis et element i en BKXML-skjema complextype har minst to forekomster (dvs. en element deklarasjon skal ha maxoccurs større eller lik 2 eller lik unbounded ), så SKALelementet legges alene inn i en ny complextype med sin Representasjon term lik Liste som beskrevet i foregående punkt. BKTPN-5 Bruk av UpperCamelcase for typer Et BKXML-skjema SKAL navngi alle sine simpletype og complextype i UpperCamelCase. BKTPN-6 Systemspesifikke navn for typer Et BKXML-skjema SKAL IKKE benytte termer som er system- eller leverandøravhengige i sine typenavn. Navngiving av elementer BKELN-1 Sammenheng mellom elementog typenavn Et BKXML-skjema SKAL navngi sine elementer identisk med elementets type, uten typens Type suffiks, hvis element erklæringen og type definisjonen forekommer sammen i skjema. BKELN-2 Bruk av UpperCamelCase for Et BKXML-skjema skal navngi alle sine elementer i UpperCamelCase. elementer BKELN-3 Systemspesifikke navn for elementer Et BKXML-skjema SKAL IKKE benytte termer som er system- eller leverandøravhengige i sine elementnavn. Navngiving av attributter BKATN-1 Bruk av lowercamelcase for Et BKXML-skjema SKAL navngi alle sine attributter i lowercamelcase. attributter BKATN-2 Systemspesifikke navn for attributter Et BKXML-skjema SKAL IKKE benytte termer som er system- eller leverandøravhengige i sine attributtnavn. Navngiving av skjemafiler BKFNR-1 Navngiving av BKXML skjemafil Et BKXML-skjema SKAL navngi sine skjema filer etter modellen <namespace prefiks>+ _ +<elementnavn>+ _ +<versjon>+.xsd. BKFNR-2 Bruk av elementnavn i filnavn Et BKXML-skjema SKAL i filnavnets <elementnavn> term angi navnet på skjemaets globale element. Hvis skjemaet inneholder en abstrakt type definisjon skal navnet på den definerte typen, uten suffikset Type brukes. BKFNR-3 Bruk av dato i filnavn Et BKXML-skjema SKAL i filnavnets <versjon> term benytte samme dato som er angitt som dato i filens namespace, angitt på formatet ÅÅÅÅMMDD. BKFNR-4 Bruk av namespace prefiks Et BKXML-skjema SKAL i filnavnets <namespace prefiks> term benytte en etablert og godkjent forkortelse for innholdets namespace term for forretningsområde. Forkortelsen skal være felles for alle skjema innen samme forretningsområde, og unik på tvers av alle forretningsområder. Generelle regler for typedefinisjoner BKGTD-1 Sterke datatyper Et BKXML-skjema SKAL definere alle sine simpletype og complextype sterkest mulig. BKGTD-2 Globale typedefinisjoner Et BKXML-skjema SKAL definere alle sine simpletype og complextype globalt. BKGTD-3 BKGTD-4 Ny definisjon av eksisterende type Bruk av innebygde XML Schema typer Et BKXML-skjema SKAL IKKE definere en simpletype eller complextype identisk med en type i et allerede eksisterende BKXML-skjema. Et BKXML-skjema SKAL IKKE bruke noen av de følgende innebygde enkle typer: anytype, anysimpletype, long, int, short, byte, unsignedlong, unsignedint, unsignedshort, unsignedbyte, normalizedstring, token, language, Side 9 av 95

10 name, NCName, ID, IDREF, ENTITY, ENTITIES, NMTOKEN eller NMTOKENS. BKGTD-5 Håndtering av binært innhold Et BKXML-skjema SKAL benytte de innebygde enkle typer anyuri eller base64binary for å håndtere binært innhold. BKGTD-6 Abstrakte typer Et BKXML-skjema KAN benytte attributtet abstract i simpletype og complextype til å definere abstrakte typer BKGTD-7 Begrensning av typeavledninger Et BKXML-skjema SKAL IKKE begrense typeavledninger med attributtene finaldefault og blockdefault i schema elementet, attributtet final i simpletype eller attributtene block og final i complextype. BKGTD-8 Bruk av støttetyper Et BKXML-skjema SKAL utelukkende benytte støttetyper for å etablere skjemaets ene typedefinisjon hvis denne ikke kan etableres uten støttetypene. Støttetypene skal ligge i samme fil som typedefinisjonen, og kan ikke brukes av andre skjema. BKGTD-9 Oppbygging av støttetyper Et BKXML-skjema SKAL definere alle sine støttetyper som simpletype eller som lister (complextype som inneholder nøyaktig en elementdeklarasjon hvor maxoccurs er større eller lik 2 eller lik unbounded ) Regler for simpletype definisjoner BKSTD-1 Bruk av list og union Et BKXML-skjema SKAL IKKE benytte konstruksjonene list eller union. BKSTD-2 Lengden av string Et BKXML-skjema BØR IKKE begrense lengden av den innebygde typen string hvis det ikke finnes en allment vedtatt lengde. BKSTD-3 Representasjon av kodelister Et BKXML-skjema SKAL uttrykke kodelister ved hjelp av konstruksjonen enumeration. BKSTD-4 Verdier i kodelister Et BKXML-skjema SKAL utelukkende uttrykke verdier i kodelister med bokstaver og tall, uttrykt i UpperCamelCase. BKSTD-5 Bruk av whitespace Et BKXML-skjema SKAL IKKE benytte whitespace fasetten eller de tilhørende konstruksjoner text, token eller normalizedstring. Regler for complextype definisjoner BKCTD-1 Oppbygning av complextype Et BKXML-skjema SKAL definere en complextype ved bruk av konstruksjonene sequence eller choice. BKCTD-2 Bruk av all Et BKXML-skjema SKAL IKKE definere en complextype ved hjelp av konstruksjonene all. BKCTD-3 Bruk av hjelpeattributt for choice En complextype som er definert ved hjelp av konstruksjonen choice SKAL ha et attributt for å fortelle hvilket av elementene som inneholder en verdi. BKCTD-4 Bruk av extension Et BKXML-skjema KAN definere en complextype ved hjelp av konstruksjonen extension. BKCTD-5 Bruk av restriction Et BKXML-skjema SKAL IKKE definere en complextype ved hjelp av restriction konstruksjonen. BKCTD-6 Bruk av mixed og empty content Et BKXML-skjema SKAL IKKE benytte blandet (mixed content) eller tom (empty content) innholdsmodell. BKCTD-7 Bruk av any og anyattribute Et BKXML-skjema SKAL IKKE benytte konstruksjonene any eller anyattribute i complextype. Regler for elementdeklarasjoner BKELD-1 Globale elementdeklarasjoner Et BKXML-skjema SKAL deklarere sitt element globalt. BKELD-2 Namespace for elementer Et BKXML-skjema SKAL tildele ett namespace til sitt element. Dvs. attributtet elementformdefault i elementet schema skal tildeles verdien qualified og attributtet form i element deklarasjonen skal ikke benyttes. BKELD-3 Bruk av default og fixed for elementer Et BKXML-skjema SKAL IKKE benytte attributtene default eller fixed i sine element deklarasjoner. BKELD-4 Bruk av nillable Et BKXML-skjema SKAL IKKE sette nillable attributtet til verdien true i sin elementdeklarasjon. BKELD-4 Bruk av substitutiongroup Et BKXML-skjema SKAL IKKE benytte substitutiongroup i sine elementdeklarasjoner. Regler for attributtdeklarasjoner BKATD-1 Bruk av attributter Et BKXML-skjema SKAL kun benytte sitt elements attributter til metadata for elementets verdi. BKATD-2 Lokale attributter Et BKXML-skjema SKAL deklarere alle sine attributter lokalt. BKATD-3 Namespace for attributter Et BKXML-skjema SKAL IKKE tildele et namespace til sine attributter. Dvs. attributtet attributeformdefault skal ikke spesifiseres (false er default verdi), og attributtet form i attributt deklarasjonen skal ikke benyttes. BKATD-4 Bruk av default og fixed for attributter Et BKXML-skjema SKAL IKKE benytte attributtene default eller fixed i sine attributt deklarasjoner. Versjoneringsregler BKVER-1 Versjonering i namespace Et BKXML-skjema SKAL angi sin versjon ved hjelp av <version> termen i sitt filnavn og i sitt namespace. BKVER-2 Bruk av dato i namespace Et BKXML-skjema SKAL i en ny versjon av et eksisterende BKXML-skjema spesifisere en datoangivelse i <versjon> termen i sitt filnavn og namespace med Side 10 av 95

11 BKNMS-1b BKNMS-1c BKNMS-1d BKNMS-1e en senere dato enn den dato som er brukt i en eventuell tidligere versjon av skjemaet. BKVER-3 Opprettelse av ny versjon Et BKXML-skjema SKAL IKKE opprettes i en ny versjon hvis skjemaets innhold er uendret. BKVER-4 Låsing av BKXML-skjema Et BKXML-skjema som er godtatt SKAL IKKE slettes eller endres i InfoStrukturBiblioteket. BKVER-5 Nye skjema i eksisterende namespace Et BKXML-skjema SKAL legges inn i et allerede eksisterende namespace (versjon) hvis det ikke endrer noe av det eksisterende innholdet. BKVER-6 Bruk av version attributtet Et BKXML-skjema BØR også angi sin nummeriske versjon i attributtet version i schema elementet. Versjoner skal her angis økende med hovedversjonsnummer før punktum og ett nivå med subversjonsnummer etter punktum. Denne versjonen angir versjonen av dette spesifikke BKXML-skjema, og trenger ikke være felles for alle BKXML-skjema innen samme namespace. Namespaceregler BKNMS-1 Navngiving av namespace Et BKXML-skjema namespace SKAL ha følgende oppbygning: <bkinngang>+ / +<bk-område>+ / +<teknikk>+ / +<versjon >. BKNMS-1a Namespace navngiving for bk- Et BKXML-skjema SKAL i sin namespace term <bk-inngang> ha verdien inngang Namespace navngiving for områder Systemspesifikke navn for namespace Namespace navngiving for versjon Namespace navngiving for teknikk Et BKXML-skjema SKAL i sin namespace term <bk-område> bruke oppbygningen <toppområde>( / <subområde>)*. Verdiene for toppområde og subområde skal hentes fra listen over områder definert under Arkitekturprinsipper. Ved behov for områder som ikke allerede er definert her, skal nye verdier godkjennes og legges til i Arkitekturprinsipper. Et BKXML-skjema SKAL IKKE benytte termer som er system- eller leverandøravhengige i sine toppområde eller subområde termer i sitt namespace. Et BKXML-skjema SKAL i sin namespace term <versjon> ha en gyldig dato på formatet ÅÅÅÅMMDD. Et BKXML-skjema SKAL i sin namespace term <teknikk> ha verdien Xml/Schema. Generelle regler for WSDL BKWSR-1 Bruk av WS-I Basic Profile 1.1 En BKWSDL SKAL følge anbefalingene til WS-I Basic Profile 1.1, og skal ikke generere feil når de testes med siste versjon av WS-I WSDL-Analyzer. BKWSR-1 Bruk av document-literal En BKWSDL SKAL benytte document-literal binding. BKWSR-3 Bruk av godkjente BKXML En BKWSDL SKAL kun benytte typer fra godkjente BKXML-skjema. typer BKWSR-4 Bruk av elementreferanser En BKWSDL SKAL i sine message elementer kun ha ett part element. Dette part elementet skal benytte element attributtet og skal referere til et globalt godkjent BKXML-element. BKWSR-5 Bruk av request-response En BKWSDL SKAL benytte request-response utveksling. BKWSR-6 Bruk av fault En BKWSDL SKAL IKKE benytte fault konstruksjonen. Alle feilmeldinger skal fanges opp i tjenesten og returneres som feilmelding i kontekstobjektet for status. BKWSR-7 Bruk av protokoller En BKWSDL SKAL definere tjenester som kommuniserer over Soap protokollen. Navngivingsregler for WSDL BKWSN-1 Bruk av BKXML navngivingsregler En BKWSDL SKAL følge navngivingsreglene for BKXML-skjema der disse gir mening. BKWSN-2 Bruk av namespace i WSDL En BKWSDL SKAL i sine namespace termer <bk-inngang>, <bk-område> og <versjon> følge reglene for BKXML-skjema. BKWSN-3 Namespace navngiving for En BKWSDL SKAL i sin namespace term <teknikk> ha verdien Xml/Wsdl teknikk i WSDL BKWSN-4 Navngiving av WSDL filer En BKWSDL SKAL navngi sine wsdl fil etter modellen <namespace prefix>+ _ +<tjenestenavn>+ _ +<versjon>+.wsdl. BKWSN-5 Navngiving av tjenester En BKWSDL SKAL navngi sin tjeneste (service) med et begrep som er dekkende for alle dens operasjoner. Et tjenestenavn BØR IKKE beskrive en handling BKWSN-6 Navngiving av operasjoner En BKWSDL SKAL navngi sine operasjoner etter HandlingObjekt navngivningsmodellen. Det er ingen faste regler for Handling eller Objekt termene, men Handling termen skal presist gjengi operasjonens oppgave. Objekt termen vil i mange tilfeller være identisk med navnet på selve tjenesten. BKWSN-7 Navngiving av meldinger En BKWSDL SKAL navngi sine meldinger (message) etter modellen <operasjonsnavn>+ In og <operasjonsnavn>+ Out for hhv. Inn og ut parameterene. BKWSN-8 Navngiving og oppbygging av En BKWSDL SKAL i sine meldinger ha nøyaktig ett part element. Dette part Side 11 av 95

12 meldingsinnhold elementet skal ha navnet body og skal referere til elementet i et gyldig BKXML-skjema som inneholder korrekte kontekst objekter samt et element som samler alle forretningsdata i inn eller ut parametrene. Nevnte BKXMLskjema skal ha som navn <operasjonsnavn>+ Request for inn parameteren og <operasjonsnavn>+ Response for ut parameteren. De tilsvarende typer skal ha samme navn, men med endelsen Type BKWSN-9 Navngiving av porttype En BKWSDL SKAL navngi sine porttype elementer etter navngivningsmodellen <tjenestenavn>+<teknikk>+ PortType. Hvor <teknikk> for eksempel er Soap, Get eller Post BKWSN-10 Navngiving av bindinger En BKWSDL SKAL navngi sine binding elementer etter navngivningsmodellen <tjenestenavn>+<teknikk>+ Binding. Hvor <teknikk> er som i punktet for porttype. BKWSN-11 Navngiving av SOAP-action En BKWSDL SKAL navngi sin SOAP-action etter modellen <namespace>+ / + # +<operasjonsnavn>. BKWSN-12 Navngiving av port En BKWSDL SKAL i sin service, navngi dens port element likt som den porttype tjenesten implementerer, men endelsen skal være Port istedenfor PortType samt at teknikken som benyttes alltid skal inkluderes i navnet. BKXML liste over representasjonstermer Representasjonsterm Beskrivelse Antall Et antall ikke-monetære enheter. Beloep Et antall monetære enheter. Data Binære data representert i base64binary Dato En dato innenfor et bestemt kalenderår, basert på ISO 8601 DatoTid Et bestemt tidspunkt, innenfor en spesifisert dato. Id(entifikator) En string som, innenfor en identifikasjonsramme, brukes til å identifisere og unikt utpeke èn instans av et objekt blant alle objekter innenfor samme ramme. Indikator En liste av nøyaktig to verdier som indikerer en tilstand. For eksempel av/på eller sann/usann. Tilsvarer boolean. Kode En enumerert kode. Maal En nummerisk verdi bestemt ved å måle et objekt. Kan angis sammen med en måleenhet fra UN/ECE Rec. 20. Navn Et ord eller en frase som inneholder den presise betegnelse for en person, et sted, ting eller konsept. Prosent En rate uttrykt som en hundrededel mellom to verdier med samme måleenhet Rate En mengde eller et antall målt i forhold til hverandre, eller en fast eller passende verdi. For eksempel kroner per time, norske kroner per EURO eller kilometer per liter. Referanse En string som brukes til å referere en bestemt objektinstans som er identifisert med en Identifikator. Tekst En generell tekststreng/tekst. Tid Tidspunkt innenfor en ikke-spesifisert dag. Url Internettadresse i form av en korrekt url Side 12 av 95

13 Toppdomener i tjenestekatalogen Område Barnehager og parker Barnevern BK Bedrifter Forurensning og renovasjon Grunnskole Helse Kemneren i Asker og Bærum Kultur, kirke, fritid Natur og idrett Plan og bygningstjenester Pleie og omsorg Sosial og bolig Vann og avløp Vei og trafikk Øvrige tjenester Støttetjenester Domenenavn Barnehage Barnevern BKB Renovasjon Grunnskole Helse Kemner Kultur Idrett Plan PLO Sosial VA Vei Diverse Stoette Side 13 av 95

14 BKXML Navngivings og Design Regler Veiledning Versjon 1.0 Dato: Side 14 av 95

15 Innholdsfortegnelse Innholdsfortegnelse...15 Forord...18 BKXML grunnlaget...18 Denne publikasjon...18 Versjon...18 Målgruppe...18 Forutsetninger...18 Avgrensning...18 Kommentarer...18 Introduksjon...19 Formål...19 BKXML 1.0 Referanser...19 Terminologi og notasjoner...20 Klassifikasjon av regler...20 Regelprefiks verdier...20 InfoStrukturBiblioteket...21 BKXML klasser...21 Bruken av eksempler...22 BKXML regler...23 [BKXML-1] Gjenbruk av eksisterende BKXML elementer og typer...23 [BKXML-2] Gjenbruk av innbygde enkle typer...24 [BKXML-3] Gjenbruk av element fremfor type...24 [BKXML-4] Gjenbruk av seneste skjemaversjon...26 [BKXML-5] Et BKXML skjemas innhold...26 [BKXML-6] Skjemareferanser...28 [BKXML-7] BKXML skjemaer i InfostrukturBibliteket...28 [BKXML-8] Systemuavhengige BKXML skjemaer...28 [BKXML-9] Klare og entydige skjemaer...29 Generelle XML Skjema regler...30 [BKGXS-1] Valg av skjemaspråk...30 [BKGXS-2] Versjon av XML...30 [BKGXS-3] Valg av encoding scheme...30 [BKGXS-4] Tilknytning til namespace...30 [BKGXS-5] Skjemareferanser...30 [BKGXS-6] Bruk av redefine...31 [BKGXS-7] Bruk av notation...31 [BKGXS-8] Bruk av schemalocation...31 Generelle navngivningsregler...31 [BKGNR-1] Unik navngiving...31 [BKGNR-2] Navngivningsmodellen for elementer, attributter og typer...31 [BKGNR-2a] Termen Objekt...32 [BKGNR-2b] Utelatelse av termen Objekt...32 [BKGNR-2c] Termen Egenskap...32 [BKGNR-2d] Termen Representasjon...33 [BKGNR-2e] Synonyme termer...33 [BKGNR-2f] Entallsform av navn...33 [BKGNR-2g] Forkortelser og akronymer...34 [BKGNR-2h] Anvendelse av tegn...34 Språkvalg for et BKXML skjema...35 [BKLNR-1] Bruk av norsk språk...35 Side 15 av 95

16 [BKLNR-2] Språkangivelse med xml:lang...35 [BKLNR-3] Ord- og fagbøker for et språk...35 [BKLNR-4] Bruk av Æ, Ø og Å...35 Navngiving av typer...36 [BKTPN-1] Type suffix...36 [BKTPN-2] Navngiving for simpletype...36 [BKTPN-3] Navn for komplekse typer...36 [BKTPN-4] Navngiving av lister...36 [BKTPN-5] Bruk av UpperCamelCase for typer...37 [BKTPN-6] Systemspesifikke navn for typer...37 Navngiving av elementer...38 [BKELN-1] Sammenheng mellom element- og typenavn...38 [BKELN-2] Bruk av UpperCamelCase for elementer...38 [BKELN-3] Systemspesifikke navn for typer...38 Navngiving av attributter...39 [BKATN-1] Bruk av lowercamelcase for attributter...39 [BKATN-2] Systemspesifikke navn for typer...39 Navngiving av BKXML skjemafiler...40 [BKFNR-1] Navngiving av BKXML skjemafil...40 [BKFNR-2] Bruk av elementnavn i filnavn...40 [BKFNR-3] Bruk av dato i filnavn...40 [BKFNR-4] Bruk av namespace prefiks...40 Generelle regler for typedefinisjoner...41 [BKGTD-1] Sterke datatyper...41 [BKGTD-2] Globale typedefinisjoner...41 [BKGTD-3] Ny definisjon av en eksisterende type...41 [BKGTD-4] Bruk av innebygde XML Schema typer...41 [BKGTD-5] Håndtering av binært innhold...42 [BKGTD-6] Abstrakte typer...42 [BKGTD-7] Begrensning av typeavledninger...42 [BKGTD-8] Bruk av støttetyper...42 [BKGTD-9] Oppbygging av støttetyper...42 Regler for simpletype definisjoner...43 [BKSTD-1] Bruk av list og union...43 [BKSTD-2] Lengden av string...43 [BKSTD-3] Representasjon av kodelister...43 [BKSTD-4] Verdier i kodelister...44 [BKSTD-5] Bruk av whitespace og tilhørende typer...44 Regler for complextype definisjoner...45 [BKCTD-1] Oppbygning av complextype...45 [BKCTD-2] Bruk av all...45 [BKCTD-3] Bruk av hjelpeattributt for choice...45 [BKCTD-4] Bruk av extension...46 [BKCTD-5] Bruk av restriction...46 [BKCTD-6] Bruk av mixed content og empty content...46 [BKCTD-7] Bruk av any...46 Regler for elementdeklarasjoner...47 [BKELD-1] Globale elementdeklarasjoner...47 [BKELD-2] Namespace for elementer...47 [BKELD-3] Bruk av default og fixed for elementer...47 [BKELD-4] Bruk av nillable...47 [BKELD-5] Bruk av substitutiongroup...48 Regler for attributtdeklarasjoner...49 [BKATD-1] Bruk av attributter...49 [BKATD-2] Lokale attributter...49 Side 16 av 95

17 [BKATD-3] Namespace for attributter...49 [BKATD-4] Bruk av default og fixed for attributter...49 Versjoneringsregler...50 [BKVER-1] Versjonering i namespace...50 [BKVER-2] Bruk av dato i namespace...50 [BKVER-3] Opprettelse av ny versjon...50 [BKVER-4] Låsing av BKXML skjema...50 [BKVER-5] Nye skjema i eksisterende namespace...50 [BKVER-4] Bruk av attributten versjon...51 Namespaceregler...52 [BKNMS-1] Navngiving av namespace...52 [BKNMS-1a] Namespace navngiving for bk-inngang...52 [BKNMS-1b] Namespace navngiving for områder...52 [BKNMS-1c] Systemspesifikke navn for namespace...52 [BKNMS-1d] Namespace navngiving for versjon...53 [BKNMS-1e] Namespace navngiving for teknikk...53 Dokumentasjon og metadata...54 Dokumentasjon...54 Side 17 av 95

18 Forord BKXML grunnlaget BKXML grunnlaget består av et antall publikasjoner, som hver avdekker viktige emneområder av BKXML paradigmet. Disse BKXML publikasjoner spiller en informerende og veiledende rolle for alle som har befatning med BKXML paradigmet. De enkelte BKXML publikasjoner fungerer blant annet som referansegrunnlag med både normative og informative definisjoner og retningslinjer for blant annet: Informasjonsarkitekter til datamodellering BKXML skjemautviklere til modellering og utvikling av BKXML skjemaer BKXML saksbehandlere til saksbehandling og godkjenning av BKXML skjemaer i regi av IKT og tilknyttede instanser som f.eks. domenekomiteer underlagt IKT. Denne publikasjon Denne publikasjon BKXML Navngivnings- og Design Regler, forkortet BKXML NDR eller bare BKNDR, definerer de regler som et XML skjema skal overholde for å kunne bli godkjent som et BKXML skjema til bruk i BKXML regi. Godkjente BKXML skjemaer er alltid grunnleggende basert på XML Schema anbefalingen. Denne publikasjon tilhører en serie som omhandler BKXML skjemautvikling og vedlikehold som samlet har til formål å dokumentere alle aspekter av BKXML paradigmet som berører utvikling og vedlikehold av XML skjemaer i BKXML regi. Publikasjoner i denne serie avdekker emner som bl.a.: Definisjoner av sentrale begreber for BKXML skjemaer Regelgrunnlag for utvikling av BKXML skjemaer Vedlikehold og versjonering av BKXML skjemaer Brukerveiledninger for utvikling av BKXML skjemaer Brukerveiledning for utvikling av BKWSDL dokumenter Versjon Denne publikasjon er 1.0 versjon av BKXML NDR. Målgruppe Denne publikasjon henvender seg til de personer, som har til oppgave å utvikle og standardisere datamodeller og grensesnitt mellom informasjonssystemer i Bærum kommune, i form av XML skjemaer. Forutsetninger Denne publikasjon forutsetter et visst kjennskap til IT, herunder XML og især XML Schema anbefalingen fra W3C. Avgrensning Denne publikasjon er ikke tenkt som en lærebok i XML eller i XML skjemadesign, da dette ligger utenfor rammene av formålet med NDR. NDR er primært tenkt som et referanseverk for XML skjemautvikleren, som ønsker å utvikle skjemaer, som kan inngå i den kommunale datamodell, basert på gjenbruk av eksisterende BKXML skjemaer. Kommentarer Kommentarer, spørsmål og forslag til forbedringer bes rettet til spesialkonsulent Øystein Aanrud, epost: Side 18 av 95

19 Introduksjon Formål BKXML NDR er utarbeidet på initiativ fra IKT og BKB Data, hvor den er et viktig instrument i kommunens standardiseringsarbeid. NDR skal brukes til å avgjøre om et XML skjema kan godkjennes som et BKXML skjema. Formålet med denne versjon 1.0 av BKXML NDR er å utarbeide reglene så de er representative og i overensstemmelse med nåtidens krav for utvikling av BKXML skjemaer. Dernest har formålet også vært at NDR som helhet skal fremstår som klar, entydig og brukervennlig for skjemautviklerne, så de er i stand til å skape resultater med en høy kvalitet til nytte for standardisering og datautveksling internt i kommunen og mellom kommunen og eksterne leverandører. Felles regler øker lesbarheten og letter fortolkningen av de data som utveksles, og hjelper til med å sikre verktøystøtte for utviklede skjemaer. Utviklere av BKXML skjemaer vil ved gjenbruk av eksisterende godkjente BKXML skjemaer, og ved overholdelse av NDRs regler, kunne utvikle nye skjemaer som også kan oppnå BKXML godkjennelse og dermed bidra til standardiserings-prosessen. BKXML 1.0 Referanser Alle dokumentene som omhandler BKXML 1.0 og Bærum kommunes navngivnings- og designregler, er laget med utgangspunkt i tilsvarende dokumenter for OIO Navngivnings- og Designregler, utarbeidet av IT- og Telestyrelsen - Ministeriet for Videnskab Teknologi og Udvikling i Danmark. Referanser: IT- og Telestyrelsen - Ministeriet for Videnskab Teknologi og Udvikling Overhold reglerne (NDR) OIOWSDL: 'Kontrakt Først'-udvikling med OIOXML Side 19 av 95

20 Terminologi og notasjoner Klassifikasjon av regler Reglenes viktighet er gradert med inspirasjon fra Internet Engineering Task Force RFC 2119 Key words for use in RFCs to Indicate Requirement Levels 6. Nøkkelordene "SKAL", "SKAL IKKE", "BØR", "BØR IKKE" og "KAN" skal i definisjon av reglene tillegges følgende betydning: SKAL SKAL IKKE BØR BØR IKKE KAN Dette ordet betyr at det definerte er et absolutt krav. Denne frasen betyr at det definerte er fullstendig forbudt. Dette ordet betyr at det definerte er et krav. Kun hvis det finnes tungtveiende grunner (som skal godkjennes som gyldige), hvor de fulle konsekvenser skal være forstått og nøye overveid, kan man se bort fra det definerte. Denne frasen betyr at det definerte forbys. Kun hvis det finnes tungtveiende grunner (som skal godkjennes som gyldige), hvor de fulle konsekvenser skal være forstått og nøye overveid og hvor det som defineres som frarådelig, er akseptabelt eller sågar nyttig, kan man benytte det definerte. Dette ordet betyr at det definerte er valgfritt. Regelprefiks verdier Alle reglene er gruppert og navngitt både med en kode, en tittel og en tekst. Navngiving av kodene er basert på de prefiks som benyttes i de navngivnings- og designregler som er utviklet til Universal Business Language (UBL) 7. Kodene er i tillegg prefikset med BK for å identifisere dem som BKXML regler. Det er også lagt til noen egne regelemner, blant annet for emner relatert til WSDL dokumenter og BKXML spesifikke emner. Regelprefix Regelemne BKATD Attributterklæring BKATN Attributtnavngiving BKCTD Kompleks typedefinisjon BKDOC Skjemadokumentasjon BKELD Elementerklæring BKELN Elementnavngiving BKFNR Filnavngiving BKGNR Generell navngiving BKGTD Generell typedefinisjon BKGXS Generell XML Schema BKLNR Språkrelateret navngiving BKMTA Metadata BKNMS Namespace BKSTD Simpel typedefinisjon BKTPN Typenavngiving BKVER Versjonering BKXML Generell BKXML BKWSR Generell WSDL BKWSN WSDL navngiving BKWSD WSDL dokumentasjon Side 20 av 95

SOSI standard - versjon 4.0 1 Del 1: Regler for navning av geografiske elementer. DEL 1: Regler for navning av geografiske elementer

SOSI standard - versjon 4.0 1 Del 1: Regler for navning av geografiske elementer. DEL 1: Regler for navning av geografiske elementer SOSI standard - versjon 4.0 1 DEL 1: Regler for navning av geografiske elementer SOSI standard - versjon 4.0 2 INNHOLDSFORTEGNELSE DEL 1: Regler for navning av geografiske elementer 1 0 Orientering og

Detaljer

Dokumentasjon av XML strukturer for ByggSøk

Dokumentasjon av XML strukturer for ByggSøk Dokumentasjon av XML strukturer for ByggSøk 28. februar 2003 Per Thomas Jahr Innhold 1 Oversikt over skjemaer...1 2 Valg mellom import og include...2 3 Enkoding...2 4 Navnerom...2 5 Regler for navngiving

Detaljer

Angivelse av EHF profiler og dokumenttyper

Angivelse av EHF profiler og dokumenttyper Angivelse av profiler og dokumenttyper Innholdsfortegnelse Veileder profiler og dokumenttyper 1. Forord... 3 1.1 Formål med dokumentet... 3 1.2 Begrepsdefinisjoner... 4 1.2.1 Dokumenttype... 4 1.2.2 Customization...

Detaljer

Beskrivelse av filformatet for likningsoppgaven pass og stell av barn

Beskrivelse av filformatet for likningsoppgaven pass og stell av barn Beskrivelse av filformatet for likningsoppgaven pass og stell av barn Beskrivelsen gjelder likningsoppgaver fra inntektsåret 2013 med første innsending i 2014. Versjon 1.0 14. desember 2012 1 Innhold 1

Detaljer

Brukerdokumentasjon. Webservices og webklient for kodeverk/ kodeverdi verifisering

Brukerdokumentasjon. Webservices og webklient for kodeverk/ kodeverdi verifisering Brukerdokumentasjon Webservices og webklient for kodeverk/ kodeverdi verifisering Innholdsfortegnelse... 3... 3... 3... 3... 4... 4... 4... 4... 8... 9... 10!... 10 "... 11 # $... 11 1. Om systemet 1.1.

Detaljer

Navngivning av XML elementer

Navngivning av XML elementer Navngivning av XML elementer Versjon 1.0 En anbefaling fra Norsk EDIPRO August 2002 Norsk EDIPRO Tel. 22 12 83 90 Postboks 2526 Soll Fax. 22 12 83 97 0202 Oslo Internet: www.edipro.no Forord Språket XML,

Detaljer

Kodelister. fortjener større oppmerksomhet. Steinar Høseggen, Geomatikk IKT AS

Kodelister. fortjener større oppmerksomhet. Steinar Høseggen, Geomatikk IKT AS Kodelister fortjener større oppmerksomhet Steinar Høseggen, Geomatikk IKT AS Definisjoner Kode (Classifier, Term) = entydig navn på et Konsept som har en form for faglig eller vitenskaplig definisjon Beskrivelse,

Detaljer

NKKN typeforslag versjon 2.0.1. Definisjon av grunntypene

NKKN typeforslag versjon 2.0.1. Definisjon av grunntypene NKKN typeforslag versjon 2.0.1 For å lette innsamling av typedata er det laget en importrutine i NKKN som muliggjør automatisering. Foreløpig kan en kun sende forslag via email, en webservice er planlagt

Detaljer

MPEG-7. Problemstilling:

MPEG-7. Problemstilling: MPEG-7 Knut Holmqvist Problemstilling: Hva tilsvarer fritekstsøk i video- og audiodatabaser? Må kunne Indeksere Spørre Søke Se gjennom Levere Multimedia Informasjon om data Metadata Dublin Core Resource

Detaljer

SOSI Produktspesfikasjon Produktnavn: KYV_Ankringsområder v. 0.9. Produktspesifikasjon: KYV_Ankringsområder

SOSI Produktspesfikasjon Produktnavn: KYV_Ankringsområder v. 0.9. Produktspesifikasjon: KYV_Ankringsområder SOSI Produktspesfikasjon Produktspesifikasjon: KYV_Ankringsområder SOSI Produktspesfikasjon - 1-1 Innledning, historikk og endringslogg 3 1.1 Innledning 3 1.2 Endringslogg 3 2 Definisjoner og forkortelser

Detaljer

Eksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus

Eksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus // class Bygning Oppgave 1 System.out.println( Bolighus ); // class Bolighus Hva blir utskriften fra dette programmet? class Blokk extends Bolighus{ // class Blokk IN105subclassesII-1 Eksekveringsrekkefølgen

Detaljer

Vedlegg til meldinger

Vedlegg til meldinger Elektronisk samhandling Vedlegg til meldinger TEKNISK SPESIFIKASJON VERSJON 2.0 13.5.2011 KITH-rapport 1036 : 2011 KITH-rapport TITTEL Elektronisk samhandling Vedlegg til meldinger Forfatter Espen Stranger

Detaljer

Transaksjonsstandard for virkesomsetningen i Norge. Transportert virke. Versjon 2.0. Desember 2007 SKOG-DATA AS

Transaksjonsstandard for virkesomsetningen i Norge. Transportert virke. Versjon 2.0. Desember 2007 SKOG-DATA AS Transaksjonsstandard for virkesomsetningen i Norge Transportert virke Versjon 2.0 Desember 2007 SKOG-DATA AS Innhold 1 INNLEDNING 3 2 DOKUMENTASJON AV MELDING OM TRANSPORTERT VIRKE 3 2.1 Oversikt 3 2.1.1

Detaljer

23.09.2015. Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert.

23.09.2015. Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert. Grunnkurs i objektorientert programmering Introduksjon til objektorientert programmering INF1000 Høst 2015 Siri Moe Jensen INF1000 - Høst 2015 uke 5 1 Siri Moe Jensen INF1000 - Høst 2015 uke 5 2 Kristen

Detaljer

Forslag til nasjonalt utvekslingsformat for bibliografiske data

Forslag til nasjonalt utvekslingsformat for bibliografiske data Forslag til nasjonalt utvekslingsformat for bibliografiske data Jan Erik Kofoed, BIBSYS Nina Berve, Nasjonalbiblioteket Frank Berg Haugen, nasjonalbiblioteket Versjon 0.4 2009-03-01 1. Mål Finne et utvekslingsformat

Detaljer

Teknologiforum, Clarion hotel, Gardermoen 2015-10-26/27. En introduksjon til SOSI del 1 Regler for UML modellering

Teknologiforum, Clarion hotel, Gardermoen 2015-10-26/27. En introduksjon til SOSI del 1 Regler for UML modellering Teknologiforum, Clarion hotel, Gardermoen 2015-10-26/27 SOSI versjon 5.0 Morten Borrebæk Kartverket En introduksjon til SOSI del 1 Regler for UML modellering (fra forretningsprosesser til tjenestemodeller)

Detaljer

Skatteetaten Drosjesentraler Beskrivelse av filformatet for innsending av opplysninger til Skatteetaten Gjelder fra inntektsåret 2013 Versjon 1.0.

Skatteetaten Drosjesentraler Beskrivelse av filformatet for innsending av opplysninger til Skatteetaten Gjelder fra inntektsåret 2013 Versjon 1.0. Drosjesentraler Beskrivelse av filformatet for innsending av opplysninger til Skatteetaten Gjelder fra inntektsåret 2013 Versjon 1.0.2 15. oktober 2014 1 Innhold 1 Introduksjon... 4 2 Krav til filvedlegg...

Detaljer

Pass og stell av barn

Pass og stell av barn Pass og stell av barn Beskrivelse av filformatet for innsending av opplysninger til Skatteetaten Gjelder fra inntektsåret 2013 Versjon 2.0.2 15. oktober 2014 1 Innhold 1 Introduksjon... 4 2 Krav til filvedlegg...

Detaljer

Beskrivelse av filformatet for opplysninger om "Kjøp fra primærnæring Pelsdyrskinn" til Skatteetaten

Beskrivelse av filformatet for opplysninger om Kjøp fra primærnæring Pelsdyrskinn til Skatteetaten Beskrivelse av filformatet for opplysninger om "Kjøp fra primærnæring Pelsdyrskinn" til Skatteetaten Gjelder fra inntektsåret 2013 med første innsending i 2014. Versjon 2.1 25. november 2013 1 Innhold

Detaljer

1. Lage og vise et enkelt XML-dokument

1. Lage og vise et enkelt XML-dokument Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Lage og vise et enkelt XML-dokument Lene Hoff (revidert av Tore Mallaug) 1.9.2013 Lærestoffet er utviklet for faget XML Teknologi 1. Lage

Detaljer

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

SOSI standard - versjon 4.0 1 Del 1: Introduksjon. DEL 1: Introduksjon

SOSI standard - versjon 4.0 1 Del 1: Introduksjon. DEL 1: Introduksjon SOSI standard - versjon 4.0 1 DEL 1: Introduksjon SOSI standard - versjon 4.0 2 DEL 1: Introduksjon 0 Innledning.....3 1 Endringslogg fra SOSI-versjon 3.4......4 2 Organisering......5 2.1 Målsetting...5

Detaljer

NORSK EDIEL BRUKERVEILEDNING. bruk av SMTP. for. Versjon: 1.0 Revisjon: E Dato: 3. Mars 2008

NORSK EDIEL BRUKERVEILEDNING. bruk av SMTP. for. Versjon: 1.0 Revisjon: E Dato: 3. Mars 2008 NORSK EDIEL BRUKERVEILEDNING for bruk av SMTP Versjon: 1.0 Revisjon: E Dato: 3. Mars 2008 Systemstøtte for Ediel / Norsk Ediel Ekspertgruppe Side: 1 INNHOLDSFORTEGNELSE 1 Bakgrunn... 3 2 Referanser...

Detaljer

Grensesnittene mellom Legemiddelverket og de andre eresept-aktørene

Grensesnittene mellom Legemiddelverket og de andre eresept-aktørene Grensesnittdokumentasjon Grensesnittene mellom Legemiddelverket og de andre eresept-aktørene - Webservice FEST for internett og Norsk Helsenett (NHN) 22.10.2014 Antall sider: 8 2 av 7 Innhold 1 Innledning

Detaljer

1. Mer om oppbyning av XML-dokument

1. Mer om oppbyning av XML-dokument Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Mer om oppbyning av XML-dokument Lene Hoff 2.9.2013 Lærestoffet er utviklet for faget XML Teknologi 1. Mer om oppbyning av XML-dokument Resymé:

Detaljer

Transaksjonsstandard for virkesomsetningen i Norge. Business Acknowledge. Versjon 2.0. Desember 2007 SKOG-DATA AS

Transaksjonsstandard for virkesomsetningen i Norge. Business Acknowledge. Versjon 2.0. Desember 2007 SKOG-DATA AS Transaksjonsstandard for virkesomsetningen i Norge Versjon 2.0 Desember 2007 SKOG-DATA AS Innhold 1 Innledning 3 2 Dokumentasjon av 3 2.1 Oversikt 3 2.1.1 Meldingstyper/funksjoner 3 2.1.2 BusinessAcknowledge

Detaljer

Forespørsel om fastlege Informasjonsmodell og XML meldingsbeskrivelse HIS 1022:2010

Forespørsel om fastlege Informasjonsmodell og XML meldingsbeskrivelse HIS 1022:2010 HIS 1022:2010.. Forespørsel om fastlege Informasjonsmodell og XML meldingsbeskrivelse Versjon 1.6 Opprinnelig dato 1.12.2008 Sist endret 15.02.2012 KITH 21/08:2012 Publikasjonens tittel: Forespørsel om

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

BOKMÅL Side 1 av 7. KONTINUASJONSEKSAMEN I FAG TDT4100 Objektorientert programmering / IT1104 Programmering, videregående kurs

BOKMÅL Side 1 av 7. KONTINUASJONSEKSAMEN I FAG TDT4100 Objektorientert programmering / IT1104 Programmering, videregående kurs BOKMÅL Side 1 av 7 NTNU Norges teknisk-naturvitenskapelige universitet Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap KONTINUASJONSEKSAMEN

Detaljer

Standard for kommunikasjon av EPJ-innhold Informasjonsmodell og XML meldingsbeskrivelse

Standard for kommunikasjon av EPJ-innhold Informasjonsmodell og XML meldingsbeskrivelse HIS 80710:2007 Standard for kommunikasjon av EPJ-innhold Informasjonsmodell og XML meldingsbeskrivelse Publikasjonens tittel: Standard for kommunikasjon av EPJ-innhold. Informasjonsmodell og XML meldingsbeskrivelse

Detaljer

Anbefalinger om videreutvikling av Oppgaveregistret

Anbefalinger om videreutvikling av Oppgaveregistret E L M E R ENKLERE OG MER EFFEKTIV RAPPORTERING Middelthuns gate 27, Postboks 5250 Majorstua, N-0303 Oslo Anbefalinger om videreutvikling av Oppgaveregistret Rapport fra ELMER-prosjektet 24. juli 2001 Et

Detaljer

Veilederdokumentenes forankring

Veilederdokumentenes forankring <UTKAST> Tittel: Utarbeidet av: Søkeord: Opplagstall: Versjon: 0.3 Dato: 29.04.2013 Veilederdokumentenes forankring Norge digitalt Veileder, Web Feature Service, WFS, NSDI, SDI, WMS, Web Map Service, GML,

Detaljer

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering.

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering. Bakgrunn Modellering har lenge vært et kjent begrep innen systemutvikling. På 80-tallet ble metoder som Yourdon/Demarco og Gane&Sarson brukt for å lage dataflyt-diagrammer. Etter hvert ble disse integrert

Detaljer

Skatteetaten Boligsameie Beskrivelse av filformatet for innsending av opplysninger til Skatteetaten Gjelder fra og med innrapportering i januar 2016

Skatteetaten Boligsameie Beskrivelse av filformatet for innsending av opplysninger til Skatteetaten Gjelder fra og med innrapportering i januar 2016 Boligsameie Beskrivelse av filformatet for innsending av opplysninger til Skatteetaten Gjelder fra og med innrapportering i januar 2016 Versjon 2.1 1. september 2015 1 Innhold 1 Introduksjon... 4 1.1 Endringer

Detaljer

Forespørsel og svar om egenandel

Forespørsel og svar om egenandel .. Forespørsel og svar om egenandel Informasjonsmodell og XML meldingsbeskrivelse VERSJON 1.1 Status: Til utprøving 6. oktober 2010 KITH-rapport 1024:2010 Innhold 1 Dokumenthistorie... 3 2 Innledning...

Detaljer

Dokumenter som skal inngå i en melding kan opprettes og signeres uavhengig av hverandre.

Dokumenter som skal inngå i en melding kan opprettes og signeres uavhengig av hverandre. Systembeskrivelse for eksterne aktører Med milepæl 3 gir Kartverket neste innblikk i den kommende løsningen for elektronisk tinglysing. Milepæl 3 gir eksterne aktører mulighet til å få innsikt i grensesnitt

Detaljer

Primus Brukerveiledning for masseimport av bilder. Primus 5.6.5

Primus Brukerveiledning for masseimport av bilder. Primus 5.6.5 Primus Brukerveiledning for masseimport av bilder Primus 5.6.5 Primus Brukerveiledning for masseimport av bilder 2 Innholdsfortegnelse Innholdsfortegnelse... 2 Brukerveiledning for masseimport av bilder

Detaljer

Transaksjonsstandard for virkesomsetningen i Norge. Transportoppdrag. Versjon 2.0. Desember 2007 SKOG-DATA AS

Transaksjonsstandard for virkesomsetningen i Norge. Transportoppdrag. Versjon 2.0. Desember 2007 SKOG-DATA AS Transaksjonsstandard for virkesomsetningen i Norge Versjon 2.0 Desember 2007 SKOG-DATA AS Innhold 1 Innledning 3 2 Dokumentasjon av 3 2.1 Oversikt 3 2.1.1 Meldinger 3 2.1.2 forretningsregler 3 2.1.3 Samhandling

Detaljer

Variabelliste og utkast til informasjonsmodell

Variabelliste og utkast til informasjonsmodell Variabelliste og utkast til informasjonsmodell Dette dokumentet beskriver et utkast til informasjonsmodell for uttrekk av data fra et EPJ-system. Modellen er i stor grad basert på eksisterende EPJ-standarder

Detaljer

NOARK Hva? Fra: Wikipedia, den frie encyklopedi

NOARK Hva? Fra: Wikipedia, den frie encyklopedi NOARK Hva? "NOARK (Norsk Arkivstandard) ble opprinnelig utviklet som en kravspesifikasjon for elektroniske journalsystemer i Statsforvaltningen. Den første versjonen NOARK 1 kom i 1984, med påfølgende

Detaljer

1. Generelt. GSI, import av datafil (spec 1.0) 1.1. Ingen individbasert innsamling. 1.2. Historikk. 1.3. Import 2010-11. 1.4. Importmulighet i GSI

1. Generelt. GSI, import av datafil (spec 1.0) 1.1. Ingen individbasert innsamling. 1.2. Historikk. 1.3. Import 2010-11. 1.4. Importmulighet i GSI 1. Generelt 1.1. Ingen individbasert innsamling Det har noen år vært gjennomført testing av en individbasert innsamling til GSI (Grunnskolens Informasjonssystem). Det foreligger ikke nødvendige godkjenninger

Detaljer

Innrapportering av trekk til NAV

Innrapportering av trekk til NAV .. Innrapportering av trekk til NAV XML meldingsbeskrivelse VERSJON 1.0 7. april 2010 Sist oppdatert: 2. februar 2012 Innhold Innrapportering av trekk til NAV... i XML meldingsbeskrivelse... i 1 Dokumenthistorie...

Detaljer