Leon van Zundert (werkzaam bij de gemeente Alkmaar) heeft bij KING een probleem gemeld dat hij ondervindt bij het genereren van code m.b.v. .Net tooling op basis van patch 14. Aangezien de schema’s in patch 15 ongewijzigd zijn gebleven speelt hetzelfde probleem in patch 15.
Leon gebruikt hiervoor de Microsoft tooling ‘xsd.exe’, ‘wsdl.exe’ en ‘svcutil.exe’ en loopt daarbij tegen probleempjes in de OpenGIS xsd's van OGC aan. Deze xsd’s blijken niet interoperabel te zijn met .NET.
Pas nadat hij een paar aanpassingen heeft uitgevoerd op de schema’s heeft hij er met een aangepast xsd tool code uit kunnen genereren. Een uitgebreide beschrijving van dat proces kun je vinden in 'Yaron Naveh's Web Services 2.0 blog'.
Met de op deze wijze verkregen code kan een WCF service worden gebouwd. In de gegenereerde code moet dan nog wel het object TinType aangepast worden door twee properties van het type LineStringSegmentType te verwijderen.
Leon heeft echter het idee veel te omslachtig bezig te zijn en vermoed dat het makelijker kan. Daarnaast kan het natuurlijk nooit de bedoeling zijn dat ontwikkelaars zelf de xsd’s van andere partijen gaan aanpassen . Daardoor zouden er misschien interoperabiliteits problemen kunnen optreden op het moment dat er met een externe partij gecommuniceerd gaat worden.
Het probleem dient dus bij de bron aangepakt te worden dus bij de OpenGIS xsd's van OGC.
Ik heb hier geen pasklaar antwoord op, maar zal het uitzoeken. Om welke versie van GML gaat het, 3.2.1?
Het betreft versie 3.1.1.2 van GML. Ik heb de versies bij het downloaden van zkn0310_20130401_patch15.zip van deze website meegekregen.
Ook Wim van Berkel van TNO meldt problemen met de OpenGIS XSD's. Hij schrijft:
We merken dat het gebruik van de opengis Xsd’s in de praktijk op redelijk wat problemen stuit. Lang niet alle ontwikkelomgevingen kunnen de complexiteit van die Xsd’s aan. We gebruiken zelf een recente versie van Java en JaxWS en zijn er met enige moeite in geslaagd een pilot te draaien met een partner die C# gebruikt. Pas met de 2012 versie van Visual Studio voor C# lukte het om alle xsd’s naar C# klasses om te zetten. En daarna waren er nog wat handmatige fixes van de gegenereerde code nodig. Daarna is het correct vullen van de Xml een behoorlijke uitdaging omdat de Xsd’s zoveel gegevensstructuren bevatten die in de BRO niet gebruikt worden.
Andere stakeholders van de BRO gebruiken minder geavanceerde omgevingen (bijv Delphi) waar het waarschijnlijk nog minder makkelijk gaat, als het überhaupt al gaat lukken.
Naar aanleiding van deze melding vermoeden wij dat de XSD Resolver die door ons is gebouwd mogelijk ook bij OpenGis goede diensten kan bewijzen. Of dat ook voor de problemen van Leon van Zundert geldt moet blijken. Daarom gaan wij kijken of we dit tool kunnen gaan publiceren.
Ik heb nog eens nader naar dit probleem gezocht. Maar aangezien wij zelf geen ontwikkelaars hebben kan ik ook niet veel meer dan op internet zoeken en navragen bij de OGC.
Ik denk dat programmeurs die hier tegenaan lopen over het algemeen de kleine aanpassingen in de xsd's doen die ook in het blog van Yaron Naveh beschreven worden, waarna het code genereren wel lukt.
Bij het Open Geospatial Consortium (OGC), waar de GML standaard in beheer is, kon ik over dit probleem niets terugvinden. Ik weet dat zij zorgen dat hun xml schema's valide zijn (ze testen met meerdere XML parsers) maar ze zullen niet kijken of de verschillende code generators er ook mee om kunnen gaan. In principe zou een code generator natuurlijk ook met een valide set schema's moeten kunnen werken. Maar bij schema's met complexe import/include structuren is dat vaak toch problematisch.
Zelf krijg ik hier bij Geonovum verder geen klachten over. Blijkbaar vindt men toch wel een workaround, denk ik dan...