NeTEx moppers

[tten...@gmail.com]

Wat mooi, een Europese standaard zodat alle systemen betrouwbaar met elkaar kunnen communiceren! Behalve... dat het dus met al die profielen al niet zo werkt, omdat ieder land z'n eigen subset implementeert.

Wat mooi dan, een Nederlandse subset van een Europese standaard, zodat alle systemen in Nederland betrouwbaar met elkaar kunnen communiceren! Behalve... dat het dus met al die versies al niet zo werkt, omdat de versies niet onderling compatible zijn.

Wat mooi dan, een bepaalde versie van een Nederlandse subset van een Europese standaard, zodat alle systemen in Nederland die die bepaalde versie implementeren betrouwbaar met elkaar kunnen communiceren! Behalve... dat 60% zich dus niet aan de standaard houdt.

Een greep uit de problemen die ik de afgelopen dagen ben tegengekomen (bestanden rondom begin dienstregelingsjaar 2025):

• ARR, levert zogenaamd 9.2.4. Maar ze voegen hun zelfverzonnen elementen <Centroid> en <ParentStopAreaRef> toe.
• BISON, levert zogenaamd 9.2.4. Maar het attribuut "versionRef" op <TypeOfFrameRef> had volgens de XSD toch echt "version" moeten zijn. Was dit niet de organisatie die de standaarden schrijft?
• CXX, levert zogenaamd 9.3.0. Behalve dan dat 9.3.0 helemaal nog niet bestaat, en je dus maar moet gokken of het een van draft1 t/m draft4 is of rc1 of (straks) de definitieve versie.
• DOVA, levert zogenaamd 9.2.4. Maar doet ook dat dingetje met "versionRef", en verzint niet gespecificeerde <ValidBetween> elementen.
• HTM, levert zogenaamd 9.2.2. Maar er verschijnt opeens een <keyList> in <Line>.
• RET, levert zogenaamd 9.2.1. Maar dan verschijnt er opeens een <capacities> in <VehicleType>, wat pas geïntroduceerd is in 9.2.2.

EBS, GVB, KEOLIS en QBUZZ leveren in mijn steekproef wel validerende NeTEx-NL bestanden aan. Hulde!

Is het moeilijk voor vervoerders om een `xmllint --noout --schema netex-nl-met-constraints.xsd NeTEx_VANONS.xsd` in hun CI of export pipeline op te nemen? Of voor het NDOV loket om deze validatie uit te voeren, voordat bestanden worden geaccepteerd? (Misschien gaat iemand nu zeggen dat dat niet de taak van het loket is. Maar voor afnemers zou het wel fijn zijn :))

Enfin, ik denk dat ik dan maar gewoon dankbaar moet zijn dat alles tenminste valide XML en UTF8 is? Dat hebben we (bijv. in Kv6) ook wel eens anders gezien...

Tot zover deze rant. Bedankt voor het lezen.

[Stefan de Konink]

Op 5/26/25 om 11:21 AM schreef tten...@gmail.com:

> Is het moeilijk voor vervoerders om een `xmllint --noout --schema netex-
> nl-met-constraints.xsd NeTEx_VANONS.xsd` in hun CI of export pipeline op
> te nemen?

Ja hallo, ga deze mailinglijst nou niet vervuilen hoe je het DUS NIET
MOET DOEN.

De Nederlandse 9.3.0 versie is opgelijnd met de aankomende NeTEx 2.0
release die je kunt vinden in de next branch.

https://github.com/NeTEx-CEN/NeTEx/tree/next


Stop met het gebruiken van afvoerputjes zoals een "afgeleid XML Schema",
voor en door mensen gemaakt die geestelijk niet in staat zijn om
software te schrijven die gebaseerd is op een standaard en dan, maar
eigen varianten te bakken. En erger nog: halsstarrig aan hun eigen falen
vasthouden.

Het enige correcte commando om te valideren is:

xmllint --noout --schema xsd/NeTEx_publication.xsd bestandsnaam.xml.gz


Dan heeft jouw software ook geen probleem met mooie optionele elementen
die netjes zijn beschreven in de Europese standaard. Ze zijn dus *niet*
zelf verzonnen, ze zijn daadwerkelijk onderdeel van de enige echte
Europese NeTEx standaard.

Verder een prima analyse dat iedereen er een potje van maakt, maar ik
zie helemaal geen commentaar over TESO, DOEKSEN, MOJO, Wagenborg, ... en
dat is natuurlijk wel weer jammer ;)

We hebben een poging gedaan om alle Nederlandse NeTEx bestanden in EPIP
beschikbaar te maken. https://data.publicationdelivery.eu/epip/nl/

