| Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #2387 is a reply to message #2372] |
Tue, 10 March 2020 13:15  |
Thomas Nygreen
Messages: 68
Registered: March 2008
|
Member |
|
|
Den 09.03.2020 10:08, skrev Dirk Bräuer:
>> No problem of technology from my side, but as I said, there are several infrastructure managers who do not allow it in their data models.
>
> So again: We can life without the attribute @dayOffset at <operatingPeriod>, but that means allowing departureDay<>0 at first <ocpTT>. This is less redundancy but more incompatibility to other data models of infrastructure managers who expect departureDay=!0 at first <ocpTT>.
There will always be data models out there that differ from the railML
data model. As long as we can reflect the information that those data
models need, I don't see a problem. In this case, a system with a native
data model that differs from railML can simply add/subtract/shift on
import/export. Creating redundancy in the model to be closer to more
native data models makes import interfaces more complicated for everyone.
Best regards,
Thomas Nygreen - Common schema coordinator, railML.org
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
