In de huidige extraElementen kan er geen validatie worden uitgevoerd op de inhoud van het element, en kan er geen structuur als inhoud worden opgegeven.
Daarom zijn er nu aanvullendeElementen in het leven geroepen.
Deze zijn nu gedefinieerd als een 'any' type, waarin dus elke gewenste structuur gezet kan worden.
Om deze structuur te kunnen valideren dient de ontvangende partij zelf handelingen uit te voeren op het bericht. Dit vergt dus extra handelingen, wat implementatie lastiger maakt.
Door het aanvullendeElementen element als volgt aan te duiden, kan er ook gevalideerd worden tegen bekende schema's binnen het koppelvlak zonder dat er een aanpassing aan het bericht hoeft te worden aangebracht. Daarnaast kunnen ontvangers die niets met de inhoud van doen willen hebben, die ook in deze constructie gewoon negeren.
<element name="aanvullendeElementen ">
<complexType>
<sequence>
<any processContents="lax" minOccurs="0"/>
</sequence>
</complexType>
</element>
Voorstel is om het element op deze manier in het basis StUF schema op te nemen, in plaats van de huidige implementatie met alleen een 'any' type.
wo, 5-10-2016 - 09.13u
#1
aanvullendeElementen
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0459.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Een goede suggestie om nog eens nader te onderzoeken wat er kan binnen de specificatie van XML Schema.
De post http://stackoverflow.com/questions/7820774/xml-validation-in-java-proces... laat zien dat het gebruik van lax mogelijk niet leidt tot de validatie die je wil, want er wordt geen fout gegeven voor elementnamen die niet gevonden kunnen worden. In geval van aanvullendeElementen lijkt dit me erg, want elementen die je niet herkent wordt je geacht te negeren.
Voor validatie van een element binnen aanvullendeElementen heb je het schema nodig waarin dat element is gedefinieerd. Dit probleem speelt overigens ook voor het bericht zelf, want StUF schrijft niet voor dat een bericht een verwijzing naar schemalocaties moet bevatten. In de praktijk valideer je met een Validator die de benodigde schema's heeft geladen. Alles bij elkaar lijkt het mij een goede suggestie om de definitie van aanvullendeElementen aan te passen conform de suggestie van Richard.
Maarten,
In de tweede alinea geef je aan dat het gebruik van lax mogelijk niet leidt tot de validatie die je wil en zeg je dat je dat erg vindt. Met die conclusie ben ik het eens om de reden die je zelf aangeeft. Je moet er immers op kunnen vertrouwen dat alle elementen die je in je bericht aan de namespace van het aanvullendeElementen schema koppelt ook gevalideerd worden. Ik begrijp daarom niet goed hoe je tot de conclusie komt dat we het voorstel van Richard moeten honoreren.
Het is overigens goed om te weten dat de lax definitie niet recursief doorwerkt. Je kunt dus niet zo maar invalid elementen toevoegen aan valid elementen van een aanvullendeElementen schema.
Ik heb het gebruik van lax nog even laten bezinken en daardoor ben ik tegen een voor mijn gevoel mogelijk nadelig effect aan gelopen. Ik ben heel benieuwd hoe anderen daar tegenaan kijken.
Stel je hebt in een aanvullend Schema een structuur gedefinieerd die het volgende toestaat:
Dan staat het gebruik van lax toe dat een verzender de volgende structuur stuurt:
De validator zal deze structuur valideren en het bericht zal dus verder verwerkt worden. Zoals Maarten zegt wordt je geacht de elementen die je niet herkent te negeren. Er is echter niets dat een ontvanger belet om in dit geval het element <d> toch te verwerken.
Ik vraag me dus af of er met de lax constructie niet een achterdeur wordt geopend om toch allerlei andere elementen door te sturen en te verwerken. En zo ja of dat een ongewenst effect is.
Is dat niet het hele idee achter de aanvullendeElementen?
Dank voor de analyse Robert. Het uitgangspunt van aanvullendeElementen is juist dat deze (aanvullend) strak gespecificeerd zijn. En dus door schema validatie volledig gecontroleerd worden. De lax constructie is wat ons betreft dan ook niet geschikt om toe te passen binnen aanvullendeElementen.
Tijdens de StUF Expertgroep van 15 februari 2017 zijn er door Robert nog twijfels geuit over de geschiktheid van de voorgestelde oplossing. het zou onbedoeld een achterdeur creëren om elementen mee te sturen die niet gevalideerd hoeven te worden. Besloten is dat Maarten en Robert hierover nog overleggen.
Ik heb mijn zorgen toegelicht aan Maarten. Deze is echter van mening dat deze zorgen naar zijn mening onnodig zijn en het afwijzen van deze oplossing ook niet rechtvaardigen.
Bijgaand vind je dan ook de uitwerking van het voorstel ter goedkeuring voor de StUF Expertgroep van 15 maart 2017.
Vertrouwend op die goedkeuring zal deze oplossing ook al worden meegenomen in de prepatch 26.
Bijlage
Bij deze een aangepast voorstel zoals het ook is opgenomen in pre-patch 26.
Bijlage
In de XSD van de bijlage staat het element nu als volgt gespecificeerd:
<element name="aanvullendeElementen ">
Met een spatie achter de naam. Dit moet uiteraard nog aangepast worden zonder spatie.
Tijdens de StUF Expertgroep van 15 maart 2017 is de uitwerking van dit onderhoudsverzoek zoals voorgesteld in reactie #10 goedgekeurd met dien verstande dat:
Daarnaast is goedgekeurd deze oplossing al meteen op te nemen in patch 26. Het onderhoudsverzoek mag tevens omgezet worden naar een erratum.