Home

Cuisine Call it a blog, a laboratory, a kitchen, whatever... Here, the co-ordinator of the Telebib centre offers the possibility to participate in his stream of consciousnesss. His native language being Dutch makes that a lot of the material presented will be in Dutch. It is what it is.
It must be absolutely clear that this is all ment to be "food for thought", and by no means has any agreed directive value.
All reactions are welcome, by e-mail.

18.11.2014 - Archief Werkgroep Normalisatie
De Werkgroep Normalisatie komt in principe maandelijks samen. We beschikken over de rapporten van deze vergaderingen tot en met 2002.
Regelmatig wil men weten wat in het verleden over één of ander onderwerp besproken werd.
Om dit zoekwerk makkelijker te maken groepeerden we alle rapporten in één enkel document.


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.


20.02.2014 - TB2-Edifact Validatie...
Sinds 05.04.2012 stelt het Telebibcentrum een eigen validatie-tool ter beschikking. Zoals op 05.04.2012 vermeld, gaat het 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" ontwikkeld door Portima, toch nog toegevoegde waarde heeft. In deze "Validatie pagina" is nu een kleine correctie gebeurd rond de controle van de eind-tag "XGT". Merk op dat het nog steeds niet de bedoeling is dat je hier bestanden van honderden megabytes groot gaat mee testen...


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.


1.03.2013 - Principium 2013 n° 3 - Artikel...
De voorzitter van onze Werkgroep Normalisatie publiceerde een artikel rond Telebib2.


7.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.
Artikel 30 van deze tekst zegt dat dit van toepassing is vanaf 01/01/2013.
Punt 14 van de inleiding stelt dat nationale standaarden ondergeschikt worden aan Europese of andere hogere standaarden, in die mate dat men zijn nationale standaarden op een gegeven ogenblik moet opgeven ten voordele van de meer internationale standaard.
Hoofdstul II - Artikel 3 - Punt 6 stelt dat men, van zodra een hogere/internationale standaard goedgekeurd en aanvaard is, de lagere/nationale standaard die daar niet volledig op aansluit niet langer mag reviseren of vernieuwen, maar dat deze dan binnen redelijke termijnen moeten terug getrokken worden.

17.12.2012 : dixit de juristen van Assuralia, handelt de verordening niet over sectorale normalisatie-instellingen. Er lijkt dus geen echte implicatie te zijn voor Telebib2.
 


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. ..."
JSON is in die zin slechts één van de mogelijke "specifieke platformen", en eigenlijk stelt het Telebibcentrum zich deze vraag niet, gezien we precies trachten onafhankelijk van de implementatie te blijven.

We hebben als oefening een XML-structuur getransformeerd naar een JSON structuur bij middel van de jsonml.xslt transformatie.

Noteer eveneens dat een tool zoals (Altova-)XMLSpy JSON volledig ondersteunt en toelaat om zeer vlot van en naar XML te switchen...


11.10.2012 - Artikel in Assurinfo...

Over Legoblokjes en Tiense suikerklontjes
In het artikel in Assurinfo nummer 9 van 8 maart “Verbeterde polisadministratie hoge prioriteit voor verzekeraars” schetst Jan Verlinden van Capgemini België het beeld van de verzekeraar die de transformatie van zijn polisadministratiesysteem als een topprioriteit ziet. De ontwikkeling van nieuwe systemen via projecten die jaren aanslepen kan vervangen worden door de ontwikkeling en het (her-)gebruik van meer eenvoudige basiselementen waarmee dan de meer complexe constructies mogelijk worden. Hier maakt men in het artikel van 8 maart de vergelijking met Legoblokjes.

Welnu, neem tien (Deense) Legoblokjes en stapel ze op elkaar, en je krijgt een stevig bouwsel.

En doe je hetzelfde met tien suikerklontjes van bij onze nationale trots, de “Tiense Suikerraffinaderij”, dan krijg je in het beste geval een wankel stapeltje.

Het verschil zit hem natuurlijk in de fameuze nopjes die maken dat de blokjes zo mooi in elkaar klikken, en tegelijkertijd ook weer vlotjes uit elkaar gehaald kunnen worden.

De focus gaat in het artikel van 8 maart naar de inhoud van de verschillende blokjes (verschillende basis-systeem-elementen met elk een stukje functionaliteit) die dan samen complexe systemen kunnen vormen.

De flexibiliteit van zo een systeem heeft dan weer alles te maken met het vlotjes uit elkaar halen en dan weer anders samen stellen van de verschillende modules.

Als het raakvlak tussen de modules nu iets is als bij een stapeltje suikerklontjes, dan ziet het er niet goed uit; probeer er maar eens eentje tussenuit te halen zonder dat alles uit elkaar valt.

Als dat raakvlak echter iets is zoals de uniforme, gestandaardiseerde Lego-nopjes, dan gaat dat stukken beter, en dan kan je inderdaad je stapeltje in twee delen breken om dan een blokje van het midden naar de top van het stapeltje te verplaatsen en dan alles terug samen te klikken.

De “nopjes” zijn in dit verhaal cruciaal.

De Telebib2 standaard staat vandaag voor die “nopjes” binnen onze sector, en dan nog hoofdzakelijk binnen het makelaarskanaal. De AS/Web modules die de verzekeraars in deze omgeving aan de makelaars geven, en de beheerpakketten van die makelaars, zijn verschijningsvormen van de “blokjes”.

Als verzekeraars krijgen we vanuit veel verschillende hoeken vragen, om niet te zeggen eisen, richting één of andere standaard. We moeten ons conformeren aan Telebib2, aan rapporteringen aan onze controle-instanties NBB en/of FSMA, Sigedis, Veridass, Kruispuntbank en zovoort.

