Definieer een speciaal element <isEen> tbv subtypering

Maarten,

je voorstel is me niet helemaal duidelijk. Ik heb mijn vragen hieronder even in vet aan jouw post toegevoegd.

================

Definieer een speciaal element <isEen> tbv subtypering

Het extension mechanisme van XML Schema heeft een aantal nadelen voor het in het schema opnemen van subtypering. De belangrijkste nadelen zijn:

De extension blijft in dezelfde namespace en je breidt dus uit in andersmans namespace.
Robert: Kun je iets duidelijker zijn? Waarom is dat een nadeel?

Het attribute StUF:entiteittype kan niet veranderd worden.
Robert: Wat zou je willen veranderen? Het is een attribuut waar een string van maximaal 30 karakters in geplaatst mag worden.

Deze problemen zijn op te lossen door in StUF analoog aan <gerelateerde> binnen een StUF-relatie in een StUF-fundamenteel het gereserveerde element <isEen> te definiëren. Als type krijgt dit element (een restriction van) een basistype dat elders gedefinieerd.

Robert: Wat je dus wil is in het XML Schema een constructie creeren waardoor je in de StUF berichten de volgende structuur kunt aanmaken:

<object entiteittype="...">
  <isEen ...>
    ..... De content bestaand uit een elementstructuur die een restrictie is van een basistype....
  </isEen>
</object>

Ik neem aan dat de restriction in een sectormodel gedefinieerd moet gaan worden zoals bijvoorbeeld dat van onderwijs zoals je hieronder aangeeft. Krijgt het 'isEen' element ook nog het attribuut 'entiteittype'?

Deze constructie maakt expliciet dat het gaat om een subtype van een elders gedefinieerd type en neemt de hierboven genoemde nadelen weg.
Robert: Ik begrijp nog niet waarom je dit zou willen.

Deze constructie kan bijvoorbeeld gebruikt worden om in een sectormodel onderwijs het entiteittype Leerling te definiëren. De relevante gegevens van NPS worden ingebracht door middel van een <isEen> element met als inhoud een restriction op BG:NPS-basis en de extra gegevens en relaties worden hieronder toegevoegd.

Robert: Bedoel je dat je in het 'isEen' element de elementen plaatst die onderdeel zijn van een restriction op NPS-basis en dat je vervolgens na het 'isEen' element nog extra elementen op kunt nemen die specifiek zijn voor een leerling? De structuur wordt in dat geval dus als volgt:

<object entiteittype="...">
  <isEen ...>
    ..... De content bestaand uit een elementstructuur die een restrictie is van BG:NPS-basis ....
  </isEen>
  ... Extra voor Leerling benodigde gegevens ...
</object>

Klopt dat?

Ik neem overigens aan dat je met NPS-basis eigenlijk NPSNINING-basis bedoelt?
Hoe ga je de 'isEen' element definieren? Als een lokaal element dat steeds, afhankelijk van de context, een ander complexType heeft?

Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0112.
De lijst met onderhoudsverzoeken vind je op: 
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Tijdens de StUF Expertgroep van 18 februari 2015 is vastgesteld dat dit issue niet alleen specifiek voor StUF-ZKN geldt maar ook voor de StUF onderlaag. Dit issue moet goed bekeken worden en wellicht kan het al als een erratum worden doorgevoerd. Volgens Maarten vd Broek kan je dit ook als een uitbreiding op de onderlaag doorvoeren.

Tijdens de StUF Expertgroep van 18 maart 2015 is het voorstel goedgekeurd. Dit RFC kan dus mee in de nieuwe versie van de StUF onderlaag.

Bij de uitwerking van dit RFC kwamen we tot de conclusie dat de <isEen>-constructie ook voor interne subtypering gebruikt moet worden, bijvoorbeeld:

NPS <isEen> RPS <isEen> SUB

uitgaande van bg0310 (dus hier nog RPS i.p.v. PES).

In de bijlage is het bestand isEen.zip met voorbeeld schema's toegevoegd.

De map isEen bevat een uitwerking van de isEen-constructie binnen SUB, RPS, NNP, NPS en VES uitgaande van bg0310. Voor het gemak zijn de overige complexTypes niet weggegooid. De extra elementen met zoekcriteria voor SUB zijn gehandhaafd, maar hierover moet nog wel definitief een beslissing genomen worden.

