Home » railML newsgroups » railml.timetable » problems with <train>s: uniqueness constraints, scope
Re: problems with <train>s: uniqueness constraints, scope [message #939 is a reply to message #938] Wed, 13 March 2013 12:54 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Andreas,

>>> 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.

We already have:

http://www.wiki.railml.org/index.php?title=TT:trainCouplingA ndSharing

especially:

http://www.wiki.railml.org/index.php?title=TT:trainCouplingA ndSharing#Why_not_to_use_the_.27scope.27_attribute.3F

and:

http://www.wiki.railml.org/index.php?title=TT:train#Example

(external links - sorry, I am not able to create wider text formations in
Wiki).

I will extend the examples especially on "additionalTrainNumber" in
future. The decision to use "additionalTrainNumber" for "Nummer des
Ergänzungsfahrplans" is newer than some of the examples (see News-Posts on
this from last year).

Best regards,
Dirk.

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: infrastructure train path: where to put path parameters
Next Topic: Fahrgastzahlen in railML
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed May 15 18:22:52 CEST 2024