Waar het Telebib2 centrum aan werkt in België, heet BiPro in Duitsland, SIVI in Nederland, en Acord in de Verenigde Staten en op de London Market. Deze organisaties komen samen in een overlegplatform onder de noemer “eEG7″ dat op zijn beurt deelneemt aan UN/CEFACT, de organisatie van de Verenigde Naties die zich toelegt op standaarden van elektronisch zakendoen.

Op http://tfig.unece.org/ is een mooie set “high level” informatie te vinden die de weg wijst in deze materie.
Une histoire de blocs Lego et de morceaux de sucre de Tirlemont
Dans un article publié dans Assurinfo n° 9 du 8 mars 2012 intitulé “Améliorer la gestion des contrats, priorité absolue“, Jan Verlinden de Capgemini Belgique esquisse l’image de l’assureur qui voit la transformation de son système de gestion des polices comme une priorité absolue. Le développement de nouveaux systèmes par le biais de projets qui mettent des années à se concrétiser peut être remplacé par le développement et l’utilisation (ou la réutilisation) d’éléments de base plus simples permettant ensuite les constructions plus complexes. À cet égard, l’article du 8 mars fait la comparaison avec les célèbres blocs Lego.

Prenez dix blocs Lego (danois), empilez-les les uns sur les autres et vous obtiendrez une solide petite construction.

Faites la même chose avec dix morceaux de sucre de notre fleuron national, “la sucrerie de Tirlemont”, et vous obtiendrez dans le meilleur des cas une petite tour en équilibre instable.

La différence réside évidemment dans les fameux tenons qui font que les blocs s’emboîtent si parfaitement l’un dans l’autre et peuvent en même temps aussi être rapidement séparés l’un de l’autre.

L’article du 8 mars met l’accent sur le contenu des différents blocs (plusieurs éléments de base d’un système ayant chacun leur part de fonctionnalité) qui peuvent constituer ensemble des systèmes complexes.

La flexibilité de ce type de système est entièrement liée à la possibilité de séparer rapidement les différents modules les uns des autres et de les réassembler ensuite différemment.

Si l’assemblage entre les modules ressemble à une pile de morceaux de sucre, vous risquez d’avoir quelques problèmes : essayez seulement d’en retirer un au milieu sans que le tout ne s’écroule !

Toutefois, si cet assemblage s’effectue de la même manière qu’avec les tenons Lego standardisés et uniformes, cela se passera beaucoup mieux et vous pourrez alors effectivement casser votre pile en deux pour ensuite déplacer un bloc du milieu au sommet de la pile et tout réassembler.

Les “tenons” jouent un rôle crucial dans cette histoire.

Le standard Telebib2 veille actuellement à ces “tenons” au sein de notre secteur , et principalement au sein du courtage. Les modules AS/Web que les assureurs fournissent dans cet environnement aux courtiers et les progiciels de gestion de ces courtiers sont des manifestations des “blocs”.

En tant qu’assureurs, nous recevons de toutes parts des demandes, pour ne pas dire des exigences, concernant l’un ou l’autre standard. Nous devons nous conformer à des normes telles que Telebib2 ainsi qu’aux reportings à nos instances de contrôle, la BNB et/ou la FSMA, Sigedis, Veridass, la Banque-carrefour et d’autres encore.

Les tâches qui sont assumées par le centre Telebib2 en Belgique le sont par BiPro en Allemagne, SIVI aux Pays-Bas et Acord aux États-Unis et sur le marché de Londres. Ces organisations se réunissent au sein d’une plateforme de concertation appelée “eEG7″ qui participe quant à elle à l’organisation UN/CEFACT.

Sur le site Internet http://tfig.unece.org/, vous trouverez un bel éventail d’informations de haut niveau qui ont pour objectif de vous familiariser avec ces domaines.

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 TC 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" 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: 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 :

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:

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.

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:

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:

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

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

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

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:

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

01/01/2009 – 31/12/2010:

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?

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


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:

Belangrijke mededelingen, voorafgaande aan de lezing van zulke RFP:

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.

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.

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

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

...


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


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.)

Nogmaals, deze nota geeft de interpretatie van de coördinator weer; dit is geen in enige werkgroep goedgekeurde tekst. Eén en ander is op 14.11.2007 geïntroduceerd binnen de CMS-GOC (Gemengde OpvolgCommissie) en werd overgemaakt aan de voorzitter, verdere respons is nooit gekomen.

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


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.)

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 :

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, …)

Normalisatie op basis van een model
Vandaag geven we de "Werkgroep Normalisatie" een zicht op een "model": In de geboden zichten ontbreekt op dit ogenblik nog de "business terminologie" voor wat "attributen" zijn binnen de "Syntax Independent Components". Rome is niet op één dag gebouwd.

De vraag is of dergelijk materiaal een werkbare basis kan zijn voor de "Werkgroep Normalisatie".
De verwachting is dat deze vraag pas kan beantwoord worden als de inhoud gelijk is aan (op hetzelfde niveau staat als) de inhoud van de Telebib2-UN/Edifact Directories. Vergelijk de inhoud van waardenlijst X058, de waarborgen, met de inhoud van de folder "Guaranteetype". Nogmaals; wat vandaag niet in de "Syntax Independent Components" bestaat, krijg je dus ook niet in deze zichten te zien.

De uiteindelijke doelstelling is te komen tot een sluitend geheel: Conclusie
Zoals verwacht is deze tekst wat te technisch geworden. Toch denken we dat er binnen iedere marktspeler mensen aanwezig zijn die op basis van deze tekst een beeld krijgen van waar we voor staan.
Aan deze mensen de uitnodiging tot reflectie en eventuele reacties.

michel.bormans@telebib2.org

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.


31.12.2006 - Overzichtje activiteiten 2006

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.