Voor SUB en RPS worden vier of vijf complexTypes gedefinieerd:

• '-basis' met alles erin. Dit complexType bevat een choice om te differentiëren tussen gebruik binnen een isEen element of binnen een gerelateerde-element met de subtypen. Dit complexType bevat alleen het attribute 'StUF:entiteittype' en geen andere attributes, omdat de andere attributes altijd zitten op de parent van een isEen-element c.q. op het subtype dat gerelateerde is. Dit complexType bevat een choice omdat het enerzijds de elementen moet bevatten nodig voor de isEen-constructie en anderzijds de gerelateerde nodig voor het gebruik van het supertype als gerelateerde.
• -isEen-basis' met de basis voor gebruik binnen een isEen-element. Hierbij is StUF:entiteittype prohibited gemaakt.
• 'isEen-kerngegevens'. Dit complexType bevat de kerngegevens bij gebruik binnen een isEen-element (is niet relevant voor bg0310, maar wel voor bg0320 gebaseerd op RSGB3, als daar verblijfsadres/bezoekadres worden opgenomen binnen SUB met één elementnaam.
• '-gerelateerde-basis' met de basis voor gebruik binnen een gerelateerde. Dit complexType bevat uitsluitend de choice tussen de subtypes met een maxOccurs gelijk aan het aantal subtypen, omdat dit nodig is binnen het scope-element van een vraagbericht.
• 'gerelateerde-kerngegevens'. Dit complexType bevat de kerngegevens bij gebruik binnen een gerelateerde. Vanuit het oogpunt van het specificeren van de kerngegevens is dit complexType niet nodig, want het bevat binnen de gerelateerde de '-kerngegevens' complexTypes van de subtypen. Dit complexType is toch opgenomen, omdat je anders de '-kerngegevens' complexTypes met kernrelaties niet kunt definiëren.

Het  resultaat ziet er natuurlijk uit. Het isEen-element is niet als eerste opgenomen, zodat de elementen in een natuurlijke volgorde staan. Als er niet één elementnaam binnen SUB komt voor verblijfs/bezoekadres, dan is de choice tussen verblijfs/bezoekadres en buitenlandsadres niet meer mogelijk.

Tijdens de StUF Expertgroep van 19 oktober 2016 is RFC0112 nogmaals behandelt. Het was al goedgekeurd met de gedachte dat we deze constructie alleen zouden gebruiken bij het hergebruik in een ander sectormodel.
We hadden ons echter niet gerealiseerd dat we deze constructie ook zouden kunnen gebruiken binnen een sectormodel.
De StUF Expertgroep spreekt af dat iedereen binnen 14 dagen aangeeft of ze het eens zijn met de uitwerking.

Wij (Centric) zijn het niet eens met bovenstaande uitwerking. De berichten worden er onnodig complexer door en het resultaat zijn heel vreemde berichten. Vul bijvoorbeeld eens een bericht in met een NPSNINING erin. Dan krijg je zoiets als het volgende:

<persoon>
  <inp.bsn>1234566789</inp.bsn>
  ...
  <isEen>
    <isEen>
      <typering>"Ingeschreven niet-natuurlijk persoon"</typering>
      ...
    </isEen>
    <isEigenaarVan>
      ...
    </isEigenaarVan>
  <isEen>
  ...
</persoon>

De betekenis van de isEen gaat in dit bericht helemaal verloren: een persoon is niet een typering. De zelfbeschrijvende eigenschap van XML gaat dus volledig verloren.

Het oorspronkelijke probleem ging over het 'extenden' van types over namespaces heen. Daarvoor is een dergelijke constructiem mogelijk een oplossing die voorkomt dat elementen moeten worden gekopieerd (hergebruik van types is hierdoor mogelijk). Of je hiervoor de isEen moet gebruiken als standaardnaam, vragen wij ons af.
Daarnaast kan met de huidige insteek dat de berichtdefinities worden gegenereerd uit een model worden gesteld dat het niet zo'n probleem is om de eigenschappen van het supertype te kopieëren naar het subtype. De automaat zorgt er immers voor dat de elementen zonder fouten worden meegenomen.

Daarom is onze conclusie: laten we onszelf nog eens afvragen of het probleem echt nog bestaat en zo ja, beperk de oplossing tot het oorspronkelijke probleem en gebruik het niet ook voor sub-/supertypen binnen eenzelfde sectormodel/namespace.

Deze oplossing leidt naar onze mening naar mooiere schema's, maar veel lelijker berichten. En naar onze mening moet juist het uiteindelijke bericht centraal staan bij het ontwerp.

Hoi Sid, neemt de bovenstaande reactie van Maarten je zorgen weg? Zo nee, kun je dan aangeven waar de andere knelpunten zitten? Zoals je begrijpt wil ik zo snel mogelijk consensus bereiken op dit punt omdat we anders niet verder kunnen met het genereren van de basisschema's en we de planning mogelijk niet gaan halen.

Ik ben bang dat we hierover geen concensus gaan bereiken. Met het attribuut entiteittype wordt het inderdaad wat logischer leesbaar dan zonder het attribuut. Neemt niet weg dat de berichten onnodig extra niveaus krijgen die alleen voor de schema's relevant zijn. De schema's vinden wij echter ondergeschikt aan de berichten.

Hierbij wil ik ook nog eens herhalen dat met het genereren van berichtschema's er veel minder noodzaak is voor een dergelijke structuring van die schema's. In het verleden hielp dat om zaken consistent te houden, maar volgens mij is dat met generatie veel minder noodzakelijk. Laten we dan ook de berichten zo simpel mogelijk houden. Dat maakt de hele standaard uiteindelijk eenvoudiger. In mijn ogen is een kleine prefix bij elementnamen minder belastend dan een (of zelfs meer) extra niveau(s) in de berichten.

Wij vinden het een lelijke oplossing. Bij doorvoeren in alle types is het zelfs een oplossing voor een 'probleem' waarvoor het oorspronkelijk niet eens bedacht is.

Hoi Sid, ik begrijp je punt. Om uit deze impasse te komen is mijn voorstel om dan maar van het hele RFC af te zien. Het lijkt me namelijk niet wenselijk om in de StUF-standaard twee verschillende mechanismes te hanteren voor subtypering: één voor binnen een sectormodel (XSD-extension, of het huidige mechanisme) en één voor buiten het sectormodel (isEen).

Het RFC was primair bedoeld om de standaard fraaier te maken maar het lost geen bestaande problemen op. In de WOZ blijkt de constructie met de isEen-relatie prima te werken. Dus isEen als een zelfstandig gedefinieerde relatie van het (externe)sectormodel en niet als standaardconstructie.

De vraag die nog overblijft is of we binnen een sectormodel subtypering gaan uitvoeren met XSD-extension of het huidige mechanisme (zoals toegepast in bg0310). In het huidige mechanisme worden alle elementen en relaties van het supertype handmatig platgeslagen (gedupliceerd) in de subtypen. Daarbij worden de subtypen met een choice in het supertype opgenomen. Bovendien worden er ook nog een aantal afleidbare gegevens aan het supertype toegevoegd om het supertype geschikt te maken voor bevragingen over subtypen heen.

Mijn voorkeur gaat uit naar de eerste optie (XSD-extension) om de volgende redenen:

• Compactere schema’s, elementen uit het supertype worden niet meer gedupliceerd naar de suptypen.
• De inheritance-structuur blijft doormiddel van het extension mechanisme gehandhaafd in het schema. Codegeneratoren kunnen deze structuur doorgeven aan de gegenereerde software libraries
• Geen aanpassingen nodig aan het UGM-model. UGM behoudt haar elegante overervingsstructuur.
• UGM is beter te onderhouden omdat er geen elementen en relaties van het supertype hoeven te worden gedupliceerd in de subtypen.
• Last, but not least: het schema-algoritme is al zo geïmplementeerd

Het werken met XSD-extension heeft wel als nadeel dat je niet in alle gevallen de volgorde kunt bepalen van elementen en relaties in de schema's en berichten. Gezien de hierboven genoemde voordelen, neem ik dit nadeel voor lief.

Tijdens de StUF Expertgroep van 16 november 2016 is besloten deze RFC af te wijzen.