Forum: railml.timetable » [railML2] Proposed semantic constraint for <specialService>

Home » railML newsgroups » railml.timetable » [railML2] Proposed semantic constraint for <specialService>

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

[railML2] Proposed semantic constraint for <specialService> [message #3394]

Tue, 19 November 2024 13:59

Milan Wölke
Messages: 206
Registered: April 2007

Senior Member

Hello community,

as some of you may know we at railML are currently developing a new version of railVIVID, the tool available for inspecting and validating railML files. While doing so we came across an issue with the element //operatingPeriod/specialService. Our developers propose to introduce a semantic constraint for this, that makes sure that any date given for specialService/singleDate must not be outside the timeframe indicated by the enclosing operatingPeriod and by extension of the associated timetablePeriod. Additionally, it should be made sure that no value specified for the attribute singleDate shall be overlapped by other <specialService> elements of the same enclosing <operatingPeriod>.

The proposed wording would be like this:

The value of @singleDate of <specialService> must not overlap with other <specialService> validity periods of the same enclosing <operatingPeriod> and must not be outside of time period defined in enclosing <operatingPeriod> and by extension the associated timetable period.

What is your opinion on this? Shall we add this or do you think this will introduce problems with existing usages? Would it be helpful for new implementors? Do you have suggestions for a better and clearer wording?

Best regards, Milan

Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML2] Proposed semantic constraint for <specialService> [message #3401 is a reply to message #3394]

Tue, 26 November 2024 14:13

Christian Rößiger
Messages: 80
Registered: March 2015

Member

Hello Milan,

I think that's a good idea and I see little potential for affecting existing implementations. However, I would take look at the existing semantic constraint TT:018 on the same page: This one already defines that specialServices must not overlap, but probably more in regard to time periods (attributes 'startDate' and 'endDate'). I would therefore define in one semantic constraint that specialServices must not overlap (neither single days nor time periods) and in a second one that all specialService definitions must be within the validity of the enclosing operationPeriod.

Best regards,
Christian

Report message to a moderator

Re: [railML2] Proposed semantic constraint for <specialService> [message #3408 is a reply to message #3401]

Wed, 11 December 2024 12:09

Milan Wölke
Messages: 206
Registered: April 2007

Senior Member

Hi Christian,

thanks for your reply. That makes sense. So we change TT:018 to:

Quote:

Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other <specialService> validity periods or single dates of the same enclosing <operatingPeriod>.

and adapt the new semantic constrain to be like this:

Quote:

The values of @singleDate, @startDate and @endDate of <specialService> must not be outside of time period defined in enclosing <operatingPeriod>.

Do you agree?

Best regards, Milan

Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML2] Proposed semantic constraint for <specialService> [message #3414 is a reply to message #3408]

Thu, 19 December 2024 09:50

Christian Rößiger
Messages: 80
Registered: March 2015

Member

Hello Milan,

Am 11.12.2024 um 12:09 schrieb Milan Wölke:
> Quote:
>> Any starting time stamp (as it may result e.g. from a
>> combination of startDate and startTime) shall be lower or
>> equal any ending time stamp (e.g. endDate) if both are
>> given. Must not overlap with other <specialService>
>> validity periods or single dates of the same enclosing
>> <operatingPeriod>.
>
> and adapt the new semantic constrain to be like this:
>
> Quote:
>> The values of @singleDate, @startDate and @endDate of
>> <specialService> must not be outside of time period
>> defined in enclosing <operatingPeriod>.
>
> Do you agree?

That's fine with me.

Best regards,
Christian

--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347

Report message to a moderator

Re: [railML2] Proposed semantic constraint for <specialService> [message #3416 is a reply to message #3414]

Thu, 19 December 2024 15:06

David Lichti
Messages: 53
Registered: December 2020

Member

I agree with the second constraint proposal. (Suggest to add an article, though.)
Quote:

The values of @singleDate, @startDate and @endDate of <specialService> must not be outside of time period defined in the enclosing <operatingPeriod>.

This constraint is about the consistency of <specialService> elements with their parent <operatingPeriod> element.

The first one, strictly speaking, only excludes overlaps of date periods (start/end date) with other date periods or single dates.
Quote:

Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other <specialService> validity periods or single dates of the same enclosing <operatingPeriod>.

It does not exclude overlaps of two single dates.

Suggest to define two separate constraints. One for the internal consistency (adding the endTime for symmetry):
Quote:

Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate and endTime) if both are given.

A second one for the relation between the individual <specialService> elements:
Quote:

The validity periods and single dates of two <specialService> elements must not overlap.

Report message to a moderator

Re: [railML2] Proposed semantic constraint for <specialService> [message #3464 is a reply to message #3394]

Thu, 13 February 2025 09:15

Christian Rößiger
Messages: 80
Registered: March 2015

Member

Quote:

The first one, strictly speaking, only excludes overlaps of date periods (start/end date) with other date periods or single dates.
Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given. Must not overlap with other <specialService> validity periods or single dates of the same enclosing <operatingPeriod>.
It does not exclude overlaps of two single dates.
Suggest to define two separate constraints.

Yes, I agree that we could be more specific here. But since in both cases (single days and periods) the parent 'problem' is the same, I wouldn't necessarily be in favour of splitting the SemCon into 2. Perhaps the following formulation would be a compromise:

Within the same operatingPeriod element, a date must not be contained in more than one specialService element. A date is considered to be contained in a specialService element if
- it is stated directly in a singleDate attribute or
- it is within the time span between startDate and endDate (inclusive in both cases)

Best regards
Christian Rößiger

Report message to a moderator

Re: [railML2] Proposed semantic constraint for <specialService> [message #3467 is a reply to message #3464]

Thu, 13 February 2025 16:46

Thomas Nygreen
Messages: 103
Registered: March 2008

Senior Member

Dear all,

I think Christian's proposal is elegant. The constraint that these dates must be within the date range of the operatingPeriod, could maybe also be included in the same constraint.

The constraint that startDate is less than or equal to endDate applies to a lot of elements, and we could maybe strip down the original TT:001 to just that (but maybe as a CO:* constraint), and apply that constraint to all relevant elements, simplifying the remaining element specific constraints.

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML2] Proposed semantic constraint for <specialService> [message #3468 is a reply to message #3464]

Thu, 13 February 2025 17:45

Milan Wölke
Messages: 206
Registered: April 2007

Senior Member

In todays timetable developer meeting we decided to go ahead with Davids proposal. We decided against the approach of Christian reasoning that a semantic constraint should be short and precise. The actual semantics of an attribute should be explained in the semantics part of the wiki pages.
Therefore we will update the exiting semcon TT:018 with the following wording:

Quote:

Any starting time stamp (as it may result e.g. from a combination of startDate and startTime) shall be lower or equal any ending time stamp (e.g. endDate) if both are given.

and introduce two new semantic constraints as follows:

TT:021:
Quote:

Within the same <operatingPeriod> element, a date must not be contained in more than one <specialService> element.

TT:022
Quote:

The values of @singleDate, @startDate and @endDate of <specialService> must not be outside of the time period defined in the enclosing <operatingPeriod>.

Best regards, Milan

Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Previous Topic:	[railML2] Wording of semantic constraints TT:015 and TT:016
Next Topic:	[railML 2] New semantic constraint for <operatingPeriod>

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sat Nov 15 18:41:49 CET 2025