Op mijn werk hebben wij nogal een berg XMLSchema bouwstenen waarmee we de verschillende interfaces van de webservices beschrijven. De meest basale bouwsteentjes zitten met z’n allen in een zogenaamd Basisschema, met als namespace http://www.suwi.nl/SuwiML/Basis-v0400. Iets minder basale bouwstenen, bijvoorbeeld een bouwsteen ten behoeve van beschrijving van Fouten (en Waarschuwingen en Info-meldingen), hebben een aparte XMLSchema beschrijving, met een aparte namespace http://bkwi.nl/SuwiML/FWI/v0102. Het is goed om voor dat soort dingen aparte bouwstenen te hebben, omdat die brokken herbruikbaar te importeren zijn in de XMLSchema beschrijvingen van de verschillende diensten. Die minder basale bouwstenen maken gebruik, door middel van imports, van de basale bouwstenen. Dan zijn er de overkoepelende XMLSchema’s die een Request of een Response van een bepaalde webservice beschrijven. Zo’n overkoepelend XMLSchema doet imports van basale bouwstenen en van minder basale bouwstenen. En die minder basale bouwstenen importeren dus weer sommige basale bouwstenen. Het gevolg is dat de namespace van de basale bouwstenen uit het Basisschema eigenlijk via twee wegen door een overkoepelend XMLSchema geïmporteerd worden: direct, rechtstreeks vanuit het overkoepelende XMLSchema, en indirect, via de minder basale bouwstenen. En daar gaat het mis. Het blijkt dat een gangbare parser als Xerces nogal rigide omgaat met dit soort geneste imports. Zodra Xerces eenmaal voor een bepaalde namespace een XMLSchema file geïmporteerd heeft, dan gaat ie niet meer voor dezelfde namespace nog eens een andere XMLSchema file importeren. Ook al geef je dat expliciet aan in import statements. Hij weigert het gewoon! Zodoende ontstaan er onaangename validatie-fouten. Snappie?
Het enige dat er op zit denk ik is in de minder basale bouwstenen de import statements uit te zetten. En te zorgen dat in het overkoepelende schema er meteen voldoende geïmporteerd wordt. Nadeel daarvan is dat de gebruikte minder basale bouwstenen op zich zelf dan niet meer valide zijn. Maar ja dat moet dan maar.
Helaas begint Xerces dan te klagen, bij het valideren van het overkoepelende XMLSchema, dat die tussenliggende bouwsteen niet valide is! Ja Xerces wat wil je nou? Ik zit dus in een deadlock…
Dus de imports in de minder basale bouwstenen weer aan gezet. In het overkoepelende schema heb ik daarnaast nu de volgorde veranderd. Dat samen lijkt te helpen. Voor deze dienst heb ik nu tenminste een XMLSchema dat ook voor Xerces door de beugel kan.