Elders gedefinieerde datatypes komen niet terecht in de Respec documentatie.

[melsk-r]

In het RSGB maken we gebruik van datatypes die in een ander model gedefinieerd zijn. Dat andere model ('Generieke Datatypen Gemeenten') is een model met als stereotype 'Basismodel'. In het RSGB hebben we een 'Intern' package met dezelfde naam gedefinieerd met de tv's 'Intern project', 'Interne naam' en 'Interne release' die een waarde hebben die gelijk is aan de gerelateerde tagged values die op het andere model zijn gedefinieerd. Lineage is dus correct gedefinieerd en het model 'RSGB' valideert dus ook goed. Ook het andere model valideert correct.

In de Respec documentatie missen echter bij de attribuutsoorten welke die datatypes gebruiken de betreffende datatypes. Deze zouden daar als link moeten worden opgenomen waarbij de link leidt naar een locatie binnen het Respec document zelf waar het datatype wordt beschreven.
Een constructie met een 'Intern' package is voor ons immers niets anders dan een beheerconstructie en de datatypes zouden verwerkt moeten worden als ware ze direct opgenomen binnen het model (in dit geval het RSGB).

Verzoek om dit te realiseren/corrigeren.

[ArjanLoeffen]

Voorbeeld

<imvert:attribute>
 <imvert:name original="ID">ID</imvert:name> 
 <imvert:type-name original="UUID">UUID</imvert:type-name>
 <imvert:type-id original="EAID_210C71EF_2252_47bc_99E1_B74A632CEC12">EAID_F997C33F_8DD0_496c_A73F_380277836CE2</imvert:type-id>
 <imvert:type-replacement>internal</imvert:type-replacement>
 <imvert:type-package>Generieke Datatypen Gemeenten</imvert:type-package>
 <imvert:type-package-id>EAPK_CF59A7FA_8770_4742_B5FA_F025FEB164DC</imvert:type-package-id>
...

In dit voorbeeld is UUID als interface opgenomen in een intern package, dat verwijst naar een extern model waarin UUID voorkomt met de id EAID_F997C33F_8DD0_496c_A73F_380277836CE2
Wat we dus nodig hebben is een methode om te weten in welk gepubliceerd respec document de UUID (met ID EAID_F997C33F_8DD0_496c_A73F_380277836CE2) is opgenomen. Voor conceptual schema's is dit vastgelegd in cs:ConceptualSchema/cs:catalogUrl .
Het is mogelijk om voor "interne" modellen de conceptual schema's uit te lezen om van daaruit ook de documentatie locatie op te pikken.

Het huidige conceptual schema VNGR-GENERIEK bevat UUID en OID náást o.,a. Polygon - misschien is dat de plek om de documentatie referentie op te nemen.

[ArjanLoeffen]

Besproken is dat interne packages bedoeld zijn voor het beheer, en niet voor publicatie. Het is dus eigenlijk de bedoeling dat de constructies in een intern package onderdeel worden van het model zoals het gepubliceerd wordt. Probleem daarbij is dat niet duidelijk is op welke plek in de catalogus die interne constructies moeten worden ingekopieerd.
graag horen we op basis van welke regels deze constructies kunnen worden ingevoegd.

[melsk-r]

Ook van mij een kort verslagje van hetgeen besproken is.

Arjan stelde voor om zo'n extern model met datatypes gewoon ook in extern documentatie (bijv. als Respec) beschikbaar te stellen en vanuit het gebruikende model hyperlinks te laten lopen naar de betreffende datatypes in die externe documentatie. Dat is ook de manier waarop het met GML zou moeten werken. Mijn argumentatie is echter dat GML een extern gedefinieerde standaard is met een eigen beheer- en publicatieregime. Daarvoor is het gerechtvaardigd aparte documentatie beschikbaar te stellen.

Dat geldt n.m.m. niet voor een package als 'Generieke Datatypen Gemeenten'. Dat is slechts een trucje om voor ons het beheer te vergemakkelijken. Dat trucje mag op geen enkele manier voor lezers van de Respec documentatie of MIM XML serialisatie zichtbaar zijn. Voor hen moeten de externe datatypes integraal onderdeel zijn van een model en moet het dus lijken alsof ze ook echt binnen het model zelf gedefinieerd zijn.

Arjan begrijpt die beweegredenen nu ook maar geeft wel aan dat we goed moeten nadenken hoe e.e.a. dan terecht zou moeten komen in de Respec. Moeten dit soort datatypes in de Respec in een apart paragraaf, met bijv. de titel 'Hergebruikte datatypes', komen te staan? N.m.m. moet dit juist niet het geval zijn omdat lezers van de Respec dan nog steeds geconfronteerd worden met het trucje dat wij vanwege beheer toepassen.

N.m.m. moet de package-structuur van een extern model gelijk zijn aan die van het herbruikende model. Een structuur als:

<<Domein>> Model
      |-- Enkelvoudige Datatype
      |-- Complex Datatype
      |-- Enmeratie
      ...etc.

moet dus zowel in het externe model als in het herbruikende model terugkomen. Dit is slechts een voorbeeld en er moet dus een naamgevingsconventie worden afgesproken die wat mij betreft per organisatie kan verschillen zolang maar steeds in alle modellen dezelfde packagestructuur terugkomt.

Zo moet dus het package 'Model/Enkelvoudig Datatype' dat bij ons in het model 'Generieke Datatypen Gemeenten' staat ook in het model 'RSGB' terugkomen. Daarmee kan Imvertor dan de uiteindelijke locatie van het datatype in de Respec documentatie bepalen.

Een probleem dat we dan nog niet hebben opgelost is wat we moeten doen met de in het externe model gedefinieerde diagrammen.
Negeren we die, nemen we ze op in de Respec van het herbruikende model en zo ja hoe dan?
Of maken we afspraken hoe daarmee om te gaan in het model, bijv. door de externe datatypen in een in het herbruikende model aanwezige diagram te plaatsen.