| Re: Wiki documentation for border <ocpTT> between two chained <trainPart> [message #1289 is a reply to message #1288] |
Fri, 24 July 2015 12:54   |
Philip Wobst
Messages: 47
Registered: November 2013
Location: Hanover, Germany
|
Member |
|
|
Hello Christian,
did you have a use case where the data for the two ocpTTs was not the
same although it should have been the same?
Maybe there are some use cases where the data would not be the same and
I can think of one customer scenario where this might be the case (not
using railML yet - unfortunately).
If we create the MUST criteria for the exporting system to define which
ocpTT attributes must be identical at a border ocpTT then we also define
must have rules for the importing system and all other railML tools.
On the Wiki page for the ocpTT an example for such a scenario exists and
possibly a description of the 'border ocpTT' and the clarification of
the term makes sense. Together with this we could outline that the
attributes a, b, c do not change at a border ocpTT in all known 'normal'
train operation scenarios. Furthermore, no importing system is expected
to handle/interpret changes if different attributes a, b, c were provided.
Best regards,
Philip Wobst
--
Philip Wobst
Consultant
Planning and Dispatching Systems
HaCon Ingenieurgesellschaft mbH
Lister Str. 15
30163 Hannover
Germany/Deutschland
Tel. +49 511 33699-498
Fax. +49 511 33699-99
mailto: philipwobst(at)haconde
http://www.hacon.de
Registry Court/Amtsgericht: Hannover HRB 1712
Managing Directors/Geschäftsführer:
Michael Frankenberg, Werner Sommerfeld, Peter Talke
|
|
|
|
Members
Search
Help
Login
Home
