| Sequence of ocpTT elements [message #799] |
Wed, 30 May 2012 17:31  |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi all,
The Wiki page about the <ocpTT> element states (Constraints) [1]:
"The sequence of the ocpTT elements inside a trainPart has to be
according to the train path."
A general rule for XML design is _not_ to evaluate the order of elements
unless it is of importance, e.g. mixed content issues in document
specific markup.
In this case the logical sequence of the <ocpTT> elements is defined by
its arrival and departure times (including days). There is no need to
require this order with the XML syntax.
We introduced an additional attribute for ordering if it was needed.
It's the same issue with all <trackElements> in the Infrastructure
sub-schema that don't have to be ordered neither by the relative
nor by the absolute mileage.
An export interface possibly orders its ocpTT elements chronologically.
But an import interface should be aware of the possible chronological
mix of ocpTT elements.
I would change the Wiki page after some possible discussion.
[1] http://wiki.railml.org/index.php?title=TT:ocpTT
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
| Re: Sequence of ocpTT elements [message #801 is a reply to message #799] |
Thu, 31 May 2012 10:36  |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Hi Susanne,
couldn't there be the case that the times in two ocptts are identical,
in particular, if times are minute-based?
I have to say that non-ordered ocptts would currently break our import.
The wiki is not versioned, but if preconditions are altered it may pose
problems. In this case, one would have to add versioning to the
documentation and changes could be only to non-released versions.
Best,
--Andreas.
Am 30.05.2012 17:31, schrieb Susanne Wunsch:
> Hi all,
>
> The Wiki page about the<ocpTT> element states (Constraints) [1]:
>
> "The sequence of the ocpTT elements inside a trainPart has to be
> according to the train path."
>
> A general rule for XML design is _not_ to evaluate the order of elements
> unless it is of importance, e.g. mixed content issues in document
> specific markup.
>
> In this case the logical sequence of the<ocpTT> elements is defined by
> its arrival and departure times (including days). There is no need to
> require this order with the XML syntax.
>
> We introduced an additional attribute for ordering if it was needed.
>
> It's the same issue with all<trackElements> in the Infrastructure
> sub-schema that don't have to be ordered neither by the relative
> nor by the absolute mileage.
>
> An export interface possibly orders its ocpTT elements chronologically.
> But an import interface should be aware of the possible chronological
> mix of ocpTT elements.
>
> I would change the Wiki page after some possible discussion.
>
> [1] http://wiki.railml.org/index.php?title=TT:ocpTT
>
> Kind regards...
> Susanne
>
|
|
|
|
| Re: Sequence of ocpTT elements [message #802 is a reply to message #801] |
Thu, 31 May 2012 10:52 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Hi Andreas,
Andreas Tanner <ata(at)ivude> writes:
> couldn't there be the case that the times in two ocptts are identical,
> in particular, if times are minute-based?
I think, in that case we should introduce an attribute for ordering. The
geographical/linear reference may not help out in cases where the ocp is
only defined with an "id" and a "name".
> I have to say that non-ordered ocptts would currently break our
> import. The wiki is not versioned, but if preconditions are altered it
> may pose problems. In this case, one would have to add versioning to
> the documentation and changes could be only to non-released versions.
That's the reason why I opened a thread for this issue. Thanks for your
quick response.
We could also change the currently documented behaviour with a next
release not changing such sensitive portions of wiki documentation
inbetween schema releases.
Other/same opinions?
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
|
|
| 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.
|
|
|
|
| Re: Sequence of ocpTT elements [message #807 is a reply to message #805] |
Mon, 04 June 2012 17:58 |
Joachim Rubröder railML
Messages: 0
Registered: November 2019
|
|
|
|
Hello everybody,
> 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.
In order to avoid breaking changes, what do you think about introducing an
optional attribute "sequence" for the ocpTT in version 2.2 and declare
that it will become required for 3.0?
Kind regards,
Joachim
--
----== posted via PHP Headliner ==----
|
|
|
|
|
|
|
|
|
|
|
|
Members
Search
Help
Login
Home
