BKXML NDR. Navngivings- og Design Regler. Versjon 1.0. Dato:

Transkript

1 BÆRUM KOMMUNE BK BEDRIFTER DATA BKXML NDR Navngivings- og Design Regler Versjon 1.0 Dato: Side 1 av 47

2 Innholdsfortegnelse Innholdsfortegnelse... 2 Forord... 5 BKXML grunnlaget... 5 Denne publikasjon... 5 Versjon... 5 Målgruppe... 5 Forutsetninger... 5 Avgrensning... 6 Kommentarer... 6 Introduksjon... 7 Formål...7 Terminologi og notasjoner... 8 Klassifikasjon av regler... 8 Regelprefiks verdier... 8 InfoStrukturBiblioteket... 9 BKXML klasser... 9 Bruken av eksempler BKXML regler [BKXML-1] Gjenbruk av eksisterende BKXML elementer og typer [BKXML-2] Gjenbruk av innbygde enkle typer [BKXML-3] Gjenbruk av element fremfor type [BKXML-4] Gjenbruk av seneste skjemaversjon [BKXML-5] Et BKXML skjemas innhold [BKXML-6] Skjemareferanser [BKXML-7] BKXML skjemaer i InfostrukturBibliteket [BKXML-8] Systemuavhengige BKXML skjemaer [BKXML-9] Klare og entydige skjemaer Generelle XML Skjema regler [BKGXS-1] Valg av skjemaspråk [BKGXS-2] Versjon av XML [BKGXS-3] Valg av encoding scheme [BKGXS-4] Tilknytning til namespace [BKGXS-5] Skjemareferanser [BKGXS-6] Bruk av redefine [BKGXS-7] Bruk av notation [BKGXS-8] Bruk av schemalocation Generelle navngivningsregler [BKGNR-1] Unik navngiving [BKGNR-2] Navngivningsmodellen for elementer, attributter og typer [BKGNR-2a] Termen Objekt [BKGNR-2b] Utelatelse av termen Objekt [BKGNR-2c] Termen Egenskap [BKGNR-2d] Termen Representasjon [BKGNR-2e] Synonyme termer Side 2 av 47

3 [BKGNR-2f] Entallsform av navn [BKGNR-2g] Forkortelser og akronymer [BKGNR-2h] Anvendelse av tegn Språkvalg for et BKXML skjema [BKLNR-1] Bruk av norsk språk [BKLNR-2] Språkangivelse med xml:lang [BKLNR-3] Ord- og fagbøker for et språk [BKLNR-4] Bruk av Æ, Ø og Å Navngiving av typer [BKTPN-1] Type suffix [BKTPN-2] Navngiving for simpletype [BKTPN-3] Navn for komplekse typer [BKTPN-4] Navngiving av lister [BKTPN-5] Bruk av UpperCamelCase for typer [BKTPN-6] Systemspesifikke navn for typer Navngiving av elementer [BKELN-1] Sammenheng mellom element- og typenavn [BKELN-2] Bruk av UpperCamelCase for elementer [BKELN-3] Systemspesifikke navn for typer Navngiving av attributter [BKATN-1] Bruk av lowercamelcase for attributter [BKATN-2] Systemspesifikke navn for typer Navngiving av BKXML skjemafiler [BKFNR-1] Navngiving av BKXML skjemafil [BKFNR-2] Bruk av elementnavn i filnavn [BKFNR-3] Bruk av dato i filnavn [BKFNR-4] Bruk av namespace prefiks Generelle regler for typedefinisjoner [BKGTD-1] Sterke datatyper [BKGTD-2] Globale typedefinisjoner [BKGTD-3] Ny definisjon av en eksisterende type [BKGTD-4] Bruk av innebygde XML Schema typer [BKGTD-5] Håndtering av binært innhold [BKGTD-6] Abstrakte typer [BKGTD-7] Begrensning av typeavledninger [BKGTD-8] Bruk av støttetyper [BKGTD-9] Oppbygging av støttetyper Regler for simpletype definisjoner [BKSTD-1] Bruk av list og union [BKSTD-2] Lengden av string [BKSTD-3] Representasjon av kodelister [BKSTD-4] Verdier i kodelister [BKSTD-5] Bruk av whitespace og tilhørende typer Regler for complextype definisjoner [BKCTD-1] Oppbygning av complextype [BKCTD-2] Bruk av all [BKCTD-3] Bruk av hjelpeattributt for choice [BKCTD-4] Bruk av extension [BKCTD-5] Bruk av restriction Side 3 av 47

4 [BKCTD-6] Bruk av mixed content og empty content [BKCTD-7] Bruk av any Regler for elementdeklarasjoner [BKELD-1] Globale elementdeklarasjoner [BKELD-2] Namespace for elementer [BKELD-3] Bruk av default og fixed for elementer [BKELD-4] Bruk av nillable [BKELD-5] Bruk av substitutiongroup Regler for attributtdeklarasjoner [BKATD-1] Bruk av attributter [BKATD-2] Lokale attributter [BKATD-3] Namespace for attributter [BKATD-4] Bruk av default og fixed for attributter Versjoneringsregler [BKVER-1] Versjonering i namespace [BKVER-2] Bruk av dato i namespace [BKVER-3] Opprettelse av ny versjon [BKVER-4] Låsing av BKXML skjema [BKVER-5] Nye skjema i eksisterende namespace [BKVER-4] Bruk av attributten versjon Namespaceregler [BKNMS-1] Navngiving av namespace [BKNMS-1a] Namespace navngiving for bk-inngang [BKNMS-1b] Namespace navngiving for områder [BKNMS-1c] Systemspesifikke navn for namespace [BKNMS-1d] Namespace navngiving for versjon [BKNMS-1e] Namespace navngiving for teknikk Dokumentasjon og metadata Dokumentasjon Side 4 av 47

