-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reguliere expressie opnemen om lege velden in verplichte strings te voorkomen #228
Comments
@PB-GNM De volgende opmerkingen
|
De tekst "Alleen als attributen gevuld zijn ZONDER leesbare karakters" bij backward compatibility moet volgens mij zijn "Alleen als attributen gevuld zijn MET leesbare karakters" |
Die naamgeving impliceert inderdaad een aparte module die er niet is, maar ik bedoelde een voorziening om data in de CVVG in te voeren. Ik heb het het woord invoermodule weggehaald. |
Goed opgemerkt. Ik heb het aangepast. |
@PB-GNM @wilkoquak is deze nog gerelateerd aan #214. Daar stonden bij soortgelijke gevallen bij een 'verplicht' veld in de xsd: minOccurs=0. |
@PB-GNM Wat wordt bedoeld met herleidbaar in: 'Is er een herlevering nodig naar de CVGG? Nee, Als nieuwe data herleidbaar is, is geen herlevering nodig.' Ik kan nu niet afleiden wat dit precies betekent. |
Er wordt bedoeld: 'eenvoudig afleidbaar uit andere of eerder ingevoerde gegevens'. Dit komt voort uit onze template voor het aanmaken van een wijzigingsverzoek en zit dus in alle issues die wijzigingsverzoek zijn. Als ik 'herleidbaar' vervang door 'eenvoudig afleidbaar' wat ik nu in dit issue gedaan heb, is het dan duidelijker? Dan pas ik het ook zo aan in de template. |
@skornsekj Nee, deze zijn ongerelateerd. #214 gaat over de vraag of je iets op moet leveren. #228 (dit issue) gaat over de vraag of het toegestaan is als je een tekst aanlevert dit ook een tekst met 0 tekens mag zijn. Computers vind een tekst met 0 tekens een prima tekst maar mensen zien dat toch anders. Het idee is nu om ervoor te zorgen dat ALS je een tekst aanlevert daar toch minstens 1 leesbaar teken in moet staan. |
@PB-GNM @wilkoquak Nog een aanvulling. Voor de attributen namespace en lokaadID geldt een naamgevingsconventie. Zie paragraaf 3.3.2.3 Identificatie binnen het informatiemodel. Binnen de CVGG wordt gevalideerd of deze attributen voldoen aan de naamgevingsconventie. Zie Validatieregel CVGG018. De vraag is of voor deze attributen alsnog een reguliere expressie opgenomen moet worden. |
Een goed punt @skornsekj, als je toch reguliere expressies gaat toevoegen dan kan je meteen beter een goede doen. Als we dat binnen dit issue doen zou het wel heel erg last-minute zijn en je voorstel wordt ook niet meer gedekt door de titel van het issue. Ik stel dus voor deze apart op te pakken. |
In de adviesgroep van 24 oktober wordt opgemerkt dat het doorvoeren van deze regel ongewenst is als het ertoe zou leiden dat al eerder aan de CVGG aangeleverde gegevens niet meer geldig zouden zijn. In dat geval kan een alternatieve oplossing zijn dat de CVGG een waarschuwing geeft op het moment dat een string zonder leesbare tekens wordt aangeleverd. Er wordt besloten de regel alleen in te voeren als dit niet leidt problemen met aan aangeleverde gegevens en anders alleen een waarschuwing te gaan geven bij het aanleveren lege strings. |
RIVM gaat na het voorgestelde formele patroon ("\S.*") problemen geeft met wat er al in de CVGG zit. Zo niet, dan is de impact laag en kan het verzoek doorgevoerd worden. |
Aanleiding wijziging
Dit verzoek is ingediend door RIVM met helpdesknummer SDIMG-154 en met de volgende motivatie:
Er wordt bij de aanlevering aan de CVGG niet gecontroleerd wat er in de characterstring velden staat zoals bij softwarepakketnaam en softwarepakketversie voor het feature Geluidberekeningsobject. Het is daardoor mogelijk lege velden of een spatie aan te leveren. Dat is ongewenst.
Voorgestelde wijziging
Het opnemen van een reguliere expressie "\S.*" in het formele patroon van de verplichte characterstrings in IMG.
Dit betekent dat het eerste karakter een leesbaar karakter moet zijn.
Daarmee wordt het mogelijk hierop te valideren bij het invoeren van data in de CVGG.
Het betreft de volgende attributen:
Impactanalyse
Geef hier een indicatie van de impact van de wijziging:
-Wie gaat er wat van merken? Data providers, softwareleveranciers, CVGG
-Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
-Is er een herlevering nodig naar de CVGG? Nee, Als nieuwe data eenvoudig afleidbaar is van de oude, is geen herlevering nodig.
-Heeft het impact op het xml-schema? Ja, Het formele patroon komt ook in het schema als <xs:pattern value="\S.*"/>
-Is het backward compatible in de zin van validatie op het schema? Alleen niet als er attributen gevuld zijn zonder leesbare karakters
-Heeft het impact op de regels in IMG? Nee
-Heeft het impact op de validatieregels voor de CVGG? Ja
-Heeft het impact op de omgevingsregeling? Nee
-Is het een X, Y, of Z wijziging? Y of Z
Toelichting
Ruimte voor extra toelichting. Bijvoorbeeld alternatieven die je overwogen hebt.
The text was updated successfully, but these errors were encountered: