Home » railML newsgroups » railML.infrastructure » <crossSection>.ocpTrackID
<crossSection>.ocpTrackID [message #308] Wed, 23 May 2012 11:14 Go to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Christian,

the attribute <crossSection>.ocpTrackID is defined as "xs:unsignedByte".
This is impracticable and probably unintended. We should either define it
as something like tGenericRef (and probably rename it into "ocpTrackRef")
or define it as a simple xs:string for common use.

Please close this issue providing a track ticket. Thank you!

Best regards,
Dirk.
Re: <crossSection>.ocpTrackID [message #312 is a reply to message #308] Sat, 23 June 2012 07:52 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Hello Dirk and anyone interested,

> the attribute <crossSection>.ocpTrackID is defined as "xs:unsignedByte".
> This is impracticable and probably unintended. We should either define
> it as something like tGenericRef (and probably rename it into
> "ocpTrackRef") or define it as a simple xs:string for common use.

Thank you for your comment. With the ticket [1] I renamed the attribute
<crossSection>.ocpTrackID into ocpTrackRef and assigned it to type
tGenericRef.

[1] https://trac.assembla.com/railML/ticket/151

Regards

--
Christian Rahmig
railML.infrastructure coordinator
Re: <crossSection>.ocpTrackID [message #439 is a reply to message #312] Mon, 12 November 2012 12:37 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>> the attribute <crossSection>.ocpTrackID is defined as "xs:unsignedByte".
>> This is impracticable and probably unintended. We should either define
>> it as something like tGenericRef (and probably rename it into
>> "ocpTrackRef") or define it as a simple xs:string for common use.
>
> Thank you for your comment. With the ticket [1] I renamed the
> attribute <crossSection>.ocpTrackID into ocpTrackRef and assigned it
> to type tGenericRef.
>
> [1] https://trac.assembla.com/railML/ticket/151

I'm sorry but I don't understand the semantics of the attribute
'ocpTrackRef' within the element 'crossSection'.

A 'crossSection' is already positioned at a certain track and may refer
to its appropriate ocp with the attribute 'ocpRef'.

The old "ocpTrackID" typed as 'unsignedByte' looks a bit like an
intended platform number. That may be now defined with the newly
introduced 'platformEdge' element.

But where should the "ocpTrackRef" refer to? What have I missed?

Any comments appreciated.

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: <crossSection>.ocpTrackID [message #440 is a reply to message #439] Mon, 12 November 2012 12:57 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Susanne,

> But where should the "ocpTrackRef" refer to?

I also did ask myself that question.

We could probably rename it "platformEdgeRef" which would be of some
practical relevance. But in rare cases there could be two platform edges
at one cross-section. (The relation from a cross-section to its platforms
is also given by both relating to the same <ocp> and laying at the same
track. So if this is not too much around the corner, we could also declare
ocpTrackRef as obsolete.)

Dirk.
Re: <crossSection>.ocpTrackID [message #445 is a reply to message #440] Mon, 12 November 2012 13:54 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:

>> But where should the "ocpTrackRef" refer to?
>
> I also did ask myself that question.
>
> We could probably rename it "platformEdgeRef" which would be of some
> practical relevance. But in rare cases there could be two platform
> edges at one cross-section. (The relation from a cross-section to its
> platforms is also given by both relating to the same <ocp> and laying
> at the same track. So if this is not too much around the corner, we
> could also declare ocpTrackRef as obsolete.)

I reopened the Trac ticket in order to clarify this issue with railML
2.2:

http://trac.assembla.com/railML/ticket/151#comment:3

I would assume that the current implementation already fulfills all
needed requirements.

A 'crossSection' has a position on a certain track. The 'platformEdge's
each have positions and lengths on the same track. That means one could
find out the appropriate 'crossSection' for a certain 'platformEdge' by
traversing along the 'track.

But anyway, why to refer from 'crossSection' to a 'platformEdge'? The
platformEdge already itself refers to an 'ocp' with the attribute
'ocpRef'. The 'track' itself may be "part of an ocp" with the element
propEquipment/trackRef.

If 'ocpTrackID' was used for a "platform number" I would declare it
deprecated.

Any comments appreciated.

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: <crossSection>.ocpTrackID [message #446 is a reply to message #445] Mon, 12 November 2012 14:40 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
> But anyway, why to refer from 'crossSection' to a 'platformEdge'? The
> platformEdge already itself refers to an 'ocp' with the attribute
> 'ocpRef'.

Dear Susanne, you are stealing my commits:

> (The relation from a cross-section to its
> platforms is also given by both relating to the same <ocp> and laying
> at the same track. So if this is not too much around the corner, we
> could also declare ocpTrackRef as obsolete.)

Dirk.
Re: <crossSection>.ocpTrackID [message #448 is a reply to message #446] Mon, 12 November 2012 15:17 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Dear Dirk,

Dirk Bräuer <dirkbraeuer(at)irfpde> writes:

>> But anyway, why to refer from 'crossSection' to a 'platformEdge'? The
>> platformEdge already itself refers to an 'ocp' with the attribute
>> 'ocpRef'.
>
> Dear Susanne, you are stealing my commits:
>
>> (The relation from a cross-section to its
>> platforms is also given by both relating to the same <ocp> and laying
>> at the same track. So if this is not too much around the corner, we
>> could also declare ocpTrackRef as obsolete.)

Shame on me!

To much done at the same time.

;-)

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: <crossSection>.ocpTrackID [message #465 is a reply to message #445] Sat, 24 November 2012 14:02 Go to previous message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Dirk, Susanne and other railML users,

>>> But where should the "ocpTrackRef" refer to?
>>
>> I also did ask myself that question.
>>
>> We could probably rename it "platformEdgeRef" which would be of some
>> practical relevance. But in rare cases there could be two platform
>> edges at one cross-section. (The relation from a cross-section to its
>> platforms is also given by both relating to the same <ocp> and laying
>> at the same track. So if this is not too much around the corner, we
>> could also declare ocpTrackRef as obsolete.)
>
> I reopened the Trac ticket in order to clarify this issue with railML
> 2.2:
>
> http://trac.assembla.com/railML/ticket/151#comment:3
>
> I would assume that the current implementation already fulfills all
> needed requirements.

after revision I reverted the renaming and marked the parameter
"ocpTrackID" of type "xs:unsignedByte" as deprecated.

Regards

--
Christian Rahmig
railML.infrastructure coordinator
Previous Topic: Something about platforms, platformEdges, serviceSections and their relation to a track
Next Topic: small issues on "register" and "tLineInfrastructureManagerCode"
Goto Forum:
  


Current Time: Fri Mar 29 05:46:33 CET 2024