Verplichting sleutelSynchronisatie in SaNNP, SaNPS en SaVES

4 reacties / 0 nieuw
Dorien Hanegraaf
Verplichting sleutelSynchronisatie in SaNNP, SaNPS en SaVES

In complexTypes NNP-Sa01, NPS-Sa01 en VES-Sa01 in woz0312_msg_lv_mutatie.xsd, versie woz0312_20150519, is de sleutelSynchronisatie op twee niveau's verplicht. Op niveau 'object' en op niveau 'isEen'.
Waarom is dit nodig en wordt hier twee keer dezelfde sleutel verwacht?

Maarten van den...

De StUF-standaard beschrijft een generiek mechanisme voor sleutelSynchronisatie in relaties (altijd verplicht, zie paragraaf 5.4.1 ihb de tweede alinea).

Het klopt dat het bij de isEen-relatie met als bijzondere betekenis dat het gaat om een relatie naar een supertype-object deze sleutelSynchronisatie semantisch dubbel op is. De StUF0301-standaard kent deze bijzondere relatie echter niet en schrijft daarom voor dat ook in deze relatie de sleutelSynchronisatie gevuld moet worden. Het lijkt me goed om hieraan vast te houden.

De eis die wordt gesteld is dat sleutelSynchronisatie de relatie uniek identificeert in de context van het synchronisatiebericht en aan deze eis wordt voldaan door in de isEen-relatie voor sleutelSynchronisatie dezelfde waarde te gebruiken als in de parent. De relatie komt per slot van rekening precies één keer voor binnen de parent. Andere waarden zijn ook toegestaan zolang de waarde de relatie maar uniek identificeert.
 

Joris Wit

Ik zie sleutelSynchronisatie inderdaad op twee niveau's bij nnpSa01, maar niet bij npsSa01. Het attribuut moet dus denk ik ook hier worden toegevoegd.

Joris Wit

Het blijkt dat dat het attribuut toch op beide niveau's is toegestaan, het verschil is dat het bij nnpSa01 verplicht is, maar bij npsSa01 optioneel. Voorlopig zou ik dus het attribuut altijd op beide niveau's opnemen (ook als het optioneel is), zodat er geen verschil is tussen beide berichtsoorten.