De validatie in de huidige StuF EF berichten is vrij summier. De XML schema's (XSD bestanden) valideren alleen op lege velden. Validaties op email, BSN, telefoonnummer, maximale lengte veld, etc. komen nu niet voor in de schema's. Graag zien wij als leverancier van GEMMA formulieren deze validaties terug komen in de schema's, omdat wij zo veel mogelijk tegen de standaard aanwillen programmeren. Stel het telefoonummer veld moet in de toekomst ook Belgische telefoonnummers toestaan, dan is het voldoende dat egem de XSD aanpast. De formulieren nemen dan direct de validatie over. Nu zijn we genoodzaakt een extra schema aan te maken met daarin de verschillende validaties, waarbij wij zelf het formaat van de telefoonnummer moeten bepalen. Hetzelfde geldt uiteraard voor emailadressen, datumvelden, etc;
Een MidOffice of BackOffice systeem mag er toch op vertrouwen dat een aangeleverd Stuf EF bericht volledig voldoet aan de eisen? Zonder een correcte validatie is dit nu niet het geval.
Kan Egem aangeven wanneer het XML schema wordt voorzien van de volledige validaties.
wo, 26-08-2009 - 21.08u
#1
Validatie in XSD bestanden
Vreemde constatering. StUF-EF valideert wel degelijk op de inhoud van velden. B.v.
<simpleType name="Telefoonnummer">
<restriction base="string">
<maxLength value="20"/>
</restriction>
</simpleType>
Je zou de validatieregels nog kunnen verscherpen door te eisen dat een telefoon precies uit 10 cijfers moeten bestaan. B.v.
<simpleType name="Telefoonnummer">
<restriction base="string">
<pattern value="[0-9]{10}"/>
</restriction>
</simpleType>
We hebben doelbewust besloten voorlopig nog niet voor de laatste definitie te kiezen omdat je dan heel zeker moet weten dat iedereen zich daar aan houdt. Je bent dan sowieso niet altijd operabel met buitenlandse telefoonnummers.
Leveranciers zijn vrij om zwaardere validaties uit te voeren op de velden in het web-formulier. Als het goed is zijn de meeste validaties al op de website uitgevoerd.
Henri,
Kun je vertellen waar de door jouw aangegeven validatieregels zijn vastgelegd. Als je de onderstaande download pakt en daar de 'working draft ef0204' (http://www.egem-iteams.nl/system/files/GEMMA+StUF+EF+berichten+20090218.zip) bekijkt, dan kom ik jouw voorbeeld nergens tegen.
Wellicht zie ik het over het hoofd?
----------
Ik ben van mening dat de leveranciers geen zwaardere regels zouden hoeven toepassen. We kunnen valideren met XSD wat voldoende zou moeten zijn, zodoende mag verwacht worden dat de XSD's die worden aangeleverd de juiste zwaarte van validatie kennen en er geen zwaardere nodig zijn.
In jouw voorbeeld van telefoonnummer verwacht ik dus dat er een validatie staat die valideert voor alle soorten telefoonnummers die voor de GEMMA formulieren mogelijk zijn, nu kan ik er ook een stukje tekst in zetten van 20 karakters dat geen telefoonnummer representateerd. Daarnaast staat in de GEMMA formulieren specificatie voor telefoonnummer dat deze maximaal 10 karakters mag zijn, terwijl de XSD er klaarblijkelijk 20 toelaat, kortom hier is geen match. Als de leverancier hier nog extra validaties op moet doen zou dit onnodig veel dubbel werk opleveren met alle gevolgen van dien en dus geen standaardisatie, wat we juist willen bereiken met de GEMMA formulieren, aangezien elke leverancier het dus anders kan doen.
Ik ben benieuwd hoe jij hier overdenkt.
Hoi Michiel,
de genoemde validatieregels zijn te vinden in de file bg0204.xsd (volg het pad "0204 working draft\bg0204" in de zip file). De file bg0204.xsd wordt via via in het EF-schema geimporteerd.
Sectormodel bg0204 is blijkbaar generieker dan de GEMMA formulieren omdat niet alle telefoonnummers in de wereld uit 10 posities bestaan. Denk bv aan de prefix +31 etc.
bg0204 gaat trouwens weer net wat te ver met 20 posities. Volgens de huidige internationale standaarden zou 15 posities genoeg moeten zijn. Wat dat betreft kan bg nog worden verfijnd.
Mvg,
Henri
Hey Henri,
Inmiddels heb ik de validaties gevonden, daarvoor dank. Wat me vervolgens opviel is dat er nog wel wat patterns niet zijn gedefinieerd. Bijvoorbeeld voor E-mail en Postcode zijn goede patterns beschikbaar voor gebruik is XSD, maar deze worden niet toegepast. En nu weet ik het niet zeker, maar volgens mij mogen namen niet uit cijfers bestaan, echter volgens de XSD wel.
Misschien kun je de volgende vraag beantwoorden:
Mogen de leveranciers er altijd vanuit gaan dat een door deze XSD gevalideerd bericht ook correct is?
Wij willen graag meeliften op de standaard XSD en als er iets aan de standaard wijzigd, dan betekent dit dat wij dit ook automatisch gebruiken. Echter als de standaard niet altijd correct is, dan zullen wij dus ook nog eens onze eigen validaties moeten maken voor het StUF-EF bericht wat weer veel dubbel werk opleverd en dan vraag ik mij af wat de meerwaarde is van de standaard XSD.
Ik ben benieuwd naar je reactie.
Met vriendelijke groet,
Michiel van Nieuwkerk
Hoi Michiel,
XSD checkt alleen op syntax en niet op semantiek. Dus zelfs als een telefoonummer voldoet aan alle syntactische eisen van de huidige internationale standaard (http://www.itu.int/rec/T-REC-E.164-200502-I/en) dan kan het nog steeds een onbestaand telefoonnummer zijn. M.a.w. XSD is slechts een hulpmiddel om berichten te valideren (zie het als een soort spellingschecker).
Sectormodel bg0204 volgt de basisregistraties o.a. GBA en de BAG waarin definities zoals die van geslachtsnaam, postcode en telefoonnummer niet (optimaal) scherp zijn gedefineerd. M.a.w. volgens de GBA mogen er blijkbaar cijfers voorkomen in namen.
Vaak word er gekozen voor ruimere formaten om interoprabiliteit met legacy-systemen te garanderen.
Mvg,
Henri