| Re: problems with <train>s: uniqueness constraints, scope [message #938 is a reply to message #932] |
Wed, 13 March 2013 09:23   |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Dirk,
Am 12.03.2013 18:12, schrieb Dirk Bräuer:
> Dear Andreas,
>
> Am 02.01.2013, 11:27 Uhr, schrieb Andreas Tanner <ata(at)ivude>:
>
>> 1. If I read the standard correctly, trainPartRefs within a trainPart
>> sequence model coupled trains. The wiki formulation
>>
>> " Therefore all referenced elements trainPart of a trainPartSequence
>> should have the same starting point and end point"
>>
>> hints to that but is not really strict enough. The formulation should
>> be changed to
>> "The <ocpsTT> of all <trainPart>s within a <trainPartSequence> should
>> contain the same sequence of <ocp>s with the same arrival and
>> departure times."
>
> It would be more restricting than today but it would also be easier for
> parsing the files. So I would agree if the others do.
>
Great.
>> 2. What variation of the trainPartSequences is allowed within one
>> train? The case
>>
>> train x runs daily from A to B, and mon-fr a trainPart is added with
>> position 2, and a trainPartSequence from B to C
>>
>> is apparently intended to be legal, while
>>
>> train y runs daily from A to B, and mo, tue, wed it continues to C but
>> thu, fr, sat to D
>>
>> is not.
>
> Your example is not clear enough to answer this. If C and D are at the
> same route, it may be allowed. If it is a Y-like arrangement it is not.
Agreed. That consensus should find its way into the wiki.
>
>> If this is so, I suggest adding the following -hopefully clarifying-
>> text to the documentation:
>>
>> "For any <train>, there is a sequence of ocpTT without locational or
>> temporal breaks, such that
>> - for any <trainPartSequence>, there is a section of that sequence
>> such that the ocpTTs of all referred trainParts of that
>> trainPartSequence correspond with that section
>> - the sections of subsequent trainPartSequences are subsequent to each
>> other
>> - for any operatingPeriod, the trainPartSequences spanned by the
>> trainParts effective on that operatingPerid has no gaps."
>
> I would not agree with the last item. I think I can imagine what you
> mean but also I think that writing of “gaps” in conjunction with
> operatingPeriods is not clarifying.
>
> In general, it was not common in RailML the past to make such far-going
> restrictions. Rather, the philosophy of RailML was to more allow than
> restrict. I understand the practical advantage of such clarifications
> but since we do not have them in RailML at other themes, I think it is
> better to stay consequently.
>
> Please consider that RailML should not be bound to the German philosophy
> of trains and train number usage. So I am afraid this would be left to
> bilateral agreements superset on RailML.
Hmh. Actually, a lot of our railMl actitivties is triggered from South
of the Alps. But be it as it is, let's leave out that constraint if you
have a use case that interferes.
>
> Andreas, please remember your own suggestions concerning a more wider
> definition of timetable periods in another discussion “thread”. There
> you see your own interest in not making things more restrictive.
Well, the difficult issue is to find the /right/ constraints...
>
>> If a designated "primary" path is needed, the constraint should at
>> least be relaxed to allow multiple trains with scope secondaryXXX.
>
> This is already the case with additionalTrainNumber.
Ok, it seems that I have to backtrack here. We were tempted to use the
additionalTrainNumber for some customer-specific train attribute. Maybe
the wiki should provide guidance that this is a bad idea.
--Andreas.
|
|
|
|
Members
Search
Help
Login
Home
