| missing bitMask at <trainPart><operatingPeriodRef> [message #781] |
Thu, 17 May 2012 13:32  |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Dear Joachim and all others,
there is one small issue which we should fix with RailML 2.2:
A <trainPart> references its operating days with <operatingPeriodRef>.
Normally one should expect that there is a 'ref' to an operatingPeriod
only and nothing more.
However, there are some more elements there for reasons which I do not
know. They are repeated from 'operatingPeriod' and therefore tend to be
redundant.
1) There are 'startDate' and 'endDate' which allow to reduce the given
operatingPeriod. I suppose this is to reduce the number of
operatingPeriods. It is easy to understand how it works and so I think we
should keep that possibility in spite of its redundancy. But: There is
currently no 'bitMask' for such a reduced operatingPeriod. Since the
'bitMask' becomes more and more the most important attribute of operating
days we should provide it here also.
--> I herewith plead for an optional 'bitMask' attribute at
<operatingPeriodRef> with the annotation: "to be used together with
startDate and endDate".
---
2) More confusing, there is a sequence <specialService> at
<operatingPeriodRef>. It seams that one can _alter_ the referred
'operatingPeriod' using special days!
- To define an <operatingPeriod> and later alter it at
<operatingPeriodRef> is very much confusing. It would be better to define
one more <operatingPeriod> and not to alter them. The size of the file has
never been a question with RailML.
- If we allow altering of operatingPeriods, why with <specialService> and
not with <operatingDay>?
- The altered operatingPeriod would again have no bitMask.
From my opinion, we should clear that situation as soon as possible. We
have two possibilities:
a) Simple to delete the sequence <specialService> from
<operatingPeriodRef>.
b) To allow the definition of operating days without an
<operatingPeriod>. This would mean
- to copy the sequence <operatingDay> into <operatingPeriodRef>,
- to add some attributes including 'bitMask',
- to declare the attribute 'ref' as optional,
--> I would plead for (a) for reasons of simplicity and less redundancy.
Best regards,
Dirk.
|
|
|
|
| Re: missing bitMask at <trainPart><operatingPeriodRef> [message #782 is a reply to message #781] |
Mon, 21 May 2012 09:23  |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Dear all,
as a general rule, I see absolutely no point in providing alternative
means of expressing one and the same thing. It only drives up the cost
of implementing the standard.
I would therefore pledge for removing these attributes from the
trainPart element and strictly restrain the standard to use of
operatingPeriods.
Best regards, Andreas.
Am 17.05.2012 13:32, schrieb Dirk Bräuer:
> Dear Joachim and all others,
>
> there is one small issue which we should fix with RailML 2.2:
>
> A <trainPart> references its operating days with <operatingPeriodRef>.
> Normally one should expect that there is a 'ref' to an operatingPeriod
> only and nothing more.
>
> However, there are some more elements there for reasons which I do not
> know. They are repeated from 'operatingPeriod' and therefore tend to be
> redundant.
>
> 1) There are 'startDate' and 'endDate' which allow to reduce the given
> operatingPeriod. I suppose this is to reduce the number of
> operatingPeriods. It is easy to understand how it works and so I think
> we should keep that possibility in spite of its redundancy. But: There
> is currently no 'bitMask' for such a reduced operatingPeriod. Since the
> 'bitMask' becomes more and more the most important attribute of
> operating days we should provide it here also.
>
> --> I herewith plead for an optional 'bitMask' attribute at
> <operatingPeriodRef> with the annotation: "to be used together with
> startDate and endDate".
>
> ---
> 2) More confusing, there is a sequence <specialService> at
> <operatingPeriodRef>. It seams that one can _alter_ the referred
> 'operatingPeriod' using special days!
> - To define an <operatingPeriod> and later alter it at
> <operatingPeriodRef> is very much confusing. It would be better to
> define one more <operatingPeriod> and not to alter them. The size of the
> file has never been a question with RailML.
> - If we allow altering of operatingPeriods, why with <specialService>
> and not with <operatingDay>?
> - The altered operatingPeriod would again have no bitMask.
>
> From my opinion, we should clear that situation as soon as possible. We
> have two possibilities:
> a) Simple to delete the sequence <specialService> from
> <operatingPeriodRef>.
> b) To allow the definition of operating days without an
> <operatingPeriod>. This would mean
> - to copy the sequence <operatingDay> into <operatingPeriodRef>,
> - to add some attributes including 'bitMask',
> - to declare the attribute 'ref' as optional,
>
> --> I would plead for (a) for reasons of simplicity and less redundancy.
>
> Best regards,
> Dirk.
|
|
|
|
|
|
| Re: missing bitMask at <trainPart><operatingPeriodRef> [message #812 is a reply to message #804] |
Mon, 17 September 2012 16:11 |
Joachim Rubröder railML
Messages: 0
Registered: November 2019
|
|
|
|
Dear all,
if you both agree, that the use of operatingPeriods should be restricted
to references, we could implement it this way:
https://trac.assembla.com/railML/ticket/158
Kind regards...
Joachim
--
Joachim Rubröder
Schema Coordinator: railML.timetable
Dirk Bräuer wrote:
>
> Dear all,
>
>> as a general rule, I see absolutely no point in providing alternative
>> means of expressing one and the same thing. It only drives up the cost
>> of implementing the standard.
>> I would therefore pledge for removing these attributes from the
>> trainPart element and strictly restrain the standard to use of
>> operatingPeriods.
>
> It is not so easy with redundancies. Of course we should avoid them as
> much as possible. But sometimes we can hardly avoid them without risking
> that RailML will not be accepted in practice.
>
> In this special case I agree with Andreas; from our side no objection
> against fully deleting (declaring deprecated) everything but the
> <operatingPeriodRef>.ref.
>
> Dirk.
>
>
--
----== posted via PHP Headliner ==----
|
|
|
|
|
|
|
|
|
|
Members
Search
Help
Login
Home
