Voorstel Hygiëne SIKB0101-protocol

Voorstel Hygiëne SIKB0101-protocol

CSO Adviesbureau Contactpersonen CSO: Johannes Battjes ([email protected])

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

Versiebeheer Versie Datum 0.1 8 februari 2007 0.2 26 maart 2007 0.3 0.3

23 mei 2007 1 juni 2007

doelgroep GO plus Beheersorganisatie SIKB PSL BC

aanleiding Eerste opzet Gedeeltelijke uitwerking voorstellen Goedkeuring regels Aangepast naar aanleiding van PSL


1

Hygiëneregels

Dit hoofdstuk formuleert een aantal regels voor hygiëne en de mogelijke aanpak ervan in 2007. Deze regels (de genummerde schuingedrukte teksten hieronder) zullen de huidige regels in Hst 4.1 van de protocol omschrijving vervangen.

1.1

Naamgeving van xsd’s

(1) “Een xsd betreft altijd een samenhangend domein binnen de bodemuitwisseling. De naamgeving is als volgt: SIKB0101 <domeinomschrijving>.xsd waarin domeinomschrijving omschrijft op wat voor soort gegevens de xsd betrekking heeft.” Dit leidt tot de volgende namen vanaf versie 6.0: • • • • •

1.2

SIKB0101 bodeminformatie.xsd SIKB0101 labresultaatgegevens.xsd SIKB0101 labopdrachtgegevens.xsd SIKB0101 labaanlevering.xsd SIKB0101 lookup.xsd

Naamgeving binnen xsd

Op dit moment is het gebruik van underscores in de naamgeving willekeurig. Bijvoorbeeld “terugsaneerwaarde” (zonder underscore en “san_bovengrond_id” (met underscore). Ook is het gebruik van afkortingen is willekeurig. Status wordt bijvoorbeeld nu eens afgekort en dan weer niet: stat_dyn versus eut_status. Ander voorbeeld: samenloop_kosten_geschat versus samenloop_kosten_werk, Sebpartij versus vervolg_WBB. Omdat de sikb-xsd’s (vrijwel) geen hoofdletters bevatten stellen we voor ter onderscheid van verschillende woorden in een naam de underscores te handhaven maar deze wel consequent toe te passen. De oude regel voor hoofdletters (Hst 4.1) luidt: Elementen zijn in hoofdletters opgenomen en attributen in kleine letters. Dit is echter voor het bodeminformatie xsd niet het geval, daar hebben elementen meestal kleine letters. Vastgestelde naamgevingsregel: (2) “Namen van attributen en elementen worden geschreven in kleine letters. Woorden worden voluit geschreven. Tussen woorden worden altijd underscores gebruikt. Acroniemen (SEB, WBB) mogen worden gebruikt in de namen, zij het in kleine letters. Opzoekwaardes die verwijzen naar de lookup xml eindigen op _id. Namen mogen niet eindigen op ‘type’ om verwarring met schema-types te voorkomen ” Vanaf versie 5.1.0 worden deze regels bij wijzigingsvoorstellen toegepast.

1.3

Gebruik types binnen xsd

De regel in Hst 4.1 luidt:


Een aantal velden die op verschillende plaatsen terug kunnen komen zijn samengevoegd in extra objecten, zoals het Geo-Object, adres en veldmonster. Dit is niet consequent toegepast. Nu is bv ‘sikb_id’ een twintigtal keer afzonderlijk gedefinieerd (met 20 maal dezelfde omschrijving). Beter is het hiervan een type te maken. Hetzelfde geldt velden als “kosten”. Hiervoor zou een bedrag-type moeten worden gemaakt (met bv 2 cijfers achter de komma). (3) “Zodra twee of meer verschillende velden een overeenkomend formaat en een overeenkomende betekenis hebben wordt een type gedefinieerd” Uit te voeren in SIKB 6.0.0 voor entiteiten sikb_idType en bedragType

1.4

Gebruik attributen en elementen

Hst 4.1 meldt over het gebruik van attributen en elementen:: Velden waarvoor duidelijke afspraken gemaakt zijn, zoals codetabellen, datum velden, ja/nee velden of en de meeste velden die hoeveelheden of dieptes bevatten zijn als attributen opgenomen. De overige velden zijn als elementen opgenomen. Deze regel lijkt niet consequent toegepast maar het is ook niet zeker wanneer een afspraak duidelijk is. (4) “Een veld wordt als attribuut gedefinieerd tenzij dit niet mogelijk is” Deze regel wordt bij het definiëren van nieuwe velden gevolgd vanaf 5.1.0.

1.5

Compacte elementen

In de huidige xsd zijn vaak samenhangende gegevens als aparte attributen aan een element ‘gehangen’. Voorbeeld: locatie/ond_kosten_werk en locatie/ond_kosten_geschat. Hierdoor wordt de samenhang tussen entiteiten niet duidelijk en krijgt het overkoepelende element veel velden. Beter ware het compacte elementen te houden met alleen samenhangende gegevens (zoals in SIKB 5.0.0 gedaan is met het nieuwe element “kosten”). (5) “Samenhangende attributen en elementen worden samengevoegd onder één nieuw element” Toepassen bij nieuwe attributen vanaf versie 5.1.0.

1.6

Toelichting

De definities in de xsd laten nu te wensen over. Bekende discussiepunten voor SIKB 5.0.0. waren kadastrale gegevens en geoobject. Maar ook belangrijke velden als eut_totaal of stat_oord in locatie hebben geen toelichting. (6) “In de toelichting op elk attribuut en element staat helder omschreven wat de betekenis van een veld is en naar welke standaard (Nen, Iso, ….) de betekenis verwijst” Toepassen bij wijzigingen vanaf versie 5.1.0.

1.7

Gebruik opzoektabellen

Overal waar codes gebruikt worden zouden opzoektabellen moeten worden toegepast. Dit gebeurt op een enkele uitzondering na goed en is een van de sterkste punten van het protocol. (7) “Waar velden codes bevatten wordt verwezen naar opzoeklijsten”


1.8

Verwijderen overbodige velden

Het is onwenselijk oude velden te handhaven omdat niet duidelijk is dat deze niet meer gebruikt hoeven worden. Voorbeeld: de oude en nieuwe kostenvelden. (8) “Verwijder velden die niet meer gebruikt worden in de uitwisseling”


Voorstel Hygiëne SIKB0101-protocol

Recommend Documents