search

nl-digigo / visi

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

Nieuw formaat voor VISI exports #67

Open gspees opened 5 years ago

gspees commented 5 years ago

In Bijlage 11 van VISI Standaard versie 1.3 wordt beschreven in welke formaat VISI-projecten gearchiveerd moeten worden.

Zie ook https://github.com/bimloket/visi/issues/25 voor de aanvullende eis voor het importeren van een VISI-archiefformaat.

Er zijn enkele verbeterpunten naar voren gekomen bij het archiveren en inlezen van projectarchieven. Bedoeling van dit issue is deze punten hier te verzamelen en op basis hiervan aanpassing van aan het archiveringsformaat door te voeren.

Verbeterpunt 1 Omschrijving: De paden naar een bericht in het VISI-archief kunnen dus danig lang worden dat de padlengte niet onsersteund wordt door het operating system. Naam: Functie: Organisatie: Ingenieursbureau Amsterda, Future Insight

Datum: 14-07-2016 Oorsprong van het verzoek: project SAA-A9

Urgentie: ‘S’ (should have; hinder kan worden omzeild in dagelijks werk; moet binnen redelijke termijn worden opgelost)

Open Standaard (VISI / COINS)

Verbeterpunt 2 Directory namen van projectdata klopt niet: 2010-12-31T00:00:00.0Z is geen geldige directory naam. Gemeld door: Ed de Later (Future Insight) Datum: 06-09-2019

Uitwerking van het voorstel door Ed de Later uit Issue #72

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:

YYMMDDHHmmssnnn root\ [naam communicatie map]\T[datumtijd][GUID]\M_[datumtijd][GUID].xml \A_[datumtijd][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.

gspees commented 5 years ago

Wat we kunnen doen om dit probleem te verhelpen is een nieuwe definitie maken van de verschillende map namen zodat deze altijd een vaste lengte hebben die onder de 255 karakters blijft. Bijvoorbeeld door voor de transactie mappen een naam te gebruiken die bestaat uit 'tr' + een guid van 36 karakters (er zijn ook langere en kortere guid's mogelijk maar guids van 36 karakters zijn gebruikelijk). De totale padlengte wordt dan 4 voor het jaar + 2 voor de maand + 2 voor de dag + 50 voor de transactie + 50 voor het bericht (datumtijd 19991212241212+ 36) = 108 (nog niet klaar maar batterij bijna leeg...)

gspees commented 5 years ago

Na discussie met Jeroen, Janax en Jens kwam ongeveer dit voorstel naar voren: een xml die de transacties en berichten en beschrijft en alle soapberichten als met hun soap guid en alle bijlagen met hun soapguid en id zoals in het soapbericht. De structuur is dan niet meer zo eenvoudig leesbaar als in de huidige export maar er zijn ook geen problemen meet met te lange bestandsnamen. De maximale bestandsnaam is de naam van de map (projectguid) + soapguid + bijlageID. Zoeken moet dan via de export.xml. Maar als er een standaard export xml is dan is het vrij eenvoudig om met een xslt en css bestand een viewer te maken. De export xml zou per bijvoorbeeld 1000 berichten per xml.

gspees commented 5 years ago

Datum en tijd verzonden niet gebruiken om soapmessages uit elkaar te houden omdat hier te vaak dubbelingen in zijn. Dit kan mogelijk wel als we ook milliseconden mee zouden nemen.

ArneBruinse commented 3 years ago

Zojuist afgesproken met Jeroen, Jens, Niek en Arne: we focussen in 1.7 op de overdracht met de <= 1.6 systematiek middels issue https://github.com/bimloket/visi/issues/72 en willen in 1.8 een verbeterslag proberen te maken.

ArneBruinse commented 11 months ago

Voorstel is om dit idee samen te overwegen met issue #77 het scheiden van data en applicatie. dus evt kan bovenstaand ontwerp meegenomen worden met een bepaalde standaard dbase structuur, of er wordt gewoon gekozen voor een nieuw archief format. zoals bijv hierboven.