De toplevel structuur van de berichten is in de huidige versie van StUF (3.01) niet consistent. Niet alleen over de verschillende berichten heen gekeken maar ook binnen berichten zelf. In het path naar de fundamentele entiteit komt vaak het element 'object'voor maar niet altijd. Soms wordt de functie van het bericht genoemd maar vaak ook niet. Zie de tabel hieronder voor een overzicht van de smaken:
| Berichttype
|
Structuur
|
|---|---|
| Vraagbericht | xxLv0x/gelijk /vanaf /totEnMet /scope/object /start/object |
| Antwoordbericht | xxLa0x/antwoord/object |
| Kennisgevingbericht | xxLk0x/object |
| Synchronisatiebericht | xxSa0x/actueel/object xxSh0x/actueel/actueel/object /historie/oudste/object /wijziging/object |
| Synchronisatieverzoekbericht | xxSa0x/object xxSh0x/object |
| Vrije berichten | Di0x/nnnnnn
Di0x/nnnnnn/gelijk |
Ik stel voor om hier meer lijn in aan te brengen.
- Als eerste stel ik voor om in het Antwoordbericht het element 'antwoord' te verwijderen;
- Als tweede stel ik voor om de fundamentele entiteit overal in een 'object' element te plaatsen. Alleen als er binnen een bericht meerdere 'object' elementen kunnen voorkomen en deze verschillende functies hebben wordt het 'object' element voorafgegaan door een of meer elementen waarmee de functie wordt aangeduid.
Dit leidt tot de volgende structuren:
| Berichttype
|
Structuur
|
|---|---|
| Vraagbericht |
xxLv0x/gelijk/object |
| Antwoordbericht | xxLa0x/object |
| Kennisgevingbericht | xxLk0x/huidig/object /oud/object |
| Synchronisatiebericht | xxSa0x/actueel/object* xxSh0x/actueel/object /historie/oudste/object /wijziging/object |
| Synchronisatieverzoekbericht | xxSa0x/gelijk/object xxSh0x/gelijk/object |
| Vrije berichten | Dxxx/entiteit/object** Dxxx/selectie/gelijk /vanaf/object /totEnMet/object /scope/object /start/object Dxxx/antwoord/object Dxxx/update/object |
* Onderzocht moet worden of dit mogelijk is aangezien beide actueel elementen op dit moment eigen stuurgegevens hebben.
** Indien RFC0438 wordt goedgekeurd zou je hier 2 'entiteit' elementen achter elkaar krijgen. Wellicht te overwegen om een van die elementen dan weg te laten.
Minder mooi aan dit voorstel is dat het antwoordbericht nu als enige afwijkt en dus nog steeds inconsistent is. Je zou kunnen overwegen daar 'xxLa0x/resultaat/object' te gebruiken.
Wat de nieuwe structuur van de vrije berichten betreft, hierin is het attribuut ‘functie’ natuurlijk helemaal niet meer nodig.
M.b.t. het 'object' element verwijs ik nog even naar RFC0438, waarin wordt voorgesteld om dat element te hernoemen naar 'entiteit'.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0439.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Ook bij dit voorstel zien wij geen voordelen (welk probleem lossen we op?) maar wel het nadeel dat iedere wijziging de overstap naar een nieuwe versie complexer maakt.
De voorgestelde structuur van vrije berichten lijkt ons in ieder geval onwenselijk, omdat vrije berichten ook echt een andere structuur kunnen hebben dan de hier beschreven structuur gekoppeld aan een Object. In dit voorstel lijkt het erop dat een vrij bericht altijd een soort "aangepaste vraag" is. De vrije berichten die wij hebben kunnen ook heel andere inhoud en dus heel andere structuur hebben.
Wij stellen voor dit voorstel snel weer af te voeren.
Ruud, ik weet dat vrije berichten ook een geheel andere structuur kunnen hebben. Het betreft dan echter alleen een Du02 bericht. Ik ben daarover misschien niet duidelijk maar ik heb niet de intentie om de structuur van een Du02 bericht aan te passen. De Di01, Du01 en Di02 berichten zijn wel onderhevig aan een vastgestelde structuur. Zie daarvoor paragraaf 7.2 van de StUF standaard. In mijn voorstel geef ik daarnaast ook voorbeelden van vrije berichten die geen 'aangepaste vraag' betreffen ('Dxxx/entiteit/object', 'Dxxx/antwoord/object' en 'Dxxx/update/object').
Tijdens de StUF Expertgroep van 15 juni 2016 lopen de reacties uiteen van het helemaal afgevoerd willen zien van deze RFC tot het voorstellen om tot een nog betere structuur te komen.
Annemiek Droogh geeft aan het RFC graag helemaal afgekeurd te zien. Voor Mark Paanakker en Henri Korver hoeft het deel van het voorstel dat gaat over de kennisgevingsberichten niet doorgevoerd te worden. Sid Brouwer ziet op dat punt juist graag de elementstructuur 'oud/object' samengevoegd in 1 element 'oudobject' en 'huidg/object' samengevoegd in het element 'nieuwobject'. Dat laatste betekent overigens wel dat daar waar in de StUF standaard wordt gesproken over 'huidig' i.r.t. de objecten in een kennisgeving dit moet worden vervangen door 'nieuw'. Robert en Sid zijn van mening dat het feit dat de berichten meer zelfbeschrijvend worden een duidelijke verbetering is.
Uiteindelijk is besloten de discussie te voorzien van de voorgestelde aanpassingen en daarna pas te beslissen wat we met het RFC gaan doen.
Bij deze zoals beloofd in de StUF Expertgroep van 15 juni 2016 het aangepaste voorstel waarin ik nu alle wijzigingen t.o.v. de huidige situatie vet heb gemaakt:
xxLv0x/gelijk/object
/vanaf/object
/totEnMet/object
/scope/object
/start/object
/oudObject
xxSh0x/actueel/object
/historie/oudste/object
/wijziging/object
xxSh0x/gelijk/object
Dxxx/selectie/gelijk
/vanaf/object
/totEnMet/object
/scope/object
/start/object
Dxxx/antwoord/object
Dxxx/update/object
* Uitgezonderd het Du02 bericht.
Tijdens de StUF Expertgroep van 21 september 2016 bleek dat de meeste leden niet achter deze wijziging staan. Er is daarom besloten het RFC af te voeren.