| Re: TrainpartRefs [message #749 is a reply to message #748] |
Thu, 08 September 2011 17:04   |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
I suggest that if two trainpartrefs refer to the same trainpart, it is
to be understood that they point to the same physical entity. So if you
have two views on the set of trains within one file (as commercial and
as operational trains), then they can "share" trainparts. But multiple
use in the sense of "another copy of that trainpart" is not allowed, in
particular not as different positions within one trainpart sequence.
About separation of ocpTT sequences: this resembles to what we do in
IVU.plan anyway, but we go even further by defining "route pattern" that
can be anchored per trip to a start / arrival / intermediate time.
--Andreas.
Am 07.09.2011 15:55, schrieb Susanne Wunsch:
> Hello,
>
> christophjobmann(at)deutschebahncom (Christoph Jobmann) writes:
>> from my point of view trainPart elements can no longer be used more than
>> once within the same trainPartSequence if rostering is included. In this
>> case you will need several almost identitical trainParts - the only
>> difference will be the id-attribute.
>
> I go with your statement. You can't deploy reservation info when using
> the same train part several times in a commercial train. All the other
> 'formationTT' elements could also differ for train parts running in the
> same train through the same 'ocpTT's.
>
>> Furthermore I don't like the thought of multiply referring to the same
>> trainPart when working with commercial and operational trains since you
>> will not be able to distinguish which references to trainParts in the
>> operational train are included in which commercial train.
>
> That's a really good point. Thanks for mentioning.
>
>> I do realize that this leads to many identical trainPart-Elements; yet I
>> find it neccessary to transmit the needed information without extending
>> the standard.
>
> railML should stay as redundancy-free as possible in the context of the
> current model.
>
> If it would be appreciated, we could separate the "ocpsTT" element for
> referencing it from each train part. But I think that there are some
> cases where some deep attributes of ocpTT differ between the coupled
> train parts. Yes, it's a very seldom use case that should be covered,
> too.
>
> railML 2.1 is even just released, so I'm not very happy in changing
> some core syntax. On the other hand, if that change would bring even
> more users to railML, it would be worth.
>
> Let's go on with this topic in this thread. Maybe it's good for the
> next major release.
>
> Any ideas, comments, questions appreciated...
> Susanne
>
|
|
|
|
Members
Search
Help
Login
Home