5 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. Side 5 av 47

6 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: oystein.aanrud@baerum.kommune.no. Side 6 av 47

7 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 standardiseringsprosessen. Side 7 av 47

8 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 1. 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) 2. 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 BKATD BKATN BKCTD BKDOC BKELD BKELN BKFNR BKGNR BKGTD BKGXS BKLNR BKMTA BKNMS Regelemne Attributterklæring Attributtnavngiving Kompleks typedefinisjon Skjemadokumentasjon Elementerklæring Elementnavngiving Filnavngiving Generell navngiving Generell typedefinisjon Generell XML Schema Språkrelateret navngiving Metadata Namespace Side 8 av 47

9 BKSTD BKTPN BKVER BKXML BKWSR BKWSN BKWSD Simpel typedefinisjon Typenavngiving Versjonering Generell BKXML Generell WSDL WSDL navngiving WSDL dokumentasjon Merk at versjon 1.0 av BKNDR ikke inneholder regler for skjemadokumentasjon eller metadata. Dette vil bli lagt til i senere versjoner. InfoStrukturBiblioteket Etter hvert som XML-skjemaer blir utviklet og godkjente som BKXML-skjemaer vil de bli bli gjort tilgjengelige i Bærum kommunes tjenestebibliotek, InfoStrukturBiblioteket. InfoStrukturBiblioteket er for tiden under utvikling, og inntil videre kan spørsmål om tilgjengelige skjemaer og andre spørsmål relatert til BKXML-skjemaer og godkjenning av disse rettes til IKT avdelingen i Bærum kommune. InfoStrukturBiblioteket vil bli tilgjengelig på iløpet av første halvdel av BKXML klasser Gjennom dette dokumentet vil det innimellom refereres til fire ulike klasser et XML-skjema kan tilhøre. Disse er: Kjerneklassen, som inneholder basale typer (simpletype) som er svært gjenbrukbare og sentrale på tvers av hele den kommunale sektor. Domeneklassen, som inneholder basale og sammensatte elementer og typer som er svært gjenbrukbare innenfor et forretningsområde i den kommunale sektor. Ettersom kjerneklassen kun inneholder basale typer, vil mange av de sammensatte typene definert her også være egnet for gjenbruk på tvers av ulike forretningsområder. BKNDR-klassen, som inneholder alle de BKXML-skjemaene som ikke er inkludert i kjerne- eller domeneklassen. Det stilles imidlertid krav om at alle skjemaene i BKNDR-klassen skal være BKXML-godkjente. Mange av typene og elementene her vil være mer spesialiserte mot spesifikke tjenester, og man kan ikke regne med like stor grad av gjenbrukbarhet. Det er likevel anbefalt at man gjenbruker skjemaer også fra BKNDR-klassen der det er mulig, fremfor å utvikle nye skjemaer med samme funksjonalitet. Adopskjonsklassen, som inneholder skjemaer som ikke er BKNDR-godkjente, men som man likevel må forholde seg til. Dette vil fortrinnsvis være skjemaer som er en del av allerede etablerte standarder (som for eksempel Noark4ws skjemaene). Det skal gode grunner til for å tillate skjemaer i adopsjonsklassen fremfor å utvikle BKNDRgodkjente varianter. Side 9 av 47

10 De tre klassene av BKXML-godkjente skjemaer er inklusive. Det vil si at alle skjemaer som finnes i kjerneklassen, også er en del av domeneklassen. Tilsvarende er alle skjemaene i domeneklassen også inneholdt i BKNDR-klassen. Se figur 1. I dette dokumentet brukes imidlertid begrepene slik at hvis formuleringen Et BKXML skjema tilhørende NDRklassen... benyttes, skal det forstås på den måte at det henvises til et BKXML skjema som kun tilhører NDR-klassen og ikke en av de to gjenbruksklassene, Kjerneklassen eller Domeneklassen. Figur 1 - NDR klassene Ettersom Bærum kommune for tiden er helt i startfasen med å definere BKXML-skjemaer, er de eksisterende skjemaene ikke ennå formelt delt inn i de ulike klassene. Reglene som er beskrevet i dette dokumentet skiller derfor heller ikke på skjemaer fra de ulike klassene Dette arbeidet er imidlertid pågående, og senere versjoner av dette dokumentet vil omhandle mer om dette. Bruken av eksempler Det gjøres oppmerksomt på at de benyttede skjemaeksempler i dette dokumentet kan være oppdiktet, og altså ikke finnes i InfoStrukturBiblioteket. Årsaken til dette er at vi ikke ønsker å benytte mer kompliserte skjemaer i eksemplene enn nødvendig for å påpeke de punktene eksemplene er ment å illustrere. Dette gjelder også når det i eksemplene i dette dokumentet refereres til eksisterende typer og elementer i diverse BKXML skjema. Det menes da at eksemplet refererer til andre skjemadefinisjoner som finnes i samme eller andre eksempler i dette dokumentet. Det refereres IKKE til eksisterende elementer og typer som reelt finnes i InfostrukturBiblioteket. Skulle det være en overlapping mellom eksempelskjemaene i dette kapittel og skjemaer i InfostrukturBiblioteket er det rent tilfeldig. I mange av eksemplene i dette dokumentet vil også filnavn og namespace være forenklet i forhold til de fulstendige reglene i BKNDR. Side 10 av 47

