| [railML3] Proposal of a semantic constraint for <baliseGroup> [message #3329] |
Fri, 27 September 2024 12:28  |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
Hi all,
the ETCS working group introduced a semantic constraint for balise groups documented in the working groups documentation for the element <baliseGroup> and <balise>. The following wording was proposed:
Quote:
The element "baliseGroup" shall always use the railML option "spotLocation" to define the balise group location on the topology.
The same wording would apply for "balise".
The following reasoning was given by the working group:
According to UNISIG-026 (versions 2.3.0, 3.4.0 or 3.6.0), section 3.4.2.2.1 and UNISIG-040 (versions 2.3.0, 3.3.0 or 3.4.0) section 3.3.1.3, a balise group (represented by the railML element "baliseGroup") shall be considered as point-shaped element without extension. The reference location of the balise group is the location of the balise with N_PIG=0.
In extension the balise also is considered a point-shaped element.
Therefore I would propose to add the quoted wording above as a semantic constraint for balise and balise group.
What do you think? Are there objections to this?
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Proposal of a semantic constraint for <baliseGroup> [message #3607 is a reply to message #3329] |
Wed, 30 April 2025 10:52  |
Milan Wölke
Messages: 213
Registered: April 2007
|
Senior Member |
|
|
As there have not been any objections to this in a long time I will implement this SemCon as proposed in the wiki, to be approved in the next coordinators meeting.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Proposal of a semantic constraint for <baliseGroup> [message #3622 is a reply to message #3607] |
Mon, 19 May 2025 17:48 |
Thomas Nygreen
Messages: 110
Registered: March 2008
|
Senior Member |
|
|
Dear community!
These constraints were discussed by the coordinators today. They are a bit outside of our defined purpose of syntactic constraints, which is to restrict the allowed values of one property depending on the values of other properties. Defining which subelements an element has is really a syntactic constraint. But more importantly, they raise a bigger question: which types of locations are valid or meaningful for which types of infrastructure entities? And (how) should we restrict that?
Should we:
1: change the modelling of infrastructure entities, so that only meaningful location types for each entity type are allowed?
2: add (many) more "semantic" constraints, mimicking a syntactic remodelling?
3: document best practice per entity type and which location types to use for that entity, but not introduce any constraints?
4: do nothing, and let the users decide for themselves what is meaningful for their use?
https://development.railml.org/railml/version3/-/issues/652
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Proposal of a semantic constraint for <baliseGroup> [message #3694 is a reply to message #3622] |
Mon, 11 August 2025 15:09 |
Marharyta Vyskarka
Messages: 21
Registered: April 2025
|
Junior Member |
|
|
Hi everyone,
I suggest to change the wording for this constraint, because currently it can be understood as <spotLocation> should always be defined for either of the elements, when it can be not specified at all. I propose to change it to "The element "baliseGroup" shall always use the railML option "spotLocation" when defining the balise group location on the topology."
Best regards,
Margo Vyskarka
Marharyta Vyskarka – Software Developer
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: [railML3] Proposal of a semantic constraint for <baliseGroup> [message #3697 is a reply to message #3694] |
Fri, 15 August 2025 09:43 |
christian.rahmig
Messages: 530
Registered: January 2016
|
Senior Member |
|
|
Hi Margo,
the changed wording is fine for me. However, in the vast majority of cases (based on current use cases) we will have a location of the balise group on the topology network. A balise group without a topology location will be an exception.
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
