| Re: Balise / baliseGroups : structure & attributes [message #414 is a reply to message #411] |
Wed, 31 October 2012 23:09   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Christian, Pierre and other railML users,
Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>>> Conceptually a balise belongs to one and only one balise group. So why
>>> not
>>> create the parent node <baliseGroup> having a list of 1..8 balises ?
>>> On top of that, attributes like countryID which today is attached to
>>> <balise> could be move the parent node <baliseGroup> (+ some additional
>>> attributes like
>>> - idBaliseGroup
>>> - its type (in Belgium we have Infill Balise Group / Signal Balise
>>> Group /
>>> Technical Fixed Balise Group / Technical Switchable Balise Group)
>>> - its reference to the signal (xs:IDRef)
> - A <baliseGroup> is modelled as an element with ID and name and
> therefore inherits the parameters id, name and code.
+1
> - A <baliseGroup> fulfills a certain function, which will be defined
> in the parameter "type" with the possible values 'infill', 'signal',
> technicalFixed' and 'technicalSwitchable'.
That above mentioned types are of different kind. A "signal" balise
group is always "technicalSwitchable". The "infill" balise group is also
always "technicalSwitchable". A "technicalFixed" balise group may be one
for odometry or for track conditions ...
Thus I would prefer the enumeration values "infill", "signal" and
"fixed" for the "type" attribute.
> - A <baliseGroup> may have a reference to a <signal>, which will be
> defined in the optional parameter "signalRef".
On another thread we currently discuss the reference from a signal to
its "train protection element". I would prefer to go the same way here.
Thus there could be a reference from a signal to its "protecting" balise
group with a "baliseGroupRef" attribute in <signal> or <signalAspect>.
> - The reference from a <baliseGroup> to up to eight single <balise>
> elements remains with the sequence of <baliseRef> objects.
As mentioned at the beginning of this thread the main idea was to define
the up to eight balises inside the balise group not referring them
outside. A balise of a balise group cannot be used otherwise by another
balise group. Some attributes of the current <balise> element should
move to the <baliseGroup> element in order to reduce not-needed
redundancy.
> [1] https://trac.assembla.com/railML/ticket/174
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
