OSO:2017/Inhoudelijke Eisen: verschil tussen versies

Uit Kennisnet Developers Documentatie
Naar navigatie springen Naar zoeken springen
k
 
(9 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 3: Regel 3:
   
 
==Dossier-formaat en -controle==
 
==Dossier-formaat en -controle==
Binnen OSO wordt gewerkt met één gestandaardiseerd formaat voor het Dossier; in OSO'17 wordt de Standaardversie: '''2017.1.0''' gebruikt.
+
Binnen OSO wordt gewerkt met één gestandaardiseerd formaat voor het Dossier; in OSO'17 wordt de Standaardversie: '''2017.1.1''' gebruikt.
 
===Eis aan Bronsysteem===
 
===Eis aan Bronsysteem===
 
Een Bronsysteem moet voorafgaand aan verzending controleren dat het Dossier hieraan voldoet.
 
Een Bronsysteem moet voorafgaand aan verzending controleren dat het Dossier hieraan voldoet.
===Eis aan Doelsysteem==
+
===Eis aan Doelsysteem===
 
*Een ontvangend systeem mag voorafgaand aan het importeren een Dossier valideren tegen de correcte versie van de Standaard. Dit is niet verplicht.
 
*Een ontvangend systeem mag voorafgaand aan het importeren een Dossier valideren tegen de correcte versie van de Standaard. Dit is niet verplicht.
 
*Bij de verdere verwerking en import van het Dossier moet een ontvangend systeem dusdandig robuust zijn dat subversies van het Dossier verwerkt kunnen worden. Met subversies worden alle versies achter onder de hoofdversie bedoelt, dus bij een hoofdversie 2017.1 moeten zowel Dossiers van versie 2017.1.0 én 2017.1.1 worden geaccepteerd.)
 
*Bij de verdere verwerking en import van het Dossier moet een ontvangend systeem dusdandig robuust zijn dat subversies van het Dossier verwerkt kunnen worden. Met subversies worden alle versies achter onder de hoofdversie bedoelt, dus bij een hoofdversie 2017.1 moeten zowel Dossiers van versie 2017.1.0 én 2017.1.1 worden geaccepteerd.)
   
  +
==Selectief uitleveren==
  +
Om bronscholen in staat te stellen de inhoud van een dossier aan te passen, zodanig dat de inhoud recht doet aan het doel van de overdracht (doelbinding) en daarbij rekening te houden met zowel de administratieve last voor de school als de impact hiervan voor systeembouwers. Er is gekozen om te gaan werken met profielen in combinatie met blokken van velden. Per profiel wordt aangegeven welke blokken verplicht, verboden dan wel optioneel zijn. De indeling per profiel is terug te vinden in de beschrijving van de OSO gegevensset.
   
  +
Een school kan optionele blokken van velden uit het dossier verwijderen, zodat deze niet meegestuurd worden. De ontvangende school kan in het dossier zien of blokken bewust uitgezet zijn. Dit wordt door de pdf-viewer (door Kennisnet geleverd) ondersteund; ontvangende systemen zijn niet verplicht dit binnen hun systeem te tonen
  +
  +
In de gegevensset wordt in OSO’17 gewerkt met profielen. Een profiel verdeelt de gegevensset in blokken van velden. Per type uitwisseling (POVO, POPO, etc.) wordt aangegeven of een blok verplicht of optioneel is.
  +
  +
Zie ook: [[OSO:2017/Samenstellen Inhoud Dossier|Selectief samenstellen Dossier]].
  +
  +
  +
==Telefoonnummer validatie==
  +
Bij het invoeren of wijzigen van een telefoonnummer in een ‘telefoon veld’ (communicatiesoort == ‘telefoon”) in OSO, dient een systeem:
  +
#Het nummer gecontroleerd mbv de [https://github.com/googlei18n/libphonenumber Google library ‘libphonenumber’]
  +
#Alleen nummers die door deze library als ‘valid’ worden beschouwd mogen geaccepteerd
  +
#Het nummer wordt vervolgens in het ‘'''E164’ formaat''' opgeslagen (output van library)<br>
  +
Bij het opslaan van het telefoonnummer wordt bij voorkeur/aanbevolen om de volgende structuur toe te passen: <telefoonnummer (E164 formaat)><spatie><aanvullende informatie>.<br>
  +
  +
Op die manier kan er wel aanvullende informatie worden toegevoegd bij een telefoonnummer en wordt het interpreteren en controleren van telefoonnummers eenduidiger.<br>
  +
  +
'''NB:''' Als eindgebruikers het telefoonnummer niet verbeteren of op enige wijze het telefoonnummer niet gecorrigeerd raakt, dan is het toepassen van 'onmogelijke telefoonnummers' geen reden om een dossier niet te verzenden of te weigeren bij importeren. Door gebruikers te attenderen en begeleiden bij het invoeren van bruikbare telefoonnummers zal (hopelijk) de kwaliteit van deze gegevens binnen OSO verbeteren.
   
   
[[Category:Book OSO|306]]
 
 
[[Categorie:Overstapservice Onderwijs]]
 
[[Categorie:Overstapservice Onderwijs]]

Huidige versie van 4 dec 2017 om 10:57

Toepassen EduStandaard OSO Gegevensset

Dossiers verstuurd via de OSO infrastructuur moeten altijd voldoen aan de EduStandaard OSO gegevensset.

Dossier-formaat en -controle

Binnen OSO wordt gewerkt met één gestandaardiseerd formaat voor het Dossier; in OSO'17 wordt de Standaardversie: 2017.1.1 gebruikt.

Eis aan Bronsysteem

Een Bronsysteem moet voorafgaand aan verzending controleren dat het Dossier hieraan voldoet.

Eis aan Doelsysteem

  • Een ontvangend systeem mag voorafgaand aan het importeren een Dossier valideren tegen de correcte versie van de Standaard. Dit is niet verplicht.
  • Bij de verdere verwerking en import van het Dossier moet een ontvangend systeem dusdandig robuust zijn dat subversies van het Dossier verwerkt kunnen worden. Met subversies worden alle versies achter onder de hoofdversie bedoelt, dus bij een hoofdversie 2017.1 moeten zowel Dossiers van versie 2017.1.0 én 2017.1.1 worden geaccepteerd.)

Selectief uitleveren

Om bronscholen in staat te stellen de inhoud van een dossier aan te passen, zodanig dat de inhoud recht doet aan het doel van de overdracht (doelbinding) en daarbij rekening te houden met zowel de administratieve last voor de school als de impact hiervan voor systeembouwers. Er is gekozen om te gaan werken met profielen in combinatie met blokken van velden. Per profiel wordt aangegeven welke blokken verplicht, verboden dan wel optioneel zijn. De indeling per profiel is terug te vinden in de beschrijving van de OSO gegevensset.

Een school kan optionele blokken van velden uit het dossier verwijderen, zodat deze niet meegestuurd worden. De ontvangende school kan in het dossier zien of blokken bewust uitgezet zijn. Dit wordt door de pdf-viewer (door Kennisnet geleverd) ondersteund; ontvangende systemen zijn niet verplicht dit binnen hun systeem te tonen

In de gegevensset wordt in OSO’17 gewerkt met profielen. Een profiel verdeelt de gegevensset in blokken van velden. Per type uitwisseling (POVO, POPO, etc.) wordt aangegeven of een blok verplicht of optioneel is.

Zie ook: Selectief samenstellen Dossier.


Telefoonnummer validatie

Bij het invoeren of wijzigen van een telefoonnummer in een ‘telefoon veld’ (communicatiesoort == ‘telefoon”) in OSO, dient een systeem:

  1. Het nummer gecontroleerd mbv de Google library ‘libphonenumber’
  2. Alleen nummers die door deze library als ‘valid’ worden beschouwd mogen geaccepteerd
  3. Het nummer wordt vervolgens in het ‘E164’ formaat opgeslagen (output van library)

Bij het opslaan van het telefoonnummer wordt bij voorkeur/aanbevolen om de volgende structuur toe te passen: <telefoonnummer (E164 formaat)><spatie><aanvullende informatie>.

Op die manier kan er wel aanvullende informatie worden toegevoegd bij een telefoonnummer en wordt het interpreteren en controleren van telefoonnummers eenduidiger.

NB: Als eindgebruikers het telefoonnummer niet verbeteren of op enige wijze het telefoonnummer niet gecorrigeerd raakt, dan is het toepassen van 'onmogelijke telefoonnummers' geen reden om een dossier niet te verzenden of te weigeren bij importeren. Door gebruikers te attenderen en begeleiden bij het invoeren van bruikbare telefoonnummers zal (hopelijk) de kwaliteit van deze gegevens binnen OSO verbeteren.