remove version and versionref from NeTEx

[ue71603]

The analysis of existing data shows, that the handling of version and versionref is an unholy mess. The xsd validation also has problems. Furthermore everything done there can be expressed by replacements of journey as well. The way stuff is exported also does not warrant it.

I think that no existing software processes it correctly.

[skinkie]

NeTEx has "the problem" (or benefit) that the id's must be unique per object, opposed to xs:ID being unique per document. If you would want to change the identifier every time a property changes, and handle the fall out of that, because now all ids of all referencing elements must also be change, this would be an option. On the other hand if you don't care about the previous "version" and just have a rolling release (like GTFS) only support changing things in the future by duplicating the object (or basically everything if a name of a stop changes in the future), this would be an option.

In practise how France, SBB and Entur have created profiles that spilt content across documents, effectively breaking any regular XML validation is the real problem. The Dutch profile, VDV462, or EPIP does not have this issue. Ok, you may argue that EPIP_LINE_OFFER may have an issue with ServiceJourneyInterchanges with different lines, but you can then always choose to ignore it, or not export it as part of a EPIP_LINE_OFFER, or write down the semantics of prerequisites, an already available option in NeTEx nobody uses.

[ue71603]

I disagree: It is not only the files. It is also that the semantic behaviour of version is never the same between multiple implementations. How to assign versions, how to handle them. What they mean.

I also don't think that each change in an object needs a new id (or version). NeTEx is - as many of the TM standards - have baken implementation of fundamental concepts (e.g. SIRI doing in a haphazard way, what you expect a full Publish/Subscribe protocol). This is like implementing ACID on your own for a DB.

We had the point with the version-element.

Also, if it were that important, why isn't it implemented in SIRI? Where you have rapid changes in things. You loose the link at the latest there. And already implementations cropping up, where there is 7 days of timetable in SIRI and no longer in NeTEx.

The current advantage is that you can ignore version in most implementations now.

[skinkie]

I think the fundamental reason why SIRI does not have a version is that it is expected to have the version of the object active on that day, as a specific instance.

It isn't obviously only 'version' it is also the second layer of availability being ValidBetween if you would consider when a set of objects are valid you could consolidate those to a valid set. Especially if there are individual data providers.

[ue71603]

France is doing SIRI ET for 3 days now. Switzerland is planning it. The way Entur does stuff doesn't need the version either.
I know this is for a group meeting :-)

[Mike-Stallybrass]

At present, I think this would be a breaking change for Entur. With Entur, a NeTEx package normally consists of more than one file (document). When referencing another object, the version has to be specified if that other object is in the same file, but no version is used if the referenced object is in another file. This is enforced during their validations. If the referenced object is external (in another file or even an external data domain), and a specific version is required, then a versionRef is used. The versionRef is actively used at present when specifying train layouts for seat reservations, for example, as dated changes to vehicle configurations come into effect.

[TuThoThai]

@ue71603 : I fully agree with removing version and versionRef from NeTEx.

Happy to work on the PR, if the group agrees!

[skinkie]

@hilcokats @Joostb61 please be at the next meeting.