Centric wees ons op het volgende punt:
Paragraaf 4.2.3.2 (geefzaakdocumentbewerken). In het antwoordbericht (Du02) zijn een aantal elementen verplicht, maar in het vraagbericht (Di02) is de scope optioneel.
Niet alle elementen onder scope.object in het vraagbericht (Di02) voldoen aan de voorwaarde dat ze leeg moeten zijn en het attribute xsi:null= “true” hebben. zie ook StUF 03.01: in gebruik.
Voor een fundamenteel entiteittype bevat het element in het element één element met een willekeurige naam en met als attribute StUF:entiteittype het fundamentele entiteittype. Dit element bevat dan als elementen de gevraagde gegevens en relaties conform het contentmodel voor het antwoordbericht. Een gegeven wordt gevraagd door het op te nemen als een element met een lege inhoud en het attribute xsi:nil=”true”.
De mening van KING is dat het door Centric aangedragen citaat uit de StUF-standaard betrekking heeft op Vraag-Antwoord berichten en niet op dienstberichten van toepassing is. De vraag aan de werkgroep is wat de beste manier is om dit op te lossen of te verduidelijken. Hierbij zien wij de volgende mogelijkheden, in volgorde van voorkeur (de meest gewenste eerst):
- Niets veranderen (scope blijft optioneel in de vraag, maar in het antwoord zit een verplichte component en de scope hoeft vanuit deze standaard niet verwerkt te kunnen worden. Voordeel hiervan is mogelijk hergebruik van berichten waarin de scope wel relevant is);
- Scope verbieden door aanpassing van het vraagbericht (Di02) (geeft meer duidelijkheid en sluit aan bij het beoogde gebruik van dit dienstbericht);
- Scope verplicht stellen (heeft grotere impact, want vereist meer verwerking bij de ontvanger van het bericht én vereist meer bij het aanmaken van het bericht);
Als de scope in het dienstbericht geen functie heeft dan is het ons inziens zeer gewenst deze uit de berichtdefinitie te verwijderen. Heeft de scope wel een functie, dan moet deze in de specificaties expliciet worden beschreven.
Wat mij betreft blijft de scope optioneel maar bevat het antwoord gewoon altijd de vaste verplichte waarden.
De schema’s zijn afwijkend van de specificaties. In de specificaties wordt niet gesproken over de (optionele) scope. Het StUF Test Platform stuurt wel een scope mee maar deze moet genegeerd worden door de ontvanger.
Om de schema’s in lijn te krijgen met de specificaties zou de scope verwijderd moeten worden.
Verwijderen heeft wel gevolgen en dit bericht wordt hiermee backwards incompatible. Daarom kan deze wijziging niet in tussentijdse patch doorgevoerd kan worden.
De scope in een nieuwe versie uit het bericht te verwijderen. Tot die tijd blijft de scope optioneel en bevat het antwoord de waarden uit de berichtspecificatie.
Dit probleem is nog steeds niet opgelost. Gezien bovenstaande reactie had dat wel moeten gebeuren in versie 1.2.
Het grootste probleem zijn naar mijn idee de scope elementen waarin het attribuut nil="true" ontbreekt. Om het vraagbericht te laten valideren tegen de schema's moeten die elementen een geldige waarde krijgen terwijl de consumer in dat scenario helemaal geen waarden heeft.
De scope weghalen uit het bericht zou een oplossing kunnen zijn, maar dan gaat de volledige RGBZ-ondersteuning verloren. Consumers kunnen dan dus niet meer gegevens opvragen dan de specificaties expliciet voorschrijven.
Wat er eigenlijk niet goed is is dat de scope elementen (met name inhoud) niet meegegaan zijn met de ontwikkelingen in StUF ZKN. Deze wijziging moet alsnog meegenomen worden in de schema's en dan zou het probleem opgelost moeten zijn.
In StUF-ZKN is dit probleem wel aangepakt. Daardoor treedt het probleem niet op in de vraag geefZaakdocumentLezen. De vraag geefZaakdocumentBewerken is een vrij bericht en maakt (ook al in versie 1.1) gebruik van eigen schema's. Bij de aanpassing in StUF-ZKN is verzuimd dit ook aan te passen in deze schema's.
Maar wellicht had dat ook te maken met het voornemen om in de volgende versie de scope helemaal weg te laten.
"In StUF-ZKN is dit probleem wel aangepakt. Daardoor treedt het probleem niet op in de vraag geefZaakdocumentLezen. De vraag geefZaakdocumentBewerken is een vrij bericht en maakt (ook al in versie 1.1) gebruik van eigen schema's. Bij de aanpassing in StUF-ZKN is verzuimd dit ook aan te passen in deze schema's."
Dat is precies wat ik bedoelde met niet meegegaan zijn in de ontwikkelingen van StUF ZKN.
Issue 489494 is hiervan aangemaakt.