Tijdens het genereren van de sources voor de "zkn0310_beantwoordVraag_zs-dms.wsdl" en "zkn0310_ontvangAsynchroon_mutatie_zs-dms.wsdl" wsdl bestanden liep ik tegen een foutmelding aan. Het lijkt er op dat een aantal schema locations niet juist in de WSDL staan. Op het moment dat ik \ vervang door / gaat het genereren van de code wel goed verder. Is dit iets wat bekend is (of al eerder gemeld)?
<xs:import namespace="http://www.egem.nl/StUF/sector/zkn/0310" schemaLocation="..\mutatie\zkn0310_msg_mutatie.xsd" />
<xs:import namespace="http://www.egem.nl/StUF/sector/zkn/0310" schemaLocation="..\vraagAntwoord\zkn0310_msg_vraagAntwoord.xsd" />
Kan dit met het gebruikte besturingssysteem te maken hebben? Windows werkt met ..\.. voor folder niveaus en Linux/webservers met ../.. .
Het kan ook nog aan de programmeertaal liggen, Java gaat anders om met slashes dan .NET. Overigens zou Windows ook met een "/" om moeten kunnen gaan, staat mij nog bij van vroeger. Welke code generatie tool gebruik je?
En voor de zekerheid: welke versie van de schema's gebruik je?
Op dit moment werken we met de patch 20 release van StUF-ZKN 3.10. De code wordt gegenereerd met behulp van de "CXF-codegen-plugin" voor Eclipse. Het betreft hier een Java ontwikkel omgeving. Het viel mij in zoverre op dat alle overige slashes die ik in de XSD's gezien heb wel als "/" zijn opgenomen. Omdat we niet alle WSDL's geïmplementeerd hebben kan het zijn dat er toch nog meer zijn.
In de CORV WSDL's staan ook backslashes. Het gaat om de WSDL's zkn0310_ontvangAsynchroon_corv.wsdl en zkn0310_ontvangAsynchroon_corv_intermediair.wsdl.
In de meeste WSDL's staan verwijzingen naar schema's die in dezelfde directory staan en gaat het meestal goed.
Om te voorkomen dat we steeds moeten schakelen ben ik wel benieuwd of een schema met gewone slashes door een .NET omgeving gebruikt kan worden. Als dat zo is moeten alle backslashes omgezet worden naar een gewone slash.
@Patrick: heb jij toevallig de beschikking over een .NET omgeving om zoiets te testen?
In gmlBase.xsd staat
<import namespace="http://www.w3.org/1999/xlink" schemaLocation="../../../xlink/1.0.0/xlinks.xsd"/>
Dus tenzij je ook de niet StUF schema's wilt aanpassen naar backslashes blijf je dit probleem houden.
De .Net tool xsd.exe kan overigens overweg met zowel slashes als backslashes
Ik heb hier nog even gekeken maar ik heb hier zelf niet direct een omgeving om dit volledig correct op te testen voor een StUF wsdl. Ik krijg diverse andere fouten indien ik de WSDL's vanuit .NET probeer in te lezen met de "wsdl.exe" uit de SDK. Ik heb echter wel een import gedaan van een andere WSDL met een shemaLocation verwijzing met "/" tekens en deze lijkt verder gewoon goed te gaan.
Daarnaast heb ik nog even gekeken in de definities van W3 en hier wordt er eigenlijk alleen maar gesproken over "/". De backslash wordt hier helemaal niet gebruikt. Ik neem aan dat .NET dit dus ook gewoon zou moeten kunnen verwerken.
Onderstaande links leiden (als ik goed gekeken heb) uiteindelijk naar paragraaf 5.2. van rfc2396.txt
http://www.w3.org/TR/wsdl20/#import_location_attribute
http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators
http://www.w3.org/TR/xmlschema-2/#anyURI
http://www.w3.org/TR/wsdl20/#import_location_attribute
http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators
http://www.w3.org/TR/xmlschema-2/#anyURI
http://www.ietf.org/rfc/rfc2396.txt (paragraaf 5.2.)
Eens met Patrick. De betreffende paragraaf is duidelijk. Dat backslashes toevallig werken in sommige omgevingen, maakt ze niet correct. Dus dit zal aangepast moeten worden in alle schema's waarin ze verkeerd staan.
Dit probleem is opgelost in de bestanden die in patch21 zijn gepubliceerd.