ArjanLoeffen
commented
2 months ago Deze casus was nog niet gebouwd. Is nu toegevoegd. Voorbeeld:
Dit levert (in Oxygen weergave):
Het schema is hier bijgevoegd. xsd.zip
De mogelijke instantie is dan (verkort):
<Model:FeatureType1>
<Model:rol1>
<Model:KeuzeRelaties1>
<Model:FeatureType2/>
</Model:KeuzeRelaties1>
</Model:rol1>
</Model:FeatureType1>NB als je wilt dat ik jullie model als testcase gebruik moet ik de EA file krijgen; het is niet mogelijk op basis van de XMI een werkend/foutloos model te importeren.
HanWelmer
M.b.t. het Keuze-construct hebben wij bekeken hoe Imvertor omgaat met de casus 4 "Keuze tussen relatiedoelen, als nadere invulling van een betekenisvolle relatiesoort van een objecttype" wat betreft het genereren van het XSD (zie XSD-bestand in de bijlage). Daaruit komen 3 bevindingen, die naar onze mening niet correct zijn en aanpassingen van Imvertor vereisen.
De wijze van modelleren van de keuze constructie (in het conceptueel model en het daarvan afgeleide logisch model; zie de andere 2 bestanden in de bijlage) hebben we voorgelegd bij Paul Janssen en die kon daarin geen fouten constateren.
Onze bevindingen
Naam (tag) van het XML-element dat de relatie naar de keuze-entiteit implementeert is gebaseerd op de name van de association connector in plaats van de name van de association target, terwijl Relatierol leidend is (regel 326 van de XSD): IST: name="heeft" SOLL: name="gerelateerdeVerkenningUK"
Voor de keuze-entiteit wordt een lege choice gegenereerd (zie ComplexType VerkenningUKType op regel 462 van de XSD): IST: Er is een lege choice gegenereerd:
SOLL: choice met daarin de root elementen by reference van de uitgaande relaties
ComplexType VerkenningUKPropertyType (regel 464 van de XSD): IST: minOccurs="0" en geen associationAttributeGroup. SOLL: minOccurs="0" en wel een associationAttributeGroup.
Onderbouwing.
Mijn interpretatie van paragraaf E.2.4.11 "UML attributes and association roles" van de GML XML Encoding rules (OGC 07-036) is dat het bij een <> van relaties (MIM casus 4) gaat om "complex content", want de target van de relatie is in dit geval een <>, zodat derhalve het "property type pattern" moet worden toegepast. Dat rechtvaardigt het genereren van een root element, een type en een propety type, zodat alle 3 bovenstaande issues van toepassing zijn.
Voor het derde issue in het bijzonder is mijn onderbouwing dat we bij mijn weten binnen MIM en ook binnen de BRO niet gebruik maken van de tagged value "inlineOrByReference", zodat er in dit geval zowel minOccurs="0" als een associationAttributeGroup moet worden gegenereerd in het popery type.
Een korte navraag bij Linda van den Brink, Wilco Quak en Pieter Brestes gaf geen uitsluitsel over hoe de GML XML encoding in dit geval (casus 4: keuze tussen relatiedoelen, als nadere invulling van een betekenisvolle relatiesoort van een objecttype) moet worden geïnterpreteerd. Zodat ik het heb geaten bij mijn persoonlijke interpretatie.
bijlagen.zip