Vanaf diverse zijden bereiken mij berichten dat het handig en goed zou zijn als
- in een StUF-bericht te zien zou zijn volgens welke schema versie (Major.Minor.Patch) een bepaald bericht is gemaakt. Dan weet je waar je aan toe bent.
- in een StUF-schema te zien zou zijn om welke versie (Major.Minor.Patch) het gaat.
Wat is jullie visie op de volgende stellingen:
- In een StUF-bericht is softwarematig vast te stellen om welke versie het gaat.
- In een StUF-bericht is via de documentatie (door een mens) vast te stellen om welke versie het gaat.
- In een StUF-schema is softwarematig vast te stellen om welke versie het gaat.
- In een StUF-schema is via de documentatie (door een mens) vast te stellen om welke versie het gaat.
Waarbij ik benieuwd ben naar de voors en tegens, impact (hoeveel werk is het om het door te voeren), invoeringsstrategie.
Ten aanzien van dat laatste punt geeft Robert aan dat hij al enige tijd in het documentatiedeel van de schema's een opmerking plaatst als:
Wijzigingen t.b.v. patch 16 (1-7-2013) vergeleken met versie stuf0301.xsd v031008:
Dit is echter alleen maar gedaan in de schema's die sowieso moesten wijzigen.
In het algemeen heb ik geen probleem met het opnemen van een patch.versienummer in de berichten, mits hieraan maar niet de verplichting voor de ontvangende applicatie voor backwards compatibiliteit wordt gekoppeld. Het ondersteunen van meerdere patch/versienummers kan snel leiden tot onoverkomelijk grote software inspanningen. Gerichte foutmeldingen (bericht bevat versienummer x en ik ondersteun alleen versie y) en vrijheid om meerdere versies te ondersteunen (bericht bevat versienummer x en ik ondersteun alleen versie y tot en met z) lijkt me meer dan voldoende. patch/versienummer opnemen in de XSDs als documentatie element lijkt me geen probleem. Is feitelijk al de gangbare werkwijze.
Stelling 1: Omdat software altijd voor een bepaalde versie wordt ontwikkeld, lijkt het me in principe geen probleem om een versienummer inclusief patch versie in een bericht mee te geven. Het opnemen van een patch-nummer moet niet leiden tot de verplichting om om de zoveel tijd over te gaan naar een versie van de software die een hogere patch-versie ondersteunt, omdat voor heel veel toepassingen het volgen van de patches niet nodig is. Het lijkt me wel goed om vast te houden aan het feit dat een namespace is gekoppeld aan Major.minor. Het patchnummer wordt dus als een separaat element of attribute in het bericht opgenomen. Praktisch gesproken zie ik wel een fors probleem, omdat de huidge StUF03.01 versie hier niet in voorziet. Het lijkt me daarmee iets voor een volgende versie van de standaard om te komen tot een voorschrift om naast de namespace een patchnummer op te nemen in de berichten. Stelling 2: Lijkt me buitengewoon lastig en niet relevant. Stelling 3: Lijkt me niet relevant. Stelling 4: Zo is het nu al geregeld.
eens met de vorige reacties. daarbij nogmaals benadrukken dat downwards compatibility gegarandeerd moet zijn. Het feit dat zender en ontvanger diverse patches voeren, hoeft niet in te houden dat foutmeldingen moeten worden gegeven. Het weergegeven van het patchniveau is wat mij betreft puur indicatief om daarmee een oorzaak voor een probleem sneller te kunnen achterhalen.
Hoe ziet iedereen bovenstaand in relatie tot standaarden die gebruik maken van andere sectormodellen? Dus bijvoorbeeld Documentcreatie: gebruikt StUF-ZKN: Het lijkt me zinvol op te nemen tot welk patch niveau er handmatig bijgewerkt is (dus bijvoorbeeld in de DCR schema's zelf of in een ander bestand uitleg opnemen 'opgesteld icm StUF-ZKN 3.10 patch 20'. Voordeel: partijen die inbouwen, weten dan op welke versie in elk geval is gekeken of het nog werkt. De vraag is: willen we dit in schema's of kan dit in een soort 'readme.txt' in de root van de zip. Dat is aanzienlijk minder intensief te beheren. En welke informatie zouden we daar dan nog meer in willen hebben?
Ad 1. Het zou handig zijn als de versie wordt meegegeven in het stufbericht. Dit zou dan puur informatief moeten zijn, berichten mogen hier niet op worden afgekeurd. Ad 2. Niet duidelijk hoe. Ad 3. Betekent dit dan ook dat het bericht wordt afgekeurd als het niet aan de versie voldoet? Ad 4. In de verschillende schema’s staat al opgenomen, als commentaar, om welke versie het gaat.
Het probleem speelt niet zo zeer op het niveau van major of minor release. Beide zijn af te leiden van de namespace. Die is zowel in het bericht als in de namespace opgenomen. Het probleem zit hem in de patches. In patches mag de namespace niet worden aangepast. Op die manier is het patchnummer dus niet af te leiden. Softwarematig vaststellen welke patch is gebruikt is niet interessant. Tenzij de software daarop moet gaan acteren. Dat zou betekenen dat in de software rekening moet worden gehouden met verschillen in patches en dat is mijns inziens niet in lijn met het idee achter de patches. Het is in ieder geval van belang de namespace niet aan te passen in verband met compatibiliteit van patches. Het zou wel waardevol zijn als in zowel de schema’s als de berichten zichtbaar is welke patch wordt gebruikt. In de schema’s wordt bij het schema element het attribuut version opgenomen. Vroeger stond daar ook het patch level in. Tegenwoordig is dat niet meer consequent in alle schema-bestanden doorgevoerd. Zo is er bv. in patch 19 in het bestand stuf0301.xsd version=”030109” opgenomen. In bestand zkn0310_ent_basis.xsd staat version= "031004" maar in bestand zkn0310_msg_mutatie staat version="031000". In veel gevallen staat er dus het patch level waarin het bestand is gewijzigd en in sommige gevallen is het patch level weggelaten. Ik zou er voor willen pleiten om in alle bestanden in een patch het patch level van die patch op te nemen. Om de mogelijkheid te creëren in berichten op te nemen welke patch is gebruikt, zou een nieuw element in de stuurgegevens kunnen worden opgenomen. Dat lijkt me echter meer iets voor een nieuwe versie van de standaard.
Helemaal eens met Ton, Sid en Erik. Ik zie in elk geval dat er draagvlak is om dit op te nemen.
Voor het toevoegen van patch versienummering in de schema's is al eerder de discussie 'Patch informatie in de StUF XML-Schema's' opgevoerd. Op basis van die discussie is RFC0144 opgevoerd.
Voor het opnemen van patchversies in de berichten is een apart RFC opgevoerd in de onderhoudsverzoeken te weten RFC0345.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 18-2-2015 is gesteld dat je aan de namespace het versienummer al af zou moeten kunnen lezen. Bij gebruik van een standaard EJB zou je moeten kunnen zien tot welk patchnummer een bericht hoort.
Toch wordt het nog steeds als erg handig gezien om deze informatie aan het bericht toe te voegen hoewel er ook is aangegeven dat het implementatie-technisch niet zo handig is. Dat wordt echter weerlegd door op te merken dat er toch al een nieuwe build gemaakt moet worden.
Ook bij supportproblemen zou het handig kunnen zijn. Dit RFC blijft dus op de lijst met mogelijk laaghangend fruit.
Bijgaand (zie bijlage) de uitwerking van RFC0345
Bijlage
Tijdens de StUF Expertgroep van 19 oktober 2016 zijn verschillende voors en tegens de revue gepasseerd.
Uiteindelijk is besloten het RFC (RFC0345) goed te keuren. In de Volgende vergadering zal een uitwerking worden gepresenteerd. Deze uitwerking kun je al terugvinden in de voorgaande post.
Tijdens de StUF Expertgroep van 16 november 2016 is besloten de uitwerking van dit RFC goed te keuren.
De afgelopen weken is het genereren van koppelvlak schema's m.b.v. de tooling (Imvertor) welke is ontwikkeld in het project 'de Nieuwe Aanpak' voor het eerst in de praktijk beproefd voor de LV-BAG.
In de opgeleverde schema's zijn ook de in deze discussie goedgekeurde 'patch' attributes op de berichtelementen geplaatst. 1 voor de StUF namespace en 1 voor de LV-BAG namespace. Bij het genereren van code op basis van de gegenereerde XML-Schema's geeft dit echter problemen omdat de codegeneratoren de verschillende 'patch' attributes niet uit elkaar kan houden. Het betreffende attribute komt tweemaal in de class omdat er geen onderscheid gemaakt wordt m.b.v. de namespace.
Om dit probleem te tackelen zouden we kunnen besluiten de namen van de patch attributes te voorzien van de prefix behorende bij de namespace waar de betreffende 'patch' attributen bij horen. Zo zou je dus de attributes 'stuf:stuf-patch' en 'lvbag:lvbag-patch' krijgen waardoor het codegeneratie probleem wordt opgelost.
Op XSD niveau is er geen issue. De elementen stuf:patch en lvbag:patch zijn qualified en helder te herkennen.
Waar het inderdaad om gaat als deze beide in hetzelfde element worden gebruikt. Oftewel: elementA.patch en elementA.patch, in XML is dit prima te doen, vanwege de namespace. Echter, bij code generatie wordt er een ClassA aangemaakt, met daarin 2x het attribuut patch.
Hier is omheen te werken door eigen attributen te definiëren en een custom mapping toe te passen. Dit heet in XML to Java generatie een xjb binding. Dit werkt alleen niet out of the box en de Java code die hierdoor ontstaat is niet 1 op 1 met de XML.
Liever zien we dus dat als twee elementen met dezelfde naam gebruikt worden binnen hetzelfde element, dat ze dan niet dezelfde name hebben.
Wellicht is er ook een generatie instelling die voorkomt dat dit probleem ontstaat in de gegenereerde classes, maar dan nog zal in het interne model in de software, waarnaartoe de gegenereerde classes gemapped worden, alsnog gekozen moeten worden om het attribuut patch onder te brengen in ofwel twee verschillende classes (wat niet klopt met de XML), ofwel moet de naam hernoemd worden (wat ook niet klopt met de XML).
Gezien iedereen dit issue op een of andere plek op zou moeten lossen, zien we liever een (op papier) naming conventie, om twee elementen binnen hetzelfde element niet dezelfde 'name' te geven in de XSD.
Vandaar het verzoek.
Tijdens de StUF Expertgroep van 19 juli 2017 vroeg Maarten zich af waarom we eigenlijk meerdere ‘patch’ attributen op een bericht nodig zouden hebben. Hij stelde voor om het te houden bij 1 'patch' attribute per bericht. De StUF Expertgroep heeft dat voorstel na enige discussie goedgekeurd. Maarten zal de nieuwe onderlaag daarop aanpassen.
Mark heeft KING naar aanleiding van dit punt gevraagd nog even goed te kijken naar het wel of niet qualified zijn van attributes en elementen in de berichten van de toekomstige koppelvlakken. Hij ging er nl. vanuit dat de namespace waarin een element of attribuut is gedefinieerd niet meer zichtbaar zou zijn.
N.a.v. het verzoek van Mark Paanakker (zie voorgaande reactie) ben ik even in het issue gedoken. Zie het bijgaande document.
Zelf heb ik een voorkeur voor het handhaven van de prefixes maar ik kan me voorstellen dat er argumenten zijn om dat toch niet te doen. Wellicht kan jij Mark zelf even aangeven wat voor jou de argumenten zijn om de prefixes in de berichten juist zoveel mogelijk te vermijden.
Bijlage
Ik heb geen uitgesproken voorkeuren voor wat betreft het wel of niet gebruiken van prefixes. De opmerking tijdens de vorige expertgroep ging eigenlijk over het waanidee dat ik blijkbaar had dat er geen prefixes meer zouden voorkomen in de 3.02. Bij deze heb jij dit ontkracht en sluit ik nu weer aan bij de denkwijze van de StUF standaard.