11 Følgende eksempel-skjemaer benyttes i flere av eksemplene i dette dokumentet: FornavnTekst.xsd: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" <element name="fornavntekst" type="string"/> </schema> MellomnavnTekst.xsd: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" <element name="mellomnavntekst" type="string"/> </schema> EtternavnTekst.xsd: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" <element name="etternavntekst" type="string"/> </schema> TelefonIdentifikator.xsd: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" "> <element name="telefonidentifikator" type="xmp:telefonidentifikatortype"/> <simpletype name="telefonidentifikatortype"> <restriction base="string"> <pattern value="(\+)?[0-9]{5,20}" /> </restriction> </simpletype> </schema> Side 11 av 47

12 BKXML regler BKXML reglene omhandler den overordnede bruk av BKXML skjemaer og dekker følgende områder: Gjenbruk av BKXML skjemaer Organisering av BKXML skjemaer [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." Gjenbrukstanken er sentral for BKXML. Av den grunn er de to første reglene (spesielt den første) og selvfølgelig overholdelsen av dem særdeles viktige for å etablere et høyt nivå av skjemagjenbruk. Denne regelen krever at man gjenbruker eksisterende komponenter. Man må med andre ord ikke definere en ny type eller erklære et nytt element, hvis tilsvarende element eller type allerede eksisterer i BKXML og som representerer den samme informasjon. Eksempel: Definér en sammensatt type som representerer en persons fulle navn Første løsning: Uten hensyn til eksisterende komponenter i Kjerne- og Domeneklassen defineres i første omgang den sammensatte type PersonNameType i følgende skjema: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <element name="personnavn" type="xmp:personnavntype"/> <complextype name="personnavntype"> <sequence> <element name="fornavn" type="string"/> <element name="mellomnavn" type="string"/> <element name="etternavn" type="string"/> </sequence> </complextype> </schema> PersonNavnType er en representasjon av en persons fulle navn med lokalt erklærte underelementer til representasjon av fornavn, mellomnavn og etternavn. Dette skjemaet er ikke et BKXML skjema, da [BKXML-1] ikke overholdes. I Kjerneklassen (se Avsnit 1.3.5, Bruken av eksempler ) eksisterer det nemlig 3 skjemaer, som hver definerer kjerneelementer til angivelse av fornavn, mellomnavn og etternavn på en person. Disse kjerneelementer skal ifølge [BKXML-1] gjenbrukes. Andre løsning: Med denne opplysningen kan skjemaet i første løsning rettes til følgende korrekte BKXML skjema, hvor [BKXML-1] er overholdt: Side 12 av 47

13 <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <include schemalocation="fornavntekst.xsd"/> <include schemalocation="mellomnavntekst.xsd"/> <include schemalocation="etternavntekst.xsd"/> <element name="personnavn" type="xmp:personnavntype"/> <complextype name="personnavntype"> <sequence> <element ref="xmp:fornavntekst"/> <element ref="xmp:mellomnavntekst"/> <element ref="xmp:etternavntekst"/> </sequence> </complextype> </schema> En konsekvens av denne tilnærmingen er også at de før fritt valgte elementnavn for fornavn, mellomnavn og etternavn nå er endret til de standardiserte kjerneelementers navn. Dessuten er den sammensatte types underelementer ikke lengre lokalt erklærte, men referanser til globalt erklærte elementer. Dermed er skjemaet heller ikke modstridende med andre regler. [BKXML-2] Gjenbruk av innbygde enkle typer "Et BKXML-skjema SKAL gjenbruke innebygde enkle typer i XML Schema fremfor å definere egne typer til å representere samme informasjon." Denne regel forebygger at man ikke definerer sine egne versjoner av de innbygde simple typer i XML Schema. Det er f.eks. ikke tillatt å definere følgende skjema til representasjon av en dato: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <element name="mindato" type="xmp:datotype"/> <simpletype name="datotype"> <restriction base="string"> <pattern value="[0-9]{8}"/> </restriction> </complextype> </schema> Den innbygde simple type date eksisterer allerede for å representere en dato og skal alltid benyttes. Den korrekte utformning er: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" <element name="mindato" type="date"/> </schema> [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." Side 13 av 47

14 Et skjema vil som oftest inneholde to gjenbrukbare komponenter, som reelt sett er to forskjellige måter å representere den samme informasjon på, nemlig et element og elementets tilsvarende type. Det er imidlertid ikke alltid helt klart, hva man skal velge og det kan være en tendens til at typen blir gjenbrukt mer enn elementet, også selv om det ikke alltid er nødvendig. Følgende regel balanserer denne tendens, så elementet blir gjenbrukt i alle de situasjoner det er mulig. Når et element eller en type gjenbrukes, vil det oftest skje i forbindelse med definisjon av innholdsmodellen for en sammensatt type. Innholdsmodellen for den sammensatte type vil enten referere direkte til det gjenbrukbare element eller indirekte til den gjenbrukbare type (via et til situasjonen erklært element, hvis type nettopp er den gjenbrukbare type). Entydig i den konkrete sammenheng Den kontekst hvor entydighet er relevant kan være på ethvert nivå helt fra det minimale omfang med entydighet i et konkret BKXML-skjema (som vist i eksemplene under) til et større omfang med entydighet på tvers av en hel skjemaavlevering med multiple skjemaer, eller enda helt overordnet for et helt fagområde (domene) som inneholder flere skjemaavleveringer. Det optimale er, hvis man som skjemautvikler kan skape entydighet i så stort et omfang som mulig. I de følgende eksempler illustreres gjenbruk av både element og type med fokus på entydighet i innholdsmodellen. Eksempel: Gjenbruk av Kjerneelement I Kjerneklassen er det definert et Kjerneelement TelefonIdentifikator samt Kjernetypen TelefonIdentifikatorType til representasjon av telefonnumre (se Avsnit 1.3.5, Bruken av eksempler ). Gjenbruk av Kjerneelementet vil se slik ut: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <include schemalocation="telefonidentifikator.xsd"/> <element name="kontaktinformasjonstruktur" type="xmp:kontaktinformasjonstrukturtype"/> <complextype name="kontaktinformasjonstrukturtype"> <sequence>... <element ref="xmp:telefonidentifikator"/>... </sequence> </complextype> </schema> I dette skjemaet skjer gjenbruket med en referanse til det globalt erklærte element TelefonIdentifikator. Eksempel: Gjenbruk av kjernetype Ved gjenbruk av kjernetypen fåes to skjemaer med følgende utseende. Først et nyt skjema med navnet MinTelefonIdentifikator.xsd, som nettopp gjenbruker typen: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" Side 14 av 47

15 xmlns:xmp=" <include schemalocation="telefonidentifikator.xsd"/> <element name="mintelefonidentifikator" type="xmp:telefonidentifikatortype"/> </schema> Det nye element MinTelefonIdentifikator erklæres med gjenbruk av kjernetypen TelefonIdentifikatorType. Dette element får følgende bruk i KontaktInformasjonStrukturType: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <include schemalocation="mintelefonidentifikator.xsd"/> <element name="kontaktinformasjonstruktur" type="xmp:kontaktinformasjonstrukturtype"/> <complextype name="kontaktinformasjonstrukturtype"> <sequence>... <element ref="xmp:mintelefonidentifikator"/>... </sequence> </complextype> </schema> Når skal man gjenbruke elementet fremfor typen? Gjenbruk av et element forutsetter at elementet er entydigt i den gitte sammenheng. Det mest konkrete eksempel på dette er i innholdsmodellen for en sammensatt type. Hvis man i en sammensatt type kun har ett element, som angir et telefonnummer er det opplagt å benytte kjerneelementet TelefonIdentifikator fordi det i denne sammenheng er entydig. Det er jo kun ett telefonnummer. Hvis det derimot er nødvendig med flere telefonnumre i den sammensatte typen, f.eks. hjemme-, mobil- og faxnummer, så er TelefonIdentifikator elementet ikke lengre entydig nok og gjenbruk av typen blir nødvendig. Dette er illustrert i skjemaet under: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <include schemalocation="hjemmetelefonidentifikator.xsd"/> <include schemalocation="mobiltelefonidentifikator.xsd"/> <include schemalocation="faxidentifikator.xsd"/> <element name="kontaktinformasjonstruktur" type="xmp:kontaktinformasjonstrukturtype"/> <complextype name="kontaktinformasjonstrukturtype"> <sequence> <element ref="xmp:hjemmetelefonidentifikator"/> <element ref="xmp:mobiltelefonidentifikator"/> <element ref="xmp:faxidentifikator"/> </sequence> </complextype> </schema> hvor de 3 elementer HjemmeTelefonIdentifikator, MobilTelefonIdentifikator og FaxIdentifikator deklareres i hvert sitt skjema med gjenbruk av den samme kjernetype TelefonIdentifikatorType (som i MinTelefonIdentifikator.xsd vist over). Vi ser at gjenbruk av type, istedenfor element fører til at vi må lage 3 ekstra skjemaer. Ettersom tendensen er at typen blir gjenbrukt langt oftere enn elementet, er følgene dermed et større antall skjemaer enn det som noen gang er nødvendig. Dette balanseres dermed i [BKXML-3] slik at man gjenbruker elementet når man kan, og dermed kun gjenbruker typen når det er nødvendig. Side 15 av 47

16 [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." Denne regel sikrer, at skjemautviklere alltid gjenbruker de nyeste versjoner av et skjema og dermed er oppdatert i forhold til den utvikling av enkelte skjemaer som naturlig må forekomme. [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." Sentralt og viktig for BKXML er å holde tingene så enkle som overhodet mulig for å balansere den uungåelige kompleksitet som naturlig vil oppstå i forbindelse med de mange mulige relasjoner og avhengigheter mellom godkjente BKXML skjemaer. Denne strategi virkeliggjøres ved at et BKXML skjema kun tillates å representere ett informasjonsobjekt eller informasjonsbegrep av gangen. Helt konkret betyr det at et BKXML skjema kun kan inneholde en elementdeklarasjon og eventuelt dets typedefinisjon til representasjon av dette informasjonsobjekt. Bemerk at et BKXML skjema ikke behøver å definerere en type til sin elementerklæring, men like gjerne kan gjenbruke en eksisterende type i et annet skjema. Fordelen ved at skjemaet med en elementdeklarasjon kun dekker over et begrep er at dette begrepet fullstendig kan dokumenteres i BKXML skjemaets metadata (det tilknyttes kun et sett metadata til et BKXML skjema). Hvis et BKXML skjema representerte et større antall informasjonsobjekter, ville det blant annet gjøre dokumentasjonen i metadataene svært kompleks. Denne en-til-en relasjon mellom skjemaets ene elementerklæring og metadata sikrer dels den fulle forståelse av skjemaets innhold og dels bedre søkemuligheter i InfoStrukturBiblioteket. Et BKXML skjema kan utover dets ene elementdeklarasjon og typedefinisjon inneholde et antall enkle typedefinisjoner som fungerer som støttetyper til elementets typedefinisjon, hvis en slik er angitt. Slike støttetyper kan f.eks. være nødvendige ved bruk av lokale attributterklæringer. Følgende eksempel illustrerer bruken av [BKXML-5] hvor utgangspunktet er skjemaet nedenfor, en sammensat type KontaktInformasjonStrukturType som representerer telefonnumre i en kontaktstruktur: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <include schemalocation="telefonidentifikator.xsd"/> <element name="kontaktinformasjonstruktur" type="xmp:kontaktinformasjonstrukturtype"/> <element name="hjemmetelefonidentifikator" type="xmp:telefonidentifikatortype"/> <element name="mobiltelefonidentifikator" type="xmp:telefonidentifikatortype"/> <element name="faxidentifikator" type="xmp:telefonidentifikatortype"/> <complextype name="kontaktinformasjonstrukturtype"> <sequence> Side 16 av 47

17 <element ref="xmp:hjemmetelefonidentifikator"/> <element ref="xmp:mobiltelefonidentifikator"/> <element ref="xmp:faxidentifikator"/> </sequence> </complextype> </schema> Ved bruk av [BKXML-5] endres ovenstående skjema til følgende skjemaer: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <include schemalocation="hjemmetelefonidentifikator.xsd"/> <include schemalocation="mobiltelefonidentifikator.xsd"/> <include schemalocation="faxidentifikator.xsd"/> <element name="kontaktinformasjonstruktur" type="xmp:kontaktinformasjonstrukturtype"/> <complextype name="kontaktinformasjonstrukturtype"> <sequence> <element ref="xmp:hjemmetelefonidentifikator"/> <element ref="xmp:mobiltelefonidentifikator"/> <element ref="xmp:faxidentifikator"/> </sequence> </complextype> </schema> med følgende 3 skjemaer. HjemmeTelefonIdentifikator.xsd <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <include schemalocation="telefonidentifikator.xsd"/> <element name="hjemmetelefonidentifikator" type="xmp:telefonidentifikatortype"/> </schema> MobilTelefonIdentifikator.xsd <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <include schemalocation="telefonidentifikator.xsd"/> <element name="mobiltelefonidentifikator" type="xmp:telefonidentifikatortype"/> </schema> FaxIdentifikator.xsd <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:xmp=" <include schemalocation="telefonidentifikator.xsd"/> <element name="faxidentifikator" type="xmp:telefonidentifikatortype"/> </schema> Side 17 av 47

18 [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 (for eksempel skjemaer som allerede er etablerte som standard)." For å sikre at en skjemaavlevering er konsistent og komplett i seg selv, er det viktig at alle for skjemaavleveringen relevante skjemaer enten inngår i skjemaavleveringen, eller allerede er godkjente BKXML skjemaer tilstede i InfoStrukturBibioteket (dvs. er enten BKNDR- eller Adopsjonsskjemaer). Denne regel forhindrer effektivt referanser til skjemaer, som ikke er under kontroll av BKXML, og man unngår dermed at det oppstår avleveringer med løse ender. [BKXML-7] BKXML skjemaer i InfostrukturBibliteket "Et BKXML skjema SKAL plasseres i InfoStrukturBiblioteket." For å sikre en ensartet tilgang til godkjente BKXML skjemaer og deres metadata skal alle skjemaer gjøres tilgjengelige i InfostrukturBiblioteket. Dermed har alle alltid fri tilgang til BKXML skjemaenes definisjoner, deklarasjoner og databeskrivelser. [BKXML-8] Systemuavhengige BKXML skjemaer "Utformingen av et BKXML-skjema skal ikke være påvirket av struktur eller begrensninger i bakenforliggende fagsystem." BKXML skjemaer skal være systemuavhengige. Desto mindre binding BKXML skjemaer har til enkelte fagsystemer, desto større er muligheten for gjenbruk av disse skjemaene. Kjerne- og Domeneskjemaer er spesielle i den forstand at de skal være generelt gjenbrukbare på tvers av kommunale sektorer. Som sådan skal de utformes uavhengig av eksisterende systemer og begrensninger. Kjerne- og Domeneskjemaer er en del av en ideell fasade, som kan kapsles rundt eksisterende fagsystemer. Et eksempel er registrering av navn for personer av forskellig nasjonalitet. Et eksisterende fagsystem kan være begrenset til støtte av ISO tegnsettet, som inneholder alle vesteuropeiske spesialtegn. Personnavn med spesialtegn, som ikke er støttet av ISO , vil ikke kunne få sitt navn registrert korrekt i et slikt fagsystem. Derfor skal et BKXML skjema til representasjon av navn være uavhengig av ethvert fagsystem og være dekkende for enhver bruk. Eksempelvis kunne typen for et fornavn være definert som: <simpletype name="fornavntekst"> <restriction base="string"> <pattern value="\p{l}*"/> </restriction> </simpletype> Denne type tillater navn uttrykt i alle verdens tegnsett og kan være et eksempel på en Kjernetype, som potentielt kan brukes globalt. De sentrale Kjerne- og Domeneskjemaer utgjør som sagt en ideell datamodell, som i visse tilfeller ikke harmonerer med eksisterende fagsystemer. Eierne av fagsystemet tvinges da til å ta stilling til hvordan den ideelle datamodell konverteres til det eksisterende fagsystem. Side 18 av 47

19 [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." Et BKXML skjema skal kun inneholde de konstruksjoner som er nødvendige for skjemaets funksjon. Skjemakonstruksjoner som hverken bidrar til skjemaets funksjon eller på annen måte øker skjemaets verdi er ikke tillatt. Med andre ord, hvis et skjema kan normaliseres til en enklere form uten at skjemaets representsjonelle verdi forringes, så skal denne enklere utforming velges fremfor enhver annen utforming. Denne regel har som det også er angitt til formål å gjøre BKXML skjemaer lettere å lese og forstå for alle parter. Spesielt med tanke på dem som ikke selv har utviklet skjemaene og som ikke har den innsikt i utformningen som utviklerne naturlig vil ha. Side 19 av 47

20 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." Det er viktig å sikre god verktøystøtte og interoperabilitet ved at alle kommunale systemer bruker samme skjemaspråk. Ellers vil det være en risiko for at syntaksspesifikke definisjoner av felleskomponenter ikke vil kunne gjenbrukes. [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)." Alle BKXML skjemaer skal som utgangspunkt benytte versjon 1.0 av XML. Da det ellers er risiko for manglende verktøystøtte, er det ikke tillatt å bruke den nyere XML versjon 1.1 til BKXML skjemaer. XML versjonen angis i XML erklæringen først i skjemaet: <?xml version="1.0"...?> <schema... >... </schema> [BKGXS-3] Valg av encoding scheme "Et BKXML-skjema SKAL anvende UTF-8 som encoding scheme." Alle BKXML skjemaer skal benytte UTF-8 som encoding scheme. UTF-8 er det transformasjonsformat til Unicode karaktersettet som fyller minst, og velges her på grunn av den brede aksept og bruk i eksisterende XML verktøyer. Merk at ISO Latin 1 (ISO ), som også støtter norske tegn ikke må benyttes. UTF-8 encoding scheme angis i XML erklæringen først i skjemaet: <?xml version="1.0" encoding="utf-8"?> <schema... >... </schema> [BKGXS-4] Tilknytning til namespace "Et BKXML-skjema SKAL tilknyttes et namespace." Namespaces utgjør ryggraden i BKXML versjoneringsstrategi og brukes således både til versjonering av enkelte BKXML skjemaer og til å skille hele skjemaavleveringer fra hverandre i separate domener. Denne bruk av namespace sikrer dels at man tydeliggjør skjemaenes tilknytningsforhold samt sikrer seg mot utilsiktet navnkollisjon. Side 20 av 47

21 Namespace for et skjema angis ved hjelp av targetnamespace attributten i schema rotelementet. [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." Et XML skjema kan referere til andre skjemaer på 3 forskellige måter via konstruksjonene include, import og redefine. Selv om disse 3 konstruksjoner fungerer på forskjellig måte, har de alle overordnet til oppgave å tillate skjemakomponenter definert i andre BKXML skjemaer å inngå i det BKXML skjema som refererer til dem. Bruken av disse konstruksjoner er angitt i denne og følgende regler. Hvis man ønsker å referere til et underskjema med samme namespace som skjemaet man refererer fra skal man alltid benytte include konstruksjonen. Hvis underskjemaet har et annet namespace, kan man kun benytte import konstruksjonen. [BKGXS-6] Bruk av redefine "Et BKXML-skjema SKAL IKKE benytte redefine konstruksjonen." Konstruksjonen redefine inkluderer et underskjema på samme måte som include gjør, men gir også samtidig mulighet for å redefinere en types inholdsmodell i det inkluderte skjemaet uten at typens navn av den grunn endres. Da typens navn ikke endres vil et skjema med en slik redefinert type slå igjennom alle de steder hvor denne type benyttes. Da dette lett kan ha utilsiktede sideeffekter og da entydighet er en særdeles viktig egenskap blandt BKXML skjemaer tillates redefine ikke. BKXML garanterer dermed at en eksisterende type alltid er den samme i alle sammenhenger. [BKGXS-7] Bruk av notation "Et BKXML-skjema SKAL IKKE benytte notation konstruksjonen." Da denne konstruksjon lager applikasjonsspesifikke bindinger til instanser skal den ikke benyttes. Notasjoner er en etterlevning fra DTD'er som er forsøkt tatt med i XML Schema for bakoverkompatibilitet uten egentlig å oppnå det. [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." Denne regel sikrer at InfostrukturBiblioteket kan opprettholde en korrekt avdekning av avhengigheter skjemaer imellom samt at skjemaenes sammenheng og fortsatte gyldighet bevares ved flytting eller kopiering fra InfostrukturBiblioteket til en alternativ plassering (for eksempel en lokal utviklingsplatform). Fordelen ved den absolutte URL er at selv BKXML skjemaer som er lokalisert et annet sted enn i InfostrukturBiblioteket, likevel har korrekte referanser. Side 21 av 47

22 Generelle navngivningsregler [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 BKXML-skjema." Navngiving av elementer og typer under et gitt namespace skal være unik slik at to forskjellige semantiske begreper ikke navngis likt. Dette medfører at man unngår navnekollisjoner, og det forenkler mest mulig gjenbruk. [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." BKXML element-, attributt- og typenavn er bygget opp av en sammensetning av de tre termene Objekt, Egenskap og Representasjon. Denne oppbygning følger de anbefalinger som ebxml har for navngiving, som igjen er basert på på ISO standard "Information technology Spesification and standardization of data elements". Det er meget bred konsensus for denne navngivingskonvensjon internasjonalt. ebxmls bruk er beskrevet i ebxml TR - Naming Convention for Core Components 10 May Version ISO standarden er under videreutvikling og har nå tittelen "Information technology Metadata registries" 4. Tabellen nedenfor viser eksempler på navn med denne navngivingsmodel: Objekt Egenskap Representasjon Elementnavn Bank Konto Identifikator BankKontoIdentifikator Person Foedsel Dato PersonFoedselsDato Skatt Prosent SkatteProsent Mengde Type MengdeType Person Kjoenn Kode PersonKjoennKode Kommunikasjon Modus Kode KommunikasjonModusKode Land Kode LandsKode Valuta Utveksling Rate ValutaUtvekslingsRate Status Beskrivelse Tekst StatusBeskrivelsesTekst Transport Metode Kode TransportMetodeKode Gate Navn GateNavn Foresatt Referanse ForesattReferanse Adresse Type Kode AdresseTypeKode Side 22 av 47

23 [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." Termen Objekt er et eller flere nøkkeleord som beskriver objektet, enheten eller konseptet som det sentrale dataelement eller -type relaterer til. For eksempel Bank, Person, Bygning, Land eller Organisasjon. [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." I de tilfeller, hvor elementet eller typen opptrer i en bestemt sammenheng hvor objektrelasjonen lett kan identifiseres eller i de tilfeller hvor objektet er ukjent kan Objekt termen utelates. I følgende eksempel er det ikke nødvendig å angi Objekt for TelefonNummer elementet, da elementet opptrer i konteksten av Ansatt elementet: <Ansatt> <TelefonNummer> </TelefonNummer> <AvdelingsNavn>BKB Data, System</AvdelingsNavn> </Ansatt> [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." Termen Egenskap er et eller flere kvalifiserende ord, som beskriver en egenskap ved objektet. Hvis det er flere ord skal hver enkelt være av betydning for objektet som blir beskrevet. Eksempler er Konto som i BankKontoIdentifikator, Foedsels som i PersonFoedselsDato eller Utgang som i BygningUtgangAntall. Beskrivelsen kan utelates hvis innholdet i elementet eller typen direkte vedrører objektet og ikke en egenskap ved objektet. [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." Termen Representasjon er et nøkkeleord, som assosierer til en enkel type. Eksempler er Identifikator som i BankKontoIdentifikator, Dato som i PersonFoedselsDato eller Antall som i BygningUtgangAntall. Se følgende tabell for mulige nøkkelord: 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 Side 23 av 47

24 DatoTid Id(entifikator) Indikator Kode Maal Navn Prosent Rate Referanse Tekst Tid Et bestemt tidspunkt, innenfor en spesifisert dato. En string som, innenfor en identifikasjonsramme, brukes til å identifisere og unikt utpeke èn instans av et objekt blant alle objekter innenfor samme ramme. En liste av nøyaktig to verdier som indikerer en tilstand. For eksempel av/på eller sann/usann. Tilsvarer boolean. En enumerert kode. En nummerisk verdi bestemt ved å måle et objekt. Kan angis sammen med en måleenhet fra UN/ECE Rec. 20. Et ord eller en frase som inneholder den presise betegnelse for en person, et sted, ting eller konsept. En rate uttrykt som en hundrededel mellom to verdier med samme måleenhet 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. En streng som brukes til å referere en bestemt objektinstans som er identifisert med en Identifikator. En generell tekststreng/tekst. Tidspunkt innenfor en ikke-spesifisert dag. (*) Representasjonstermene ovenfor er tatt fra ebxml og er stort sett alle identiske med den norske oversettelsen av deres termer. [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." Med denne regel unngås uheldige navneformuleringer, som IdentifikasjonsIdentifikator,som skal endres til bare Identifikator. [BKGNR-2f] Entallsform av navn "Et navn SKAL angis på entallsform, med mindre navneordet er en flertallsform." Navn skal beskrive enkelte elementer. Hvis det er tale om flere forekomster av det samme element skal man følge reglene for lister som er beskrevet senere i dette dokumentet. [BKGNR-2g] Forkortelser og akronymer "Et navn BØR IKKE benytte forkortelser og akronymer, med mindre disse er de vanligst brukte termer." Da forkortelser og akronymer hemmer lesebarheten bør de ikke benyttes. Hvis der er behov for å lage forkortelser bør man benytte eksisterende forkortelser. Hvis det ikke eksisterer en alminnelig brukt forkortelse, finn på én som gir mening og er entydig. Forkortelser skal skrives med store bokstaver. Side 24 av 47

25 [BKGNR-2h] Anvendelse av tegn "Et navn SKAL IKKE inneholde annet enn bokstaver og tall." XML anbefalingen tillater også bruk av underscore _, punktum. og bindestrek -, men da UpperCamelCase er valgt som navnestandard for elementer og typer er det ikke bruk for disse tegn. Side 25 av 47

26 Språkvalg for et BKXML skjema [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." Som generell retningslinje for valg av språk i forbindelse med navngiving av elementer, attributter og typer i BKXML skjemaer skal det benyttes norsk bokmål i all navngiving. [BKLNR-2] Språkangivelse med xml:lang "Et BKXML-skjema SKAL i sitt xml:lang attributt i elementet schema ha verdien NB." Språk i et BKXML skjema skal angis i attributtet xml:lang i henhold til IANA- LANGCODES 5. Det vil si at koden NB skal brukes for norsk bokmål. Koden NO skal unngås da den ikke identifiserer om det er bokmål eller nynorsk det dreier seg om. [BKLNR-3] Ord- og fagbøker for et språk "Navngiving i et BKXML-skjema SKAL skje i henhold til Norsk rettskrivingsordbok eller relevante fagbøker." All navngivning skal gjøres i henhold til regler for syntaks og korrekt stavning, som spesifisert i relevante ord- og 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 Å." På grunn av problemene med manglende verktøystøtte for de norske spesialtegn æ, ø og å må disse spesialtegn ikke benyttes. I stedet for anbefales det å benytte kombinasjonene ae, oe og aa for å representere henholdsvis æ, ø og å. 5 Side 26 av 47

27 Navngiving av typer [BKTPN-1] Type suffix "Et BKXML-skjema SKAL avslutte navnet til en simpletype eller complextype med suffikset Type." Navnene på datatyper skal slutte med tekststrengen Type. Denne endelsen fjernes i det respektive elementnavn. Dette sikrer at man alltid kan se forskjell på typer og elementer. [BKTPN-2] Navngiving for simpletype "Et BKXML-skjema SKAL benytte termen Representasjon for alle sine simpletype." Alle basale typer (simpletype) i et BKXML skjema skal ha en term for Representasjon i navnet og denne termen skal hentes fra tabellen under regel [BKGNR-2d] i dette dokumentet. [BKTPN-3] Navn for komplekse typer "Et BKXML-skjema SKAL i sin Egenskap 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 skal termen Egenskap være Struktur. Termen for Representasjon skal utelates for komplekse typer" Navngivingen for komplekse typer håndteres annerledes enn for simple typer. Verdier for termen Representasjon fra tabellen i avsnitt 4.6 i dette dokumentet, gir i utgangspunktet ikke mening for sammensatte typer og skal derfor utelates. Man regner i BKXML sammenheng med to hovedvarianter av komplekse typer. I det ene tilfellet inneholder den komplekse typen kun ett element, men dette elementet kan gjentas mer enn en gang. Typen regnes da som en liste, og typens Objekt term skal representeres av navnet på det elementet som repeteres i listen, mens typens Egenskap term skal anta verdien Liste. I det andre tilfellet representerer den komplekse typen en sammensatt type eller en struktur som representerer et objekt bestående av flere ulike bestandeler (elementer). I disse tilfellene skal typens Objekt term gis et navn som representerer det sammensatte objektet, mens typens Egenskap term skal anta verdien Struktur. [BKTPN-4] Navngiving av lister "Hvis et element i en BKXML-skjema complextype har minst to forekomster (dvs. en element deklarasjon har maxoccurs større eller lik 2 eller lik unbounded ), så SKAL elementet legges alene inn i en ny complextype med sin Egenskap term lik Liste som beskrevet i foregående punkt." Ofte har man bruk for å representere lister i et XML skjema. Dette gjøres ved å sette attributten maxoccurs til et element større eller lik to, eller lik unbounded. I et XML skjema er det tillatt å representere en forening og dens medlemmer slik: Side 27 av 47

28 <complextype name= ForeningStrukturType> <sequence> <element name= Navn type= xsd:string /> <element name= Medlemmer type= xsd:string minoccurs= 0 maxoccurs= unbounded /> </sequence> </complextype> Denne fremgangsmåten er imidlertid ikke tillatt for et BKXML skjema. For å oppnå en bedre struktur i XML filene skal alle lister defineres eksplisitt på denne måten: <complextype name= ForeningStrukturType > <sequence> <element name= Navn type= xsd:string /> <element name= Medlemmer type= tns:medlemsliste /> </sequence> </complextype> <complextype name= MedlemsListe > <sequence> <element name= Medlem type= xsd:string minoccurs= 0 maxoccurs= unbounded /> <sequence> </complextype> Merk at default verdien for bade maxoccurs og minoccurs er lik 1 hvis man ikke angir dem. [BKTPN-5] Bruk av UpperCamelCase for typer "Et BKXML-skjema SKAL navngi alle sine simpletype og complextype i UpperCamelCase." UpperCamelCase betyr, at navnet skal begynne med en stor bokstav, deretter begynner hvert nytt ord med en stor bokstav. Et eksempel: <element name="bankkontoidentifikator" type="tns:bankkontoidentifikatortype"> [BKTPN-6] Systemspesifikke navn for typer "Et BKXML-skjema SKAL IKKE benytte termer som er system- eller leverandøravhengige i sine typenavn." Formålet med BKXML er å fremme utviklingen av gjenbrukbare grensesnitt og typer. Alle BKXML typer skal derfor gjenspeile forretningens behov og struktur, uten å ta hensyn til underliggende fagsystemer eller deres leverandører. Side 28 av 47