| Re: Sequence of ocpTT elements [message #805 is a reply to message #803] |
Fri, 01 June 2012 10:51   |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
If the standard is relaxed in this point, any software has the problem
of solving sorting ambiguities. The case of identical times is not
purely academic but does occure in practice. So why, without need,
introduce ambiguities?
If a condition of the order of child elements is bad XML style, I would
follow Susannes suggestion for an ordering index, and introduce the
precondition (by documentation) that the times must be weakly ascending
by the index.
The index would have to be mandatory, and that's why I would not
implement it as a metering index because possibly one would have to
write fictuous data if the metering is unknown. Moreover, in theory
(maybe someone uses railML for model trains?) there could be two ocptts
with same meter...
It seems as if this was a breaking change, so I would prefer leaving it
for 3.0.
--Andreas.
Am 31.05.2012 13:43, schrieb Dirk Bräuer:
> Dear Susanne and Andreas,
>
>> Other/same opinions?
>
> From my side, it is up to the reading software
> - either to sort the times chronologically
> - or to declare that OCPTTs have to be ordered on input (additionally to
> RailML).
>
> I do not see a big problem in the additional declaration. I think that
> there always will be additional demands on the softwares dealing with
> RailML.
>
> Actually, we currently have arrival/departure times which come sometimes
> in a non-sorted order (from an Austrian Infrastructure Company) for
> reasons which I do not know. We sort them on input and refuse the input
> if there are two with the same time. It is up to the data source to
> secure data integrity.
>
> From our side, a kind of "ordering index" as an additional attribute
> does not change the situation very much: Either we sort by
> arrival/departure times and refuse if there are two OCPTTs with the same
> times or we sort by index and refuse if there are two OCPTTs with the
> same index...
>
> If you consider introducing a new "ordering attribute", may be a
> "running length" (meters calculated from the beginning of train's route)
> would be solution which also allows a unique order but includes the
> additional value of the distances which many reading programmes want to
> have and which otherwise can only be calculated more difficulty.
>
> Best regards,
> Dirk.
|
|
|
|
Members
Search
Help
Login
Home
