Geonovum / MIM-Werkomgeving

Werkomgeving van MIM. Bevat werk en alle pre-publicatieversies.
https://geonovum.github.io/MIM-Werkomgeving/
7 stars 16 forks source link

Modelelement identificatie tekst aangepast met technisch en functione… #512

Closed ThiesMesdag closed 3 months ago

ThiesMesdag commented 3 months ago

…le identificatie. zie issue #480

lennartvanbergen commented 3 months ago

Fijn dat het modelelement heet.

Maar vermoedelijk zit hier nog wel iets van werk in, niet moeilijk, maar wel nodig. Wat er nu staat is anders dan besproken/bedoeld. Zie comment.

Aangenomen nog dat model identificatie ook ergens staat genoemd, ik las het niet in de tekst van de pull request ...

ThiesMesdag commented 3 months ago

Wat is: "technisch: GUID of functioneel: Tagged value?"

ik wil de technische id van een tol helemaal niet weten en niet zien en nergens in de tekst van MIM zien (behalve om te zeggen dat we die als MIM niet bedoelen en ook niet willen gebruiken als modelelement id).

een GUID is een gegeven, net als 'hallo' dat is. Een GUID is ook een datatype. Verder is een GUID niks.

we zouden ook nog niet gaan ondersteunen dat iemand de modelelement identificatie kan overrulen, dus een tagged value is nog niet aan de orde.

De aanpassing van URL naar modelelement identificatie had ik al gedaan. In navolging van de uitleg van Marco, die stelde dat je altijd een (technisch) id hebt voor een modelelement, ook al geef je die in een tool als EA niet expliciet op. En dat daarom modelelement identificatie verplicht moet zijn in het metamodel. Dit heb ik toegevoegd aan de toelichting van de modelelement identificatie.

In EA is die identificatie het Guid. Voor de volledigheid heb ik dat dus opgenomen. in de kolom van EA, verder Het staat in de kolom EA, dus tool specifiek. De modelelement identificatie is verplicht in het metamodel, maar hoef je in EA niet te definiëren, want ieder element krijgt automatisch een GUID. Misschien moet ik deze uitleg nog even toevoegen aan de tekst.

Met het onderscheid tussen de technische identificatie en de functionele identificatie van het modelelement is het probleem van het al of niet verplicht moeten toevoegen van een modelelement identificatie ook opgelost.

naschrift: Maar als dat voor nu wat te wild is en we halen modelelement identificatie als tagged value uit het model, dan zouden we wat mij betreft ook het default uri verhaal moeten verplaatsen naar hoofdstuk 5.

Een andere optie is om de tekst zo te laten zoals hij was voor deze pull request, maar dan de tagged value optioneel te maken, ten behoeve van functionele identificatie. Dan heeft het uri verhaal ook een wat logischere plek

pmaria commented 3 months ago

Wat is: "technisch: GUID of functioneel: Tagged value?" ik wil de technische id van een tol helemaal niet weten en niet zien en nergens in de tekst van MIM zien (behalve om te zeggen dat we die als MIM niet bedoelen en ook niet willen gebruiken als modelelement id). een GUID is een gegeven, net als 'hallo' dat is. Een GUID is ook een datatype. Verder is een GUID niks. we zouden ook nog niet gaan ondersteunen dat iemand de modelelement identificatie kan overrulen, dus een tagged value is nog niet aan de orde.

De aanpassing van URL naar modelelement identificatie had ik al gedaan. In navolging van de uitleg van Marco, die stelde dat je altijd een (technisch) id hebt voor een modelelement, ook al geef je die in een tool als EA niet expliciet op. En dat daarom modelelement identificatie verplicht moet zijn in het metamodel. Dit heb ik toegevoegd aan de toelichting van de modelelement identificatie.

In EA is die identificatie het Guid. Voor de volledigheid heb ik dat dus opgenomen. in de kolom van EA, verder Het staat in de kolom EA, dus tool specifiek. De modelelement identificatie is verplicht in het metamodel, maar hoef je in EA niet te definiëren, want ieder element krijgt automatisch een GUID. Misschien moet ik deze uitleg nog even toevoegen aan de tekst.

De identificatie die tooling er automatisch aan geeft is hier niet van belang. Het gaat om de verplichte functionele identificatie die geldt, en dus ook uitgewisseld moet worden. Die GUID is niet onderdeel van MIM en ook niet transfereerbaar naar andere MIM-toepassende omgevingen, de modelidentificatie wel.

Dus ik ben het met Lennart eens dat we het niet over de technische GUID moeten hebben.

PalmJanssen commented 3 months ago

Vraag. Is dit uitgetrild en klaar voor merge? Ik begrijp zelf dat Modelelementidentificatie een optioneel tagged value wordt in het UML metamodel. Dat ingevuld wordt als er een afwijkende waarde van toepassing is die niet gelijk is aan de default. (onderwater zit er altijd een technische EA interne id)

En er staat De package, ik noem het altijd Het package. Heb ik dat verkeerd?

pmaria commented 3 months ago

Vraag. Is dit uitgetrild en klaar voor merge? Ik begrijp zelf dat Modelelementidentificatie een optioneel tagged value wordt in het UML metamodel. Dat ingevuld wordt als er een afwijkende waarde van toepassing is die niet gelijk is aan de default. (onderwater zit er altijd een technische EA interne id)

@PalmJanssen in het metamodel niet optioneel, maar in het gebruik wel optioneel in te vullen.

ThiesMesdag commented 3 months ago

Vraag. Is dit uitgetrild en klaar voor merge? Ik begrijp zelf dat Modelelementidentificatie een optioneel tagged value wordt in het UML metamodel. Dat ingevuld wordt als er een afwijkende waarde van toepassing is die niet gelijk is aan de default. (onderwater zit er altijd een technische EA interne id)

En er staat De package, ik noem het altijd Het package. Heb ik dat verkeerd?

Volgens mij kan het worden gemerged. Het oorspronkelijke issue 480 gaat over de verplichte modelelementidentificatie in LD en daarin wordt besproken dat je het niet verplicht zou moeten in vullen. In de tekst (MetamodelAlgemeen.md) staat nu dat " In de meeste gevallen zal een modelleur dit metagegeven niet expliciet invullen maar uitgaan van de defaultwaarde." Dat lijkt mij tegemoet komen aan het bezwaar dat het verplicht ingevuld zou moeten worden.

De of het package komt allebei voor, ik denk dat beiden kan en het afhankelijk is van de context "het package informatiemodel" en "de package alias" .