transport-apis
transport-apis copied to clipboard
public-transport
version field for Trias
To my surprise, bwegt-trias.json now supports Trias 1.2 without me noticing before.
If the request contains <Trias version="1.1", it answers like a Trias 1.1.
If the request contains <Trias version="1.2", it answers like a Trias 1.2.
The same holds for VVO Trias.
Before I write a PR updating those values, I'd like to discuss the Trias Schema:
It might be valuable for a client to know that a Trias instance supports version 1.1 AND 1.2.
Storing this information appears to be not possible with the current JSON schema.
P.S. if there was a breaking change in the Trias JSON schema: Currently a version "1.3.1" would be not possible to store. I found no hint in the TRIAS standard that they will have only one dot in the version.
It might be valuable for a client to know that a TRIAS instance supports version 1.1 AND 1.2.
Can you give an example? I could not come up with one on my own yet.
P.S. if there was a breaking change in the Trias JSON schema: Currently a version "1.3.1" would be not possible to store. I found no hint in the TRIAS standard that they will have only one dot in the version.
Indeed. However as long as there is no Patch-Version available, I would not update the schema yet, as currently a configuration with two dots would be considered a wrong configuration (as there does not exist a two or more dotted version of TRIAS yet).
Can you give an example? I could not come up with one on my own yet.
Example for instances: both, MobidateBW and VVO Sachsen currently support 1.1 and 1.2. (at least a few weeks ago)
Example for usage: Server supports 1.2 and client hasn't been updated to 1.2 and wants to know if 1.1 is still supported.
Can you give an example? I could not come up with one on my own yet.
Example for instances: both, MobidateBW and VVO Sachsen currently support 1.1 and 1.2. (at least a few weeks ago)
Example for usage: Server supports 1.2 and client hasn't been updated to 1.2 and wants to know if 1.1 is still supported.
Okay maybe I wrongly phrased my question: I assume that every server that supports 1.2 also supports requests for version 1.1. (At least as a workaround when you take the 1.1 request and just set the version of the request to 1.2) as this is a minor release and should not break anything. So If your client supports all fetaures with 1.1. it should still function, if you just change the number version number in the requests to 1.2. If that is not the case, then the TRIAS standard seem to not comply to semantic versioning and we would have a need to collect the currently supported versions. Otherwise I would leave that out and just set the version to the newest version available.
I assume that every server that supports 1.2 also supports requests for version 1.1
AFAIR MobiData BW wants to remove support for 1.1 in autumn. But I'm not a reliable source for this information, I can't talk for them.
AFAIR MobiData BW wants to remove support for 1.1 in autumn. But I'm not a reliable source for this information, I can't talk for them.
Then I would not bother to somehow manage two versions in the TRIAS configuration. And even if they support it longer, I still don't see the need.