In de huidige StUF-schema's wordt veelvuldig gebruik gemaakt van attributes. Bijvoorbeeld in het volgende bericht worden in het object-element drie attributes gebruikt (StUF:entiteittype="NPS", StUF:verwerkingssoort="T" en StUF:sleutelVerzendend="423456789"):
<BG:object StUF:entiteittype="NPS" StUF:verwerkingssoort="T" StUF:sleutelVerzendend="423456789">
<BG:inp.bsn>123456789</BG:inp.bsn>
<BG:geslachtsnaam>Korver</BG:geslachtsnaam>
<BG:voornamen>Henri Peter</BG:voornamen>
...
</BG:object>
In principe leidt het gebruik van attributes naast elementen tot compacte en leesbare XML-berichten. Echter er zijn helaas ook nadelen die dit voordeel overschaduwen (zie ook het rapport van gemeente Den Haag in samenwerking met SIG):
- codegeneratietools gaan niet altijd even goed om met attributes.
- het restriction mechanisme van XSD gaat op een andere manier om met attributes dan met elementen. Dit leidt tot onnodige complexiteit.
Het voorstel is om voortaan geen attributes meer te gebruiken en ons te beperken tot elementen. Hieronder een voorbeeld van de nieuwe notatie van bovenstaand bericht:
<BG:object>
<StUF:entiteittype>NPS</StUF:entiteittype>
<StUF:verwerkingssoort>T</StUF:verwerkingssoort>
<StUF:sleutelVerzendend>423456789</StUF:sleutelVerzendend>
<BG:inp.bsn>123456789</BG:inp.bsn>
<BG:geslachtsnaam>Korver</BG:geslachtsnaam>
<BG:voornamen>Henri Peter</BG:voornamen>
</BG:object>
Een ander voordeel is dat de XML-schema’s van StUF nu dichter aanschurken tegen JSON, immers JSON kent alleen elementen en geen attributes:
{
"BG:object": {
"StUF:entiteittype": "NPS",
"StUF:verwerkingssoort": "T",
"StUF:sleutelVerzendend": 423456789,
"BG:inp.bsn": 123456789,
"BG:geslachtsnaam": "Korver",
"BG:voornamen": "Henri Peter"
}
}
Dit erratum is opgevoerd in de onderhoudsverzoeken als RFC0415.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Wellicht is het dan wel goed om dit soort (meta) gegevens op te nemen in speciale groepen.
Hoe gaan we overigens om met attributes die gekoppeld zijn aan een element.
Ik denk dan niet alleen aan het attribute voor metagegevens maar ook de noValues attributen.
Mochten we gaan kijken naar de noValue en de onvolledige datums, dan lijkt het mij verstandig dit zsm voor te leggen aan het Federatief overleg GAB (zie ook http://www.noraonline.nl/wiki/Gemeenschappelijke_Afspraken_Berichten). Nu er een voorstel is voor een bredere standaard, zou het jammer zijn eenzijdig wat anders te gaan doen.
Bij nader inzien valt het wellicht wel mee: de voorstellen van GAB zijn niet zo gedetailleerd.
@John: Goed idee om een strikje te leggen (container element) om de metagegevens van een entiteit. Hieronder een voorstel:
<BG:object>
<StUF:entiteit>
<StUF:entiteittype>NPS</StUF:entiteittype>
<StUF:verwerkingssoort>T</StUF:verwerkingssoort>
</StUF:entiteit>
<BG:geslachtsnaam>
<StUF:waarde>Korver</StUF:waarde>
</BG:geslachtsnaam>
<BG:voorvoegselGeslachtsnaam>
<StUF:noValue>geenWaarde</StUF:noValue>
</BG:voorvoegselGeslachtsnaam>
<BG:voornamen>
<StUF:waarde>Henri Peter</StUF:waarde>
</BG:voornamen>
< /BG:object>
In dit voorbeeld zien we ook de nieuwe (element)representatie van het voormalige attribute "noValue". Deze nieuwe representatie van noValue is al uitvoerig beschreven in RFC0413.
@Sid: Zoals je zelf al aangeeft zijn de voorstellen van GAB redelijk abstract. Zover ik het kan overzien zeggen de GAB-voorstellen niets over hoe je noValue of onvolledige datum op XML-niveau vorm geeft. Dat kunnen we dus zelf bepalen. Voor de zekerheid zal ik het morgen nog even aankaarten. Het toeval wil dat er morgen weer een bijeenkomst is van de GABbers ;-)
Tijdens de StUF Expertgroep van 18 november zijn de voordelen en nadelen van het voorstel besproken.
Daarover bestond echter geen consensus. Zo waren niet alle aanwezigen het er over eens dat code-generatie zonder attributes eenvoudiger wordt. Ook was niet iedereen het er over eens dat het toepassen van StUF hierdoor eenvoudiger wordt.
Tijdens de StUF Expertgroep van 16 december 2015 is wederom duidelijk geworden dat niet iedereen een versie zonder attributes een verbetering vindt. In het argument dat een vertaling van een versie zonder attributes naar JSON eenvoudiger is kon eveneens niet iedereen zich vinden.
Er gaat een pilot starten bij gemeente Den Haag waarin (naar verwachting) een vertaling naar JSON wordt uitgewerkt. Het is verstandig om deze af te wachten en te kijken waar tegenaan wordt gelopen. In ieder geval is de StUF Expertgroep van mening dat deze RFC nu nog niet uitgewerkt moet worden
Tijdens de StUF Expertgroep van 16-3-2016 is aangegeven dat we in de schema’s toch nog wat leesbaarheid willen handhaven. Ook in het scenario met betrekking tot de nillables (RFC0413) zit nog steeds een attribute. De StUF Expertgroep heeft de RFC afgekeurd.