De redenatie achter deze verandering is als volgt:
Ambiguiteit verminderen. In documentatie kan het mogelijk verwarring schelen als je element namen (bijv. motie) makkelijk kunt onderscheiden van complex types/gegevens die onder een element moeten komen (bijv. motieGegevens). Als alle complexTypes telkens dezelfde uitgang hebben - ...Gegevens, in dit geval - is het voor lezers meteen helder wat er bedoeld wordt.
Het voelt uberhaupt goed om dingen met andere rollen andere namen te geven.
Ik heb ook de naam van wat kindjes van natuurlijkPersoon veranderd. nevenfunctieNatuurlijkPersoonGegevens vond ik iets te lang, en kijkend naar het informatiemodel plaatje zou de naam van die tag sowieso nevenfunctie ipv nevenfunctieNatuurlijkPersoon moeten zijn.
Na deze verandering heb je wel twee subelementen met precies dezelfde naam (namelijk naam onder natuurlijkPersoon en naam onder vergadering), maar ik denk niet dat dat super veel verwarring gaat opleveren.
Overigens is deze "naming convention" compleet van MDTO afgekeken.
De redenatie achter deze verandering is als volgt:
motie
) makkelijk kunt onderscheiden van complex types/gegevens die onder een element moeten komen (bijv.motieGegevens
). Als alle complexTypes telkens dezelfde uitgang hebben -...Gegevens
, in dit geval - is het voor lezers meteen helder wat er bedoeld wordt.Ik heb ook de naam van wat kindjes van
natuurlijkPersoon
veranderd.nevenfunctieNatuurlijkPersoonGegevens
vond ik iets te lang, en kijkend naar het informatiemodel plaatje zou de naam van die tag sowiesonevenfunctie
ipvnevenfunctieNatuurlijkPersoon
moeten zijn.Na deze verandering heb je wel twee subelementen met precies dezelfde naam (namelijk
naam
ondernatuurlijkPersoon
ennaam
ondervergadering
), maar ik denk niet dat dat super veel verwarring gaat opleveren.Overigens is deze "naming convention" compleet van MDTO afgekeken.
Sluit #38.