NeTEx-CEN
remove version and versionref from NeTEx
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.
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.
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.
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.
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 :-)
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.
@ue71603 : I fully agree with removing version and versionRef from NeTEx.
Happy to work on the PR, if the group agrees!
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.
In order to make my humble contribution: totally agree with Matthias. In practical, a version attribute without a strong/shared semantic behind is useless and not used. Into our customer's datasets, the version concept is not used on most of NeTEx classes. The only notable usage is on models like Stop Place/Quay or Line. But it's often presenting because ... NeTEx asks it and not for practical/user oriented feature.
It could be a powerful concept, but it would require a widely shared semantic (from data production to user display), a relation with the object validity period, a more advanced dependency management (like version="> 1.8.11"), a not linear/incremental approach, etc.
A first useful step, the version/versionRef attribute could be optional to match the real usage. But the XSD constraints could be unhappy with this approach.
One frequently asked question I've seen (last one today at a NeTEx training we're holding) is very simple: how to advertise a name change, can I use version for that? I wonder if keeping it only for very narrow, proven use-cases, could be interesting?
Otherwise agree, I find that having versions potentially on everything is not something a reuser can properly handle with reasonable effort.
And sidenote re @ue71603, can you clarify "France is doing SIRI ET for 3 days now", I do not understand? Thank you!
