> Blog

07.06.2018 - RSS in MS Outlook... Op 28.09.2007 vertelden we al dat we de techniek van de "RRS news feeds" in gebruik namen. De bijwerkingen aan onze web-site worden sindsdien ook op deze manier meegedeeld. Web-browsers bieden al langer functionaliteit om zich te abonneren op zo een "news feed". MS Outlook, en waarschijnlijk ook de andere e-mail programma's kunnen dit nu ook integreren en beheren. We vinden het de moeite waard dit even in herinnering te brengen. Op de homepagina staat een icoontje . Het komt er op neer dat je de onderliggende hyperlink op één of andere manier moet opnemen/instellen in het browser of e-mail programma.

Les RSS dans MS-Outlook... Le 28.09.2007 nous avons signalé que nous utilisons cette technique des "RSS news feeds". Les modifications de notre site-web et de son contenu sont ainsi communiquées. Les browser offrent depuis longtemps la possibilité de s'abonner à ce genre de "news feed". MS Outlook et probablement les autres gestionnaires des e-mail aussi, permettent une même intégration et gestion. C'est suffisamment utile pour vous être rappellé. Sur notre page d'acceuil se trouve une icône . Il suffit de reprendre l'hyperlien sousjacent et de l'intégrer au bon emplacement dans votre browser ou gestionaire e-mail.

05.10.2017 - UN/CEFACT Conference on celebrating "30 years of UN/EDIFACT" - Rome, Italy Background Over the past thirty years, the use of the UN/EDIFACT global data exchange standard has continued to increase year on year. There are many eCommunities that depend daily on UN/EDIFACT-based message exchanges to support their industry sectors. Despite the promises of XML, voiced first in 1999 and other subsequently emerging data exchange alternatives, usage of classic EDI based on UN/EDIFACT and ANSI X.12 vastly outnumber any of the new technologies. But, new valuable opportunities are clearly available, which will most likely compliment rather than replace. To support multiple syntaxes and technologies the UN/CEFACT “Buy, Ship, Pay” domains have developed a harmonised set of core component structures and reference data models which support semantic interoperability across any syntax or technology used for data exchange. Objective This Conference did highlight and celebrate examples of these UN/EDIFACT implementations particularly in the global supply chain and transport and logistics areas and did Illustrate that the continued use of UN/EDIFACT remains a crucial choice for stable and reliable electronic data exchange to facilitate international trade. This importance was highlighted in 2016 with the development of the VERMAS UN/EDIFACT message for satisfying the data exchange requirements of the Verified Gross Mass IMO SOLAS (safety at sea) regulation. The maritime industry as whole has chosen to use the VERMAS message as the only acceptable electronic message format ever since this global SOLAS VGM regulation came into force. There were two panel sessions followed by discussion opportunities. The first did highlight transport and logistics use cases and the second did highlight uses of UN/EDIFACT across the supply chain. The speakers were asked to highlight the benefits accrued in their specific environments and also to introduce their ideas about how newly emerging technologies may be able to provide additional opportunities to extend the migration to electronic data exchanges to further enhance trade facilitation. The Audience: UN/CEFACT Experts who have implemented or are planning to implement UN/CEFACT standards into their business processes. Potential users of blockchain who might want to understand use of UN/CEFACT standards in international supply chain environments Parties that have an interest in facilitating cross border trade Organizers: UN/CEFACT Supply Chain and Transport & Logistics Domains

... Presentations: - Transport and Logistics use of UN/EDIFACT : Maritime Carrier View / Port Community System View / Ship Planning View / Hazardous Goods Control View / Freight Forwarder View / Service Provider View - Supply chain and other uses of UN/EDIFACT : Insurance Sector View / Floristry Sector View / Health Sector Wholesale View / Food Retail Sector View / Automotive Sector View / An Express Industry Perspective Certificates of Significant Contributions 30 years ago UN/CEFACT began the development and publication of the first global EDI standard - UN/EDIFACT. • The building of this new standard needed the underpinning development of a new syntax as well as the development of a directory of message structures. • The syntax has been published through the ISO fast-track and has been continuously developed and maintained in partnership with ISO TC154. • The initial two message structures - purchase order and invoice - have been joined by more than 100 further messages covering the data exchange requirements of many business and governmental sectors. None of this standardisation work would have been possible without huge efforts contributed by many hundreds of experts over the past years. However, this standard would not have resulted in the massive implementation success that has been achieved without: • Communities of trading partners working together to define subsets and message implementation guides perfected to satisfy their particular data exchange needs • Development of key code lists which can be used across multiple sectors (and which are now reused for other syntaxes such as XML) • Availability of tools to enable the building and publication of message implementation guides and validation services • Availability of translators for sending and receiving message instances • Continuous expert support to ensure quality and trustability of the twice-yearly publication of the UN/EDIFACT Directories • Implementation experts for providing support The awards to celebrate the success of the past years of UN/EDIFACT aim to recognise organisations and eCommunities which have made significant contributions in any of the above areas.

01.10.2016 - Principium 2016 n° 9 - Artikel...
De voorzitter van onze Werkgroep Normalisatie publiceerde een artikel over normalisatie: "La numérisation, la normalisation et leurs avantages".

26.06.2014 - Het (Europees) Aanrijdings-Formulier, en het gebruik van QR-codes...
(08.06.2017 : De documentatie is aangepast in de zin dat ze nu tweetalig NL/FR is.)
(22.02.2017 : Let wel, het gebruik van deze QR-code valt onder de verantwoordelijkheid van de verzekeraar. De makelaar die hier op één of andere manier wil op inspelen moet van de betrokken verzekeraar het voorafgaandelijke akkoord bekomen.)
(15.02.2017 : QR-code in zijn definitieve versie.) Ondertussen is dit dossier blijven evolueren. De definitieve implementatie wijkt qua inhoud totaal af van wat hier tot nu toe gedocumenteerd is. De definitieve en juiste documentatie is verspreid via de reguliere Assuralia-kanalen. We hernemen dat document hierboven in zijn meest recente versie.
Wat hieronder volgt is dus slechts historiek.
(27.01.2016 : QR-code inbegrepen id-verzekeraar.)
(07.07.2015 : QR-code met maximale inhoud.)
(01.07.2015 : QR-code of Datamatrix.)
(21.05.2015 : De voorbeelden zijn nu lichtjes aangepast op basis van de Namespace 2015.)
Er is beslist in de QR-code de nationale identificatie van de tussenpersoon op te nemen, inbegrepen de (ISO-)aanduiding van die nationaliteit. In België is dat dan de aanduiding BE gevolgd door het KBO-onderneming-nummer (KruispuntBank Ondernemingen), eventueel het KBO-vestigingseenheid-nummer.)
Men denkt na over een sectorale aanpak rond het (Europees) Aanrijdings-Formulier in de vorm van een smartphone-app, en dit in combinatie met QR-codes die de informatie van de Groene Kaart (en aanverwante informatie) beschikbaar stellen aan dergelijke smartphone-app.
In die sfeer ontwierpen we een structuur/voorstelling van dat formulier, waarin alle info-elementen hernomen zijn.
In dit stadium ontwerpen we nog geen berichten tussen actoren; dat zal nog afhangen van te maken conceptuele keuzes qua hoe en wat.

Op basis van die structuur ontwierpen we dan de verzameling info-elementen die in dergelijke QR-code kan aangeboden worden. We maakten dit voorbeeld aan via de tool beschikbaar op website "http://www.qr-genereren.nl/". Merk op dat de inhoud van de QR-code ondermeer vertelt op basis van welk schema die inhoud opgebouwd is; de info is "self-explanatory". Die te respecteren regels zijn in het bijhorende schema Entities.xsd vastgelegd; dat gaat dan over maximale veldlengtes en dergelijke. Merk ook op dat deze bouwstenen deel uitmaken van een groter raamwerk dat ook nog eens in zijn geheel gedocumenteerd is. In die documentatie, onder "Telebib2Model" - "Entities" - "EuropeanAccidentNotificationQRData" is dan een visueel diagram te vinden, en daarin een relatie "Insured" met een veld "D0601" met de "business betekenis" "Insured Name" en de "maximale lengte" 35. De (smartphone-)applicatie kan dan de gegevens van "Voertuig A" gaan inlezen uit zo een QR-code, en idem voor "Voertuig B", waarbij de app zelf voorziet in functionaliteit die toelaat te kiezen voor hetzij "A" hetzij "B". Dergelijke QR-code kan voozien worden op de Groene Kaart zelf, of op een begeleidend schrijven, of op een smartphone-scherm... Opnieuw, in dit stadium kijken we meer naar de mogelijke inhoud, dan naar de finale technische uitwerking. (We merkten al dat de lange tekstuele xml-tags veel van de in de QR-codes beschikbare ruimte verbruiken, en daarom vielen wa al terug op meer numerieke, kortere tags.) Op mijn smartphone heb ik een app "NeoReader". Test 1: Geactiveerd en de smartphone foto-lens gericht op de op de web-pagina zichtbare QR-code, geeft na enkele seconden de inhoud van de QR-code leesbaar op de smartphone. Test 2: Print op papier van deze web-pagina, afdruk-grote 50%, de kleine QR-code is dan nog 2,5 cm breed/hoog. Scan OK. / Met 1 potloodstreep dwars door de QR-code : Scan OK. / 2 strepen : Scan OK / 3 strepen : Scan lukt niet meer. Test 3: Print op papier van deze web-pagina, afdruk-grote 75%, de kleine QR-code is dan nog 3,8 cm breed/hoog. Scan OK. / Met 1, 2, 3 potloodstrepen dwars door de QR-code : Scan OK. / 4 strepen : Scan lukt niet meer. Nog wat andere, bijkomende commentaar rond onderdelen van het aanrijdingsformulier, en hoe die eventueel kunnen voorgesteld worden: - De situatieschets (nr.13) en de beide handtekeningen (nr.15) zijn digitale afbeeldingen, opgeslagen binnen het document zelf, zodanig dat alles één geheel vormt. - De "eerste impact" (nr.10) bekijken we als een raster-afbeelding van 35 millimeter breed en 26 millimeter hoog. We geven het punt van eerste impact dan weer als coördinaten horizontaal en verticaal vertrekkende van links-bovenaan. (18 horizontaal en 13 verticaal is dan het midden van de rechterflank van de auto.)

(dit is een png-bestand) (dit is een jpg-bestand)

Qr-code of Datamatrix: dit is een Datamatrix-formaat "streepjes" of beter "blokjes" code. Dit is een alternatief voor de QR-code standaard. Onze voorkeur lijkt uit te gaan naar de QR-code, omwille van de hogere data-capaciteit, en omdat het er op lijkt dat er meer tools zijn die de QR-code ondersteunen.

11.03.2014 - Cijfers met betrekking tot 2013...
Op 11.03.2013 publiceerden we cijfers voor het werkjaar 2012.
We ontvingen nu van de operator van het sectorale platform diezelfde cijfers voor het werkjaar 2013.

Het resultaat is de volgende tabel, waarin we 2013 kunnen vergelijken met 2012.
Het is duidelijk dat er door een aantal spelers grote stappen vooruit gezet zijn, maar toch is er nog steeds werk aan de winkel.
Tegelijkertijd lijken de aantallen globaal gezien te dalen. Dit moeten we op één of andere manier zien te onderzoeken en te verklaren.
De "bijgevoegde documenten" (berichten M9730) stijgen met 150%, van 180.000 naar 470.000; dat is in ieder geval een "benefit", zeker in de context van de verdere digitalisatie.

07.03.2014 - Vloten in gedelegeerd beheer - Communicatie dekkingen in BA...
De Veridass Aanbeveling 2.0 blijft omstreden. Op basis van wat we horen, lijkt het ons opportuun een alternatief voor te stellen.
We werkten een voorbeeld uit van een bericht dat enkel focust op de informatie nodig voor Veridass, en dus zonder de informatie ten behoeve van audit en opvolging door de verzekeraar van wat bij de makelaar gebeurt.
We hebben dit enkel uitgewerkt in de vorm van een XML-structuur, bij middel van het bestaande model, zonder aan dat model wat dan ook te wijzigen.
De oefening toont aan dat dit kan. Dit bewijst enige mate van maturiteit van het model.

