search

nl-digigo / visi

Beheeromgeving van de VISI open standaard.
https://nl-digigo.github.io/visi/
6 stars 4 forks source link

opschonen ongebruikte raamwerk onderdelen #126

Open ArneBruinse opened 2 years ago

ArneBruinse commented 2 years ago

in de systematiek bestaan de volgende raamwerk onderdelen, die niet gebruikt worden en er is vaak niet (goed) beschreven wat de functie is en zeker niet hoe software er mee om moet gaan. Het gaat om de volgende types:

In de EC vergadering van 8 juli 2022 hebben we besloten om bovenstaande lijst nog een keer door alle stakeholders te laten toetsen of hier geen elementen tussen staan die toch ergens een toepassing kennen of om een andere risico eerst nader beschouwd moeten worden. Alle elementen waar geen bezwaar op verwijdering op terug komt, proberen we in de 1.7 release al uit de systematiek te verwijderen om zo de systematiek iets begrijpelijker te maken voor nieuwkomers. Alle elementen waar commentaar op terug komt, verhuizen we naar de 1.8 backlog om eerst nader onderzoek te doen, zodat we dan kunnen bepalen of voor die elementen:

Voor 1.7 stellen we voor om de "opruimscope" tot dit niveau te beperken. Andere te onderzoeken gebieden zijn in ieder geval:

MarkMulderTeec2 commented 1 year ago

