RIV Tekniska Anvisningar |
DomänschemaVersion 2.1. |
8 ARK_0006 |
2024- |
09- |
18 |
...
Innehållsförteckning
Innehållsförteckning |
---|
...
|
Versionshistorik | |||
Utgåva | Revision Datum | Beskrivning | Ändringarna gjorda |
av |
PA1
2011-06-27
Dokumentet skapat
A | 2011-10-19 | Fastställd revision |
Arkitekturledningens tekniska expertgrupp, Center för eHälsa i samverkan
PB1
B
2012-01-03
Fastställd revision
Marcus Krantz | ||
B | 2012-01-03 | Fastställd revision Uppdaterat dokumentet i och med byte av projektplats från Osor till Google code. Enbart ändringar under rubriken Referenser. |
hans.thunberg@callistaenterprise.se
Hans Thunberg | ||
C | 2013-06-19 | Ny revision efter CeHis nya processer |
Arkitektur och regelverk, Center för eHälsa i samverkan | |||
2.1.1 | 2014-08-20 | Förtydligat regel #6 och flyttat XML-exempel till bilagor. | Mattias Nordvall |
2.1.1 | 2014-09-26 | Lagt över i Inera mall och publiserat. | Lennart Eriksson |
2.1.2 | 2015-12-17 | Uppdaterat länkar i referenstabell | Mattias Nordvall |
2.1.3 | 2018-05-08 | Lagt till att även domänprefix kan ha olika värden, var förut hårt satt till "riv:" Förtydligat namnsättningsregler och struktur för domän resp interaktionsnivå Ändrat regel #4 från bör till skall | Björn Hedman |
2.1.4 | 2019-11-20 | Förtydligat att domänprefix används för att signalera ansvarig domän men att ägandeskapet av en domän kan ändras utan att domänens namnrymd ändras. | Björn Hedman |
2.1.5 | 2019-12-20 | Förtydligat hur hantering av minor uppdateringar ska ske regel 2, namsättning fil ändrat kapitel med exempel till att hänsvisa till bilagor Ändrat felaktig benämning i regel 6 (bytt tjänsteschema till domänschema) | Björn Hedan |
2.1.6 | 2020-09-24 | Generaliserat ”Notera”-information från ”det kan dock finnas domäner som har en extern ägare som ändå har riv som prefix” till ”det kan dock finnas domäner som har en annan ägare än det som angetts i prefixet” eftersom det även kan finnas fall där externa domäner som inte har riv som prefix ägs av Inera |
...
. Förtydligat att ANY-elementet kan bytas ut mot enbart ett element, rättat domän-prefix och små punkterings och skrivfel. Lagt till beskrivning för hur versionsförändring ska ske när komplexa typer, som definierats i domänschemat, ska ändras. | Ranjdar Fallyih Thomas Siltberg Claudia Ehrentraut | ||
2.1.7 | 2021-09-09 | Obsoleta mailadresser borttagna ur revisionshistoriken. Ersatta med namn | Anders Malmros |
2.1.8 | 2024-09-18 | Förbättrat läsbarhet genom bättre formatering och referenser i löptext | Björn Hedman |
1. Inledning
Detta dokument beskriver regelverket RIV Tekniska Anvisningar Domänschema 2.1.
...
1.1 1 Målgrupp
Denna anvisning riktar sig till dem som ska specificera XML-scheman för tjänstekontrakt i en nationell tjänstedomän. Anvisningen innehåller endast regeluppsättningen. För bakgrund, motiv, krav samt de principer som ligger till grund för framtagning av reglerna hänvisas till Översikt RIV Tekniska Anvisningar [R2].- Översikt 2.0
1.2 2 Syfte
Syftet med denna anvisning är att beskriva designregler och namngivningsregler för de meddelandetyper som skall användas inom en tjänstedomän.
1.3 3 Tillgänglighet
Detta dokument är publicerade publicerat under licensen Creative Commons CC-BY-SA (http://creativecommons.org/licenses/by-sa/2.5/se/ ).
Det betyder att du fritt får kopiera, distribuera och skapa bearbetningar av anvisningarna , under förutsättning att upphovsmannen ( Sveriges Kommuner och Landsting) Regioner anges (, men inte på ett sätt som antyder att de godkänt eller rekommenderar din användning av verket).
1.4 Referenser
...
Ref
...
Dokument
...
Beskrivning och ev. webbadress
...
Ansvarig
...
[R1]
...
Beskrivning av ”Venetian Blind”
...
.
Webblänk till hemsidan:
http://www.xfront.com/GlobalVersusLocal.html
...
Okänd.
...
[R2]
...
Översikt RIV Tekniska Anvisningar
...
Bakgrund, motiv, krav samt de principer som ligger till grund för utvecklingen av denna anvisning.
http://rivta.se/documents/ARK_0001/
...
Arkitekturledningens tekniska expertgrupp, SKL
...
[R3]
...
W3C-rapport om utökningsbara XML-scheman
...
2
...
http://www.w3.org/2001/tag/doc/versioning-xml
...
W3C
...
[R4]
...
WS-I Basic Profile
”Defines the WS-I Basic Profile 1.1, consisting of a set of non-proprietary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability”
...
.
...
The Web Services Interoperability Organization och ISO
...
Meddelanderegler
Regel #1, designmönster för domänscheman
"Venetian Blind" [R1] skall användas som designmönster för domänscheman.
http://www.xfront.com/GlobalVersusLocal.html
Designmönstret Venetian Blind innebär följande:
Den interna strukturen i ett meddelande byggs upp med hjälp av globalt deklarerade typer. Med ”globalt deklarerade” menas deklarationer som görs direkt under schema-elementet.
Endast rotelementet är deklarerat som ett globalt element. I web-service-fallet innebär det att request- och response-elementen är globalt deklarerade element medan resten är typer.
Anm. I vissa fall kan även andra element än request och response behöva vara globala, t ex används element-referenser till globala element i importerade scheman för att stödja versioneringsstrategin, se nedan.
Motiv: Interoperabilitet, WS-I Basic Profile
Regel #2, namn på xsd-filen
Schema-filen för ett domänschema skall namnges enligt följande regel: ${tjänstedomän}_${m.n}.xsd
Motiv: Att ha med versionsnummer i namnet på källkodsfiler är generellt sett något man försöker undvika då det försvårar användning av versionshanteringsverktyg (t ex Subversion, Microsoft Visual Studio). I fallet med domänschema behöver man dock kunna hantera flera olika versioner samtidigt (i byggsystem mm) och för att underlätta den hanteringen ingår versionsnumret i filnamnet på tjänstekontrakt och tjänstescheman. I normalfallet ersätts filen av den nyare versionen.
Exempel: Första version : itintegration_monitoring_1.0.xsd
Efter minoruppdatering : itintegration_monitoring_1.1.xsd
Regel #3, namn på target namespace
Attributet targetNamespace på schema-elementet skall ha ett värde som definieras av följande regel: urn:${domänPrefix}:${tjänsteDomän}:${majorVersion}
Namngivningsregler för namespace är formulerade enligt följande uppställning:
Tjänstedomänens prefix: ${domänPrefix}, t ex riv eller riv-application
Tjänstedomänens namn: ${tjänsteDomän}, t ex clinicalprocess:activity:request
Domänschemats version: ${majorVersion}, tex 1
Reglerna för namnsättning av domän finns mer utförligt beskrivna i dokumentet för domännamnsättning
Motiv:
Domänprefixet ska avspegla signaler vilken organisation som ansvarar för support och utveckling av respektive domän.
NOTERA: det kan dock finnas domäner som har en annan ägare än det som angetts i prefixet, detta sker i de fall som ägandeskapet ändrats utan att hela domänen ska re-faktureras.
Användningen av major-version i namnrymden är en av att följa fastslagen versioneringsstrategi [R3]. Att ha en unik namnrymd per tjänstekontrakt (tjänsteinteraktion + roll) är en förutsättning för att följa WS-I Basic Profiles [R4] regel om ”operation signature” (http://www.ws-i.org/Profiles/BasicProfile-1.1.html).Det också generellt goda förutsättningar för att implementera generella bryggor och tjänsteväxlar
Exempel:
Nationell domän
urn:riv:itintegration:monitoring:1
Applikationsdomän
urn:riv-application:sob:apps:resident:1
Extern domän
urn:riv-lv.lv.reporting.pharmacovigilance
Regel #4, användning av schema-attributet version
Schema-attributet version skall sättas till "m.n"
Motiv: Då namnrymden inte innehåller minor-version, ger detta en dokumentation som följer intentionen med attributet.
Exempel: <schema ... version="1.0>
Regel #5, användning av any-element för utökningsbarhet
För att uppnå framåtkompatibilitet skall ett xsd:any element läggas in sist i alla komplexa typer som ska kunna utökas, exempel:
Motiv: För att uppnå framåtkompatibilitet måste man "förbereda" sina XML scheman för framtida utökningsbarhet. Detta är en del av den tillämpade strategin för versionering [R3].
Exempel:
Kodblock |
---|
...
<xs:complexType name="SomeType"> |
...
<xs:sequence> |
...
<xs:element name="someElement" type="xsd:string" /> |
...
<xs:element name="someOtherElement" type="xsd:int" /> |
...
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" namespace="##other"/> |
...
</xs:sequence> |
...
</xs:complexType> |
Regel #6, nya element i utökningsschema
För att lägga till nya element och skapa en ny minor-version av ett tjänsteschemadomänschema, skall följande regler följas:
- De
Det nya
elementen läggselementet läggs till i befintligt schema
närmast föreoch ersätter any-elementet i den komplexa typ som ska utökas.
DessaDetta nya element har ingen typ, utan refererar (xsd:ref=”…”) element som är rotelement i en ny schema-fil (utöknings-schema)
Exempel
<xs:element ref="m1:financingOrganization" minOccurs="0" maxOccurs="unbounded" />
För att ändringen ska vara bakåtkompatibel så måste
dedet nya
elementenelementet ha attributet minoccurs=”0”.
Det leder i sin tur att any-elementet måste tas bort.Detta för att uppfylla kravet på Unique Particle Attribution i Xml Schema 1.0. Följden blir att denna komplexa typ inte kan förändras fler gånger på ett bakåtkompatibelt sätt.
- De
Det nya
elementenelementet definieras i en ny schema-fil (utökningsschema) med ett namn som följer följande regel: ${tjänstedomän}_${m.n}_ext.xsd
Utökningsschemat ska ha en targetNamespace enligt följande regel: urn:
riv${domänPrefix} :${tjänsteDomän}:${m.n}
Domänschemat importerar (xsd:import) utöknings-schemat som ges namnrymdsalias enligt följande regel: m${n}
Exempel:
xmlns:m1='urn:riv:infrastructure:directory:organization:GetUnitResponder:2.2'
Domänschemats versionsattribut ändras till den nya minor-versionen.
I nästa major-version av tjänsteschemat flyttas element-deklarationerna in från alla utökningsscheman (det finns ett för varje minor-version som tilkommit sedan förra major-versionen skapades). Dessutom läggs eventuellt borttagna any-element tillbaka, enligt regel #5.
När komplexa typer som definierats i domänschema ska ändras så sker versionsförändringen enligt följande:
Nya (minor) versionen av domänschemat ersätter tidigare fil.
Endast interaktioner som får strukturell påverkan av ändringar i domänschema behöver ändra version.
Med strukturell påverkan menas att interaktionen använder element som förändrats i domänschemat.
Övriga interaktioners schemafiler importerar förvisso nya schemat så det sker en förändring av importen i filen men inte interaktionens struktur och därför ökas inte version i interaktionen eller filnamn.
Tidigare versioner av domänschemat försvinner.
Motiv: Detta förfarande är en konsekvens av vald strategi för versionering [R3]. Se [R2] W3C Extending and Versioning Languages: XML Languages . Se http://rivta.se/documents/ARK_0001/ för ytterligare bakgrund.
Se även bilaga Bilaga 1 och 2 2 för exempel på utökningar.
Regel #7 Nationella tecken
Domänscheman ska inte använda nationella tecken i såväl elementnamn, attributnamn som vid listning av värdemämngder för uppräkningstyper. Följande exempel bör därför undvikas:
Kodblock |
---|
<xs:simpleType name= |
...
”Å”> <xs:annotation> |
...
<xs:documentation>…</xs:documentation> |
...
</xs:annotation> |
...
<xs:restriction base=”xs:string”> |
...
<xs:enumeration value= |
...
”Återställas helt” /> |
...
<xs:enumeration value= |
...
”Återställas delvis” /> |
...
<xs:enumeration value= |
...
”Det går inte att |
...
bedöma” /> |
...
</xs:restriction> |
...
</xs:simpleType> |
Motiv: För att undvika interoperabilitetsproblem bör man ej använda sig av nationella tecken när man definierar typer som kommer att användas i ett tjänstekontrakt. Ofta uppstår annars fel vid kodgenerering från schemat.
3 Bilaga 1: Exempel på bakåtkompatibel utökning
Detta är ett verkligt exempel från CRM-domänen där följande förändringar görs:
- Tre nya icke-obligatoriska element läggs till.
- Any-elementet tas bort (pga Unique Particle Attribution)
Ny minorversion: crm_scheduling_1.1.xsd
...
.
...
<xs:schema xmlns:tns="urn:riv:crm:scheduling:1" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:m1="urn:riv:crm:scheduling:1.1"
targetNamespace="urn:riv:crm:scheduling:1" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.1">
<xs:import namespace="urn:riv:crm:scheduling:1.1" schemaLocation="crm_scheduling_1.1_ext.xsd"/>
<xs:complexType name="SubjectOfCareType">
<xs:sequence>
<xs:element name="phone" type="xs:string" minOccurs="0"/>
<xs:element name="email" type="xs:string" minOccurs="0"/>
<xs:element name="address" type="xs:string" minOccurs="0"/>
<xs:element name="coaddress" type="xs:string" minOccurs="0"/> <xs:element ref="m1:firstName" minOccurs="0"/>
<xs:element ref="m1:middleName" minOccurs="0"/>
<xs:element ref="m1:lastName" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Utökningsschema med element som tillkommit i 1.1: crm_scheduling_1.1_ext.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:tns="urn:riv:crm:scheduling:1.1" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:riv:crm:scheduling:1.1" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.1">
<xs:element name="firstName" type="xs:string"/>
<xs:element name="middleName" type="xs:string"/>
<xs:element name="lastName" type="xs:string"/>
</xs:schema>
Vid nästa major-version görs följande förändringar:
- De tillagda elementen flyttas från utökningsschemat till huvudschemat
- De tillagda elementen kan nu göras obligatoriska
- Any-elementet läggs tillbaka
Ny major-version: crm_scheduling_2.0.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:tns="urn:riv:crm:scheduling:2" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:riv:crm:scheduling:2" elementFormDefault="qualified" attributeFormDefault="unqualified" version="2.0">
<xs:complexType name="SubjectOfCareType">
<xs:sequence>
<xs:element name="phone" type="xs:string" minOccurs="0"/>
<xs:element name="email" type="xs:string" minOccurs="0"/>
<xs:element name="address" type="xs:string" minOccurs="0"/>
<xs:element name="coaddress" type="xs:string" minOccurs="0"/> <xs:element name="firstName" type=”xs:string” minOccurs="1"/>
<xs:element name="middleName" type=”xs:string” minOccurs="0"/>
<xs:element name="lastName" type=”xs:string” minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
4 Bilaga 2: Exempel på icke-bakåtkompatibel utökning
Detta är ett fingerat exempel från CRM-domänen där följande tre nya element läggs till. Utökningen blir icke-bakåtkompatibel eftersom flera av elementen är obligatoriska (minoccurs=”1”). Om åtminstone det sista elementet är obligatoriskt så kan any-elementet behållas för framtida bruk.
Ny minorversion: crm_scheduling_1.1.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:tns="urn:riv:crm:scheduling:1" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:m1="urn:riv:crm:scheduling:1.1" targetNamespace="urn:riv:crm:scheduling:1" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.1">
<xs:import namespace="urn:riv:crm:scheduling:1.1" schemaLocation="crm_scheduling_1.1_ext.xsd"/>
<xs:complexType name="SubjectOfCareType">
<xs:sequence>
<xs:element name="phone" type="xs:string" minOccurs="0"/>
<xs:element name="email" type="xs:string" minOccurs="0"/>
<xs:element name="address" type="xs:string" minOccurs="0"/>
<xs:element name="coaddress" type="xs:string" minOccurs="0"/> <xs:element ref="m1:firstName" minOccurs="1"/>
<xs:element ref="m1:middleName" minOccurs="0"/>
<xs:element ref="m1:lastName" minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Utökningsschema med element som tillkommit i 1.1: crm_scheduling_1.1_ext.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:tns="urn:riv:crm:scheduling:1.1" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:riv:crm:scheduling:1.1" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.1">
<xs:element name="firstName" type="xs:string"/>
<xs:element name="middleName" type="xs:string"/>
<xs:element name="lastName" type="xs:string"/>
</xs:schema>
Vid nästa major-version integreras elementen från mellanliggande utökningsscheman i huvudschemat: crm_scheduling_2.0.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:tns="urn:riv:crm:scheduling:2" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:riv:crm:scheduling:2" elementFormDefault="qualified" attributeFormDefault="unqualified" version="2.0">
<xs:complexType name="SubjectOfCareType">
<xs:sequence>
<xs:element name="phone" type="xs:string" minOccurs="0"/>
<xs:element name="email" type="xs:string" minOccurs="0"/>
<xs:element name="address" type="xs:string" minOccurs="0"/>
<xs:element name="coaddress" type="xs:string" minOccurs="0"/> <xs:element name="firstName" type=”xs:string” minOccurs="1"/>
<xs:element name="middleName" type=”xs:string” minOccurs="0"/>
<xs:element name="lastName" type=”xs:string” minOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
...