/rant

--
Stefan

[tten...@gmail.com]

Interessant! Dat is, voor zover ik kan zien, nergens gedocumenteerd. Ik dacht dat https://bison.dova.nu/standaarden de plek was waar de Nederlandse standaarden werden gepubliceerd. Voor wie bestaat dat NL-profiel dan überhaupt, als leveranciers zich er niet aan hoeven houden en afnemers ook niet?

Ik heb dezelfde set bestanden net even door de Europese NeTEx XSD gehaald (laatste versie van GitHub, 74b4cd9). De resultaten stemmen niet hoopvol...

Pass: BISON

Fail: ARR, CXX, DOVA, EBS, GVB, HTM, KEOLIS, QBUZZ, RET

Let wel: deze XSD valideert ook referenties, dus ik kan niet met zekerheid zeggen dat alle fails terecht zijn. In ieder geval GVB, HTM, KEOLIS en RET geven errors die niet met referenties te maken hebben. Kan natuurlijk een versie-dingetje zijn, maar dan is de Europese standaard dus ook niet backwards compatible, en hier is al helemáál geen manier om te achterhalen welke versie je dient te gebruiken. Het is allemaal version="ntx:1.1".

Bootjes doen we nog niet, dus die moppers hou je nog tegoed ;)

EPIP is weer zo'n afgeleid product, waar vast een en ander is geharmoniseerd en gecorrigeerd, maar vast ook weer een en ander is verhakseld of verdwenen. Daar ben ik sinds de ervaringen met GTFS wat huiverig voor.

[Stefan de Konink]

Op 5/26/25 om 1:02 PM schreef tten...@gmail.com:

> Interessant! Dat is, voor zover ik kan zien, nergens gedocumenteerd.

Vrijwel ieder NeTEx document nu en in het verleden bevat dat het
Nederlands profiel een subset is van het Europese. Dat vervolgens toch
mensen het presteren het Nederlandse profiel zodanig aan te passen dat
het niet meer matched met het Europese is het daadwerkelijke probleem.

> Voor wie bestaat dat NL-profiel dan überhaupt, als
> leveranciers zich er niet aan hoeven houden en afnemers ook niet?

De XSD is gemaakt voor partijen die geestelijk niet in staat waren
software te maken op basis van de Europese XSD omdat ze dan uit de
documentatie moesten halen welke elementen verplicht waren. Ik heb er
hard (en inmiddels succesvol) voor gelobbied om die Nederlandse XSD weg
te krijgen. Waarom is er een NL-profiel? Omdat we in Nederland afspraken
maken wat de minimale data is die we uitwisselen.

> Ik heb dezelfde set bestanden net even door de Europese NeTEx XSD
> gehaald (laatste versie van GitHub, 74b4cd9). De resultaten stemmen niet
> hoopvol...
> Pass: BISON
> Fail: ARR, CXX, DOVA, EBS, GVB, HTM, KEOLIS, QBUZZ, RET
> Let wel: deze XSD valideert ook referenties, dus ik kan niet met
> zekerheid zeggen dat alle fails terecht zijn.

De versies voor 9.3 "falen" op andere plekken. Elementen zonder
"version"-attribuut worden niet gecontroleerd. Daarnaast zijn de
referenties naar bijvoorbeeld EPIAP in EPIAP zelf incompleet (staat bij
DOVA al maanden een incident van open). En ligt het aan de producent of
alle BISON definities in de levering worden opgenomen.

> In ieder geval GVB, HTM,
> KEOLIS en RET geven errors die niet met referenties te maken hebben. Kan
> natuurlijk een versie-dingetje zijn, maar dan is de Europese standaard
> dus ook niet backwards compatible, en hier is al helemáál geen manier om
> te achterhalen welke versie je dient te gebruiken. Het is allemaal
> version="ntx:1.1".

De NeTEx 2.0 versie is niet backwards compatible met 1.x. Voorbeelden
zijn gepruts met TypeOfFuel en FuelType.

> Bootjes doen we nog niet, dus die moppers hou je nog tegoed ;)

Tis duidelijk dat de prioriteit niet bij het Oerolfestival ligt ;)

> EPIP is weer zo'n afgeleid product, waar vast een en ander is
> geharmoniseerd en gecorrigeerd, maar vast ook weer een en ander is
> verhakseld of verdwenen. Daar ben ik sinds de ervaringen met GTFS wat
> huiverig voor.

Dat is wat mij betreft terecht. Nederlandse OV mensen zouden Nederlandse
bron data moeten verwerken. Niet het volgende afvoerputje of API's.

--
Stefan