Een goedemorgen, Ik ben bezig een set van java classes te genereren a.d.h.v. ef0315_OntvangAsynchroon_mutatie.wsdl Dit lukt echter niet omdat de wsdl niet valideert. Eerdere versie van StUF-EF heb ik nog niet geprobeerd. Het eerste probleem zit in attribuut version in element . Hier krijg ik de melding : [Xerces] cvc-complex-type.3.2.2: Attribute 'version' is not allowed to appear in element 'definitions'. Het tweede probleem zit in het element op regel 4. Dit element staat daar volgens de validator niet goed. De melding die ik krijg is: [Xerces] cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://schemas.xmlsoap.org/wsdl/":annotation}'. One of '{"http://schemas.xmlsoap.org/wsdl/":service, "http://schemas.xmlsoap.org/wsdl/":import, "http://schemas.xmlsoap.org/wsdl/":types, "http://schemas.xmlsoap.org/wsdl/":message, "http://schemas.xmlsoap.org/wsdl/":portType, "http://schemas.xmlsoap.org/wsdl/":binding}' is expected. Deze 2 problemen zorgen ervoor dat mijn wsdl2java conversie niet lukt. Zover ik kan achterhalen is element een element beschreven binnen namepace http://www.w3.org/2001/XMLSchema en niet binnen namespace http://schemas.xmlsoap.org/wsdl/ Wat mij ook opvalt is dat element zover ik kan bepalen altijd het eerste sub-element moet zijn en dat is in deze WSDL, maar ook in andere StUF gerelateerde WSDL schema's niet het geval. Gelukkig gaat mijn wsdl2java conversie daar niet op stuk.
di, 18-11-2014 - 12.11u
#1
Validatie WSDL
Goedemorgen,
Ik had wel een reactie verwacht m.b.t. mijn bericht hierboven. Hoe kan ik helpen dit puntje op te lossen?
Mvg
Dag Lex,
Hoewel XML-Spy er geen problemen mee heeft mag het 'version' attribute in principe niet aanwezig zijn in het root-element van een WSDL instance. Oxygen, dat eveneens de Xerces parser gebruikt geeft inderdaad ook een foutmelding op dat punt.
Wat betreft het 'annotation' element is opvallend dat XML-Spy dat automatisch verplaatst naar het einde van het bestand als je het bestand opent (zie daarvoor de Text view) en het vervolgens goedkeurt zonder daar melding van te maken. Uit het schema van WSDL blijkt dat je voor het 'import' element een 'documentation' element mag plaatsen. Als ik het 'documentation' element uit het 'annotation' element daarheen verplaats en het dan lege 'annotation' element verwijder dan is die foutmelding ook verdwenen.
Dit ondersteunt je constatering dat in andere WSDL's het 'documentation' element ook op de verkeerde locatie staan. Dit zal ik dan ook als erratum aanmelden.
Xerces geeft trouwens ook nog foutmeldingen op de 'documentation' elementen in regel 329 en 780.
Het 'documentation' element in regel 329 moet volgens het schema als eerste element binnen 'binding' en het 'documentation' element in regel 780 moet volgens het schema als eerste element binnen 'port'. Ook deze beide acties worden door XML-Spy automatisch uitgevoerd zonder een melding te geven.
In het erratum dat ik zal opvoeren zal ik dus tevens de locatie van deze 'documentation' elementen laten checken.
Overigens denk ik dat je bij het genereren van code heel veel baat kunt hebben bij onze XSD Resolver (zie https://gemmaonline.nl/index.php/XSD-Resolver). Kijk daar maar eens naar.
Groet
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0359.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Hallo Robert,
Bedankt voor je reactie.
Oxygen en zo ook de apache CXF wsdl2java tool hanteren strakkere regels dan blijkbaar XML spy.
Op zich heel goed natuurlijk, maar lastig bij documentation en annotation elementen, gezien deze niet echt belangrijk zijn voor het genereren van de juiste Java classes.
Goed om te lezen dat dit zo opgepakt wordt.
Ik heb een de XSD Resolver bekeken en als voorbeeld de bg0310_beantwoordVraag_vraagAntwoord.wsdl er door heen gehaald. De resolved XSD's zijn prettiger omdat er b.v. geen gebruik meer wordt gemaakt van restriction base's, wat het converteren naar Java makkelijker maakt.
Voor mij biedt dit geen voordeel omdat ik aan een applicatie werk, welke diverse sectormodellen naast elkaar moet kunnen gebruikten. De huidige WSDL en XSD's kan ik in de huidige structuur gebruiken en van daaruit Java componenten genereren. Conflicten in bijvoorbeeld de gml XSD's heb ik tot nu toe nog in binding files kunnen oplossen.
In ieder geval bedankt voor het meedenken en de tip.
Ik heb in alle in de bijlage voorkomende WSDL's de locatie van de 'documentation' elementen aangepast. Dat betrof niet alleen het 'documentation' element aan het begin van het bestand maar ook hier en daar het 'documentation' element binnen andere elementen zoals 'binding' en 'service/port'. Daarnaast heb ik in enkele bestanden ook het attribute 'version' van het 'definitions' element verwijderd.
Zojuist heb ik trouwens geconstateerd dat XML-Spy een 'documentation' element dat voor een 'import' element staat bij openen automatisch verplaatst naar de tweede positie in het root-element. Vreemd gedrag van XML-Spy. We zullen Altova om opheldering vragen.
Bijlage
Ik heb eerder deze week het probleem aangekaart bij Altova en aangegeven dat het verplaatsen van een 'documentation' element direct na het 'import' element niet volgens het XML-schema voor een WSDL, dat je hier kunt vinden, is. Zij gaven echter aan dat in datzelfde document ook een voorbeeldbeschrijving staat van de structuur van een WSDL bestand (zie hier) waarin het 'documentation' element wel na het 'import' element staat. Waarna ik heb aangegeven dat het bewuste W3C document dus niet consistent is.
Zojuist heb ik de volgende reactie van hen ontvangen:
I referred the matter to our developers and they agree that there is an inherent ambiguity/contradiction in the spec. Accordingly, I have now entered your preferred interpretation as a feature request into our issues tracking database. It has the tracking number and title:
"47344 - Allow WSDL validation result that does not require 'import' statement as first child of 'definitions'"
Ik ga er vanuit dat dit probleem in een van de volgende versies van XML-Spy zal worden opgelost. Tot die tijd zullen wij er rekening mee moeten houden dat WSDL files bij het inlezen in XML-Spy door dat programma aangepast kunnen worden.
Tijdens de StUf Expertgroep van 18-2-2015 is besloten de oplossing niet te honoreren en het onderhoudsverzoek af te voeren. Leveranciers die met Xerces code willen genereren moeten zelf de betreffende correctie aanbrengen in de WSDL’s.