Problemen bij valideren met StUF EF XSD-bestanden

Hallo Peter,
Het ef0310.msg.xsd schema bevat in elk geval twee overbodige import statements, namelijk
<import namespace="http://www.egem.nl/StUF/StUF0301" schemaLocation="../0301/stuf0301.xsd"/>

en

<import namespace="http://www.egem.nl/StUF/sector/bg/0310" schemaLocation="../bg0310/bg0310.ent.xsd"/>

Ik zou allereerst proberen of je de zaak werkend krijgt na verwijdering van deze twee import statements.

Ook met deze import statements zijn de schema's overigens valid volgens XMLSpy. Om zeker te weten of de schema's valid zijn conform de Schema standaard is een check mogelijk via de link http://www.w3.org/2001/03/webdata/xsv, maar hiervoor dienen de schema's beschikbaar te zijn op een via het web bereikbare locatie. Ik verwacht dat de schema's valid zullen blijken te zijn.

Mocht verwijdering van deze import statements niet voldoende zijn en de schema's zijn valid, dan is er misschien aanleiding om uit te zien naar andere tooling. Ik zelf heb bijvoorbeeld met de standaard java tooling nog geen problemen ondervonden met de StUF-schema's, maar heb dit specifieke schema nooit getest.

Beste Peter,
dank voor je melding. Je kan problemen, opmerkingen en suggesties m.b.t. StUF EF kwijt op het StUF EF forum. Fouten in StUF EF en suggesties ter verbetering zullen door KING opgepakt worden.
Ik stel voor dat je de suggesties van Maarten uitprobeert (waarvoor dank).
Ik zal de twee overbodige import statements voorleggen aan onze StUF EF expert.
Mvg,
Remko de Haas  / remko.dehaas (@] kinggemeenten.nl

Hallo Peter,

Ik liep in een ander project tegen een mogelijk soortgelijk probleem aan.

Als in de hele boom van schema's die ontstaat vanuit het topschema een namespace of twee verschillende manieren wordt geïmporteerd, dan bleek dit te leiden tot problemen in Xerces en Saxon validators. Ze vonden de schema's niet meer valid. De door jou genoemde melding wijst ook in deze richting.

Dit probleem is op te lossen door in de hele boom van schema's een namespace steeds met hetzelfde schema (het 'grootste' schema dat er voor deze namespace is) te importeren. In de EF-schema's kan dit probleem spelen met de namespace "http://www.egem.nl/StUF/StUF0301", omdat ef0310.ent.xsd hier efstuf0310.xsd importeert en het geïmporteerde schema efbg0310.xsd importeert stuf0301.xsd en het door efbg0310.xsd geinclude bg0310.ent.xsd importeert weer bgstuf0310.xsd. Om bij jou de boel validerend te krijgen zou je één bestand in de namespace StUF moeten definiëren dat alles bevat wat alle andere schema's nodig hebben en dit bestand importeer je dan overal voor de namespace http://www.egem.nl/StUF/StUF0301".

De beheerders van de schema's kunnen dit probleem niet voor je oplossen, omdat er ook veranderingen nodig zijn in bgstuf0310.xsd en bg0310.ent.xsd, dat door een andere partij beheerd wordt dan het sectormodel eFormulieren. Het gaat hierbij bovendien om veranderingen die vanuit de te veranderen schema's ongewenst zijn (MTOM wordt bijvoorbeeld dan ook verplicht gemaakt in bg0310.

Het is een probleem in de gebruikte tooling, want een tool als XMLSpy heeft hier geen problemen mee.

Maarten

Ik liep tegen een soortgelijk probleem aan. Wij zijn bezig berichten te definieren (met hulp van Maarten) voor IMGeo / BGT waarbij we gebruik maken van StUF. De schema's valideren in XML Spy, maar niet in Oxygen. Oxygen maakt gebruik van Xerces. Validatie in SaxonEE leverde ook validatiefouten op. Het gaat niet om precies dezelfde meldingen waar eerder in deze thread melding van gemaakt werd, maar wel om meldingen die terug te voeren zijn op hetzelfde probleem met includes en imports. De meldingen zijn als volgt: The type {typename} is referenced, but has not been declared Ik heb met de support van Oxygen en SaxonEE gemaild over dit probleem. Mogelijk ook nuttig voor anderen, dus ik post ze hier even. Beide partijen geven aan dat dit te maken heeft met het op verschillende plekken importeren van dezelfde namespace maar met verschillende inhoud. Het is op te lossen door een hoofdschema te maken waarin je alle schema's uit die namespace includeert, en altijd het hoofdschema te importeren. In Oxygen is een workaround. De standaard parser die zij gebruiken, Xerces, heeft een optie "honour-all-schemalocations" om te forceren dat de schemas altijd volledig worden gelezen en niet gecacht worden.

Hier het antwoord van Oxygen support:

"This is a gray area in the XML Schema spec AFAIK and most schema processors implemented a one main schema per namespace rule, at least as their default behavior. At some moment Xerces added a feature that when turned on will make the parser disregard this rule and force the loading of all schema files that are specified for a namespace. The feature is called "honour-all-schemaLocations" and in oXygen you can enable it from the Options->Preferences -- XML -- XML Parser options page. If I enable this feature in oXygen and then use the "Reset cache and validate" (or reopen the schema file) I get the schema file you mentioned reported as valid. A possibility to avoid this is to create a main schema for each namespace that includes all the schema documents that define components in that namespace and refer to this main schema everywhere where that namespace is imported." En van SaxonEE support: "There are indeed differences between processors in the handling of include/import, and the specification gives sufficient latitude that one cannot say definitively who is right. From your description, the most likely cause is different interpretations of in the case where the processor, at the time this is encountered, has already read one or more schema documents for a.uri. Some processors will read the contents of b.uri (possibly but not necessarily failing if the contents conflict with other components for the same namespace), whereas some will ignore it on the basis that the schema for this namespace is already known. Xerces actually gives you an option which strategy you want to follow. There's a rule you can follow to avoid this problem: if the schema for a namespace is split across more than one document, you should have one "root" module that xs:include's all the others (directly or indirectly), and an xs:import from a different target namespace should always nominate the root module for that namespace in its schemaLocation attribute. (It can get more complicated with xs:redefines, of course...)"