Op het StUF-BG forum is er een discussie (ONV0343) gaande over zoeken op delen van woorden zoals bedrijfsnaam. Om dit probleem goed op te lossen is een RFC op de StUF-onderlaag nodig. Het voorstel is om de wildcards van SQL te gebruiken (%, _, etc.) in StUF-vraagberichten. In de nieuwe XML-stijl waarin we geen attributes meer gebruiken (alleen elementen) zouden we dat bijvoorbeeld als volgt vorm kunnen geven:
<BG:gelijk>
<StUF:entiteit>
<StUF:entiteittype>NPS</StUF:entiteittype>
</StUF:entiteit>
<BG:geslachtsnaam>
<StUF:waarde>Korver</StUF:waarde>
</BG:geslachtsnaam>
<BG:voorvoegselGeslachtsnaam>
<StUF:noValue>geenWaarde</StUF:noValue>
</BG:voorvoegselGeslachtsnaam>
<BG:voornamen>
<StUF:waarde>Henri%</StUF:waarde>
<StUF:wildcards>true</StUF:wildcards>
</BG:voornamen>
< /BG:gelijk>
Binnen het element "voornamen" wordt het nieuwe gereserveerde element "wildcards" gebruikt om aan te geven dat het element "waarde" wildcards kan bevatten, in dit geval het % symbool, en dus als een LIKE afgehandeld moet worden in plaats van als een '='. Wellicht is het een idee om de IN-operator van SQL ook te ondersteunen. Misschien moeten we daarvoor ook nog een syntax voor verzinnen.
Ook zouden we een element "caseSensitive" kunnen toevoegen als je specifiek op hoofdletters wilt zoeken, bijvoorbeeld:
<BG:voornamen>
<StUF:waarde>Henri%</StUF:waarde>
<StUF:wildcards>true</StUF:wildcards>
<StUF:caseSensitive>true</StUF:caseSensitive>
</BG:voornamen>
De vraag is of het verstandig is om case sensitivity op deze manier te regelen op berichtniveau (runtime), omdat dit nogal wat implicaties heeft voor de verwerking van de vraag. Misschien is het beter om dit design time te regelen (in de sorteringen van het koppelvlak) en dan heb je het bovengenoemde element "caseSensitive" niet nodig. Het is ook een optie om beide mogelijkheden toe te staan in de StUF-onderlaag en dat de keuze (design- versus run-time regelen van case sensitivity) wordt gemaakt op koppelvlakniveau.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0418.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Voortschrijdend inzicht leidt tot een belangrijk probleem in het gebruik van '%'-tjes als wildcards, namelijk dat deze niet toegestaan hoeven te zijn in het simpleType voor een element. Bijv. het bg0310-schema accepteert geen %-symbolen in het element <postcode>. Dit probleem kan mogelijk getackeld worden door een apart element te definiëren voor het ingeven van zoekcriteria met wildcard-tekens dat String is, dan ben je ook af van het element StUF:wildcards.
Is er behoefte aan escape-symbolen om wildcard-tekens (zoals % en _) als normale tekens te interpreteren? Zo ja, hoe gaan we dat doen? Een mogelijkheid is om de ESCAPE-clause van SQL, bijv.
WHERE omschrijving LIKE '%10-15!% off%' ESCAPE '!';
als uitgangspunt te nemen. We zouden dan het bovenstaande statement als volgt kunnen omzetten naar StUF:
<ZKN:omschrijving >
<StUF:zoekwaarde>%10-15!% off%</StUF:zoekwaarde>
<StUF:escape>!</StUF:escape>
</ZKN:omschrijving>
Persoonlijk zou ik aan het probleem met de toegestane tekens in het simpletype niets doen in de onderlaag.
Als dit al speelt (postcodes staan volgens mij niet op het lijstje voor zoeken met wildcards in RSGB-bevragingen), dan is het ook in het koppelvlak op te lossen door voor de selectiecriteria een (ander) simpletype te gebruiken, waarin het wildcardteken wél is toegestaan.
Ook van het probleem met het escape-karakter zou ik vooralsnog zeggen: keep it simple. Vooralsnog zou ik dit niet doen en dan maar accepteren dat bij het zoeken op wildcards de wildcardkarakters zelf niet als teken worden beschouwd. Ze worden in ieder geval toch gevonden (het wildcardkarakter zelf matcht ook met de wildcard) en zonder wildcards zoeken werkt wel weer met die karakters.
Tijdens de StUF Expertgroep van 18 november 2015 zijn een aantal aspecten van zoeken met wildcards besproken, de vorm (reguliere expressies vs SQL), de implicaties van met wildcards zoeken voor de achterliggende database, de noodzaak voor het zoeken met wildcards, case sensitivity en het moment waarop je keuzes maakt over de vorm van zoeken.
Uiteindelijk is de voorgestelde oplossing geaccepteerd.
Tijdens de StUF Expertgroep van 16 december 2015 is het probleem aan de orde gesteld dat het niet binnen alle simpleTypes mogelijk is een % teken op te nemen. Verder is nog gediscussieerd over escape karakters en de noodzaak daarvan en nogmaals over het moment waarop de keuzes voor zoeken moeten worden gemaakt.
Uiteindelijk is aangegeven dat een oplossing voor dit probleem in samenhang met gerelateerde RFC's gepresenteerd moet worden zodat daarover in samenhang gediscussieerd kan worden.
In de bovenstaande post staat: "Uiteindelijk is de voorgestelde oplossing geaccepteerd." Dit wekt de suggestie dat het RFC is goedgekeurd. Dit is geenszins het geval, het RFC staat nog open voor discussie.
In de afgelopen bijeenkomst van de StUF Expertgroep is het voorstel gedaan om het attribute "exact" te vervangen door het attribute "wildcard" met de waarden "exact", "begintMet" en "bevat". De waarde "exact" is equivalent aan een zoekterm zonder %-tekens (wildcard van SQL). De waarde "begintMet" is equivalent aan een zoekterm dat eindigt met een %-teken. De waarde "bevat" is equivalent aan een zoekterm dat begint en eindigt met een %-teken. De reden om geen %-teken te gebruiken is dat we geen %-teken hoeven toe te voegen aan simpleType's die van zich zelf geen %-teken in hun waardenbereik bevatten. Het is de bedoeling om dit voorstel in de aankomende bijeenkomst van de expertgroep als een hamerstuk goed te keuren.
In het kader van volledigheid, is het dan niet logisch om ook een 'eindigtMet' op te nemen in de standaard?
Wat mij betreft een prima idee om de waarde "eindigtMet" ook mee te nemen in het waardenbereik van het attribute "wildcard". In mijn ogen moet de StUF-onderlaag zo volledig mogelijk zijn. Je kunt altijd nog "restricten" in de koppelvlakken als je bepaalde waarden voor een wildcard niet wilt gebruiken.
Ik heb nog een beetje moeite met de naam van het attribuut in combinatie met de waarden die mogelijk zijn. Met de attribuutnaam wildcard en een waarde begintMet, zou ik als nietsvermoedende lezer denken dat de wildcard aan het begin van het zoekargument zou moeten staan (begint met wildcard). Dit is nu net niet het geval. Exact zou in dat verband ook 'geen' moeten zijn (etc).
Wellicht is een attribuutnaam 'vergelijking' of iets dergelijks toepasselijker, of we zouden (naar mijn mening) de waarden aan moeten passen. ('geen', 'beginEnEind', 'begin' en 'eind' of iets dergelijks).
Ik kan me helemaal vinden in het voorstel van Sid.
Ook eens met het voorstel van Sid. Dus de attribute-naam "wildcard" behouden, maar dan met logische namen in het waardenbereik: 'geen', 'beginEnEind', 'begin' en 'eind'.
Sid heeft een goed punt. Je kunt dit op twee manieren aanvliegen:
1. Vertellen dat je een wildcard gebruikt en aangeven waar die wildcard staat
"ik zoek met wildcard en die plaats ik aan het begin, aan het eind of aan begin en eind"
2. Vertellen dat je een string zoekt en aangeven waar je die string zoekt
"ik ben op zoek naar deze string en ik wil die strings vinden die exact overeenkomen, met deze string beginnen, met deze string eindigen, of waar deze string in voorkomt"
Het voorstel wat er nu staat hinkt op twee gedachten, door aan de ene kant te zeggen ik gebruik een wildcard, maar dit toe te lichten vanuit het perspectief van de zoekstring.
@Rens, in posts #13 en #14 geven Maarten en ik toch al aan dat we het eens zijn met Sid?
Klopt, ik had beter moeten lezen ;)
Ik ben het er ook mee eens.
Een off-topic vraag. Hebben jullie er ook last van dat het je niet makkelijk wordt gemaakt op een post te reageren? Ik krijg heel vaak de melding "Dit formulier is verouderd. Kopieer alles wat u niet heeft opgeslagen in onderstaand formulier en herlaad daarna deze pagina.".
Het is een heel geklooi om een reactie te plaatsen. Heel vervelend, want dat nodigt niet echt uit om te reageren. Herladen lost het probleem bij mij meestal niet direct op...
Ja ik ken het probleem, heel vervelend. Herladen is bij mij gelukkig wel een effectieve oplossing. Ik zal het probleem doorgeven aan onze webmaster.
Tijdens de StUF Expertgroep van 18 mei 2016 is besloten het RFC goed te keuren volgens het in reactie #14 geposte voorstel. In een koppelvlak kan dit vervolgens ingeperkt worden.
M.b.t. het probleem dat Rens heeft ervaren ('verouderd formulier) kan ik melden dat onze provider maatregelen heeft genomen waardoor het probleem opgelost zou moeten zijn. Indien dit niet het geval mocht zijn dan horen wij dat natuurlijk graag.
Als deze reactie wordt getoond, dan is het de bevestiging dat het werkt :)
Bijgaand (zie bijlage) de uitwerking van RFC0418. In het bijgevoegde document zijn alleen de wijzingen m.b.t. dit RFC zichtbaar. Deze uitwerking zal in de aankomende EG-meeting als hamerstuk behandeld worden. In geval van bezwaar, graag ruim van te voren melden via dit forum.
Bijlage
Bijgaand (zie bijlage) de Word-versie van de uitwerking van bovenstaande RFC. In Word is het voor sommigen handiger om van de ene revisie naar de andere te springen dan in PDF. Ook zijn er mogelijk nog een paar verbeteringen doorgevoerd. Dus graag deze word-versie gebruiken voor de review.
Bijlage
Tijdens de StUF Expertgroep van 19 oktober 2016 is bij het bespreken van RFC0343 verzocht om het aantal elementen waarop wildcards toegepast kunnen worden te beperken. Daarnaast twijfelde Maarten er nog aan of er niet twee verschillende wildcards toegevoegd moesten worden. Een waarbij je overal wildcards mag plaatsen en een waarbij dat beperkt is.
De StUF Expertgroep was het er mee eens dat je het gebruik van wildcards moet kunnen beperken. Maarten gaat daarvoor aanpassingen aanbrengen op het schema van de onderlaag.
Tijdens de StUF Expertgroep van 16 november 2016 is besloten de uitwerking van dit RFC goed te keuren.
De stuf0302.xsd bevat al de volgende simpleType's voor wildcards:
<simpleType name="Wildcard">
<restriction base="string">
<enumeration value="geen"/>
<enumeration value="begin"/>
<enumeration value="eind"/>
<enumeration value="beginEnEind"/>
</restriction>
</simpleType>
<simpleType name="WildcardEind">
<restriction base="StUF:Wildcard">
<enumeration value="geen"/>
<enumeration value="eind"/>
</restriction>
</simpleType>
Mijn voorstel is om de volgende complexType's toe te voegen aan de stuf0302.xsd:
<complexType name="WildcardElement">
<simpleContent>
<extension base="string">
<attribute name="wildcard" type="StUF:Wildcard"/>
<attribute ref="StUF:noValue"/>
</extension>
</simpleContent>
</complexType>
<complexType name="WildcardEindElement">
<simpleContent>
<extension base="string">
<attribute name="wildcard" type="StUF:WildcardEind"/>
<attribute ref="StUF:noValue"/>
</extension>
</simpleContent>
</complexType>
Deze types kunnen (her)gebruikt worden in de vraagberichten. Hieronder een voorbeeld van wildcard-elementen in het <gelijk>-element van een vraagbericht voor het entiteittype GEM (GEMEENTE):
<complexType name="GEM-gelijk-MijnKoppelvlak">
<sequence>
<element name="gemeenteCode" type="StUF:WildcardEindElement" minOccurs="0"/>
<element name="gemeenteNaam" type="StUF:WildcardElement" minOccurs="0"
...
</sequence>
</complexType>
In bovenstaand complexType van het (fictieve) koppelvlak MijnKoppelvlak is er een beperkte wildcard (geen, eind) opgenomen in het eerste element en een volledige wildcard (geen, begin, eind, beginEnEind) in het tweede element.