Overdraagbaarheid lopende projecten of VISI archief bij switch van leverancier

[ElisabethKloren]

Actiehouder gebruikerscommissie: Suzan van der Broek en Patrick Halters

[edelater]

Besproken tijdens de werksessie 2020-05-29. (Gé, Jens en Ed)

Om het VISI-archief werkbaarder te krijgen is het noodzakelijk de indeling van dit archief aan te passen. De huidige wijze zoals voorgeschreven in de standaard levert al snel problemen op bij gebruik van Microsoft Windows aangezien de maximale padlengte (260 karakters) makkelijk overschreden kan worden.

Het voorstel:

Prefixen van mappen en bestanden:

• T: Transactie
• M: Bericht
• A: Bijlage
• F: Raamwerk
• S: XSD Schema
• P: Projectspecifiek bericht

Datum/tijd:

• YYMMDD_HHmmssnnn

  
  root\
   \[naam communicatie map]\T_[datum_tijd]_[GUID]\M_[datum_tijd]_[GUID].xml
                                                 \A_[datum_tijd]_[GUID].zip
  
   \[naam projectinfo map]\[datum_tijd]\F_[raamwerk naam].xml
                                       \S_[schema naam].xml
                                       \P_[psb naam].xml

- Datum/tijd bij de transactie is dezelfde als die van het eerste bericht van die transactie.
- Namen van communicatie- en projectinfomap zijn vrij te kiezen aangezien de inhoud van die mappen voor zich spreekt. 
- Zelfde geldt voor de namen van raamwerk, psb en schema. Deze zijn te herkennen aan hun prefix.

Op deze wijze voorzien we in het volgende:
- De bestanden zijn opvolgend in tijd te vinden.
- Aan de bestandsnaam is te zien wat voor type bestand het is (bericht, bijlage, raamwerk, psb).
- Maximale padlengte is te voorspellen en blijft ruim onder de 260 karakters (wel afhankelijk van de gekozen projectroot, communicatie- en projectinfo mappen).
- Door het schema op te nemen bij de projectinfo is er geen andere software nodig (promotor) om berichten uit het archief te kunnen valideren.

Als dit eenmaal verwerkt is in de standaard dient het exporteren/importeren van een project ook weer onderdeel te worden van certificering. Hiervoor is het noodzakelijk dat er een representatief project te exporteren/importeren is. Dit dient door 1 van de stakeholders gefaciliteerd te worden.

[jvgeijlswijk]

Eerste versie van testscenario's zijn toegevoegd aan beschrijving van keurmerktest: https://github.com/bimloket/visi/wiki/Testscenario's#scenario-inlezen-van-gearchiveerd-visi-project https://github.com/bimloket/visi/wiki/Testscenario's#scenario-archiveren-van-visi-project

[ArneBruinse]

Bevinding om later te behandelen: de documentatie zegt dat bestandslengte en/of mapnaam lengte afgebroken moet worden voor visi XML files, maar niet voor bijlagen. Hierdoor worden padlengtes problematisch, ookal hebben TEchnia en B&S hier oplossingen voor gemaakt dat dit geen directe problemen meer oplevert. Onderstaande documentatie: https://github.com/bimloket/visi/wiki/Bijlage-11-Richtlijn-voor-het-archiveren-van-VISI--projecten

uitzoeken of we de documentatie willen verhelderen en/of dat er ook afknip regels voor bijlagen moeten komen.

[ArneBruinse]

Bij B&S hebben we de mogelijkheid om een transactie over te hevelen naar een nieuwer raamwerk/van een latere datum. Hierdoor krijg je bijv transacties die gestart zijn in raamwerk 2 van het project, maar later verder gegaan zijn in raamwerk 5. Op zich is in het archief zichtbaar dat deze transactie werkt met raamwerk 5, maar de kans op fouten bestaat als de importerende software er vanuit zou gaan dat deze transactie nog in raamwerk 2 behandeld moet worden. Importerende software kan dan bijv doordat de datum van het eerste bericht ligt tussen de inleesdatum van raamwerk 2 en 3, deze koppelen aan 2, terwijl B&S bedoeld heeft dat de transactie gekoppeld wordt aan raamwerk 5, die in de namespace van het laatste bericht van de transactie staat.

We weten niet direct wat we met dit risico aan moeten. Het overzetten van een transactie naar een ander raamwerk zou in de systematiek opgenomen kunnen worden als alle partijen het daarmee eens zijn. tot die tijd weten we niet echt een workaround voor dit probleem.

[ArneBruinse]

Opmerkingen Technia op export B&S:

• namespace van raamwerk mist in PSB's in de export
• volgens Technia mag een minlength niet samen met enumeraties in een XSD restrictie van een UDT. B&S pakt deze punten op.

[ArneBruinse]

Voorstel voor dit issue: De tests tussen Technia en Bakker&Spees zijn succesvol uitgevoerd obv documentatie 1.6 Dit was het doel voor de 1.7 Voor 1.8 en/of later stellen we issue #67 voor als verbetering van het exportformaat

Deze kan volgens @jvgeijlswijk en @ArneBruinse na akoord EC vergadering gesloten worden door @ElisabethKloren .