OIOXML skema regelsamlingen

Transkript

1 OIOXML skema regelsamlingen Navngivnings- og Design Regler (NDR) Høringsversion Høringen forløber fra onsdag den 7. april 2004 indtil til fredag den. 7 maj 2004 kl Høringssvar sendes til XML-komitéens sekretariat enten via adressen <xml@itst.dk> eller med post til "XML-sekretariatet, IT Strategisk kontor, IT- og Telestyrelsen, Holsteinsgade 63, 2100 København Ø. Elektronisk udgave kan findes på IT og Telestyrelsen, april 2004

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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