(Dit verzoek is ingediend door gemeente Den Haag en gemeente Amsterdam).
Gevraagde wijziging:
T.b.v. ‘vrije’ berichten levert KING XSD-gegevensdefinities waarin geen gebruik wordt gemaakt van de XSD tag RESTRICTION voor complex types. Voor simple types ligt het voor de hand om restrictions te gebruiken.. Het gebruik van namespaces volgt de ‘best practices’.
Voorbeeld: Huidige definitie van AOA-kerngegevens is als volgt:
<complexType name="AOA-kerngegevens">
<complexContent>
<restriction base="BG:AOA-basis">
<sequence>
<element name="identificatie" .../>
<element name="authentiek" .../>
...
</sequence>
...
</restriction>
</complexContent>
</complexType>
Vervangen door:
<complexType name="AOA-kerngegevens">
<sequence>
<element name="identificatie" .../>
<element name="authentiek" .../>
...
</sequence>
...
</complexType>
Toelichting:
Restriction van complex types in XML Schema is niet goed te vertalen naar object oriëntatie in code en wordt ook afgeraden (zie: http://www.xml.com/pub/a/2002/11/20/schemas.html?page=4#restriction, http://www.xfront.com/composition-versus-subclassing.html, Erl, Thomas e.a., Web Service Contract Design & Versioning for SOA, Chapter 12, p 333).
De code omvat altijd alle elementen en attributen van de basisklasse, ondanks dat in de restriction aangegeven is dat alleen een klein deel van de elementen mag gebruikt worden.
Om er voor te zorgen dat de namespace uniek is, begint de namespace altijd met de organisatie die verantwoordelijk is voor het XML schema (zie: http://en.wikipedia.org/wiki/XML_Namespace, http://www.w3.org/TR/xml-names/). Een XML schema die door KING/EGEM gemaakt wordt begint dus met http://www.egem.nl en een XML schema die door Gemeente Den Haag gemaakt wordt begint dus met http://www.denhaag.nl. Door het gebruik van restrictions van complex types is dit niet mogelijk.
King stelt een zogenaamd resolver tool ter beschikking waarmee de gevraagde transformatie geautomatiseerd kan worden doorgevoerd. Voor onderhoud en beheer heeft de huidige vorm van de schema's de voorkeur, omdat je bij wijzigingen de consequenties ervan via het al dan niet valide zijn van schema's kunt doorgronden.
Het namespace probleem begrijp ik niet goed. Voorzover worden in StUF-schema's over het algemeen namespaces gebruikt die voldoen aan deze eis. Kan je voorbeelden geven waar er niet aan voldaan wordt?
Eens met Maarten van de Broek: Doel van de huidige XSDs is bericht validatie en beheer van de berichtspecificaties. Vanuit code generaties kas er sprake zijn van andere, confliceterende wensen. Wellicht dat de King XSD resolver hierin kan helpen.
Ik snap het probleem van onderhoud en beheer van de schema’s, zoals ze nu worden aangeboden. Het is dan alleen van belang om ze ook op deze wijze te positioneren. Nou lijkt het zo als of deze bruikbaar zijn voor het ontwikkelen van software. In de huidige situatie is dat niet goed mogelijk met standaard software voor Java en .NET.
Dus mijn voorstel zou zijn:
De reactie van Maarten geeft aan dat de StUF bg0310 set met wsdl's en xsd's niet zijn bedoeld voor implementatie van de webservice. Zo worden ze wel gezien en gebruikt. Ik ben het met Bastiaan eens dat dit duidelijk vermeld moet staan.
De niet-vrije berichten worden compleet als "contract" inclusief wsdl geleverd. Uitgangspunt is dat zowel consumer als provider zonder wijzigingen dit contract moet kunnen implementeren. Dat is nu niet het geval.
Voor de vrije berichten zou er een set bruikbare XSD's moeten komen naast de set voor onderhoud en beheer.
Aanvullend op de inbreng van Bastiaan en André nog een toelichting.
Over de afgelopen tien jaar zijn er enorm veel webservices bij vele gemeenten in gebruik genomen. Een van de onbetwiste 'best practices' van webservices is het gebruik van gemeenschappelijke XSD-definities (zoals het bijvoorbeeld in het SUWI-domein in Nederland al sinds 2001 gebeurt). Vanzelfsprekend zouden deze gegevensdefinities voor het gemeentelijke domein landelijk beschikbaar moeten zijn. Tot nu toe is dit helaas nog niet geregeld. Ook ligt voor de hand dat deze definities op basis van StUF worden gemaakt, en wel in de vorm die geschikt is voor de gangbare ontwikkelstandaarden voor webservices, te weten Open Source frameworks, WCF van Microsoft etc.
De stelling van de gemeenten Den Haag en Amsterdam is dat de verantwoordelijkheid voor het maken en beheren van deze schema's een logische taak van KING zou moeten zijn, een soort verlengde van StUF.
Het is niet effectief dat iedere gemeente zelf de resolver van KING gaat gebruiken. Het opstellen van optimale schema's vereist een hoog niveau van expertise (XSD, WS ...) en die is ook bij de goede ontwikkelaars meestal niet beschikbaar.
Grote gemeenten zoals Amsterdam en Den Haag kunnen deze problematiek weliswaar prima aan - met behulp van de 'resolver' kunnen wij beslist zelf de XSD-definities van StUF aanpassen aan de vereisten van gangbare ontwikkelomgevingen - maar vanuit het landelijke oogpunt en qua kosten-effectiviteit is dat verre van optimaal.
Ook willen wij de onvruchtbare discussies over de toepasbaarheid van StUF t.b.v. de SOA-oplossingen op de juiste manier tot goede einde brengen.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0132.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 20-5-2015 is besloten dit RFC af te voeren.