Let op: dit verzoek is ook geplaatst in het StUF 2 forum omdat het verzoek voor elke stuf versie geldt.
In de StUF standaard staat dat lege elementen en relaties een noValue attribuut moeten hebben met een reden waarom de waarde leeg is. geenWaarde, waardeOnbekend, etc. Wij werken met DotNet en genereren alle proxyclassen automatisch. Nu worden bij het genereren van de XML op basis van de in code geinstantieerde objecten, alle enkele elementen (naam, identificatie, maar ook relaties, echter niet arrays ofwel: choice-elementen, en maxOccur > 1) die geen waarde hebben (NULL in code) altijd opgenomen in de gegenereerde XML (ondanks dat ze null zijn in code dus), met de attribuut sxi:nil="true". Dit mag niet volgens StUF, want er moet een noValue attribuut worden meegegeven, maar volgens de XSD mag dit wel. Omdat de XSD dit toestaat, wordt het lege element door DotNet op deze manier geserializeerd (standaard gedrag). Het wel-vullen van het noValue attribuut voor het element kan alleen door het element te instantieren maar zorgt er weer voor dat de sxi:nil=true weer niet wordt geserializeerd (het element is immers niet meer null)
Om te zorgen dat het attribuut wordt weergegeven, of dat de elementen helemaal niet worden opgenomen in de XML, moet ik alle gegenereerde classen aanpassen (100.000+ regels code) wat een op StUF gebaseerde koppeling ineens een heleboel werk maakt als je in DotNet werkt. Het zou heel erg fijn zijn om de StUF standaard de verplichting van de noValue attribuut niet te hebben als er een defaultValue mogelijk is.
Aangezien Pink niet van de StUF standaard wil afwijken is de gewenste aanpassing in de StUF standaard tekst als volgt m.b.t. lege elementen:
- Er hoeft in geval van lege elementen geen noValue attribuut worden meegegeven indien met de applicatie leverancier een standaardwaarde is afgesproken.
Als StUF dit niet meer verplicht stelt, doet Pink dit ook niet, en is communiceren via StUF ten eerste: weer wat flexibeler geworden (alleen toevoeging in de documentatie) zonder bestaande functionaliteit te wijzigen (het wel meesturen van de noValue attribuut kan immers nog steeds) en ten tweede: een heel wat minder grote investering voor alle DotNet ontwikkelaars.
Het niet meer verplicht stellen van het novalue attribuut bij lege waarden lijkt mij een behoorlijke stap terug in het standaardiseren van gegevensuitwisseling. Dan krijgen we weer een wirwar van bilaterale afspraken over de interpretatie van lege waarden (geenWaarde, waardeOnbekend, etc.). Het is juist één van de meerwaarden van StUF dat hier eenduidigheid biedt.
Het is natuurlijk wel jammer dat jouw generatie-tool daar problemen mee heeft. Centric gebruikt volgens mij al enige tijd DotNet technologie en van hun heb ik nog geen klachten vernomen. Wellicht maken zij geen gebruik van generatietools of hebben zij extra software ontwikkeld om de onvolkomenheden. Ik zal het hun vragen en het naar je terugkoppelen.
Niet alle StUF-koppelvlakken zijn geschikt voor codegeneratie. Vaak is codegeneratie leuk voor snelle prototyping maar niet de eindoplossing voor een robuuste en flexible koppeling
Heb nog even zoals beloofd contact opgenomen met Centric. Zij onderkennen de problemen die jullie signaleren. Ze hebben daar tot nu toe (met de nodige moeite) omheen kunnen werken.
Volgens Centric zijn er zelfs meer problemen: bij het ontvangen van elementen waarvan het attribuut xsi:nil de waarde true heeft, standaard alle overige attributen (o.a. het noValue attribuut) verloren gaan. Dit probleem is er al sinds StUF2.
Ze hebben dat opgelost door op uitgaande berichten een transformatie toe te passen. Inkomende berichten krijgen een omgekeerde transformatie. Het xsi:nil attribuut wordt daarbij toegevoegd of verwijderd waardoor de code wel toegang heeft tot extra attributen. Deze work-around is grotendeels zelf ontwikkeld en passen ze nu toe sinds StUF2.
Verder laat Centric elementen die er niet zijn weg door extra code toe te voegen met een zelf ontwikkelde generator.
Nog een ander probleem volgens Centric is het verschijnsel dat de standaard generatoren van .Net niet correct omgaan met de restriction constructie die in StUF3 veel gebruikt wordt. Er wordt dan code gegenereerd, die bij toepassing foutieve XML berichten aanmaakt. Het probleem van de restrictions is opgelost met een zelf ontwikkeld tool dat restrictions omzet in equivalente constructies die wel correct door de generatoren van .Net behandeld worden.
Wij gebruiken JaxWS en WSConsume om code te generen op basis van een XSD en StUFKletser om via een API een bericht samen te stellen. In beide gevallen hebben wij geen problemen ondervonden met het xsi:nil attribuut of het Stuf:noValue attribuut.
Ik stel dus voor dat .NET problemen opgelost worden binnen .NET of door de software leverancier die .NET gebruikt.
Los daarvan lijkt het invoeren van bilaterale afspraken een veel te grote stap terug.