(Dit verzoek is ingediend door gemeente Den Haag en gemeente Amsterdam).
Gevraagde wijziging: In StUF definities wordt geen gebruik gemaakt van xsd:any en mixed content.
Toelichting:
Het gebruik van xsd:any is te generiek, en wijk af van de intentie van webservices om het contract zo specifiek mogelijk te beschrijven (Erl, Thomas e.a., Web Service Contract Design & Versioning for SOA, Chapter 12, p 316, http://www.ibm.com/developerworks/xml/library/ws-tip-xsdcaution/index.html, http://xml.coverpages.org/HP-StephensonSchemaBestPractices.pdf). In sommige gevallen wordt dit omgezet in een algemeen object, in andere gevallen wordt de inhoud van xsd:any direct omgezet naar een XML DOM structuur. Hierbij worden veel objecten aangemaakt, wat veel geheugen kan kosten. Het overzetten van XML d.m.v. een string is eenvoudiger en de ontwikkelaar kan zelf besluiten wat er met de XML gedaan moet worden.
xsd:any wordt nauwelijks toegepast binnen de StUF-sectormodellen. In de stuf0301.xsd komt het voor om slecht te definiëren zaken als de inhoud van het berichtenbestand of de vrije xml-structuur binnen het detailsXML element van een foutmelding toch nog enigszins te definiëren. Binnen sectormodellen ken ik geen gebruik hiervan.
Bij mijn weten wordt er in de StUF-sectormodellen nergens gebruik gemaakt van het attribute mixed="true" en bij mijn weten impliceert het ontbreken het mixed attribute in een complexType definitie dat mixed content niet is toegestaan. Kan je aangeven waar je probleem zich voordoet?
Het klopt inderdaad dat als een mixed attribuut ontbreekt, mixed content niet is toegestaan. Het bezwaar wat wij hebben tegen het gebruik van een vrije xml structuur is uitgelegd in de toelichting.
Mijn voorstel is om die detailsXML uit StUF te verwijderen.
gezien de reactie het volgende voostel:
- verwijder detailsXML. Er is al een details element van type String 1000 lang waarin fouten kunnen worden weergegeven
- verwijder de AnyType complexTypes in stuf0301.xsd. Het voegt niets toe.
Dit gaat mij toch wel wat snel. In het bericht maakt het qua serialisatie nogal wat uit of een type is gedefinieerd als String of als anyType. Binnen een String moeten bijvoorbeeld alle '<' van de tags vervangen worden door '<'. Het deserialiseren van een xml-fragment verstuurd als String wordt zo een aparte operatie die de ontvanger moet uitvoeren als een soort nabewerking op het bericht. Ik vraag me af of dit semantisch wel duidelijker is dan het meegeven van het anyType complexType. De gebruiker weet dan in elk geval dat er een xml-fragment volgt.
Ik vraag me af in hoeverre je je bij het beschrijven van een berichtenstandaard dient te laten leiden door de implementatiedetails die op termijn wel worden opgelost. Het lijkt mij beter om te gaan voor semantische zuiverheid.
In principe ga ik mee met de oorspronkelijke opmerking. Maar daar waar nu binnen StUF gebruik gemaakt wordn van anyType heb er geen bezwaar tegen.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0136.
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.