Het verStUFfen van het Informatiemodel ZTC en de bespreking daarvan in de Expertgroep StUF geven aanleiding om de modellering van zaaktypespecifieke eigenschappen te wijzigen. Nu kunnen willekeurige attributen op willekeurige wijze gespecificeerd worden. Dat is niet wenselijk want kan leiden tot een willekeur aan attributen, met zelfs de mogelijkheid dat eenzelfde attribuut op verschillende wijze bij zaaktypen wordt gespecificeerd. Het voorstel is om een eigenschap cq. attribuut te ontlenen aan een informatie- en berichtenmodel door daarnaar te verwijzen. Zie voor een volledige beschrijving van dit voorstel het document bij mijn eerstvolgende reactie (ik zie geen mogelijkheid om aan deze 'post' een bestand toe te voegen).
vr, 6-09-2013 - 08.49u
#1
Wijziging modellering zaaktypespecifieke eigenschappen
Recent is er een aanpassing gedaan op StUF om dynamisch te kunnen linken naar andere sectormodellen. Op die manier kunnen bijv. domeinspecifieke entiteiten worden opgenomen in een StUF-Zaken object. Hoe verhoudt zich dat voorstel tot het opnemen van zaaktypspecifieke eigenschappen? Wordt in StUF-ZTC gebruik gemaakt van hetzelfde mechanisme? Gr. Hugo
Hoe zit dat met BGT (Basisregistratie Grootschalige Topografie) en Stuf GEO. Kun je hier ook direct mee linken?
Hugo, dat verhoudt zich prima. De behoefte aan het kunnen uitwisselen van zaaktypespecifieke eigenschappen is juist de aanleiding geweest voor de door jou genoemde uitbreiding van StUF. In de ZTC wordt per zaaktype gespecificeerd om welke eigenschappen het gaat. De wijziging in de ZTC gaat er om dat niet zomaar willekeurige eigenschappen genoemd worden maar dat verwezen wordt naar reeds in informatie- en berichtenmodellen gemodelleerde eigenschappen.
Michel en Hugo, in de vergaderstukken van de aankomende bijeenkomst van de StUF Expertgroep staat een verbeterd voorstel voor het toevoegen van specifieke eigenschappen aan zaakberichten inclusief een voorbeeld in de context van een kapvergunning, zie de files 'zaakspecifieke gegevens in stuf v07.pdf' en 'zkn0310_20130911.zip' in dit zip bestand. In dit voorstel kun je zien dat het geen probleem is om dynamisch te linken naar andere sectormodellen. In het voorbeeld van een kapvergunning wordt vanuit StUF-ZKN 3.10 en StUF-ZTC 1.0 gelinkt naar StUF-BG 3.10 en het fictieve StUF-GV 1.0 (Groen Voorziening). Maar hetzelfde principe kan worden gevolgd om te linken naar StUF-BGT of StUF-IMGEO.
De wijze van modellering van zaaktypespecifieke eigenschappen in het Informatiemodel ZTC is herhaaldelijk besproken in zowel de Expertgroep Informatiemodellen als de StUF-expertgroep. Uitkomst op hoofdlijnen is dat ondersteund wordt dat een eigenschap bij een zaaktype op één van twee manieren vastgelegd kan worden: door deze te specificeren (naam, type, lengte, kardinaliteit, waardenverzameling) dan wel door te verwijzen naar een berichtenstandaard waarin de eigenschap is gespecificeerd (namespace). Bijgaand het wijzigingsvoorstel.
Bijlage
Uit de gekozen opzet met referenties naar eigenschappen zou kunnen worden afgeleid dat applicaties in staat worden geacht door een verwijzing naar berichtmodellen 'automatisch' de betreffende elementen te interpreteren. De betreffende business logica zal echter nog steeds gecodeerd moeten worden op basis van vooraf gemaakte afspraken. Alleen een aanpassing van de definitie van de zaakspecifieke gegevens in de ZTC zal deze business logica niet automatisch beïnvloeden. Sterker nog: het zal waarschijnlijk leiden tot foutsituaties in deze applicaties omdat de gecodeerde business logica niet meer aansluit bij de aangeboden data. In die zin lijkt het voorstel dus meer flexibiliteit te beloven dan in de praktijk kan worden gerealiseerd. Met referenties naar beschikbare informatiemodellen wordt wel bereikt dat het voor alle betrokkenen duidelijk is welke gegevens worden uitgewisseld. Verwijzingen naar de berichtmodellen (XML-schema's en namespaces) draagt mijns inziens echter weinig bij. De XML schema standaard is niet opgezet voor de validatie van individuele elementen maar dient voor validatie van XML documenten als geheel. Er zijn om die reden, voorzover mij bekend, geen standaard tools beschikbaar waarmee individuele elementen kunnen worden gevalideerd op basis van XPath expressies in schema's. Bovendien lijkt mij dit een veel te complexe en mede daarom weinig robuuste aanpak. Bovendien schiet deze aanpak het doel enigszins voorbij. Om te voorkomen dat er XML Schema's moeten worden opgesteld voor het zaakspecifieke blok voor ieder zaaktype moeten nu voor alle elementen in die blokken XPath expressies worden opgesteld. Dat is qua omvang en complexiteit vergelijkbaar. Bovendien zijn betrokkenen die niet in staat zijn XML Schema's op te stellen over het algemeen ook niet in staat XPath expressies op te stellen naar onderdelen van bestaande schema's. In de beschrijving van het XPath element staat dat de waarde van deze attribuutsoort optioneel is. "Indien geen waarde aanwezig is, dan zijn alle elementen die deel uit maken van de Namespace zaaktypespecifieke eigenschappen. Deze hoeven dan dus niet per element cq. per eigenschap gespecificeerd te worden." Dit attribuut maakt echter deel uit van het objecttype Eigenschap waarin individuele eigenschappen worden gemodelleerd. Het is mijns inziens dus niet terecht hier naar een groep te verwijzen. Al met al zou ik er dan toch voor willen pleiten te kiezen voor het opstellen van XML schema's voor de zaakspecifieke blokken per zaaktype. In het voorstel is de namespace omschreven als de "De naam van het schema waarin de eigenschap is opgenomen". Dat is niet juist. De namespace is een aanduiding van de context van de opgenomen definities en dat is niet de naam van het schema. Het opnemen van de schemalocatie is alleen zinvol als deze voor de zender en de ontvanger van de berichten beschikbaar is. Dat betekent dat de schema's op een breed toegankelijke locatie moeten staan. Het is dan zinvol de lengte van de string af te stemmen op die van een url.