Home » railML newsgroups » railML.infrastructure » InfraAttributes and InfraAttrGroups (Can InfraAttributes and InfraAttrGroups be used by other elements than tracks?)
Re: InfraAttributes and InfraAttrGroups [message #1412 is a reply to message #1406] Fri, 02 September 2016 09:56 Go to previous messageGo to previous message
christian.rahmig is currently offline  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
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: [railML3|alpha] Remarks on example_tiny_v02.xml of v0.is3
Next Topic: [railML3|alpha] Empty <choice/> in RTM_ElementPartCollection
Goto Forum:
  


Current Time: Sun May 05 20:43:32 CEST 2024