Det här exemplet är taget från en riktig uppdatering gjord i kontraktet GetUnit. Uppdateringen 2.2 påverkar enbart kontraktet GetUnit men har föregåtts av en tidigare utökning av domänschemat från 2.0 till 2.1 enligt bilden nedan.
Utökning 2.2
Utökningen sker endast i interaktionens scheman eftersom typen UnitType är definierad där men principerna för import och adressering hade varit desamma om det varit i domänschemat.
UnitType utökas i interaktionsschema 2.2
Schemafil: GetUnitResponder_2.2.xsd
GetUnitResponder_2.2_ext.xsd definierar elementet financingOrganization och importeras och används i schemat för interaktionen enligt följande:
EXT-filens namespace “urn:riv:infrastructure:directory:organization:GetUnitResponder:2.2'“ ges alias m1, och med namespace beskrivet tvåställigt, men target namespace för hela schemat sätts enbart på huvudversionen 2. ( Detta görs i schemataggen, alias är schemaavgränsat så det ska inte bli en konflikt med det m1 som definieras i domänschemat ovan)
(OBS! schemafilen nedan är avkortad till att endas innefatta förändrade typer)
Därefter infogas det nya elementet som referens i UnitType som utökas och där används namespace alias (m1) för att klienter med olika versioner ska kunna identifiera de namespace som de känner till (alias används för att öka läsbarheten, det går tekniskt att använda det fullständiga namespacet).
Och de utökade typerna har då heller inte längre ANY attributet.
NOTERA: utöver ovanstående exempel så har domänen gjort ytterligare versionsuppdateringar av GetUnit interaktionen (2.3 och 2.4). Gången kring 2.3 är formellt lite felaktig, eftersom samma attribut utökades två gånger, men det fastställdes aldrig någon version 2.3 och det ska således inte finnas någon konsument eller producent på den version så därför fungerar det rent praktiskt att utöka UnitType två gånger och ändå vara bakåtkompatibel (det korrekta hade varit att 2.3 skulle innefattat all fyra objekten i 2.3 och 2.4)
