version attribute make clear through the xsd and documentation that @version is a number (entur-interpretation) or any
skinkie opened this issue · 14 comments
<xsd:attribute name="version" type="VersionIdType" use="required">
<xsd:annotation>
<xsd:documentation>Version number of referenced entity.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
For now VersionIdType is said to be "A revision identifier (e.g. a number) that should be updated (e.g. increased) each time the unit that is refers to is modified." and its type is "xsd:normalizedString"
Having a number (as characters in the normalizedString) mandatory is of course ok for a profile ... but probably much more complicated in the general case (but it can be a recommendation)
For now VersionIdType is said to be "A revision identifier (e.g. a number) that should be updated (e.g. increased) each time the unit that is refers to is modified." and its type is "xsd:normalizedString" Having a number (as characters in the normalizedString) mandatory is of course ok for a profile ... but probably much more complicated in the general case (but it can be a recommendation)
The problem is that in several parts of the annotation it is explicitly mentioned as a number. Must be cleared up if it is not a number, or it is.
At minimum, refine annotations
Don't change the type, but make recommendations for monotonically increasing use (what about dates).
There is also difference between the global Frame versioning and the per object versioning.
Guidelines to be added in EPIP/NeTEx and Guidance document
@ue71603
Added to the guidance document in 5.9. so only André's stuff left
Added to the guidance document in 5.9. so only André's stuff left
@ue71603 Can you please point me to the guidance document mentioned?
@trurlurl . The guidance document was updated by me. It is in the DATA4PT sharepoint. I would ask you to update it in the NeTEx specs to have the same information (part 1,4 and 6 probably). If you need the guidance document, I can send you a copy.
I added the following text to the version attribute documentation of EntityInVersion
, in part 1 and part 4: "Allowed values are "any", or a string adhering to agreed-upon formatting and interpretation rules (representing, e.g., numbers or dates). Consecutive versions should be strictly increasing."
And in the xds: PR #794 . Is that what you wanted?
The problem with the wording 'string' is that it is in computer terms still an alphanumerical list of characters. If something is strictly increasing, are we then going in the ballpark of a, b, c? To be honest, it should be much more clear if we would explicitly state this thing is 'any' or numerical, and must be strictly increasing.
@skinkie A bit less elegant, but would the following be sufficiently clear? I find the word "string" useful here, but I'll try to think of a further alaternative.
"With the exception of "any", consecutive versions should be strictly increasing. Which ranking relation applies will depend on the chosen format and interpretation of the version strings (numbers, dates, …). "
Is it possible to omit the word 'string' altogether? Because this will keep the door open towards alphanumerical interpretations. I personally do not care. Our friends from Germania do...
What about this?
The value may be "any" or a VERSION number adhering to agreed-upon formatting and interpretation rules (representing, e.g., numbers or dates). Consecutive VERSION numbers should be strictly increasing.
Perfect. Lose enough for profiles, strict enough to state intentions.