Indien er in een xsd bestandsnaam een extra punt voorkomt, dan gaat het opvragen van de xsd via de webservice bij bepaalde tooling fout.
Het lijkt erop alsof er bij de eerste punt wordt gestopt met zoeken en daardoor dus niet zkn0310.msg.xsd wordt opgevraagd maar zkn0310.msg. En dat bestand bestaat uiteraard niet.
Hallo Dennis,
Het lijkt me verstandig om problemen met tooling waar mogelijk op te lossen. In dit geval zouden alle punten behalve de laatste vervangen kunnen worden door een ander scheidingsteken, bijvoorbeeld een "_".
Ik stel voor dat dit wordt meegenomen in de actie die voor de volgende patch (1-3-2011) beoogd is, namelijk het herstructureren van de schema's, zodat er makkelijker mee te werken en er eenvoudiger nieuwe koppelvlakken aan een sectormodel kunnen worden toegevoegd.
Maarten
Hoi Maarten,
In de nieuwste XSD's en WSDL's van KING komen in de bestandsnamen nog steeds meerdere punten voor.
Ik verwacht dat hier problemen op gaan treden (zie mijn eerdere post op 6 december).
Staat dit punt nog steeds op de agenda?
Vanuit een theoretisch oogpunt is het heel goed als alle entiteiten afgeleid zijn van centraal beheerde moedertypes en bronbestanden, maar in de meeste appicaties valt er moeilijk te werken met hele massa's aan gelinkte schema's. Daarom zou het heel prettig zijn als er steeds nadat een nieuw schema of nieuwe WSDL is opgeleverd, vervolgens ook een 'gecombineerd schema' gemaakt wordt waarin alle objecten en berichten aanwezig zijn. Dit zodat er bij 1 WSDL gewoon altijd 1 schema hoort.
Deze benadering hoeft niet te bijten met de 'officiële' schema's zoals ze nu aangeleverd worden en voorkomt dat elke organisatie zelf zijn wsdl's/xsd's moet gaan hacken om het werkend te maken.
Dit punt staat wat mij betreft nog steeds op de agenda. Onderzocht zou moeten worden of King van de huidige schema's geautomatiserd een simpeler versie kan afleiden, waarin geen restricties voorkomen. Het is dan een stuk hanteerbaar voor ontwikkelaars die willen genereren op basis van de schema's. Overigens vind ik dit wel een onverstandige strategie rond StUF, omdat het gaat om software die nog jaren onderhouden miet worden en die daardoor gevoelig is voor het patchen van de schema's.
Hoi Maarten, bedankt voor je reactie.
Ik pleit hier niet voor aanpassingen aan de bron schema's, maar puur als laatste stap nadat alle aanpassingen in de bron schema's gedaan zijn. Als het geautomatiseerd kan, dan kun je prima bij elke patch een nieuwe samenvoeging genereren vanuit 'de StUF repository'.
Is er misschien een handige ontwikkelaar in de community die dit kan maken en publiek beschikbaar wil maken? ;-)