Volgens de huidige schema's moet een update van een bestaand document via updateZaakdocument_Di02 een opbouw hebben waar veel onduidelijk in is. Ik heb hieronder een valide bericht gezet, met inline-documentatie wat er allemaal mis aan is:
edit: de xml wordt niet goed getoont en ik plaats dit dan maar als bijlage van onderstaande opmerking.
Nog een edit: ik type allemaal lege regels als opmaak, maar zie hier niets van terug. Met twee browsers niet.
On topic: Ik kan me niet voorstellen dat het zo bedoeld is dat ik het oude en het nieuwe voorkomen moet opnemen in het stuf bericht. Dan zou ik nml ook het oude inhoud-element moeten opnemen. Ik vermoed dat de xsd moet worden aangepast zodat alles netjes wordt en er 1 nieuw voorkomen van het document kan worden verstuurd, analoog aan het toevoegen van een nieuw document. Een workaround is de overbodige elementen te benoemen in documentatie met een afgesproken dummy vulling.
Ik heb het item geregistreerd als [ZDS-43] en de post van Wouter enigszins aangepast qua nieuwe regels. Community functionaliteit: is bekend, wordt aan verbeterde omgeving gewerkt. Tot die moeten we het hiermee doen. Op eoa manier werkt het wel als ik berichten bewerk, dus ik heb het maar even zoals bovenstaand opgelost.
STP (scenario 5) keurt Wouters oplossing (1 object) goed.
Het bericht in de bijlage is in grote lijnen conform de specificaties. Alleen moeten zowel de mutatiesoort als de verwerkingssoort een 'W' bevatten. Het gaat hier immers om een wijziging. De berichtdefinitie zoals die in de specificaties is opgenomen is overeenkomstig hetgeen in paragraaf 7.2.3 van de StUF 0301 specificaties over vrije berichten is opgenomen. Tot zo ver de theorie. Praktisch kleven er inderdaad nogal wat bezwaren aan de manier waarop mutaties moeten worden doorgegeven. Het meest problematisch is dat de complete inhoud van het document twee keer moet worden opgenomen in het bericht. En als het bericht in de geest van StUF wordt verwerkt, dan zou de provider eerst via de CMIS koppeling de bestaande inhoud moeten opvragen en vergelijken met de aangeleverde oude situatie. In de praktijk is dat een overbodige controle als we ervan uitgaan dat de gebruiker het document eerst uitgechecked heeft en in de update de correcte waarde van checkedOutId aanlevert. Dit zou er voor pleiten het uitchecken van documenten verplicht te maken. Daarnaast is het ook zo dat de inhoud van het document volgens de zaak-dms service specificaties verplicht is. Dat betekent dat, ook als de consumer een enkel metagegeven als b.v. de ontvangstdatum zou willen corrigeren, de complete inhoud van het document twee keer in het bericht moet worden opgenomen. Het lijkt me dat we in ieder geval het element inhoud optioneel moeten maken. Daarnaast zou het prettig zijn als we de mogelijkheid hebben van het was/wordt regime af te wijken als het gaat om het wijzigen van de inhoud van documenten. Maar dat laatste is volgens mij in strijd met de StUF specificaties.