05.03.2014 - Namespace 2014...
Onder "XSD Schema" (deze pagina is bereikbaar vanuit de home-page) zie je nu dat we de stap zetten van een "Namespace 2013" naar een "Namespace 2014".
De opzet blijft dezelfde.
De input blijft komen vanuit de werkzaamheden van de Werkgroep Normalisatie, aangevuld met inspiratie vanuit de hoek van de werkzaamheden binnen eEG7 en UN/CEFACT.
Op dit ogenblik gaat het vooral over volledigere integratie van alle nieuwigheden die in 2013 onstaan zijn. (Alles wat onder "Version Information" vermeld staat tot en met versie 6.80 is nu overgenomen.

31.10.2013 - Veridass Aanbeveling 2.0 en Namespace 2013...
Deze aanbeveling is eerstens geformuleerd in de vorm van een Excel-bestand, waarna dit "vertaald" is naar een TB2-Edifact structuur op basis van MCI 0139.
We hebben de MCI 0139 beschrijving dan nu ook nog eens bekeken naast/met het (Telebib2-XML-)Model.
Het resultaat is/zijn enkele aanpassingen in dat Model, en een voorbeeld van dergelijke XML-structuur, met daarin de gegevens die we gebruikten in het Excel-voorbeeld-bestand.

22.10.2013 - Namespace 2013...
Onder "XSD Schema" (deze pagina is bereikbaar vanuit de home-page) zie je nu dat we de stap zetten van een "Namespace 2012" naar een "Namespace 2013".
De opzet blijft dezelfde.
De input blijft komen vanuit de werkzaamheden van de Werkgroep Normalisatie, aangevuld met inspiratie vanuit de hoek van de werkzaamheden binnen eEG7 en UN/CEFACT.
Op dit ogenblik gaat het vooral over volledigere vertaling naar het Engels en het Duits van de gebruikte terminologie.

24.09.2013 - Gestructureerde berichten uitgewisseld tussen niet synchroon evoluerende actoren...
Het is gebruikelijk dat men brieven, e-mails en dergelijke bewaart in één of andere agenda/historiek en dat deze consulteerbaar blijven.
De idee leeft dat men gestructureerde berichten (precies omdat deze gestructrueerd zijn) bij ontvangst afhandelt en definitief integreert en dus niet langer hoeft te bewaren.
De partijen evolueren in de praktijk echter niet synchroon, wat maakt dat deze redenering niet opgaat.
In dit verband hebben we wat we in 2003 vertelden een beetje aangepast/uitgebreid.

11.03.2013 - Cijfers met betrekking tot 2012...
Binnen de Werkgroep Normalisatie, deels in verband met de vragen in de richting van een nieuwe/andere te implementeren syntax, is er op en bepaald ogenblik gevraagd naar informatie over wat er precies in de praktijk gebracht is.
We vroegen de operator van het sectorale platform een tabel te leveren met:
- in de kolommen : de semesters 2011.01 / 2011.02 / 2012.01 / 2012.02 / 2013.01
- in de rijen :
- - het totaal aantal exchange units (XEH ... XET)
- - - sub-totaal per object-action code (XEH.X912)
- - - - sub-totaal per domain code (XEH.X916)
- - - - - sub-totaal per format-code (XEH.C910.X940)
- - - - - - sub-totaal per business content description (XEH.C910.X943)
- - - - - - - sub-totaal per business content description version (XEH.C910.X944)

Als antwoord ontvingen we de volgende tabel, met cijfers voor het jaar 2012.
Deze cijfers zetten de theorie van onze SLA/3 tegenover de realiteit van het terrein, op een anonieme en globale wijze.
Het lijkt logisch dat iedere speler afzonderlijk en voor zichzelf dezelfde informatie kan opvragen bij de operator van het platform. De globale cijfers zijn dan de "benchmark" waaraan men zich kan spiegelen.
De gegevens X943 en X944 zijn beschikbaar (te implementeren) sinds release 2008, en we zitten nu in release 2013.
De cijfers spreken voor zich; er is nog werk aan de winkel.

01.03.2013 - Principium 2013 n° 3 - Artikel...
De voorzitter van onze Werkgroep Normalisatie publiceerde een artikel rond Telebib2 : "Les normes et leur avenir dans notre secteur".

07.12.2012 - European standardization policy...
Op 5-6 december 2012, tijdens onze eEG7 bijeenkomst kregen we de volgende informatie.

November 2012 - Regulation on European standardization
Regulation (EU) No 1025/2012 of 25 October 2012 on European standardisation
Following its adoption by the Council on 4 October 2012, the Regulation (EU) No 1025/2012 of the European Parliament and of the Council of 25 October 2012 on European standardisation was published in the Official Journal of the European Union in the series L 316. This Regulation aims at modernising and improving the European standards setting to make it faster and at the same time more inclusive.

26.11.2012 - TB2-XML versus JSON...
Java Script Object Notation (JSON) is vandaag een veel gebruikte syntax. Men stelt de vraag of we deze moeten verkiezen boven XML...

Binnen Sparx Systems - Enterprise Architect spreken we van "Model Driven Architecture" en van een "Platform Independent Model".

"... The OMG’s Model Driven Architecture initiative is aimed at increasing productivity and re-use through separation of concern and abstraction. A Platform Independent Model (PIM) is an abstract model which contains enough information to drive one or more Platform Specific Models (PSM). Possible PSM artifacts may include source code, DDL, configuration files, XML and other output specific to the target platform. ..."

12.10.2012 - Artikel in Assurinfo...

22.08.2012 - TB2-XML...
Sinds vandaag is de pagina "MCI" (Message Content Inventory) enigszins aangepast. In de header van de pagina is een nieuwe link toegevoegd, net na de link richting UN/Edifact MIG : "TB2-XML : added info".
In de nieuwe pagina duiden we de overeenkomstige elementen aan binnen ons model en dus ook in de daarvan afgeleide XML-Schema's.
Idealiter zou telkens de volledige (bericht-specifieke) "x-path" moeten weergegeven worden. Dat is echter in deze fase nog niet gebeurd.
De oefening heeft ook nog eens aangetoond dat het model weliswaar grosso-modo volledig is, maar dat er toch nog hiaten zijn.

05.04.2012 - TB2-Edifact Validatie...
A. Sinds 10.01.2012 is op de "Downloads" pagina de Telebib2 UN/Edifact "Validation tool" beschikbaar, inbegrepen wat uitleg rond de installatie, het gebruik, en de precieze "scope" van de tool. De eerste reacties zijn positief, maar het concrete gebruik van de tool blijft voorlopig nog wat onduidelijk.
B. In de marge van de ontwikkeling van de tool (hetgeen extern gebeurde) had het Telebibcentrum voor zichzelf iets gelijkaardigs gebouwd. Het gaat hier over een web-pagina waarin je een "edi-bestand" kan uploaden, en dan als respons een "validatie-rapport" krijgt. De enkele gebruikers die hiermee al kennis maakten stellen dat dit, naast de mogelijkheden geboden door de "Validation tool" (zie A.), toch nog toegevoegde waarde heeft. Als dat zo is, dan is het nuttig deze "Validatie pagina" ook te publiceren. Wat dan bij deze gebeurd is. Merk op dat het niet de bedoeling is dat je hier bestanden van honderden megabytes groot gaat mee testen...

17.02.2012 - Namespace 2012...
Onder "XSD Schema" (deze pagina is bereikbaar vanuit de home-page) zie je nu dat we de stap zetten van een "Namespace 2011" naar een "Namespace 2012".
De opzet blijft dezelfde.
De input blijft komen vanuit de werkzaamheden van de Werkgroep Normalisatie, aangevuld met inspiratie vanuit de hoek van de werkzaamheden binnen eEG7 en UN/CEFACT.

10.03.2011 - Een bijkomende oefening...
Er zijn onlangs vragen gesteld rond mogelijke berichten in verband met verslagen van raadsgeneesheren.
We maakten nu een oefening op basis van het "Verslag Raadsgeneesheer - Gemeen Recht - Auto".
Wat ons beviel was dat een groot deel van de oefening kon, zonder enige toevoeging aan het bestaande model.
Het zijn enkel de inhoudelijke details van dit document die nog niet gemodelleerd zijn.
We hebben nu een eerste aanzet van die bijkomende modellering toegevoegd, maar wensen nu wat bijkomende input en/of reacties...
Men kan ook dit voorbeeld bekijken in de browser, en (opnieuw) tegelijkertijd in een ander browser-venster de onderdelen gaan opzoeken in de model-documentatie.

24.02.2011 - Een stapje vooruit...
We blijven werken aan het model in Enterprise Architect.
We maken daar gebruik van "code generating functionality" en hebben onze eigen templates opgesteld die dienen om de 3 schema's aan te maken. Dit zijn Entities.xsd, Codelists.xsd, DataTypes.xsd en BasicTypes.xsd.
Op basis van die schema's werken we een aantal voorbeelden uit van xml bestanden, van berichten...
Een voorbeeld van een bericht over een persoon. (Het zijn in dit stadium meer voorbeelden van bericht-structuren, dan van berichten.)
Een voorbeeld van een bericht over een contract.
Een voorbeeld van een bericht over een kwijting.
Een voorbeeld van een bericht over een borderel.
Een voorbeeld van een bericht over een rekeninguittreksel.
Een voorbeeld van een bericht over een schadedossier.

Je kan nu zo een voorbeeld bekijken via je browser, en tegelijkertijd in een ander browser-venster de onderdelen gaan opzoeken in de model-documentatie.

(10.03.2011 - dit stukje zijn we verder blijven aanpassen...)

02.06.2010 - Muziek en standaarden...
Voor wat het waard is, deze losse bedenking waar we menen een zekere analogie te zien.

16.03.2010 - Van Telebib2-Edifact naar Xml-Edifact...
Op basis van de bevindingen van einde 2009 maakten we enkele oefeningen. Het schema "Tb2XmlEdifact.xsd" is hiervan het resultaat. Dit is nu gepubliceerd in de namespace "www.telebib2.org/Namespace/2009". Nogmaals, dit is nog geen goedgekeurd materiaal, de continuïteit hiervan is niet gewaarborgd.

10.12.2009 - Complexity in the name of simplicity...
Dit is een "white paper" met als volledige titel "Complexity in the Name of Simplicity: Can Information Exchange Standards Meet eBusiness Needs?", te vinden op www.illumonus.com.

De daar uitgewerkte argumentatie is zeer herkenbaar.

De finale conclusie legt de nadruk op de transformatie van EDI naar XML, als vervanging van de syntax, maar met behoud van de inhoudelijke structuur. Op die wijze bewaart men niet alleen de band met de EDI standaard als structuur, maar ook qua opgedane ervaring en kennis.

In dit verband vermeldt men de ISO TS 20625 "Rules for generation of XML scheme files (XSD) on the basis of EDI(FACT) directories or implementation guidelines".

Men ziet de huidige gebruikers zo XML uitwisselingen opstarten, zonder daarom de bestaande back-end EDI translators te moeten vervangen. Dit is essentieel, omdat:
- het mogelijk maakt COTS (*) applicaties te bouwen die XML gebruiken en die KMO-gerichte oplossingen bieden, en
- het de grotere organisaties niet verplicht hun bestaande EDI applicaties te vervangen.
Op die manier moeten de huidige hoofdrolspelers geen significante investeringen en/of wijzigingen aangaan.
Deze zijn dan wel al goed geplaatst om, dankzij méér eBusiness, bijkomende besparingen te doen, en dit mits een minimale investering in een bijkomende, eenvoudige front-end XML-to-EDI/EDI-to-XML processor.

(COTS: "Commercial-Off-The-Shelf" products, as opposed to "made to measure".)

Op en.wikipedia.org/wiki/XML/EDIFACT is een korte samenvatting van deze principes te lezen.

In grote lijnen krijgen we dan de volgende spelregels:

segmenten:
3-letter-tag
 --> "S"-"Underscore"-"3-letter-tag" : opent een xml-segment-element
 --> "/S"-"Underscore"-"3-letter-tag" : sluit een xml-segment-element

composite data element:
1-letter-3-cijfer-id
 --> "C"-"Underscore"-"1-letter-3-cijfer-id" : opent een xml-composite-data-element
 --> "/C"-"Underscore"-"1-letter-3-cijfer-id" : sluit een xml-composite-data-element

simple data element:
1-letter-3-cijfer-id
 --> "D"-"Underscore"-"1-letter-3-cijfer-id" : opent een xml-simple-data-element
 --> "/D"-"Underscore"-"1-letter-3-cijfer-id" : sluit een xml-simple-data-element

voorbeeld:
     ATT+X010+C005'
=   ATT+X010+X011:X901:X902:X012'
== ATT+0200+2:::Persoonlijke lening' (dit is een concreet voorbeeld)

en dit geeft dan:
   <S_ATT>
      <D_X010></D_X010>
      <C_C005>
         <D_X011></D_X011>
         <D_X901></D_X901>
         <D_X902></D_X902>
         <D_X012></D_X012>
      </C_C005>
   </S_ATT>

en voor het concreet voorbeeld:
   <S_ATT>
      <D_X010>0200</D_X010>
      <C_C005>
         <D_X011>2</D_X011>
         <D_X012>Persoonlijke lening</D_X012>
      </C_C005>
   </S_ATT>

op één lijn:
   <S_ATT><D_X010>0200</D_X010><C_C005><D_X011>2</D_X011><D_X012>Persoonlijke lening</D_X012></C_C005></S_ATT>

er zijn nog andere beginletters of prefixen voorgesteld:
   M_ : message
   G_ : segment group
   S_ : segment
   C_ : composite data element
   D_ : data element

en optioneel kan ook een suffix ..._?...?, op basis van één of andere semantische interpretatie, whatever that means...

06.11.2009 - A view on enterprise software and semantics from the inside out...
Dit is de blog van Collibra, en spin-off van de Vrije Universiteit Brussel.
Naast de blog is er ook de website.

Op 1 october 2009 nodigden we Collibra uit op de eEG7 sessie in Brussel.
Onze eerste indruk is positief, zijn verhaal wekt interesse.
We voelen aan dat dit een zekere leegte invult.
Als eEG7 groep moeten we dit in het oog houden en proberen in te passen in ons eigen verhaal.

Op 15 october 2009 hadden de coördinator van het Telebibcentrum en Stijn Christiaens een lang gesprek. We gaven details rond Telebib en zijn context, en we kregen details rond het aanbod en de context van Collibra.
De conclusie was dat het zinvol kan zijn dat Collibra zijn verhaal doet aan onze stakeholders, hetzij individueel, hetzij in groep.
Idealiter zou dit kunnen op basis van een proof of concept, op basis van Telebib-materiaal.
Als Telebibcentrum wijzen we wel nog eens expliciet op onze huidige implementatie in de Telebib2-Edifact syntax.

We hebben nu materiaal aangemaakt dat kan helpen bij dergelijke proof of concept. Hiervoor gebruikten we de MIG's van het gedeelte "Contracten" van de Release 01.01.2011. Met wat we daar vinden hebben we een ganse reeks "patterns" aangemaakt en staan we nu op het punt deze te combineren in "berichten". Hiervoor is echter een bijkomende tussenkomst van Collibra gewenst.

30.10.2009 - Transformatie van EDIFACT berichten met Open Source gereedschappen.
Op deze web-pagina vonden we wat info rond de stand van zaken...

http://danga.blogsome.com/2008/10/06/sap-neemt-de-uncefact-core-components-als-basis-voor-warp-10/

http://danga.blogsome.com/2008/06/13/transformatie-van-edifact-berichten-met-open-source-gereedschappen/

http://danga.blogsome.com/2008/04/05/hoe-lossen-we-het-interoperabiliteitsvraagstuk-op/

Er is blijkbaar nog steeds geen kant en klare oplossing beschikbaar, niet voor een "zuivere edifact" omgeving, en zeker niet voor ons "dialect"...

16.10.2009 - The day we actually started publishing this page.
For some time now, we (I) did have the idea that it might be a good thing to communicate about these things. I did look at some blog-tools (Wordpress and the like), but for the moment I opt for a quick and dirty approach.

"Food for thought" (the original name for this page) is actually the title of a book written by Steven Pinker. If you are interested in some fresh ideas on what language is about, you might enjoy reading this one.

I'll go back in the past and will gather older material which I think still being of interest. I'll gradually build up towards today's date, and then will really start publishing things as of today... At this moment, I am still occupied gathering such older information, hence this is "WIP" (Work in progress).

14.07.2009 - De validatie van uitgegeven berichten en de publicatie van de resultaten

Korte samenvatting

De context:
Het Telebibcentrum beheert en publiceert een syntaxis voor de electronische uitwisseling van berichten.
Binnen deze syntaxis is een bibliotheek aangelegd van gegevenselementen, al of niet voorzien van waardenlijsten.
Met deze gegevenselementen worden MIG’s (Message Implementation Guides) opgesteld die de inhoud van de berichten bepalen.
Dit geheel ligt niet voor eens en voor goed vast, maar blijft evolueren in functie van wat er binnen onze marktomgeving gebeurt.
MIG’s maken deel uit van “Releases” (opeenvolgende publicaties) waarvoor termijnen vastgelegd worden aangaande hun implementering door de verschillende spelers.

Het probleem:
Men ervaart vandaag dat een aantal spelers er niet in slagen de termijnen te respecteren, en dat er dus een verschil is tussen wat het Telebibcentrum in de Releases beschrijft, en wat er in werkelijkheid uitgewisseld wordt. Dit verschil geeft aanleiding tot allerhande discussies en verspilling van tijd en energie.

De oplossing:
De in de GTN/WGN (Groupe de Travail de Normalisation / Werkgroep Normalisatie) voorgestelde oplossing behelst eerstens dat het Telebibcentrum publiceert welke speler wat effectief implementeert, en zo een correct beeld geeft van de werkelijkheid.

Een uitbreiding:
Vanuit de GTN/WGN, en dan vooral vanuit de hoek van de makelaardij, komt de bijkomende vraag om de dingen met iets meer detail dan vandaag gebruikelijk weer te geven.
Context:
Een MIG zegt dat een gegeven verplicht, al dan niet optioneel aanwezig moet zijn.
Probleem:
Het ene gegeven is het andere niet, er zijn er van absoluut belang, heel belangrijke, gewenste, “nice to have”, … Als je dit niet erkent, dan kan je vandaag een MIG perfect implementeren, terwijl je in de praktijk slecht weinig kan doen met het ontvangen bericht.
Oplossing:
Een MIG bepaalt de aanwezigheid van een gegeven als verplicht / aangeraden / optioneel / conditioneel. (Deze opdeling komt niet uit de lucht gevallen, maar is gefundeerd op gelijkaardige problemen/oplossingen in andere sectoren dan de onze.)

De uitwerking:
Het Telebibcentrum verkrijgt:

• een tool die toelaat MIG’s volledig, en met voldoende detail te beschrijven. Noteer dat “voldoende detail” slaat op de hierboven weergegeven uitbreiding. Noteer dat “volledig” slaat op andere, in deze samenvatting niet uitgediepte, gebreken.
• een (andere) tool die toelaat berichten op basis van MIG’s te valideren. Dergelijke validatie heeft te maken met de zuivere syntaxis, maar ook met de “filters”, met wat sommigen “kruiselingse controles” noemen, en zelfs met een zekere mate van inhoudelijke controle.
• dezelfde tool kan toelaten het bericht te “labelen”:
  • Gouden label : echt alle mogelijke info is aanwezig, ook de “optionele”;
  • Groen label : alle verplichte en alle aangeraden info is aanwezig;
  • Oranje label : alle verplichte info is aanwezig;
  • Rood label : er ontbreekt verplichte informatie.

Het Telebibcentrum publiceert de MIG’s, voert de validaties uit, en publiceert de resultaten, na bekrachtiging door de makelaardij.
(Het Telebibcentrum zou de validatie als een webservice permanent ter beschikking kunnen stellen.)

De situatie vandaag

De website
De website www.telebib2.org wordt tot op vandaag nog altijd onderhouden via “Macromedia Dreamweaver 8”, hoofdzakelijk in combinatie met de Access dBase “.\Data\Telebib2.mdb”.

Er zijn wel al enkele andere *.mdb bestanden aanwezig, doch in dit stadium van minder belang.
“.\Data\TB2Credits.mdb” : hetgeen op de pagina “Credits” verschijnt.
“.\Data\TB2Implementation.mdb” : een eerste conceptuele oefening rond het toekomstige publiceren van de resultaten.
“.\Data\TB2Model.mdb” : een n-de conceptuele oefening in de richting van xml en dergelijke.

De databank
De databank vormt zowat de hoeksteen van de dag-dagelijkse activiteiten van het Telebibcentrum.

Deze is eveneens beschikbaar als “download” op de website. Zie de pagina “Downloads”; in het onderdeel “Syntax dependent standards” > “Telebib2-UN/Edifact” > “Access database” : “Telebib2.zip” is een gecomprimeerd bestand.

Dergelijke databank is in essentie een verzameling van tabellen.

De tabel-lijst is gesorteerd op de kolom “Description” (en niet zoals gewoonlijk op de kolom “Name”).
Het veld “Description” omschrijft, min of meer gestructureerd, de bestaansreden van de tabel.

De tabellen “Non-syntax - …” bevatten de verzamelde informatie, los van de implementerende syntaxis. (Denk aan de notie “business rules” / “zakelijke spelregels” / “règles du métier”.)
De tabellen “UN/Edifact - …” bevatten de informatie rond de tot vandaag gebruikte syntaxis.

De tabellen MCIsTitle / MCILines / Releases bevatten de informatie over de MCI’s (Message Content Inventories).
In principe zijn het deze MCI’s die binnen de GTN/WGN finaal goedgekeurd worden, en toegewezen worden aan een “release”.

In principe gebeuren daarna de nodige aanpassingen aan de syntaxis, en worden dan in deze syntaxis de MIG’s gemaakt met als leidraad de MCI’s.

De tabellen A_DE tot en met A_SEGMENT_LAYOUT beschrijven de “zuivere syntaxis”.

De tabellen Migs / Main / Segment en MigComm / Mig_MCI bevatten de informatie over de MIG’s.

De inhoud van de tabellen Migs / Main / Segment komt in principe uit het gebruik van de EDI-Builder tool.

De tabellen ROD_domain / TypePolicy_domain / Guarantee_domain bevatten de “filters per domein”. Eigenlijk vormen de MIG’s samen met de “filters” één geheel, in de zin dat elke implementatie beide dient te respecteren.

Het gebruik van de EDI-Builder tool
De tabellen Migs / Main / Segment in Telebib2.mdb krijgen hun inhoud vanuit de EDI-Builder tool. De tool is een erfenis daterende van de overdracht van de activiteiten van Luc Sterck aan Michel Bormans (de verhuis van het Telebibcentrum van Portima naar Assuralia).

Het “referentie-materiaal”, de bouwstenen die de EDI-Builder tool de gebruiker aanbiedt om daarmee een MIG te bouwen, komt eveneens uit tabellen in Telebib2.mdb. Het is wat we hierboven de “zuivere syntaxis” noemen.

De gebruiker “vertaalt” als het ware de MCI naar de overeenstemmende MIG, en gebruikt op dat ogenblik als “input” een print-out van de MCI, of consulteert de MCI via de website.

De via de tool aangemaakte MIG’s worden opgeslagen in een tool-specifiek formaat met de extensie *.emg.
Daarnaast voorziet de tool ook nog de volgende mogelijkheden :

• Generate Edifact String
• Generate HTML documents
• Export for EDI traductor
• Export for documentation
• Export Mig to Access

Enkel de eerste en de laatste worden (binnen het Telebib centrum) effectief gebruikt.

In zekere zin is dit een tool die documentatie aanmaakt, of dan toch die de informatie verzamelt die in de documentatie zal getoond worden. Die “documentatie” is finaal de voorstelling van de MIG’s zoals te vinden op de website.

Uiteindelijk levert het Telebib centrum de informatie aan de verschillende ontwikkelaars:

• via consultatie van de website,
• via download van de databank, en gebruik van de tabellen.

Het gebruik van de AS/2-Workspace
Portima biedt zijn “platform-klanten”, dit wil zeggen de verzekeraars en de softwareleveranciers die aansluiten op de (vroegere) backbone en/of op de (huidige) AS/Web omgeving, de ontwikkelingsomgeving die hun helpt bij de ontwikkeling en implementatie van de op de Telebib2 standaard gebaseerde berichten.

Het Telebibcentrum gebruikt deze AS/2-workspace vandaag niet.

Dit geheel bevat (ondermeer) een validatie-tool, en dit is een validatie die verder gaat dan wat het Telebibcentrum qua spelregels publiceert, in de zin dat:
- de informatie uit de MIG’s hier samengevoegd is met de informatie uit de “filters”,
- er hier zelfs kruiselingse controles effectief gedefinieerd zijn die in de zuivere MIG’s niet expliciet vermeld staan, maar slechts impliciet afgeleid kunnen worden.
Het is echter niet duidelijk wie deze tool gebruikt.

In 2006, bij de verplaatsing van het Telebib centrum, is dit gegeven niet ter sprake gekomen; men beschouwde dit blijkbaar niet als behorende tot het terrein van het Telebib centrum.

Alternatieven qua bruikbare tools

Er zijn verscheidene tools op de markt die op het eerste zicht de gezochte functionaliteit bieden. MapForce (www.altova.com) en Gefeg.FX (www.gefeg.com) zijn tools die op dit vlak als vaste waarden mogen beschouwd worden.

De Belgische “Telebib2/Edifact” syntaxis is echter een dialect, een benadering van de “UN/Edifact” syntaxis, en wijkt er op een aantal elementaire punten van af.

De (historische) verklaring van deze situatie lijkt te zijn dat we in die mate “early adopters” geweest zijn, dat we dingen zijn gaan gebruiken die nog niet definitief vastgelegd waren, en die uiteindelijk op een andere manier vastgelegd werden.

In de mate dat we België als een eiland beschouwen kunnen we deze tools dus negeren.

De verzekeraar zit echter niet op dit ene eiland, hij is veelal aktief in verschillende landen, en zijn beslissingscentrum qua data- en systeem-architectuur ligt in vele gevallen elders.

Binnen die beslissingscentra streeft men naar “best practices” op een internationale schaal. (Bijvoorbeeld de gedachte: “think globally, act locally”.)

Op basis van deze gedachtegang bestudeerden we de functionaliteit van die tools.
We bestudeerden de verschillen qua syntaxis, en beschreven deze dan in functie van die tools, en we hebben dit dan overgemaakt aan beide firma’s.

Altova heeft onze vraag genoteerd en opgenomen in de lijst die periodiek voorgelegd wordt aan hun “technology committee”, echter zonder enige garantie qua beslissing noch termijnen.
Gefeg heeft ons een concrete offerte gedaan voor de nodige aanpassingen.

Als verzekeraar lijkt Altova MapForce ons een goede keuze als all-round tool voor alles wat met mapping te maken heeft (gesteld dat ons Telebib2/Edifact dialect ondersteund wordt).

Als Telebib centrum zijn we zeer sterk aangetrokken door de oplossing van Gefeg. De “gewenste aanpassingen” zoals hieronder beschreven zijn in grote mate (helemaal) geïnspireerd door wat we binnen die tool aantroffen.

Een bijkomend argument pro deze tools is dat wat betreft de migratie naar XML, deze voorzien in al het nodige om dergelijke stap op een coherente, gestructureerde manier te kunnen opbouwen.

De gewenste aanpassingen

Het is relatief eenvoudig de vraag te beschrijven op basis van de bestaande toestand. Het gevolg is echter wel dat de vraag dan gesteld wordt in termen van die bestaande toestand, in termen eigen aan de aanbieder van die bestaande toestand.
Hetgeen volgt veronderstelt eveneens dat de lezer kennis en inzicht heeft in wat de bestaande syntaxis is, zoniet zal men wat moeite hebben met het gebruikte jargon.

De EDI-Builder tool
Een MIG wordt aangemaakt op basis van een uitwisselingseenheid-template waaruit de segmenten opgepikt worden die men effectief in de MIG wenst op te nemen, met dien verstande dat men de verplichte segmenten zo wie zo moet opnemen.

De uitwisselingseenheid-template toont voor ieder segment zijn status verplicht/optioneel, en zijn multipliciteit. (rood vinkje = verplicht, blauw getal 9 = onbeperkte multipliciteit)

De template toont eveneens voor ieder segment de samenstellende delen (data-elementen, enkelvoudige en/of samengestelde) met hun status verplicht/optioneel, maar niet hun multipliciteit bij middel van een getal, wel bij middel van overeenstemmende multiple voorkomens.
(De verklaring hiervan is dat onze edifact-variante implementatie dateert van voor de “ontdekking” van de “data-element repetition indicator”. Aan de specifieke Edifact karakters + : ‘ ? is op een bepaald ogenblik de * toegevoegd met dergelijke betekenis.)

De template toont dan ook nog eens voor elk samengesteld data-element de samenstellende enkelvoudige data-elementen met hun status verplicht/optioneel, en hun multipliciteit bij middel van overeenstemmende multiple voorkomens.

De hier gebruikte notie “verplicht” moet begrepen worden binnen de hiërarchie waar ze zich voor doet. Een onderdeel kan verplicht zijn binnen een geheel dat op zijn beurt optioneel is; enkel als dat geheel er effectief is moet dat verplichte onderdeel er dan ook effectief zijn.

De template toont de informatie die besloten ligt in de syntaxis.

De MIG gaat nu, binnen de grenzen van deze syntaxis, bijkomende, engere grenzen, of restricties vastleggen. Op die manier distilleert men uit de quasi absolute vrijheidsgraad geboden door de zuivere syntaxis, de in de praktijk werkbare berichten waar de communicerende partners effectief iets mee kunnen doen.

De MIG toont voor ieder opgepikt segment, ieder samengesteld data-element, ieder enkelvoudig data-element de status “verplicht” zoals opgelegd door de syntaxis.

Voor elk in de MIG opgepikt segment, optioneel qua syntaxis, kan de MIG specificeren dat dit segment binnen deze MIG verplicht is. Dit moet verfijnd worden naar de mogelijkheden verplicht / aangeraden / optioneel / afhankelijk.

Voor elk in de MIG opgepikt segment, moet de MIG specificeren welke status elk data-element (samengesteld, enkelvoudig, en enkelvoudig binnen samengesteld) heeft.
Er moet dan nog één keuze toegevoegd worden: “niet gebruikt”.

De betekenis van deze termen.

En.	Nl.	Fr.	Betekenis
Mandatory	Verplicht	Obligatoire	De syntaxis stelt het gegeven verplicht.
Conditional	Conditioneel	Conditionnel	De syntaxis stelt het gegeven niet verplicht. De MIG zal dus vertellen wat er moet of kan gebeuren.
Required	Vereist	Exigé	De MIG stelt het gegeven verplicht.
Advisable	Wenselijk	Recommandé	De MIG stelt het gegeven niet verplicht, maar vraagt met nadruk het toch maar te leveren.
Optional	Optioneel	Optionnel	De MIG stelt het gegeven niet verplicht.
Not used	Niet gebruikt	Non utilisé	De MIG verbiedt het gegeven.
Dependent	Afhankelijk	Dépendant	De MIG stelt het gegeven verplicht in functie van de aanwezigheid en/of de specifieke waarde van een ander gegeven. Dit heeft enkel zin als men de voorwaarden precies kan beschrijven en valideren.

De MIG moet, voor ieder data-element, de karakteristieken opgelegd door de syntaxis, verder kunnen verfijnen, met andere woorden bijkomende restricties opleggen, zonder afbreuk te doen aan wat de syntaxis bepaalt.

• Alfanumeriek kan numeriek worden.
• Een lengte x kan korter worden (y mits y<x).
• Alfanumeriek tekenset x kan beperkt worden tot tekenset y (mits x={…(y)…}).
• Een waardenlijst kan minder waarden bevatten.

De MIG moet de aanwezigheid van data-elementen, of hun inhoud, afhankelijk kunnen stellen van andere aanwezige/afwezige data-elementen en hun inhoud.
In principe moeten hier onder meer de spelregels vervat in de “filters” mee kunnen gecontroleerd worden.
Dit vereist eerstens dat deze “andere data-elementen” eenduidig kunnen geïdentificeerd worden. Hiervoor moet de nodige techniek geconcipieerd worden.
Ten tweede moet een pseudo-taal geconcipieerd worden die toelaat de nodige te valideren regels voor te stellen. Men moet hier denken aan het gebruik van diverse operatoren, zoals daar zijn:

• Logische : AND | OR | NOT | XOR
• Comparatieve : = | < | > | <= | >= | <>
• Rekenkundige : + | - | * | /
• Verzamelingen : in [“a”,”b”,”c”]

De MIG moet voor dit alles ook voorzien in de mogelijkheid te bepalen wat het concrete resultaat is van een validatie, wat met andere woorden de eventuele boodschap is die verschijnt (of een fout-boodschap, of een verwittiging, of een constatatie). Hier komt idealiter ook een aspect “meertaligheid” bij te pas.

De databank
De databank zal de nodige wijzigingen moeten ondergaan, in functie van wat ontwikkeld wordt binnen de EDI-Builder tool, zodat de gehele informatie die een MIG omvat kan opgeslaan worden.
De EDI-Builder tool zal de aangepaste export-functionaliteit voorzien in de richting van de aangepaste databank.
De validatie-tool op zijn beurt dient zijn referentie-informatie te vinden in en te halen uit dezelfde databank.
Op deze manier komen we tot een sluitend, coherent geheel.

Idealiter worden alle bestaande export functionaliteiten in de EDI-Builder tool behouden en aangepast (Generate Edifact String / Generate HTML documents / Export for EDI traductor / Export for documentation / Export Mig to Access).

De validatie-tool
De validatie-tool laat toe de verzameling van MIGs in een overzicht te visualiseren.

De v-tool (validatie-tool) bekomt al dergelijke referentie-informatie uit de databank.

Net zoals de EDI-Builder tool een geheel vormt met de databank (aanmaak en export/opslag van referentie-informatie), vormt de v-tool een geheel met dezelfde databank (terugvinden en gebruiken van referentie-informatie).

De v-tool laat de import van een te valideren edi-string toe, hetzij via het openen van een bestand (bijvoorbeeld een *.txt bestand), hetzij via een copy/paste van de string zelf.

De te valideren string kan in de v-tool bekeken worden, eerstens in zijn ruwe vorm, ten tweede op een meer gebruiksvriendelijke manier.
Het minimum lijkt hier de voorstelling van één segment per lijn, in combinatie met indents die de gelaagdheid van de informatie weergeven.
De v-tool kan hier verder gaan qua gebruiksvriendelijkheid, het is aan de leverancier om hier intelligent en relevant gebruik te maken van wat in de referentie-informatie aanwezig is.
Denk hier aan het tonen van labels in aanvulling op codes, of aan het gebruik van kleur in functie van de status van data-elementen (oranje = Vereist / groen = Wenselijk / zwart = Optioneel).

De te valideren string kan dan in verband gebracht worden met de gepaste MIG, en op die basis kan een validatie-proces gestart worden.

Een validatie houdt in dat de edi-string qua inhoud vergeleken wordt met de MIG:

• De regels van de syntaxis worden gerespecteerd,
• De regels van de MIG worden worden gerespecteerd,
• Daar waar een specifiek gedefiniëerde foutboodschap relevant is moet deze uiteindelijk in een rapport verschijnen, inbegrepen de duiding waar precies binnen de gehele edi-string de anomalie zich voordoet. Idealiter verwijst dergelijke boodschap zowel naar de betrokken plaats in de edi-string, als naar de plaats in de MIG of in de van de MIG afgeleide documentatie.

In het geval de validatie geen afwijkingen constateert kan nog steeds een rapport gegeven worden met bijvoorbeeld als inhoud:

• Datum en tijdstip van de uitgevoerde test,
• Aantal bytes van de geteste string,
• Bestandsnaam van de geteste string,
• Per status, het aantal verwachte data-elementen, (*) (**) (***)
• En per status, het aantal effectieve data-elementen,
• Wat geeft per status, de verhouding effectieve/verwachte (een percentage).

De laatste drie zijn relevant voor het “volledigheidslabel” dat men uiteindelijk aan een MIG-implementatie wenst toe te kennen:

• Rood: fout – er ontbreekt verplichte informatie,
• Oranje: alle verplichte info is aanwezig,
• Groen: alle verplichte en alle aangeraden info is aanwezig,
• Goud: alle mogelijke info is aanwezig, ook de “optionele”.

Tegelijkertijd is de correcte/relevante telling van deze zaken vermoedelijk niet zo eenvoudig.

(*) Vanaf hier ontstaan concepten die ik tot nu toe in geen enkele tool of documentatie of conceptuele nota ben tegen gekomen. Zelfs Gefeg gaat niet zo ver. Dit gaat dus een bijkomende kost zijn.

(**) Ondertussen heeft de makelaardij dit nog een stapje verder doorgetrokken. Zij wijzigen de regel:
“Groen: alle verplichte en alle aangeraden info is aanwezig”
In:
“Groen: alle verplichte info is aanwezig, en van alle andere info is er voldoende aanwezig”.

Hierbij drukken zij deze “voldoende” uit in percentage “aanwezige andere info / potentiële andere info” (1), en geven deze waarde niet per geheel bericht, maar per logisch onderdeel van dat bericht (2). Denk hier aan verzekeraar / tussenpersoon / nemer / object / waarborg / …
Het gehele bericht krijgt dan een “volledigheidslabel” “groen” indien alle logische onderdelen hun specifieke “voldoende” behaalden.

Dit voegt nogmaals complexiteit toe, en zal dus de kostprijs nog verhogen.

(***) Op basis van (**) hierboven heeft Portima zijn tool aangepast, en vermoedelijk levert dit dan ook de gewenste functionaliteit (visie en concept komende van de makelaardij).

Het is echter niet zeker dat dit het gewenste “sluitend, coherent geheel” zal leveren, waar de validatie gefundeerd zit op dezelfde informatie(-databank), als deze die de documentatie oplevert, en die haar input krijgt van het Telebibcentrum en bij uitbreiding van de WGN.

Bijkomend slagen we er zo nog steeds in op ons “Telebib2/Edifact dialect”-eilandje te blijven. (operationele en tactische pro’s versus tactische en strategische contra’s)… .

20.01.2009 - De "Multilingual View" is nog wat verbeterd
Attributen en codelijsten worden nu ookweergegeven. Zie http://www.telebib2.org/ModelViewframeSet.asp.

20.01.2009 - Verder timmeren aan de weg
(Vervolg op de tekst dd. 14.11.2007.)
Na 14.11.2007 is er niet meer verder gewerkt aan dit document. Het Telebibcentrum is echter wel blijven timmeren aan de weg. Op de website, op de pagina http://www.telebib2.org/XSDs.asp, geven we onder de hoofding "Historical info" weer hoe de kennis en het inzicht zijn blijven evolueren, en hoe we kwamen tot wat we op die pagina onder de hoofding "Things as of today" voorstellen.

Het "lastenboek XML" is opgemaakt op basis van de kennis, de concepten zoals beschreven op die web-pagina. Dit zijn de dingen zoals uitgewerkt in de periode 25.10.2007 - 15.07.2008.

Het "lastenboek XML" zelf is opgesteld in de periode 10.07.2008 - 30.09.2008.

De laatste contacten met BVVM lijken gans dit verhaal echter terug in vraag te stellen. Dan toch op zijn minst wat betreft het aspect "nieuwe syntaxis 2 naast bestaande syntaxis 1".

Zelf blijven we overtuigd van de waarde van de notie "normalisatie, syntaxis-onafhankelijk en op basis van een model".

In de loop van maand 10.2008 hebben we dan nog de bemerking vanwege een it-consultant, betrokken in een telebib-project binnen een verzekeraar, nader bekeken. (Je kan niet alles tegelijk doen; op een bepaald ogenblik verkies je af te maken waar je mee bezig bent, in casu het lastenboek, en stel je andere dingen even uit.)

Van het ene kwam het andere en finaal komen we nu uit bij een variante aanpak die hetgeen het lastenboek beschrijft nogmaals wijzigt zoniet overbodig maakt.

Het komt er op neer dat we nu weten hoe we volgens de spelregels van een specifieke software-tool onze EDI berichten kunnen beschrijven en catalogeren, en hoe we dan met deze tool deze berichten kunnen mappen op allerhande andere berichten in allerhande andere syntactische systemen. Eén van deze andere syntactische systemen kan dan de xml-structuur zijn die we aanmaken via onze modelleringstool. (Het gaat hier over het implementeren van de Altova-Mapforce tool.) Binnen dit verhaal blijft er één op te lossen struikelblok; dergelijke toolset gaat uit van een 100% coherente implementatie van de algemene EDI-syntax, terwijl het Belgische Telebib2-EDI op een bepaald (elementair) vlak een dialect is. We gaan er van uit dat hier een mouw aan gepast kan worden.

13.01.2009 - Een actieplan 2009-2010

• 01/01/2009 - 23/09/2009: TB2-project for release 01.01.2011:
  De beslissing is genomen dat dit een "light release" is, die de verzekeraars de tijd geeft een inhaalbeweging te maken.
  De inhoud van deze release ligt niet vast, maar er is quasi beslist:
  • de ontbrekende definities aan te vullen;
  • de afwerking van de vertalingen in het Duits;
  • de IBP-vereisten te beantwoorden (Internet Broker Processes);
  • de notie "vrijstelling" verder te implementeren.
• 01/01/2010 - 22/09/2010: TB2-project for release 01.01.2012:
  In principe volgt er op de "light release" terug een zwaardere, volledigere release.
  De inhoud van deze release ligt niet vast, maar er bieden zich wel een aantal domeinen aan:
  • de elementen die de basis van de premieberekening uitmaken;
  • de collectieve verzekeringen, ongevallen, gezondheid en leven;
  • de vloten en de industriële risico's, het domein "ondernemingen".

Dit zijn de "projecten" in de lijn van de bestaande werking van het Telebibcentrum en zijn huidig operationeel kader.

Een fundamenteler actieplan blijft de uitwerking van de weg:

• waaraan in 2007 hoofdzakelijk conceptueel gewerkt is (waarover nagedacht en van gedachten gewisseld is);
• waarvoor in 2008 een eerste traject is uitgetekend en bewandeld;
• waar die eerste stappen nu al geleid hebben tot enkele bijsturingen en alternatieve keuzes.

Het resultaat is het plan, of het traject, zoals hieronder beschreven.

01/01/2009 - 31/12/2010:

• Normalisatie op basis van een model. (1)
• Generatie van XML XSD-schema's vanuit dat model. (2)
• Mapping van normalisatie-model-schema's versus bestaande Edifact(-dialect)-implementatie. (3)
• De mapping toont aan dat het model de huidige implementatie niet juist of onvolledig weergeeft;
  terug naar (1); dit is dus een iteratief proces.
• De mapping is volledig. (4)
• De Xml-syntax is nu een bruikbaar alternatief. (mijlpaal)
• Ontwikkel een finale versie van de meertalige presentatie van het model aan de zakelijke gebruikers. (5)
• Overtuig de zakelijke gebruikers te normaliseren op basis van een model; nu niet enkel bij middel van ideeën en concepten, maar bij middel van tools en werkmiddelen. (6)
• Publiceer releases bij middel van model-releases, inbegrepen hun afgeleiden. (7)
  In totaliteit zijn dat dan:
  • het model;
  • de Xml XSD-schema's;
  • de Edifact-implementatie;
  • en de mapping.
• Doe de maintenance van het model. (8)
• Doe de maintenance van de Edifact-implementatie. (8)
• Doe de maintenance van de mapping. (8)
• ? Geef de Edifact-implementatie (de maintenance van -) terug aan Portima?
• ? Geef de mapping (de maintenance van -) terug aan Portima?
• Mapping van de eEG7 SMILe3 model elementen op/in het Telebib-model. (9)

  SMILe : "Single Model of Insurance Lines for e-Business" :
  Wat Telebib is voor België, is Bipro voor Duitsland, is SIVI voor Nederland, .
  We brengen dat binnen eEG7 samen in SMILe.

Wat SMILe is voor de EG, is Acord voor de USA, is CSIO voor Canada, .
eEG7 en Acord brengen dat binnen UN/CEFACT-TBG8 samen in het P6 project.

En dat gaat dan op zijn beurt naar UN/CEFACT-TBG17.
( zie verder bijgevoegd schema / kader )

• De mapping vereist wijzigingen in hetzij eEG7 SMILe3, hetzij het Telebib-model; dit is input voor eEG7 en/of voor Telebib.
• De mapping is maximaal. (10)
• De "delta" van Telebib naar eEG7 is gekend en die kennis is gestructureerd en beheersbaar.
• Het eEG7 SMILe3 model is een subset van de UN/Cefact-TBG8 submission, submission die gecoördineerd wordt met Acord binnen de P6 werkgroep, en gericht is tot UN/CEFACT-TBG17.
• UN/CEFACT-TBG17 levert de uiteindelijke globale "Core Component Library" (CCL).
• Mapping van de CCL elementen op/in het Telebib-model. (11)
• De mapping is maximaal. (12)
• De "delta" van Telebib naar de CCL is gekend en die kennis is gestructureerd en beheersbaar.
  • Internationale (verzekerings-)softwareleveranciers, genre IBM, SAP en andere, integreren deze CCL in hun aanbod.
  • De kennis van de "delta" helpt dergelijk internationaal aanbod lokaal in te passen.
  • Omgekeerd kan de "delta" nationale leveranciers helpen in hun internationale ontplooiing.
  • Telebib kan zelf verder evolueren in de richting van de CCL, via aanpassingen aan, en/of uitbreidingen op basis van die CCL.

Is de Belgische makelaardij geïnteresseerd in dit verhaal? Zo ja, tot waar, indien niet in het volledige verhaal?

Heeft de Belgische verzekeraar interesse?
Deze die enkel in België opereert?
Deze die internationaal opereert?
Deze die zijn ICT lokaal ontwikkelt?
Deze die zijn ICT lokaal aankoopt?

Heeft de Belgische softwareleverancier interesse?
Leveranciers van pakketten voor de makelaardij? (Portima, CRM, Helix, LIS, .)
Leveranciers van platformen voor communicatie? (Portima, CRM, Binex, .)
Leveranciers van pakketten voor verzekeraars? (Vereycken & Vereycken met UL3, .)

Specifieke vraag omtrent de opvolging van internationale evoluties inzake normering; is er een dreiging dat Europa wordt overspoeld door Amerikaanse standaarden?

• Is dat een bedreiging?
  Vergeet niet dat eEG7 en Acord al samenwerken, via P6, in de richting van de globale Core Components Library.
• Voor wie?
  Verzekeraars / makelaars / ict-leveranciers / Portima-netwerk / Telebib?
• Amerikaanse standaarden = Acord (laten we daar van uit gaan)

Swift : herverzekeringsoperaties : Acord implementatie (weliswaar ex Rinet, ex London Market Writer's initiative)
Bipro (Duitsland) is goed bezig (met als basis eEG7 Smile3 en hun eigen inbreng terzake).
Wie ontwikkelt al op multi-nationale schaal, in het bijzonder met Duitsland?

31.12.2008 - Overzichtje activiteiten 2008

• Projectgroep Uitwisselingen Leven-Individuele: 9 sessies in 2008, Telebib Release 01.01.2010: cut-off en presentatie op 25/09/2008.
• Werkgroep Normalisatie : 2-maandelijkse sessies.
• Werkgroep Xml: 3 sessies in 2008.
• eEG7 European Insurance Industry e-Business Standards: 2-maandelijkse sessies, vanaf 2de jaarhelft gereduceerd tot 3-maandeljkse sessies.
• eEG7 European Insurance Industry e-Business Standards: vanaf 06.2008 opname functie "secretary".
• eEG7 P6 : opname van onze europese standaard, in de globale UN/Cefact-TBG8 standaard, in samenspraak met Acord: 2-wekelijkse telefoonconferenties plus 6-maandelijkse face-to-face meetings.
• Quick Wins 2008:
  • 01.2008 : Voorstelling aan de CMS-GOC van een systeem dat toelaat de implementatie van de releases door de verschillende spelers te catalogeren. Men is echter niet bereid hier klaar en duidelijk over te communiceren. (Zie wat betreft het voorgestelde systeem de web-pagina http://www.telebib2.org/ImplementationsA.asp.)

30.09.2008 - Van de Telebib2 UN/Edifact syntax naar de Telebib2 XML syntax
(We geven hier de essentie van de "RFP" weer, zoals gekend op die datum.)

Inleiding
Het Telebibcentrum staat in voor de definitie van de berichten uitgewisseld tussen makelaars en maatschappijen. Deze berichten worden vandaag uitgewisseld volgens de Telebib2-UN/Edifact standaard. Men wenst deze berichten te kunnen uitwisselen volgens een XML standaard, zonder echter deze of gene partij te verplichten de bestaande Edifact standaard te verlaten. Het Telebibcentrum heeft een Telebib2-XML standaard uitgewerkt, en heeft een concept uitgewerkt dat de bestaande standaard naast de nieuwe standaard plaatst, en dat éénduidige verbanden legt tussen de diverse voorkomende gegevenselementen.

Op basis van dit concept publiceert het Telebibcentrum een “Request for Proposal” (RFP) (“verzoek tot voorstel”) die vraagt naar:

• 1. software die berichten vertaalt van/naar Telebib2-UN/Edifact naar/uit Telebib2-XML;
• 2. de bruikbaarheid van dergelijke software door de diverse spelers die vandaag gebruik maken van de Telebib2-UN/Edifact standaard.

Belangrijke mededelingen, voorafgaande aan de lezing van zulke RFP:

• 1. Het Telebibcentrum publiceert sinds jaren al zijn informatie via zijn website. Er heeft zich in de loop der jaren een zekere gebruikersgemeenschap ontwikkeld rond dit ganse gebeuren. In de mate van het mogelijke richt deze RFP zich ook tot de lezer die nog niet met dit gebeuren vertrouwd is, maar toch gaan we ervan uit dat er al enige basiskennis aanwezig is.
• 2. Nogmaals, het Telebibcentrum heeft in dit stadium een concept uitgewerkt, en heeft dit concept tot op zekere hoogte getoetst. Het concept beschrijft als het ware het stramien dat we volgen in de uitbouw van onze vertalende woordenboeken “Telebib2-UN/Edifact -> Telebib2-XML” en “Telebib2-XML -> Telebib2-UN/Edifact”. Met andere woorden; we weten hoe we onze vertalende woordenboeken gaan opvullen, maar we moeten het weliswaar nog doen.
  In concreto moet eerstens de tabel, die de elementen van een MCI (Message Content Inventory) mapt op de elementen van het Model, volledig opgevuld worden. In concreto moet tweedens de tabel, die de elementen van een Telebib2-UN/Edifact-MIG (Message Implementation Guide) mapt op de elementen van een MCI, opgevuld worden.

De Telebib2-UN/Edifact syntax
De Telebib2 UN/Edifact syntax staat beschreven op de website van het Telebibcentrum, onder het gedeelte "Syntax Dependent Components" – "Telebib2 UN/Edifact Repository".

Onder "Introduction" zijn een "Gebruikersgids" en een beschrijving van de "Syntax" te vinden. Dit zijn essentiële documenten om tot een goed begrip van deze syntax te komen.
Onder "Directories" worden de de verschillende samenstellende elementen beschreven en gecatalogeerd.
Onder "MIGs" worden de diverse "Message Implementation Guides" gecatalogeerd.

Onder "Downloads" zit de mogelijkheid het bestand "Telebib2.zip" te downloaden, via het punt "Syntax dependent standards" > Telebib2-UN/Edifact > "Access data base". Dit bestand bevat de databank "Telebib2.mdb"; een access bestand.

Dit bestand bevat vandaag de basis-informatie waar de sector gebruik van maakt. Denk hier aan de in het kader van Assurnet/2 geboden functionaliteit.

De tabellen van deze databank hebben een Naam en een Omschrijving die duidelijk weergeven welke informatie waar aanwezig is. Het onderscheid tussen syntax-specifieke en niet-syntax-specifieke informatie is eveneens duidelijk weergegeven.

De Telebib2 XML syntax
De ontwikkelingen met betrekking tot de Telebib2 XML syntax staan beschreven op de website van het Telebibcentrum, onder het gedeelte "Syntax Dependent Components" – "Telebib2 XML Repository".

Onder "DTDs" staat informatie die de resultaten weergeeft van werkzaamheden die in het verleden werden uitgevoerd maar die om allerlei redenen niet tot finale resultaten geleid hebben. Begin 2007 is er eigenlijk beslist niet verder te gaan in dergelijke richting.

Onder "XSD Schema" staat informatie die de vandaag voorgestelde concepten beschrijft ("Things as of today") en hoe we tot dergelijke concepten gekomen zijn ("Historical info").

Het bestand "TB2Model.mdb" waarvan sprake op deze webpagina bevat de basisinformatie ten behoeve van de gevraagde ontwikkelingen.

De tabellen van deze databank kunnen in groepen ingedeeld worden en hebben tevens een Naam en een Omschrijving in die zin.

• Tabellen die de informatie komende van het Model bevatten.
  Om de informatie van het Model naar hier te brengen is er nog een tussenstap gemaakt via een "TELEBIB2_MCI.mdb" databank.
• Tabellen die de “Message Content Inventories” beschrijven.
  Inbegrepen het éénduidige verband tussen de inhoud van de MCI en de inhoud van het Model.
• De tabellen die de “Telebib2-UN/Edifact Message Implementation Guides” beschrijven.
  Inbegrepen het éénduidige verband tussen de inhoud van de MIG en de inhoud van de MCI.

Er zijn ook nog een 4-tal tabellen die de informatie komende uit de dBMain tool weergeven. Het is echter niet de bedoeling iets te ontwikkelen op basis van deze laatste 4 tabellen.

De "Access-Form" "F_MCI" geeft een visueel beeld van de manier waarop een gegeven van een MCI uiteindelijk éénduidig verband houdt met een gegeven van het Model. Het is duidelijk dat de enkele afgewerkte MCI’s slechts toelaten de concepten te toetsen, en dat er hier nog een zware workload ten laste van het Telebibcentrum ligt.
De tabel "t_Telebib2Model_MCIDetail" bevat hier de kern van de zaak; de éénduidige verbanden tussen MCI en Model.

De "Access-Form" "F_MIG" geeft een vergelijkbaar visueel beeld van de wijze waarop een gegeven van een MIG uiteindelijk éénduidig verband houdt met een gegeven van een MCI. Opnieuw is het duidelijk dat de enkele afgewerkte MIG’s slechts toelaten de concepten te toetsen, en dat er nog heel wat te doen is door het telebibcentrum.
De tabel "t_Telebib2Edi_MIG2MCI" bevat hier de kern van de zaak; de éénduidige verbanden tussen MIG en MCI.

De "Telebib2 XML Namespace 2008" waarvan sprake op de webpagina, en de "ROD060 v1" als eerste voorbeeld van "Message implementation Guide" in Telebib2-XML, geven dan weer wat de uiteindelijke tegenhanger is van het gelijkaardige bericht in zijn Telebib2-UN/Edifact syntax.

Vertalen van/naar de Telebib2-UN/Edifact syntax naar/van de Telebib2-XML syntax
Om de zaak nu nog concreter voor te stellen.

ROD060 (Gegevens gezin) staat beschreven in de MIGs Release 01.01.2007, en is niet meer gewijzigd.

In de Release 01.01.2010 MIGs Contracten vinden we diezelfde ROD060, met daar de mogelijkheid een voorbeeld te downloaden met bestandsnaam "ROD060_200901.edi".

De inhoud daarvan is de string in de Telebib2-UN/Edifact syntax.
XGH+1+X921:X922+X923:X924'XRH+1'ROD+060'NME+001+x--x'ADR+002+x--x:x--x:x--x::x--x:x--x+x--x+x--x+x--x'ATT+4100+x--x'ATT+4160+x--x'QTY+133:9--9'QTY+050:9--9'XRH+2'ICD+xxx'XRT+2'XRT+1'XGT+1'

Dikwijls maken we dergelijke string een ietsje meer leesbaar, maar dat doen we puur ten behoeve van de lezer.

• XGH+1+X921:X922+X923:X924'
  • XRH+1'
    • ROD+060'
    • NME+001+x--x'
    • ADR+002+x--x:x--x:x--x::x--x:x--x+x--x+x--x+x--x'
    • ATT+4100+x--x'
    • ATT+4160+x--x'
    • QTY+133:9--9'
    • QTY+050:9--9'
      • XRH+2'
        • ICD+xxx'
      • XRT+2'
  • XRT+1'
• XGT+1'

Anderzijds is ROD060v1.xml het overeenkomstig voorbeeld in de Telebib2-XML syntax.

• <?xml version="1.0" encoding="UTF-8"?>
• <tb2ent:Family xmlns:tb2ent="http://www.telebib2.org/Namespace/2008/Entities"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.telebib2.org/Namespace/2008/Entities
  http://www.telebib2.org/Namespace/2008/Entities.xsd">
  • <InsuranceObjectText>Janssens</InsuranceObjectText>
  • <InsuranceObjectTreatmentCode>1</InsuranceObjectTreatmentCode>
  • <InsuranceObjectChangeIndicator>1</InsuranceObjectChangeIndicator>
  • <SubsidiaryRiskObject></SubsidiaryRiskObject>
  • <FamilyTypeCode>1</FamilyTypeCode>
  • <PersonsTotalQuantity>4</PersonsTotalQuantity>
  • <ChildrenTotalQuantity>2</ChildrenTotalQuantity>
  • <CivilLiabilityPrivateLifeCoverType>11</CivilLiabilityPrivateLifeCoverType>
  • <OfficialAddress>
    • <AddressLanguageCode>1</AddressLanguageCode>
    • <StreetName>Jansstraat</StreetName>
    • <HouseNumberIdentifier>123</HouseNumberIdentifier>
    • <BoxNumberIdentifier>A</BoxNumberIdentifier>
    • <AddressExtension></AddressExtension>
    • <AddressIdentifier></AddressIdentifier>
    • <PostalCode>3570</PostalCode>
    • <CityCode>0</CityCode>
    • <CityName>Alken</CityName>
    • <CountryCode>B</CountryCode>
    • <CountryName></CountryName>
  • </OfficialAddress>
• </tb2ent:Family>

In het XML voorbeeld zijn concrete waarden ingevuld. Als we deze even overnemen in het Edifact voorbeeld krijgen we het vogende.

• XGH+1+X921:X922+X923:X924'
  • XRH+1'
    • ROD+060'
    • NME+001+Janssens'
    • ADR+002+Jansstraat:123:A:::+3570+Alken+B+'
    • ATT+4100+11'
    • ATT+4160+1'
    • QTY+133:4'
    • QTY+050:2'
      • XRH+2'
        • ICD+xxx'
      • XRT+2'
  • XRT+1'
• XGT+1'

...

26.03.2008 - "Model Tree View" vervangen door "Multilingual View"
We hebben deze views herwerkt en vervangen door iets performanters. Zie http://www.telebib2.org/ModelViewframeSet.asp.

31.12.2007 - Overzichtje activiteiten 2007

• Projectgroep Uitwisselingen Schade: 8 sessies in 2007, Telebib Release 01.01.2009: cut-off en presentatie op 17/10/2007.
• Projectgroep Uitwisselingen Leven-Individuele: opgestart 07/12/2007, 2 sessies in 2007.
• Werkgroep Normalisatie: maandelijkse sessies.
• Werkgroep Xml: opgestart 15/02/2007, 4 sessies in 2007.
• eEG7 European Insurance Industry e-Business Standards: 2-maandelijkse sessies.
• Quick Wins 2007:
  • Message Implementation Guides worden nu opgeleverd, inbegrepen voorbeeld-bestanden.
  • De website laat toe te "jumpen" van/naar Message Content Inventories naar/van Message Implementation Guides.
  • Ingebruikname van een Assurmember-Forum "Normalisatie".
  • Ingebruikname van een Assurmember-Forum "Leven-Individuele".

14.11.2007 - Projectgroep "Vie et individuelle / Leven en persoonlijke"
De Werkgroep Normalisatie kiest voor de definitieve benaming "Vie et Individuelle / Leven en Persoonlijke" (de vooropige naam was "Projectgroep Persoonlijke").

14.11.2007 - De standpunten van de diverse marktspelers
(Vervolg op de tekst dd. 18.10.2007.)

• Assuralia
  De verzekeraars kunnen vandaag blijkbaar leven met de bestaande Telebib2-UN/Edifact omgeving.
  Het lijkt er sterk op dat zij aanvaarden dat deze omgeving zich min of meer beperkt, enerzijds tot de standaardproducten (private lines), en anderzijds tot de standaardprocessen (overall kwijtingen en rekeninguittreksels, sales en claims in private lines), en dus niet inbegrepen de maatwerk-processen (sales en claims in commercial lines, en/of in specifieke product-segmenten).
  
  Zij zijn eerstens vragende partij qua analyse baten/kosten.
  
  Het Telebibcentrum krijgt vragen van systeem- en/of data-architecten rond het gegevensmodel.
  Er is minstens één verzekeraar die ontwikkelingen gestart heeft op basis van de gepubliceerde (draft-) DTD.
  Er is minstens één verzekeraar die ontwikkelingen doet op basis van het (syntaxis onafhankelijke) gegevensmodel.
  
  Meerdere verzekeraars (de meerderheid?) gebruiken binnen hun (interne) processen Xml technieken.
  
  
• Feprabel en FVF
  Binnen de hier besproken context is het onderscheid tussen Feprabel en FVF hoofdzakelijk te herleiden tot de gesproken landstaal. Daarom worden beide hier onder één punt besproken.
  
  Vermoedelijk kan er toch nog enig onderscheid gemaakt worden tussen enkele typeringen qua makelaarskantoor.
  
  De huidige Telebib2-UN/Edifact omgeving lijkt de behoeften van een eerste categorie redelijk goed te dekken. De gesprekspartners binnen deze categorie zijn business-mensen die eigenlijk geen boodschap hebben aan technische keuzes genre "Edifact of Xml".
  
  Een tweede categorie is deze die qua gebruikt beheerspakket neigt naar toegevoegde functionaliteit, al of niet via maatwerk. In deze zin kom je hier relatief kort bij de makelaars-leden van BVVM; daar zijn er zelfs makelaars met volledige maatwerk-systemen. De huidige Telebib2-UN/Edifact omgeving lijkt de behoeften van deze tweede categorie minder goed, minder volledig te dekken.
  Hiervoor kunnen misschien twee verklarende factoren gezien worden.
  • Grotere kantoren hebben systemen nodig die organisatorische problemen aanpakken. Denk aan consolidatie van boekhoudingen van bijkantoren, of nog aan beheer van onderagenten, .
  • Het zakenvolume uit standaardproducten (private lines) kan relatief aan belang verliezen tegenover het zakenvolume uit producten op maat (commercial lines, of specifieke product-segmenten).

Dit blijft echter nog altijd meer een "business-problematiek", waar de keuze "Edifact of Xml" eigenlijk minder relevant is.

• BVVM
  De leden van BVVM maken, behoudens uitzonderingen, gebruik van eigen ontwikkelingen of van systemen ontwikkeld op maat.
  
  Als het zakenvolume van een BVVM lid hoofdzakelijk komt van de verkoop van standaardproducten, dan is het te verwachten dat zijn systeem op maat zich concentreert op zijn organisatorische problemen, en dat zijn systeem op maat de beschikbaar gestelde standaard-tools integreert.
  
  Als het zakenvolume van een BVVM lid hoofdzakelijk komt van de verkoop van producten op maat, dan slaagt hij er meestal niet in de verkoop van standaardproducten volledig af te stoten. Het klassieke voorbeeld is de bedrijfsleider wiens private woning, familiale, bijstand, . dienen verzekerd te worden naast de verzekeringen ten behoeve van zijn bedrijf. Dit "noodzakelijke kwaad" is dikwijls moeilijk in te passen in de ontwikkelde eigen systemen. Eigenlijk is dit nu net het argument pro de maximale benutting van de door de leveranciers van standaardproducten geboden standaard-tools.
  
  In beide gevallen dienen de standaard-tools geïntegreerd te worden in bedrijfs-eigen systemen.
  
  Net zoals verzekeraars vandaag binnen hun (interne) proces-stromen hier en daar al Xml technieken gebruiken, is dit ook zo voor BVVM leden.
  
  Bij het BVVM lid dat zelf zijn systeem ontwikkelt hoor je niet langer alleen de stem van de "business-people", maar nu ook deze van de "(ict-)technical-people" (information and communication technology). Deze stem gaat in de richting van Xml en vermoedelijk eveneens modellering, net zoals dat het geval is bij de verzekeraars.
  
  Als het BVVM lid dan ook nog eens ressorteert binnen een internationale groep, met eventueel zijn specifieke technische normen, strategische keuzes en dergelijke, dan zijn dat meer dan waarschijnlijk zaken die de stem richting modellering en Xml versterken.
  Als dergelijke internationale groep dan al keuzes gemaakt heeft op basis van andere nationale standaarden dan de Belgische, of zelfs op basis van standaarden die zichzelf voorstellen als internationaal, dan is het meer dan begrijpelijk dat dergelijke groep een eventuele Belgische Telebib2-Xml standaard in vraag stelt.
  
  
• Portima, als operationeel platform
  AS/2 en AS/Web volgen de Telebib2 normen. Ook hier bestaan vandaag al enkele stapjes binnen de onderliggende proces-flows waar er sprake is van gebruik van Xml technieken.
  Indien men beslist dat binnen het Portima platform conversies gaan gebeuren van/naar de huidige Telebib2-UN/Edifact syntaxis naar/vanuit de Telebib2-Xml syntaxis, en als men dit dan beschouwt als een onderdeel van de baten/kosten analyse, dan is het precies de hoger in deze tekst beschreven mogelijke werkwijze die al een beetje informatie geeft ten behoeve van die (kosten-) analyse.
  
  
• Softwarehuizen
  Voor zover bekend, hebben de softwarehuizen relatief veel interesse in de mogelijke implementatie van Xml technieken.

25.10.2007 - een artikel in Assurinfo nr. 34.

Het artikel "Telebib2 één jaar". De inhoud stemt overeen met de tekst dd. 28.09.2007 hieronder.
De redactie van Assurinfo had het wat moeilijk met de inhoud daarvan. Men vond het qua inhoud te technisch, niet gericht op het doelpubliek. Ik heb het van op mijn terrein wat moeilijk met dergelijke reactie. Ik ben immers ook een lezer van Assurinfo, en ik kom dus ook artikels tegen die me qua inhoud zowel als qua jargon vreemd zijn...

18.10.2007 - de verdere uitwerking van een "sluitend geheel".
(De term "sluitend geheel" komt uit de tekst hieronder, dd. 01.10.2007.)

• de "Werkgroep Normalisatie" werkt op basis van een taal-eigen zicht op het gegevensmodel (dit noemen we cyclus-punt_1),
• de coördinator stopt de resultaten van het normalisatie-werk in het model via een modelleringstool,
• vanuit de modelleringstool kan een xsd-schema aangemaakt worden,
• van het xsd-schema kunnen de taal-eigen zichten afgeleid worden (voorbeelden hiervan zijn
  in het Nederlands http://www.telebib2.org/ModelTreeJNl.asp en
  in het Frans http://www.telebib2.org/ModelTreeJFr.asp ),
  • de "Werkgroep Normalisatie" ziet dan het resultaat van zijn werkzaamheden,
  • de "Werkgroep Normalisatie" kan met dat materiaal een volgende cyclus van werkzaamheden aanvatten (terug naar cyclus-punt_1),
• van het xsd-schema worden ook Access tabellen afgeleid die in Telebib2.mdb terechtkomen,
  • deze tabellen leveren de bouwstenen voor de MCI's (Message Content Inventories), een MCI is een tabel :
    

    Met vandaag de kolommen:	In de toekomst zou dit moeten zijn:
    New/updated/deleted	Te behouden informatie
    Data element (business)	Uitgedrukt in "business terminologie" Nl en Fr, conform aan taal-eigen zicht op gegevensmodel
    Code list - Indicator	Ik ben nog niet zeker of alles qua code-lists in het gegevensmodel moet geïntegreerd worden, of dat het zoals vandaag er naast mag blijven bestaan.
    Code list - Identifier
    Code list - Version
    Usage (mandatory/conditional/optional)	Te behouden informatie
    Condition(s)	Te behouden informatie
    XML-tag (echter vandaag nog niet gebruikt)	Te verwijderen informatie (*1*)
    UN/Edifact representation (including comments)	Te verwijderen informatie (*1*)
    (nu onbestaande) Data element (model-technisch)	Uitgedrukt in "technische terminologie", conform het gegevensmodel.

    (*1*) : de MCI is syntaxis-onafhankelijk; de MIG is syntaxis-specifiek; volgens mij dient de MIG te verwijzen naar de MCI, en niet omgekeerd; dit type informatie moet dus behoren tot, of deel uit maken van, de MIG.
    
    
  • deze MCI's liggen aan de basis van MIG's (Message Implementation Guides) in de Telebib2-UN/Edifact syntaxis,
    (25.10.2007 : foutje : aan de basis van een Telebib2-UN/Edifact MIG ligt de combinatie van MCI + Telebib2-UN/Edifact Directory.)
  • en deze zelfde MCI's liggen aan de basis van MIG's in de Telebib2-XML syntaxis,
  • omgekeerd, refereert de detailinhoud van een MIG eenduidig naar zijn MCI, dan is er sprake van een "mapping" van de MIG in syntaxis A van/naar dezelfde MIG in syntaxis B,
  • de bestaande Telebib2-UN/Edifact MIG's zouden dus moeten aangevuld worden met verwijzingen naar de MCI's (of juister, naar MCI-tabel-records),
  • en iets gelijkaardigs voor de Telebib2-Xml MIG's.
• wat zit er vandaag in telebib2.mdb in de MIG-beschrijvende tabel: te vervolledigen...
• van het xsd-schema (of uit de modelleringstool zelf) kan meer technisch getinte documentatie gegenereerd worden, ten behoeve van de softwaremensen,
  (http://www.telebib2.org/Namespace/2007/Development/Documentation/Schema/tb2BaseV03.html ) en
  (http://www.telebib2.org/Namespace/2007/Development/Documentation/Model/tb2BaseV03Umod.html )
• de gebruikte modelleringstool ondersteunt de standaarden voor uitwisseling van modellen (via "xmi" bestanden); techneuten kunnen dan het model in hun eigen tools importeren.

In deze voorstelling van zaken is er sprake van een herwerking van de (tabelmatige) representatie van de MCI's.
Ik ben daar echter nog niet aan toe, omdat alle "bouwstenen" nog niet aanwezig zijn.

Op dit ogenblik verfijn ik nog de inhoud van het xsd-schema qua aanwezige taal-eigen "business-terminologie" en "-definities".
Van zodra ik dit als voldoende volledig aanvoel wil ik :

• nog eens nadenken over het al of niet integreren van de Telebib2-waardenlijsten,
• alle, versus de huidige situatie Telebib2-UN/Edifact, ontbrekende "bouwstenen" toevoegen.
  Dit zijn eigenlijk alle dingen die in Telebib2-UN/Edifact bestaan, en die niet expliciet bestaan in het bestaande dBMain model.
  Bijvoorbeeld : er zijn meer dan 100 Guarantee-qualifiers (list X058) terwijl mijn "model-oriented documentation" voor Class "Guaranteetype" slechts +- 20 finale sub-classes geeft.

Als dat gebeurd is, kunnen de MCI's verfijnd worden door opname van de gepaste model-gerelateerde informatie (verwijzingen naar de passende bouwstenen).

En als dat gebeurd is, kunnen de Telebib2-UN/Edifact MIG's verfijnd worden door de opname van de verwijzingen naar de passende MCI-tabel-records. (Hier vermoed ik te zullen moeten werken met tussenliggende tabellen, omdat het niet zonder meer mogelijk is de tool "EDI Builder" aan te passen zodanig dat deze die bijkomende informatie kan beheren.)

De Telebib2-Xml MIG's kunnen dan afgeleid worden van de MCI's, wetende dat de Xml-tags overeenkomen met de "technische terminologie" van het model. Wat de tool "EDI Builder" hier doet voor de Edifact berichten, op basis van de telebib2.mdb, kan een tool zoals Altova XMlSpy doen voor de Xml berichten, op basis van het basis-model-schema (vandaag het bestand http://www.telebib2.org/Namespace/2007/Development/Telebib2BaseV03.xsd).

Dan moet er nog gekeken worden of er een expliciet mappende tabel nodig is in de richting Xml-MIG's -> MCI's.

Dan moet er gedacht worden aan "converting" op belgisch, sectoraal niveau.

Dan kan er eveneens gedacht worden aan "converting" op/naar andere (xml-)omgevingen.

Laat deze "verdere uitwerking" nu al toe op een gefundeerde wijze te evalueren wat de baten/kosten zijn van de stap richting Xml?

Ik ben daar op dit ogenblik nog niet zeker van.
Het lijkt me eveneens wenselijk in groep verder te praten over wat de realistische termijnen zijn om dergelijk verhaal te realiseren.
Deze termijnen zij belangrijk, omdat deze de internationaal georiënteerde makelaar toelaten in te schatten wanneer en in welke mate hij synergieën kan verwachten qua implementatie/connectie/. met systemen die als basis andere standaarden hebben.

01.10.2007 - Normalisatie in een omgeving met één syntaxis.
De leden van de "Werkgroep Normalisatie" hebben tot vandaag slechts te maken gehad met onze Telebib2-UN/Edifact syntaxis. De oorspronkelijke coördinator heeft van in het begin gewezen op, en is herhaaldelijk teruggekomen op het bestaan van een syntaxis onafhankelijke visie op het ganse gebeuren.

De tot op heden beschikbare technologische hulpmiddelen, met name de software tools bedoeld om te modelleren, beantwoorden blijkbaar niet aan de noden en/of mogelijkheden van de businessmensen. Businessmensen die met veel gevoel voor sectorale collegialiteit heel wat tijd en energie investeren in iets waarvan de directe return niet altijd even makkelijk te duiden is. Deze zin staat hier om duidelijk te maken dat schrijver dezes niet de minste kritiek wenst te uiten op de geleverde inspanningen; laat hierover geen enkel misverstand ontstaan.

We wensen echter wel te begrijpen hoe het komt dat het syntaxis onafhankelijke deel van de Telebib2 informatie relatief weinig gebruikt wordt binnen de "Werkgroep Normalisatie".

Een eerste argument is dat praktijkmensen zich richten op hetgeen waar zij in hun praktijk dagdagelijks mee te maken hebben. En in dit geval is dit de bestaande berichtgeving in de Telebib2-UN/Edifact syntaxis.

Een tweede argument betreft eenvoudigweg de gebruikte taal. De Telebib2-UN/Edifact syntaxis is aan zijn basis weliswaar opgebouwd uit acroniemen van telkens 3 letters met een Engelstalige inslag. Maar de verdere/diepere consultatie van dat deel van de website geeft al snel de nodige meertalige terminologie weer waar deze acroniemen voor staan. Op die manier kan de "Werkgroep Normalisatie" hetgeen waar hij dagdagelijks mee te maken heeft, ook nog eens in zijn dagdagelijkse taal behandelen.

Dit is niet het geval voor de onderdelen "Dictionary" en "Models" van de "Syntax Independent Components". De hier geboden informatie is ééntalig Engels.


Normalisatie in een omgeving met twee syntaxi
De premisse dat het eigenlijke "normalisatiewerk" los staat van een implementerende syntaxis wordt door de "Werkgroep Normalisatie", op zijn minst als theoretisch concept, aanvaard.

Eén of andere XML syntaxis doemt stilletjes aan op aan de verre/nabije horizon.

Daar waar de business mensen nog niet doordrongen zijn van het concept van modellering als basis van programmering, geeft de woordcombinatie "model based programming" in Google 71.400.000 hits.

Binnen de informaticadiensten en de softwarehuizen behoeven modelleringstools geen verdere uitleg. Dergelijke tools worden daar dagdagelijks gebruikt.

Het risico nemende dat dit verhaal te technisch wordt, stellen we dat in de praktijk "normalisatiewerk" dat zich baseert op een implementerende standaard, door de eigenheden van deze standaard beïnvloed/gekleurd wordt. Er worden op bepaalde ogenblikken keuzes gemaakt, beslissingen genomen, in functie van die implementerende standaard.
Concrete voorbeelden hiervan kunnen gezien worden in de Telebib2-UN/Edifact waardenlijsten X052, de tabel "risico-objecten", en X058, de tabel "waarborgen". In beide gevallen is het alsof er geprobeerd is in ééndimensionale verzamelingen dingen naast elkaar te zetten, dingen die veelal onderling hiërarchische verbanden lijken te hebben. (Bijvoorbeeld: terrein en werf, inboedel en inhoud en materieel, .)

• Maandag 08.10.2007. Commentaar van Luc Sterck.
  Ik vind je initiatief om deze nota te schrijven zeer goed. Het is belangrijk zo nu en dan eens de balans op te maken.
  Ik merk dat er behoorlijk wat vooruitgang is geboekt het afgelopen jaar. Het lijkt mij dat vooral de inhoud van de website sterk geëvolueerd is. Natuurlijk valt het mij ook op dat er nu meer aandacht wordt geschonken aan de meer technische aspecten. Dat zal voornamelijk te maken hebben met het feit dat jij een een meer technisch profiel hebt dan ik. Nu, dat is natuurlijk niet erg. Elk vogeltje zingt zoals het gebekt is. Belangrijk is echter wel dat je de taal spreekt van de meerderheid van de gebruikers waarmee je de vergaderingen beleeft en zeker van de voortrekkers daaronder. Belangrijk is ook dat er voldoende aandacht blijft voor de definities van de gegevens. Hoe dan ook, "keep on going".
• Maandag 29.10.2007. Commentaar van Paul-Emmanuel Casier.
  Ik nam je nota een paar keer door. Het vroeg wat oefening om er weer in te komen.
  Je ontwerp van onderscheid tussen de business terminologie en de technische terminologie beantwoordt (althans wat mij betreft) aan een stille verzuchting van lange jaren. Ik wil graag geloven dat die brug tussen de professionele realiteit en de onderliggende techniek meer mensen uit de business ertoe zal bewegen zich actief te bezinnen over een behoorlijke structurering en intellectuele onderbouw van hun eigen activiteit en zich daarom ook meer voor de correcte benoeming van de dingen zullen interesseren.
  Zelf ben ik grote voorstander van een normalisering die onafhankelijk is van enige syntaxis. Het zorgt voor meer openheid en transparantie en vormt derhalve een grotere kans op meer ontwikkeling en meer dynamisme.
  En ja, het vergt allemaal meer inspanningen nu - voor meer creativiteit en productiviteit straks.

28.09.2007 - Een terugblik op het eerste jaar op eigen benen.
Vrijdag 28.09.2007. - Het is nu tijd om even terug te kijken op het voorbije jaar; de eerste 12 maanden "op eigen benen" zijn immers voorbij.

Release 01.2009
De release 01.2009 is afgehandeld en woensdag 17.10.2007 volgt de officiële presentatie. Net zoals ondervonden in de allerlaatste fase van de afsluiting van de release 01.2008, zijn er ook nu enkele "last-minute" onzekerheden; met name de nog niet bereikte consensus rond het al of niet opnemen van de "ingesloten documenten" in deze nieuwe release. Het werk van de "Projectgroep Schade" is op een ordentelijke manier verlopen, en zijn conclusies vinden nu hun weerslag in het materiaal dat op onze website gepubliceerd wordt. De gepaste dank is verschuldigd aan alle deelnemers aan de diverse vergaderingen, zowel deze van de "Projectgroep Schade", als deze van de "Werkgroep Normalisatie".

Contacten met marktspelers
In de loop van de voorbije 12 maanden werden enkele eerste concrete contacten gelegd met belanghebbenden binnen ons samenwerkingsverband. Dit was slechts een aanzet tot initiatieven die zeker moeten volgehouden worden. De doelstelling is hier een antwoord te vinden op vragen in de stijl van "Wat zijn de wederzijdse verwachtingen?", of nog; "Wat kan het Telebibcentrum concreet voor u doen?".

Eén van de concrete resultaten van deze gesprekken is dat er nu, ter gelegenheid van de release 2009, bijkomend materiaal opgeleverd wordt.
. Zoals voorheen worden de MCI's (Message Content Inventories) geleverd; dit is de syntax-onafhankelijke voorstelling van de uit te wisselen berichten.
. Zoals voorheen worden de MIG's (Message Implementation Guides) geleverd; dit is de Telebib2-UN/Edifact syntax-specifieke voorstelling van de uit te wisselen berichten.
. Nieuw zijn de voorbeeld-bestandjes die samen met deze Telebib2-UN/Edifact MIG's geleverd worden. De bedoeling is dat deze voorbeelden de ontwikkelaars bijkomende hulp en/of inzicht geven in de te leveren implementatie.

Dagdagelijkse contacten
Binnen de opeenvolgende vergaderingen van de "Projectgroep Schade", en binnen de periodieke vergaderingen van de "Werkgroep Normalisatie" werden eveneens voor verbetering vatbare punten opgemerkt.

Sinds enige tijd beschikbare (kleine) extra's zijn ondermeer:
. de mogelijkheid de web-pagina "MCI's" te sorteren op basis van de releases;
. de mogelijkheid om in de web-pagina "MCI's" de met een MCI overeenstemmende MIG aan te klikken;
. de mogelijkheid om in een individuele MCI-web-pagina de overeenstemmende MIG aan te klikken;
. en omgekeerd, de mogelijkheid om in een individuele MIG-web-pagina de overeenstemmende MCI aan te klikken.
Dit alles maakt een wat soepelere consultatie van de geleverde informatie mogelijk.

En verder, binnen het onderdeel "Syntax Dependent Components - UN/Edifact Repository - Directories":
. de pagina "Qualifier / Code lists" eveneens te bekijken per "gekwalificeerd segment";
. en daar kan je dan ook nog eens doorklikken naar dezelfde lijst, maar dan viertalig;
. en daar kan je dan nog eens doorklikken naar wat voor de betreffende code vermeld staat in de "Syntax Independent Components - Dictionary".
Dit alles nogmaals ten behoeve van de vlotte consultatie van de geleverde informatie.

Binnen de "Syntax Independent Components - Dictionary":
. de functie "Search the dictionary" zoekt niet langer enkel op de kolom "Name", maar op de volledige inhoud van de tabel;
. en de dan getoonde resultaten zijn eerst gerangschikt op "Type" en dan pas op "Name".
Dit laat bijvoorbeeld toe een UN/Edifact-gegeven vlotjes te lokaliseren in de Dictionary.

Binnen de "Syntax Independent Components - Models - Data Model - Browse the model - Entity List":
. een alternatieve sortering van de tabel, eerst op de "Parent entity", en dan pas op de "Entity name".
Dit geeft een iets beter zicht op de hiërarchie van de gegevens.

Binnen de "Syntax Independent Components - Code lists":
. een rood vraagtekentje duidt het ontbreken van een definitie aan, men moet dus niet meer doorklikken om dat dan pas achteraf te moeten constateren;
. het al of niet bestaan van de Duitstalige en Engelstalige omschrijving is nu onmiddellijk zichtbaar;
. hetzelfde rode vraagtekentje wordt gebruikt op de onderliggende pagina met de coderingen van een individuele codelijst;
. en ook daar worden de Duitstalige en Engelstalige omschrijvingen onmiddellijk weergegeven.

Assurmember - Forum
Op basis van besprekingen in de "Werkgroep Normalisatie" hebben we op 27.03.2007 het forum "Productiviteit - Werkgroep Normalisatie" in gebruik genomen.
Sindsdien werden een 14-tal onderwerpen via deze weg behandeld. Het is duidelijk gebleken dat dit de groepsgewijze communicatie en beslissingen vereenvoudigt. Het lijkt erop dat dit heel wat impact heeft op het verloop van periodieke vergaderingen van de "Werkgroep Normalisatie", in de zin dat de te behandelen onderwerpen meer en beter op,voorhand gekend zijn, en dat er dus sneller kan beslist worden.

RSS
De fervente web-surfers onder ons kennen ondertussen het gebruik van dergelijke "news-feeds". De bijwerkingen aan onze web-site worden nu ook op deze manier meegedeeld. Aan u dus om u hier op in te schrijven via de door uw browser geboden functionaliteit.

(Op basis van dit eerste deel is in Assurinfo Nr. 34 dd. 25.10.2007 het artikel "Telebib2 één jaar "op eigen benen" verschenen.)

En nu verder?
- Levensverzekeringen, Gezondheidszorgen, Persoonlijke Ongevallen, Financiële Producten.
- Waarborgen, Sub-waarborgen, Dekkingen.
- Uitbreidingen, Uitsluitingen.
- Dekkingslimieten, Vrijstellingen, Berekeningsbasissen.
- XML: een andere syntaxis naast en/of in vervanging van de Telebib2-UN/Edifact syntaxis.
Dit is in grote lijnen de lijst van onderwerpen waarbinnen we voor de nabije toekomst keuzes moeten maken qua investering van tijd en energie.

"Projectgroep Persoonlijke"
Bij gebrek aan een definitieve naam, en in functie van de finale scope van deze volgende projectgroep, geven we hem voorlopig deze naam.
De doelstelling is de verdere detaillering van de gegevens nodig voor de verwerking van contracten binnen de takken Leven, Gezondheid, Persoonlijke Ongevallen, en de (verwante) Financiële Producten, en dit alles beperkt tot de individuele contracten.
Deze projectgroep zal in de loop van de maand oktober opgestart worden; alle kandidaturen zijn welkom.

"Werkgroep baten/kosten XML"
Waar onze gebruikelijke "projectgroepen" ressorteren onder onze "Werkgroep Normalisatie" is dit hier niet hetzelfde.
De CMS/GOC (Comité Mixte de Suivi / Gemengde OpvolgCommissie) wenst in eerste instantie dat deze werkgroep een antwoord formuleert op de vraag qua verhouding baten/kosten van een dergelijke stap.
Men kan deze baten/kosten bestuderen als verzekeraar, als makelaar, als softwarehuis, als beheerder van een centraal platform.
In een eerste fase is herhaaldelijk geopperd dat de mogelijkheid om terug te vallen op andere dan de Belgische Telebib2 standaard dient onderzocht te worden; de analyse qua baten/kosten kan dan daarna op een gefundeerde manier gebeuren.
De CMS/GOC heeft echter duidelijk te kennen gegeven dat men vasthoudt aan de Telebib2 standaard.
Ondertussen hebben we het op de website beschikbare materiaal uitgebreid. Waar dat tot voor kort slechts bestond uit een "DTD" (met excuses voor het hier gebruikte technische jargon), hebben we dat nu aangevuld met een eerste versie van een "XSD" schema, inbegrepen een documentatie-set aangemaakt via een professionele software-tool.

• Overname activiteiten Luc Sterck: voorzien in continuïteit.
• Projectgroep Boekhoudkundige Uitwisselingen: Telebib Release 01.01.2008: cut-off en presentatie op 25/09/2006.
• Projectgroep Uitwisselingen Schade: opgestart 30/05/2006, 8 sessies in 2006.
• Werkgroep Normalisatie: maandelijkse sessies.
• eEG7 European Insurance Industry e-Business Standards: 2-maandelijkse sessies.

15.06.2006 - The Telebib Centre is repositionned: from Portima to Assuralia.
On 15.06.2006 Michel Bormans joins the Telebib Centre. As had been agreed by the different actors in the field, this is the moment for starting the relocation of the Centre. By the end of september 2006 the relocation is a fact.

29.09.2003 - Thinking of discrete steps versus fluidity.
Me trying to picture the situation "as is" versus "as should be". This is a powerpoint presentation with the file name WIP-View-Evolutive_20130924.pps.
(24.09.2013 - One note added stating why messages received by some actor should not be discarded/deleted too soon.)

00.05.1990 - For the sake of history : Telebib1.
We have an Excel file grouping all Telebib1 info.