Language (zie Language werkt niet in huidige oplossing #125 )

Vanuit Simplified hebben wij de mogelijkheid om meertalig te werken. Ook voor buitenlandse toepassingen zou het goed zijn om te weten in welke taal iets gemaakt is. Dit veld nu weggooien lijkt ons in het verband met de vergrotingswens van VISI niet juist. Het voorstel is om de standaard taalcode van max 6 tekens te gebruiken indien gebruikt. Als het veld leeg is mag de software zelf een taal instellen. Jos gebruikt “NL” voor Nederlands. Voorbeeld: nl-NL; en-US; en-GB;

MarkMulderTeec2 commented 1 year ago

Category (zie https://bimloket.github.io/visi/visi1.6/#dfn-category)

Code (zie https://bimloket.github.io/visi/visi1.6/#code )

Vanuit het masteronderzoek komen we een aantal punten tegen waar we voor de vertaling van DEMO een aantal velden nodig hebben om informatie over de vertaling kwijt te raken. Deze velden zijn daar een voorbeeld van. We hebben ze bijvoorbeeld nodig om de transactiefase informatie in op te slaan.

MarkMulderTeec2 commented 1 year ago

RequiredNotify (zie https://bimloket.github.io/visi/visi1.6/#dfn-requirednotify)

Op dit moment is het berichten spel van VISI gebaseerd op heen en weer. Voor een aantal momenten in het transactiepatroon van DEMO hebben we een moment nodig dat er 2x een bericht vanuit dezelfde partij komt. Hiervoor zouden we dit attribuut kunnen gebruiken. Voorgesteld gebruik is dat de ontvanger van het bericht niet zelf reageert, maar dat de software zelf antwoord geeft. Voorbeeld: Als DEMO een promise doet kan de andere partij een Promise-Ack (requirednotify=false) terugsturen en daarna kan een declare/state gegeven worden. Zo weet de ontvangende partij dat de promise er is.

MarkMulderTeec2 commented 1 year ago

Send (zie https://bimloket.github.io/visi/visi1.6/#dfn-send)

Received (zie https://bimloket.github.io/visi/visi1.6/#dfn-received)

Mag weg.

MarkMulderTeec2 commented 1 year ago

ResponsibilityScope (zie https://bimloket.github.io/visi/visi1.6/#dfn-responsibilityscope)

ResponsibilityTask (zie https://bimloket.github.io/visi/visi1.6/#dfn-responsibilitytask)

ResponsibilitySupportTask (zie https://bimloket.github.io/visi/visi1.6/#dfn-responsibilitysupporttask)

ResponsibilityFeedback (ziehttps://bimloket.github.io/visi/visi1.6/#dfn-responsibilityfeedback )

ik weet dat Jos dit soms vult of vulde in zijn raamwerken, maar aangezien geen gebruiker dit ooit te zien krijgt, of om gevraagd heeft, lijkt het dat deze (na akkoord van Jos) verwijderd kan worden. Dit geldt ook voor de andere 3 regels. Vanuit DEMO zijn dit de werkinstructies. Dit is de handleiding voor wat mensen moeten doen. Ik zou dit nu niet weggooien omdat we hiermee hele processystemen overbodig kunnen maken omdat de beschrijving gewoon in je workflow systeem staat.

MarkMulderTeec2 commented 1 year ago

InterfaceType (zie https://bimloket.github.io/visi/visi1.6/#dfn-interfacetype)

ValueList (zie https://bimloket.github.io/visi/visi1.6/#dfn-valuelist)

Result (zie https://bimloket.github.io/visi/visi1.6/#dfn-result)

Mag weg

MarkMulderTeec2 commented 1 year ago

BasePoint (zie de Leidraad 1.6, Bijlage 2

VISI-systematiek Deel 1; Raamwerken) vreemd genoeg is deze niet terug te vinden in de _2.exp, maar kan alsnog uit de leidraad opgeruimd worden. Geen enkele uitleg is te vinden over dit element. In VISI 1.2 komt dit in de documentatie al niet voor. Mag weg.

MarkMulderTeec2 commented 1 year ago

Subtransaction (zie https://bimloket.github.io/visi/visi1.6/#dfn-subtransactions)

Mag weg

MarkMulderTeec2 commented 1 year ago

Group / Group type (zie GroupTypes in raamwerk #139 en https://bimloket.github.io/visi/visi1.6/#dfn-subtransactions )

Aangezien transacties niet zo werken als in DEMO willen we de group graag gaan gebruiken voor het markeren van 1 DEMO transactie. Zo kunnen we de transacties die uit meer berichten staan maar om een VISI reden wel/niet in dezelfde transactie horen toch plaatsen in een DEMO transactie Voorbeeld: Group T01.

MarkMulderTeec2 commented 1 year ago

Start Date (zie https://bimloket.github.io/visi/visi1.6/#dfn-startdate)

End Date (zie https://bimloket.github.io/visi/visi1.6/#dfn-enddate)

Deze informatie is uitstekend te gebruiken om bijvoorbeeld een bericht een beperkte duurzaamheid te maken. Dan heeft dat bericht een begin en einddatum en kan het gebruikt worden om een actie te laten uitvoeren. Voorbeeld: MsgAanbieding (startdate 1-6-2022; enddate 30-6-2022)

ArneBruinse commented 1 year ago

Thx!! alvast mijn eerste reacties:

We hebben ze bijvoorbeeld nodig om de transactiefase informatie in op te slaan

Hoi Mark, er is al een veld "TransactionPhase" voor dit doel.

DEMO hebben we een moment nodig dat er 2x een bericht vanuit dezelfde partij komt. Hiervoor zouden we dit attribuut kunnen gebruiken.

er is met de demo-oplegger op de visi 1.6 systematiek gekozen om dit op te lossen met bovenstaande transactionphase. Als deze op promise staat ingesteld, mag er wel een tweede bericht in dezelfde richting verzonden worden.

Zo kunnen we de transacties die uit meer berichten staan maar om een VISI reden wel/niet in dezelfde transactie horen toch plaatsen in een DEMO transactie

Even of ik deze goed begrijp: dus je wilt dat als er een samengestelde visi transactie is die bestaat uit meerdere demo-transacties, op deze manier de verschillende demo transacties in de visi transactie markeren? Dan krijg je in een raamwerk dus 2 transactielijsten, 1 met visi transacties en onder "grouptypes" een lijst met demo transacties. Is het niet verwarrend als we een element gaan gebruiken met een naam die niet duidelijk de lading dekt van het doel? Dan zou ik hooguit voorstellen om grouptype te verwijderen en een nieuwe aan te maken -- of grouptype te henoemen naar DEMO-Transaction oid?

Dan heeft dat bericht een begin en einddatum en kan het gebruikt worden om een actie te laten uitvoeren. Voorbeeld: MsgAanbieding (startdate 1-6-2022; enddate 30-6-2022) in eerdere besprekingen over deze toepassingsrichting kwamen we steeds erop uit dat planningen altijd schuiven en dat de software dan zomaar opeens een veld of bericht niet meer aanbiedt of opeens wel. De kans dat iemand een raamwerk gaat aanpassen zodra er een planningswijziging is geaccepteerd is in de praktijk op dit moment nihil. Daarnaast loopt er al een verzoek om het raamwerk nog minder projectspecifiek te maken, zodat dit goed gebruikt kan worden voor meerdere projecten. Een dergelijke toepassing is juist nog veel project specifieker. Daarnaast vanuit de bril van de software leverancier: ik ben bang voor veel belletjes van gebruikers die klagen dat visi onbetrouwbaar is omdat het gedrag van de applicatie zomaar opeens verandert. Op basis van deze argumenten is in het verleden er steeds voor gekozen dit dus niet zo toe te gaan passen.

MarkMulderTeec2 commented 1 year ago

Resultaat vergadering:

ArneBruinse commented 1 year ago

aanvullend resultaat vervolg vergadering: Central soap server wordt met 1.7 ook uit de documentatie verwijderd na unaniem akkoord.

JeroenHiemstra commented 8 months ago

20220930.zip Elementen verwijderd uit de bestanden _2.exp. _3.xsd en _5.exp (zie bijlage)