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.