Wij hebben te maken met een patstelling tussen 2 leveranciers.
Leverancier A stuurt een bericht over een huwelijksluiting.
Leverancier B keurt dit bericht af, omdat het niet volledig is.
Leverancier A ontkent dit echter.
Het welles/nietes-spel zorgt er vervolgens voor dat er geen andere berichten meer worden verwerkt.
Wij willen graag verder, dus hoe bepaal ik (als leek) nu wie van beide partijen gelijk heeft? Oftewel hoe weet ik of een bericht conform Stuf is? Is er een Stuf-geschillencommissie of ombudsman/vrouw waar ik dit kan voorleggen?
Jan Symons
Consulent I&A
Kun je het 'omstreden' StUF-bericht aan deze discussie attachen? Dan we kijken we ernaar en zal EGEM er een oordeel over vellen.
PS Graag wel eerst het bericht depersonaliseren.
Jan,
Op de EGEM website staat een document waarmee gemeenten en andere StUF gebruikers geholpen worden met het schrijven van bestekteksten voor op StUF gebaseerde koppelingen. Hoewel deze fase voor jullie een gepasseerd station is kan dit document jullie wellicht nog wel helpen om overeenkomst tussen de 2 leveranciers te bereiken.
Het document kun je vinden op: https://www.surfgroepen.nl/sites/stuf/Shared%20Documents/B_StUF_Bestekte...
Doe er je voordeel mee!
Henry,
Bijgaand het bericht en de melding van de ontvangende applicatie.
De foutmelding is: E [Xerces] cvc-complex-type.2.4.b: The content of element 'PRS' is not complete. One of '{"http://www.egem.nl/StUF/sector/bg/0204":a-nummer}' is expected.
Beste Jan,
Het verzonden bericht is niet geldig en de verzender zal zijn software moeten aanpassen om te komen tot een geldig bericht. Omdat het PRS-element binnen PRSPRSHUW het attribute sleutelOntvangend bevat hoeven de in principe verplichte kerngegevens van PRS niet te worden opgenomen.
De foutmelding geeft aan dat het volgens het schema verplichte element a-nummer wordt verwacht. Deze foutmelding kan voorkomen worden door naast het attribute sleutelOntvangend ook het attribute xsi:nil="true" op te nemen met xsi de prefix voor de namespace "http://www.w3.org/2001/XMLSchema-instance".
Ik hoop dat de twee leveranciers op deze manier tot een oplossing kunnen komen.
Met vriendelijke groet,
Maarten
Beste mensen,
John Rooijakkers van PinkRoccade heeft me erop gewezen dat het bericht volgens bg0204 versie 09 wel geldig hoort te zijn, omdat in alle elementen in de gerelateerde PRS binnen PRSPRSHUW minOccurs="0" hebben en daar heeft hij gelijk in. Ik was er naïef vanuit gegaan dat de ontvanger met correcte schema's had gevalideerd en zal dit in het vervolg niet meer doen.
Ik heb daarom het bericht dat Jan heeft geuploaded gevalideerd met XMLSpy tegen bg0204.xsd versie 09. De conclusie is dat het bericht niet valideert, maar om een heel andere reden. Het attribute soortEntiteit heeft als prefix d5p1: en dit mag niet. Het verwijderen van deze prefix leidt tot een validerend bericht. De zender zal derhalve deze prefix dienen te verwijderen en de ontvanger dient na te gaan of er wordt gevalideerd met de officiële schema's.
Excuses voor de eerder gestichte verwarring.
Maarten
Maarten, John
Waarom is dit fout?
<PRS d3p1:soortEntiteit="F" xmlns:d3p1="http://www.egem.nl/StUF/StUF0204">
In het bericht staat op dezelfde regel waar de alias naar verwijst.
John: Eenzelfde bericht hebben jullie afgelopen vrijdag bij onze partnertest gewoon kunnen verwerken.
Hein
Hallo Hein,
Het is fout, omdat in het schema soortEntiteit niet is gedefinieerd als reference naar dit attribute binnen de StUF namespace, maar als gewoon attribute. De namespace prefix d3p1 voor soortEntiteit is daardoor niet toegestaan.
Met vriendelijke groet,
Maarten
Hoi Hein,
Zoals mijn collega Henk Koops je via mail gemeld heeft, constateerde wij de onderstaande foutmelding in XMLSpy:
File C:\stufbg_algemeen\centric\20090604\Lv01_vraag.xml is not valid.
Attribute 'd3p1:soortEntiteit' is not allowed in element <PRS>
Error location: vraagBericht / body / PRS / @d3p1:soortEntiteit
Details
cvc-complex-type.3.2.1: Complex type definition 'BG:PRS-vraag' of element <PRS> does not allow attribute 'd3p1:soortEntiteit' and no attribute wildcard matches it.
cvc-elt.5.2.1: The element <PRS> is not valid with respect to the actual type definition 'BG:PRS-vraag'.
Zonder XSD validatie konden wij jullie bericht echter wel in CiVision Makelaar verwerken.
Groeten, John.
Nog even voor de duidelijkheid wat extra uitleg.
Laten we het XML-Schema 'stuf0204.xsd' eens nader bekijken.
Zoals je daar kunt zien is het attribuut 'soortEntiteit' in het 'attributeGroup' element (met de waarde 'fundamenteel' voor het 'name' attribuut) lokaal gedefinieerd.
De andere attributen zijn in datzelfde schema globaal gedefinieerd en er wordt vanuit het genoemde 'attributeGroup' aan gerefereerd middels een 'ref' attribuut.
Die wijze van modelleren in combinatie met de waarde 'unqualified' voor het attribuut 'attributeFormDefault' bovenin het XML-schema zorgt er voor dat het attribuut 'soortEntiteit' niet met een prefix gedefinieerd mag worden.
Je kunt je nu afvragen waarom er voor gekozen is om het attribuut 'soortEntiteit' lokaal te definieren terwijl de andere attributen wel globaal gedefinieerd zijn.
Dat het tot verwarring leidt moge inmiddels duidelijk zijn.
Dit heeft echter een goede reden.
Het bewuste attribuut wordt gebruikt in twee verschillende situaties. In beide situaties heeft het attribuut een vaste waarde. In de ene de waarde 'F' en in de andere de waarde 'R'.
Als er voor gekozen was om dit attribuut globaal te definieren was die functionaliteit niet mogelijk geweest.
Waarom de andere attributen in de genoemde 'attributeGroup' (bijv. 'verwerkingssoort') niet ook gewoon lokaal gedefinieerd zijn is wat mij betreft WEL een geldige vraag. Dat zou in ieder geval geleid hebben tot een eenduidiger gebruik van prefixes. Nadelen van die wijze van modelleren zie ik zo vlug ook niet. Wellicht is echter ook hier een goede reden voor en kan iemand daar hier enige uitleg over geven.
De andere attributen zijn globaal gedefinieerd omdat je anders herhaling van definities krijgt. Immers zowel de attributeGroup definities voor fundamentele en relationele entiteiten gebruiken dezelfde attributen. En het is natuurlijk zaak om zoveel mogelijk hergebruik te maken van bestaande definities om de schema's makkelijk te kunnen beheren. Ik heb net in XMLSpy wat zitten experimenteren en het lukte mij om het attribute "soortEntiteit" globaal te definieeren met behoud van de flexibiliteit om daarna pas de fixed value te bepalen. Volgens mij is het probleem nu maximaal elegant opgelost. Applausje voor mezelf ;-)
M.a.w. deze definities valideren zonder problemen in Spy.
<attribute ref="StUF:soortEntiteit" use="required" fixed="F"/>
<attribute ref="StUF:soortEntiteit" use="required" fixed="R"/>
<attribute name="soortEntiteit" type="string"/>
Henri,
Je krijgt niet zozeer herhaling van definities. Deze definities kunnen immers nog steeds in de simpleTypes geplaatst worden waarnaar middels het 'type' attribuut verwezen wordt. Dus wat dat betreft bereik je best wel hergebruik.
Je kunt er echter wel minder zeker van zijn dat de attributen ook overal dezelfde naam hebben. Dat wordt nl. niet meer afgedwongen door het schema.
De door jou uitgewerkte oplossing is inderdaad elegant. Enige nadeel is dat er nog steeds een prefix gebruikt moet worden voor attributen wat een instance toch weer lastiger leesbaar, voor ons mensen, maakt.
Beste mensen,
De oplossing van Henri is inderdaad elegant. De hamvraag is echter of het hier gaat om een functionele wijziging of een erratum. Met de huidige minder elegante definities werkt het ook en ze specificeren eenduidig wat er moet gebeuren.
Dit lijkt me een issue voor de expertgroep.
Maarten