Element 'aanvullendeElementen' en attribute 'schemaLocation' attribute ontbreken

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

3 reacties / 0 nieuw
Login of registreer om te kunnen reageren
ma, 8-06-2015 - 15.34u
#1
Robert Melskens
Element 'aanvullendeElementen' en attribute 'schemaLocation' attribute ontbreken

Probleem
Met patch 21 is de goedgekeurde  ‘aanvullendeElementen’ constructie (ERR0303) gepubliceerd.
Dit behelsde het aanpassen van de paragrafen 3.2.4 en 3.2.4.1 en het toevoegen van paragraaf 3.2.4.2.
Om de betreffende constructie te kunnen gebruiken had aan het schema ‘StUF0301.xsd’ echter ook de volgende regels toegevoegd moeten worden:

<element name="aanvullendeElementen" type="anyType"/>

en

<attribute name="schemaLocation" type="string"/>

De documentatie refereert naar de twee bovengnoemde XSD-definities maar we zijn vergeten om ze ook daadwerkelijk aan het schema toe te voegen.

Oplossing
Voeg de betreffende componenten alsnog toe aan het schema StUF0301.xsd.

Bovenaan
Robert Melskens

Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR0395.
De lijst met onderhoudsverzoeken vind je op: 
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Bovenaan
Robert Melskens

Tijdens de StUF Expertgroep van 17 juni 2015 hebben de leden van de StUF Expertgroep aangegeven geen probleem hebben met deze correctie en besloten dit al in patch 22 door te voeren.

Wel is er een opmerking gemaakt over het attribute 'schemaLocation' en dan met name het formaat van dat attribute. Men vroeg zich af of er niet beter het formaat anyURI gebruikt kan worden. Het voorstel om het formaat vooralsnog op string te laten staan vond geen bijval aangezien er dan later mogelijk weer backwardse compatibiliteit problemen gaan ontstaan.

Uiteindelijk is afgesproken dat KING een onderzoek zou starten naar het gebruik van anyURI en aan de hand daarvan de schema's en/of de standaard zou gaan aanpassen.

Ik heb dit onderzocht en qua validatie heb ik geen meerwaarde kunnen ontdekken voor het gebruik van anyURI. Zoals uit de reactie van Michael Kay in deze discussie blijkt is er totaal geen verschil tussen anyURI en string.

Voor het gemak heb ik de reactie van Michael Kay hieronder toegevoegd:

The road to xs:anyURI was paved with good intentions. The XSD 1.0 spec is notoriously vague about what validation rules should be applied to it (it contains the notorious phrase "This definition imposes only very modest obligations on minimally conforming processors", while failing to say clearly what those obligations are) and in consequence many implementations allow anything (or almost anything). In XSD 1.1 the WG admitted defeat and changed the spec so the lexical space is exactly the same as xs:string. The XQuery and XSLT specifications also treat xs:anyURI more-or-less as equivalent to xs:string.

So should you use xs:anyURI? Well, it provides a bit of documentation of your intent, and it might give you better bindings to data types in other languages. It has a bit more semantics than xs:string, though it's all very implicit. But the fact that something is present in a spec doesn't mean you have to use it.

De enige meerwaarde die het gebruik van anyURI biedt is dus dat het wat documentatie biedt over het gebruik van het ‘schemaLocation’ attribute. KING heeft op basis hiervan besloten om het formaat van het 'schemaLocation' attribute onveranderd op 'string' te laten staan. Daarnaast hebben wij de tekst van paragraaf 3.2.4.2 niet aangepast zoals ons was verzocht in de StUF Expertgroep van 17 juni 2015. Wij hebben namelijk niet de illusie dat wij daar waar de Working Group voor XSD 1.1 gefaald heeft (zoals je hierboven in de quote van Michael Kay kunt lezen) zullen slagen om exact te definiëren waaraan een uri zou moeten voldoen.

Bovenaan