Opvragen zaak of document ID

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

7 reacties / 0 nieuw
John Rooijakkers
Opvragen zaak of document ID

Bij het opvragen van een zaak of document ID ontvangen wij onderstaande response:

<zkn:identificatie StUF:exact="true">**key**</zkn:identificatie>

Wij verwachten het attribute exact niet in dit antwoord. Wat zegt het ZS-DMS koppelvlak hierover.

 

 

Michiel Verhoef

Van deze vraag is issue 489933 aangemaakt.

Michiel Verhoef

Hallo John,

Noch de Zaak- Documentservices specificatie noch de StUF standaard zegt hier iets over. Volgens het XSD schema mag dit, zowel voor Zaak- Documentservices als het StUF-ZKN sectormodel.

In welke gevallen krijg je dit antwoord?

John Rooijakkers

We krijgen dit  antwoord bij de koppeling met één specifiek ZSDMS systeem bij het verzoek om een document-ID.

Michiel Verhoef

Dus de vraag gaat niet over het gebruik van wildcards in de waarde van de documentidentificatie maar puur over het attribuut exact? In plaats van de waarde "**key**" staat er dus een documentidentificatie zonder wildcards etc?

Zoals gezegd, technisch en volgens de xsd schema's mag het. Het is misschien een beetje overbodig maar technisch niet fout.

John Rooijakkers

Klopt, het gaat om de aanwezigheid van het attribuut exact:

<zkn:identificatie StUF:exact="true">1234567890</zkn:identificatie>

Wellicht is dit nu schema technisch niet fout, maar wel overbodig en daarmee verwarrend, dus liever verbieden.

Michiel Verhoef

Het attribuut exact is onderdeel van de StUF standaard en wanneer het op deze plek overbodig is, is het op nog veel meer plekken overbodig te noemen.

Als dit op deze plek niet meer toegestaan kan worden moet dat ook en vooral eerst in de StUF onderlaag geregeld worden. Mocht dit je wens zijn verzoek ik je een onderhoudsverzoek bij de StUF expertgroep in te dienen om dit fundamenteel te regelen en niet op één plek in een koppelvlak.