Regelsamling for udvikling af XML Schemaer

Transkript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20