Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

opschonen ongebruikte raamwerk onderdelen #126

Open
ArneBruinse opened this issue Dec 2, 2021 · 14 comments
Open

opschonen ongebruikte raamwerk onderdelen #126

ArneBruinse opened this issue Dec 2, 2021 · 14 comments
Labels
1.7 - 20220930 1.9 voorbereiding
Milestone
Release VISI syst...

Comments

@ArneBruinse
Copy link
Collaborator

ArneBruinse commented Dec 2, 2021 •
edited
Loading

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:

  • a: betere documentatie moet komen of
  • b: alsnog tot verwijdering over gegaan kan worden

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

  • in part II kijken wat er opgeruimd kan worden. Daar heeft bijvoorbeeld Appendixtemplate een objectcode (Github item nog aanmaken)
  • de mogelijkheid om in een raamwerk elementen direct in een ander element te definieren, in plaats van altijd verwijzen naar op zichzelf staande elementen. (zie Directe types invoegen ipv verwijzen opruimen uit de _3.xsd #117)
@ArneBruinse ArneBruinse changed the title opschonen ongebruikte raamwerk element eigenschappen opschonen ongebruikte raamwerk onderdelen Jul 8, 2022
@MarkMulderTeec2
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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

Mag weg

@MarkMulderTeec2
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator

Resultaat vergadering:

  • language -> blijft (optineel) - er moet een lijst komen met toegestane language coderingen
  • category + code -> code wordt behouden voor het opslaan van T1_request, wat geen fase is (fase - request);
    category gaat weg
  • requiredNotify -> gaat eruit; losse stuk documentatie wordt geintegreerd in 1.7
  • send + received-> gaat eruit
  • alle responsibility -> blijft; in 1.7 heel duidelijk uitleggen hoe dit bedoeld is en hoe kan het geimplementeerd worden
  • interfacetype + valuelist + result -> gaat weg
  • basepoint -> gaat weg
  • Subtrancation -> gaat weg
  • group group type -> blijft. beschreven wordt hoe de group gebruikt gaat worden.
  • start date + end date -> gaat weg; functionaliteit komt in 1.8 en kan in de software aan of uitgezet worden of het gebruikt wordt in het raamwerk

@ArneBruinse
Copy link
Collaborator Author

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

@JeroenHiemstra
Copy link
Collaborator

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

@tessaderoos tessaderoos mentioned this issue Feb 21, 2024
Closed
@tessaderoos tessaderoos added the 1.9 voorbereiding label Oct 4, 2024
@redmer redmer added 1.9 voorbereiding and removed 1.9 voorbereiding labels Nov 15, 2024
@tessaderoos tessaderoos moved this to Ready in VISI 1.7 Nov 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
1.7 - 20220930 1.9 voorbereiding
Projects
VISI 1.7
Status: Ready
Milestone
Release VISI systematiek 1.7 (20210331)
Development

No branches or pull requests
5 participants
@redmer @ArneBruinse @tessaderoos @MarkMulderTeec2 @JeroenHiemstra