| InfraAttributes and InfraAttrGroups [message #1396] |
Mon, 15 August 2016 12:12  |
Christoph Jobmann
Messages: 2
Registered: August 2016
|
Junior Member |
|
|
Greetings,
I recently started looking into the infrastructure subschema.
As far as I can tell the element InfraAttrGroup and thereby the underlying InfraAttributes elements can only be references by track elements. That makes sense considering that most infraAttributes children are strongly connected to tracks.
Are there similar elements that can be used for the elements of type ocp? If not - are there plans to add them?
For now I see three ways to add information I would rather wrap up in some kind of attribute Containers:
- Use the regular extension Point and add an element for referencing infraAttributes Element
- Use the "other" extension point and add references as user-defined attributes or elements.
- Add a trackref pointing to a dummy track that contains an appropriate attributeGroupRefs element
I prefer the first option, even though it has the downside that it enables connecting an ocp with attributes that only make sense for tracks.
The second option has the downside that the generalInfraAttribute Elements can not be used anymore.
The third option is not really an option from my point of view - but it is the only way I see without adding new user-defined elements or attributes.
I made up an example where the options are demonstrated and hope that they help understanding my point. Extensions are marked by a NEW: prefix.
<railml>
<metadata>
<infrastructureManager id="im1" name="DB Netz AG"/>
</metadata>
<infrastructure id="i">
<infraAttrGroups>
<infraAttributes id="ia1">
<owner infrastructureManagerRef="im1"/>
</infraAttributes>
<infraAttributes id="ia2">
<generalInfraAttributes>
<generalInfraAttribute>
<attributes>
<attribute name="myNewAttribute" value="42"/>
</attributes>
</generalInfraAttribute>
</generalInfraAttributes>
</infraAttributes>
</infraAttrGroups>
<tracks>
<track id="dummy1">
<infraAttrGroupRefs>
<infraAttrGroupRef ref="ia1"/>
<infraAttrGroupRef ref="ia2"/>
</infraAttrGroupRefs>
</track>
</tracks>
<operationControlPoints>
<ocp id="ocp1">
<!-- Option 1 -->
<NEW:infraAttrGroupRefs>
<NEW:infraAttrGroupRef ref="ia1"/>
<NEW:infraAttrGroupRef ref="ia2"/>
</NEW:infraAttrGroupRefs>
</ocp>
<ocp id="ocp2" NEW:OwnerRef="im1">
<!-- Option 2 -->
<NEW:myNewAttribute value="42"/>
</ocp>
<ocp id="ocp3">
<!-- Option 3 -->
<propEquipment>
<trackRef ref="dummy1">
</propEquipment>
</ocp>
</operationControlPoints>
</infrastructure>
</railml>
Am I missing something? Which way is considered as best, are there other ways?
Kind regards
Christoph Jobmann
|
|
|
|
| Re: InfraAttributes and InfraAttrGroups [message #1406 is a reply to message #1396] |
Thu, 01 September 2016 08:41  |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Christoph,
there is currently no other option than to use the "any other" extension
point of an <ocp> to add an <infraAttributes> to an <ocp>.
Since an <ocp> has plenty of attributes and properties so far, I guess
there was no need to do so.
But, it is normally not in the sense of railML to extend it with a
structure coming from railML itself. In other words, the "any other"
extension point should, in my understanding, only be used with your own
sub-structures. If you really need an extension with a railML-own
sub-structure (as <infraAttributes>) there should be an "official" way
to do so.
So my question would be now: Which information exactly do you want to
add to an <ocp>? Since there are these plenty of properties of <ocp>s I
wonder why there is not already a solution for it.
To describe the "owner" of an <ocp>, what your example suggests:
- Please be aware that <ocp> is only a virtual place for a
cross-reference from lines and tracks to the timetable (and vice-versa).
Therefore, the typical place for an <ocp> is the middle of a station or
the middle of a platform of a station alongside a track. There is no
<ocp> in reality. That's why there is no "direct" owner of an ocp so far.
- For the owner of the tracks of an ocp, use <owner
infrastructureManagerRef=.../> of the track.
- For the owner of the platforms of an ocp, there should be a
possibility to use an /infrastructureManagerRef/ attribute at a
<platformEdge>. I do not know whether there is one right now, but if not
it should be better to solve the problem in this way.
- For the owner of the overhead wires of an ocp... And so on, there
should be /infrastructureManagerRefs/ at each physical infrastructure
element.
It is surely not acceptable to use "dummy tracks".
I would suggest you write here by which attributes you want to extend an
<ocp>. This may help us to understand the character and generality of
the extension. May be Christian can check whether there is already a
solution for them.
With best regards,
Dirk Bräuer.
---
Am 16.08.2016 um 15:24 schrieb Christoph Jobmann:
> Greetings,
>
> I recently started looking into the infrastructure
> subschema.
>
> As far as I can tell the element InfraAttrGroup and thereby
> the underlying InfraAttributes elements can only be
> references by track elements. That makes sense considering
> that most infraAttributes children are strongly connected to
> tracks.
>
> Are there similar elements that can be used for the elements
> of type ocp? If not - are there plans to add them?
> For now I see three ways to add information I would rather
> wrap up in some kind of attribute Containers:
>
> Use the regular extension Point and add an element for
> referencing infraAttributes Element Use the "other"
> extension point and add references as user-defined
> attributes or elements. Add a trackref pointing to a dummy
> track that contains an appropriate attributeGroupRefs
> element
>
> I prefer the first option, even though it has the downside
> that it enables connecting an ocp with attributes that only
> make sense for tracks.
> The second option has the downside that the
> generalInfraAttribute Elements can not be used anymore.
> The third option is not really an option from my point of
> view - but it is the only way I see without adding new
> user-defined elements or attributes.
>
> I made up an example where the options are demonstrated and
> hope that they help understanding my point. Extensions are
> marked by a NEW: prefix.
>
> <railml>
> <metadata>
> <infrastructureManager id="im1" name="DB Netz AG"/>
> </metadata>
> <infrastructure id="i">
> <infraAttrGroups>
> <infraAttributes id="ia1">
> <owner infrastructureManagerRef="im1"/>
> </infraAttributes>
> <infraAttributes id="ia2">
> <generalInfraAttributes>
> <generalInfraAttribute>
> <attributes>
> <attribute name="myNewAttribute" value="42"/>
>
> </attributes>
> </generalInfraAttribute>
> </generalInfraAttributes>
> </infraAttributes>
> </infraAttrGroups>
> <tracks>
> <track id="dummy1">
> <infraAttrGroupRefs>
> <infraAttrGroupRef ref="ia1"/>
> <infraAttrGroupRef ref="ia2"/>
> </infraAttrGroupRefs>
> </track>
> </tracks>
> <operationControlPoints>
> <ocp id="ocp1">
> <!-- Option 1 -->
> <NEW:infraAttrGroupRefs>
> <NEW:infraAttrGroupRef ref="ia1"/>
> <NEW:infraAttrGroupRef ref="ia2"/>
> </NEW:infraAttrGroupRefs>
> </ocp>
> <ocp id="ocp2" NEW:OwnerRef="im1">
> <!-- Option 2 -->
> <NEW:myNewAttribute value="42"/>
> </ocp>
> <ocp id="ocp3">
> <!-- Option 3 -->
> <propEquipment>
> <trackRef ref="dummy1">
> </propEquipment>
> </ocp>
> </operationControlPoints>
> </infrastructure>
> </railml>
>
> Am I missing something? Which way is considered as best, are
> there other ways?
>
> Kind regards
> Christoph Jobmann
|
|
|
|
| Re: InfraAttributes and InfraAttrGroups [message #1411 is a reply to message #1396] |
Fri, 02 September 2016 09:27 |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Christoph,
let me comment on your post inline:
Am 16.08.2016 um 15:24 schrieb Christoph Jobmann:
> [...]
>
> As far as I can tell the element InfraAttrGroup and thereby
> the underlying InfraAttributes elements can only be
> references by track elements. That makes sense considering
> that most infraAttributes children are strongly connected to
> tracks.
That is correct. Currently, infraAttrGroups can only be referenced from
tracks.
> Are there similar elements that can be used for the elements
> of type ocp? If not - are there plans to add them?
The problem will be solved with railML3 as it will allow to reference
parameter sets (like infrastructure parameters) from any type of
NetElement, even from a whole network. For railML baseline 2, such a
possibility is currently missing.
> For now I see three ways to add information I would rather
> wrap up in some kind of attribute Containers:
>
> Use the regular extension Point and add an element for
> referencing infraAttributes Element Use the "other"
> extension point and add references as user-defined
> attributes or elements. Add a trackref pointing to a dummy
> track that contains an appropriate attributeGroupRefs
> element
>
> I prefer the first option, even though it has the downside
> that it enables connecting an ocp with attributes that only
> make sense for tracks.
I prefer the first version as well: It should be possible to reference
to infraAttrGroups from an OCP, too. The mentioned downside can be
solved by extending the variety of possible parameters so that also
specific OCP features can be modelled.
The main question for now:
Do you need to have a solution for railML baseline 2 or will it be OK if
we solve the issue just with railML 3?
Best regards
Christian
--
Christian Rahmig
railML.infrastructure coordinator
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: InfraAttributes and InfraAttrGroups [message #1412 is a reply to message #1406] |
Fri, 02 September 2016 09:56 |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Dirk,
just a few remarks regarding your answer post:
Am 01.09.2016 um 08:41 schrieb Dirk Bräuer:
> Dear Christoph,
>
> there is currently no other option than to use the "any other" extension
> point of an <ocp> to add an <infraAttributes> to an <ocp>.
>
> Since an <ocp> has plenty of attributes and properties so far, I guess
> there was no need to do so.
>
> But, it is normally not in the sense of railML to extend it with a
> structure coming from railML itself. In other words, the "any other"
> extension point should, in my understanding, only be used with your own
> sub-structures. If you really need an extension with a railML-own
> sub-structure (as <infraAttributes>) there should be an "official" way
> to do so.
Absolutely correct. The "any other" container shall be used only
temporarily for company specific extensions of the schema, but not for
placing information that are already modelled in railML (but
unfortunately not accessible at the moment).
> So my question would be now: Which information exactly do you want to
> add to an <ocp>? Since there are these plenty of properties of <ocp>s I
> wonder why there is not already a solution for it.
>
> To describe the "owner" of an <ocp>, what your example suggests:
>
> - Please be aware that <ocp> is only a virtual place for a
> cross-reference from lines and tracks to the timetable (and vice-versa).
> Therefore, the typical place for an <ocp> is the middle of a station or
> the middle of a platform of a station alongside a track. There is no
> <ocp> in reality. That's why there is no "direct" owner of an ocp so far.
>
> - For the owner of the tracks of an ocp, use <owner
> infrastructureManagerRef=.../> of the track.
>
> - For the owner of the platforms of an ocp, there should be a
> possibility to use an /infrastructureManagerRef/ attribute at a
> <platformEdge>. I do not know whether there is one right now, but if not
> it should be better to solve the problem in this way.
>
> - For the owner of the overhead wires of an ocp... And so on, there
> should be /infrastructureManagerRefs/ at each physical infrastructure
> element.
If I need to formulate a ticket out of it, I would write: "It shall be
possible to define an owner for every physical infrastructure element."
Correct? An OCP can be operated by someone, but the owner is relevant
only for the station and its facilities.
> It is surely not acceptable to use "dummy tracks".
Agree!
> I would suggest you write here by which attributes you want to extend an
> <ocp>. This may help us to understand the character and generality of
> the extension. May be Christian can check whether there is already a
> solution for them.
I am ready.
> With best regards,
> Dirk Bräuer.
Best regards
Christian
--
Christian Rahmig
railML.infrastructure coordinator
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
