Talk:TmIntervalsByDoW

jens 06:27, 16 August 2010 (UTC)
It looks like it was a rainy weekend in Somerset. :)

I see my proposal of a big complex attribute somehow rejected. If the uncertain construction with DYWKRN is the reason I would like to ask Raphael if a construction is possible saying DYWKRN requires the input of two values saying the first value is the start and the last value is the end of a range.
That avoids a bit of code. What do you think?

DavidAcland 09:52, 16 August 2010 (UTC)

Yes; and a BBQ was planned. The cooks grilled under umbrellas. Sadly no photo.

Row	Sub-attribute	Camel Code Identifier	Multiplicity	Sequential
1	DYOFWK	dayOfWeek	0..1	n/a
2	DYWRST	dayOfWeekRangeStart	0..1	n/a
3	DYWRND	dayOfWeekRangeEnd	0..1	n/a
4	TIMREF	timeReference	1	*
5	TIMSTW	timeOfStartOfWork	1..*	True
6	TIMENW	timeOfEndOfWork	1..*	True

I have amended the multiplicity at rows 5 & 6 above to reflect the current design for WKHRDY and allow for multiple work periods in a day.

The risk seemed to me with rows 1,2 & 3. If they are all optional and will all carry days of the week as enumerations like DYOFWK, how could a production system do any validation checks? And it also seems odd to have three simple attributes with the same lists or am I missing something?

Our earlier construction just looked more rigorous and I think I can accept the added complexity to achieve that.

However I am unsure how we cover a work schedule which has 5 standard days but with two different work patterns for the 6th and 7th days; or indeed for a schedule where there are 4 standard days and different patterns on the 5th, 6th and 7th. And then again, we might have (starting on Monday): Day, Day, 1/2 Day, Day, Day, 1/2 day, very short day.

I suppose with either construction we have to have multiple WKSHEDs:

1) Range 1: First "Day, Day"

2) First "1/2 day"

3) Range 2: Second "Day, Day"

4) Second "1/2 Day"

5) "Very short day"

I have also tried to think of a lifting bridge or lock gate, which provides interrupted service to navigation during the morning, lunch and evening land traffic rush hours. At all other periods the land traffic can be stopped to allow vessels to pass. This means that there is more, possibly continuous, service at weekends.

jens 11:41, 16 August 2010 (UTC) Let me start with the last problem. It is not more than to suck off the information source. We will leave the path of fuzzing information by verbal description. A lot of work comes.
The first item is much harder and I must say, "Well argued". It is hard to reply. I know that Raphael and John introduced the range idea and this is probably a good tool for the data encoder. However, behind that is the methodology to split up the range to single days. And now I am asking: "For what do we need that range?" Is it against the rule to use a working schedule for each day with optional information repetition?; means can we delete the range stuff.
The multiplicity of DYOFWK makes sense as it is stated above because it is an enumeration. If we construct now that e.g. one service has two working days, Mo and Die, we have to multiply WKSHED in any case. I believe the advantage a range offers is minor.
Martin's advice: What we are discussing here is the data model. That can be different from the mariner/encoder-machine interface. And I think he is right.

DavidAcland 12:45, 16 August 2010 (UTC)

Ok. However our short term objective is a workable Product Specification and the reason behind that is to expose this sort of discussion. What we are doing with complex attributes is doing a bit of pre-composition.

I wonder if we can provide the simple attributes for both. Although we are showing representative bindings, producers of data sets are free to use others. What we have done in the last few days is to start working up two alternative bindings.

I have to agree that the advantage of a range design shows best when we have a simple repeated work pattern.

jens 12:52, 16 August 2010 (UTC) David, What means both in "I wonder if we can provide the simple attributes for both."?

DavidAcland 13:05, 16 August 2010 (UTC)

I mean the design above here and on the WKSHED page.

DavidAcland 14:36, 16 August 2010 (UTC)

Jens and I spoke. Agreed to leave the example as on the WKSHED page for the moment. Several reasons:

1) We wanted to hear Raphael's views

2) Eivind has already started work on the MPA application schema

3) A simpler design is also possible using a slightly different binding of attributes with their current definitions

raphael 03:25, 17 August 2010 (UTC): Whatever we do, it will be necessary to define a constraint which software checks when the dataset is created or validated. We already say "Duplicates or overlaps are not permitted." This effectively amounts to the validation rule:
Rule 1: Different instances of WKSHED bound to the same SRVHRS must apply to different days of the week.

If you like we can explicitly state another constraint for ranges:
Constraint: If one end of a "day range" is given, the other must be given too.

This would be quite easy to code in editing or dataset validation software.

raphael 06:26, 17 August 2010 (UTC): I can't see any logical error in either the table above or what is on the WKSHED page. I too think we will need multiple WKSHEDs. (And as I wrote above, I think a "constraint" will be needed whatever we do.)

(DYWKRN was introduced to avoid repeating information about start and end time in multiple places, which multiplies human effort invites human error if work time changes. I don't remember who initially objected to the one-day-per-attribute approach - Jens, John, or me. The discussion dates to SNPWG9. I understand what Martin says about distinguishing between the model and the human/software interface, but what's likely to happen is that the user interface designers will take the easy way out. On the other hand, doing it does simplify the model and it is not logically wrong or incomplete, so if both of you think that way best, fine.)

Concerning services that give different priority at different times of day: This could be done by adding another text sub-attribute to describe the "service level" at each time period. It might be better to place this information elsewhere, though, because it is another piece of data encoders have to enter and check.

raphael 19:10, 12 August 2011 (UTC): This remark may be useful to writers of product specifications: Product specifications may need to allow WKSHED to be repeated in order to allow encoding of schedules which vary for different days of the week.

(This is a consequence of limiting the multiplicity of WKHRDY to 0..1.)

raphael 16 Sep 2011: Do you remember whether a convention was defined for representing 24/7 working hours?

Is “24/7” implied by the absence of the WKSHED attribute of SRVHRS, or must we use WKSHED and explicitly encode the 24/7 working hours?

jens 19 Sep 2011: I tried to recall the discussions about that problem.

I think we should explicitly encode each day.

Leaving information empty means "no information available" unless it is mandatory. In the latter case we can provide "not specified" to fulfil the requests of providing an attribute value.

DavidAcland 23 Sep 2011: Sorry for the delay in replying. I agree that we should be explicit.

However I can envisage that encoding software could provide short cuts or a working time wizard that completed all the attributes for common conventions such as 24/7, Monday to Friday, Sunday to Thursday and office hours of 9 - 5 or 8 - 4.

There also seems to be the possibility that the standard pattern is 24/7 but that in some cases services and facilities are closed for a few national holidays; such as perhaps Easter and Christmas Days. This would imply to me that there should be the possibilty to stipulate a rule, perhaps in the product specification, that the Non-standard working day NWKDAY overides WKSHED, and could offer another, perhaps reduced WKSHED.

raphael 23 Sep 2011: The modeling solutions you mention are all fine, they all work. I suggest we pick one and record all such conventions and stipulations on the Wiki as they are discussed, so we don't lose track.

In addition it will give writers of product specifications some conventions to constrain them. Different product specifications can of course make different rules, but I think writers of product specifications would prefer to have some guidance or conventions so they do not reinvent the wheel. Uniform conventions are important to mitigate the problem of information exchange between different future products.

DavidAcland 10:25, 28 September 2011 (UTC) Ok. Here is an attempt to summarise conventions suggested to date, and few more suggestions:

WKSHED has to be explicit. 24/7 would be defined as working every day (1-7). WKHRDY has to show start of working day is 0000 and end of working day is 2400.

If DYWKRN is used the following constraint applies:
Constraint: If one end of a "day range" is given, the other must also be given.

WKSHED can be repeated if not all working days are the same.

NWKDAY overrides WKSHED.

On a NWKDAY, WKSHED is optional. If a limited service is provided on a non-standard working day, that is described in a separate WKSHED. If service is not available WKSHED is not populated.

Problem: How do we bind this non standard WKSHED to the NWKDAY?

jens 07:37, 30 September 2011 (UTC) I think we can not make an exemption of an exemption. A non working day is a non working day. We should try to find a solution if the working schedule for particular days is different from the "normal" working day schedule.

raphael 01:58, 4 October 2011 (UTC):
I don't quite see the problem. Couldn't we also bind complex attribute WKSHED to the information object NWKDAY?

We can make the multiplicity of WKSHED 0..* in NWKDAY, 0 meaning that WKSHED is absent and the day is a full holiday.

The data capture guide can say something like:
The service hours for a normal work week are defined using SRVHRS[WKSHED] (*). Reduced or no service during particular holidays (i.e., other than the regular weekend) is described using NWKDAY[VARDAT, FIXDAT, WKSHED], with the absence of WKSHED in an NWKDAY object indicating no service on the dates specified by VARDAT or FIXDAT.

(*) AAAAAA[BBBBBB] means attribute BBBBBB when bound to object AAAAAA.

Jens, given that NWKDAY is defined as a non-standard working day, does this address the point you raised or would you prefer to define a new object?

jens 07:22, 7 October 2011 (UTC)Raphael, You are correct with the model and I fully agree. I take the term "Non-Working Day" literally; no work means no work during a non working day.
That brings me to another question: Working on every third Sunday (officially non-working day), working on holiday on request, etc. or other constructions like that. I think that is the point where we have to employ TXTDSC or INFORM in our model.

DavidAcland 12:59, 7 October 2011 (UTC) I think we are OK for the general case of limited working on a national holiday. The definition and indeed the name of NWKDAY is "Non-standard working day". I think we were cleverer when we were younger because this seems to cover the situation we are now discussing. I have corrected the name on the SNPWG FCD page, which has been misleading us, to agree with the name on the NWKDAY page. Would it help perhaps if we changed the acronym to NSWKDY? Not too difficult and now would be better than later.

I agree we need to be able to revert to TXTDSC or INFORM for the undefinable and irregular departures from the rule.

raphael 04:02, 10 October 2011 (UTC): Agreed on using TXTDSC/INFORM. VARDAT should do for specifications like "third Sunday of the month". "Service available On request" or "Service By special arrangement" would go in TXTDSC or INFORM.

I think NSWKDY is better than NWKDAY, but have no strong feelings about it.

Earlier we discussed binding WKSHED to NWKDAY, but since each NWKDAY describes a specific day, WKHRDY would be better than WKSHED (and we don't have to decide what to put in the other sub-attributes of WKSHED).

jens 12:22, 11 October 2011 (UTC) I agree with NSWKDY too. So David, pls change it!
Raphael, thanks for pointing us to the proper use of VARDAT. I agree. If we don't limit the VARDAT use to NWKDAY we are much more flexible with modelling particular days differ from the normal procedure.

DavidAcland 14:55, 12 October 2011 (UTC) Acronym NWKDAY changed to NSWKDY.

raphael (talk) 01:08, 6 February 2017 (CET): Proposed definition: Time intervals by days of the week.
Remarks:

• The sub-attribute dayOfWeekIsRange indicates whether an instance of this complex attribute encodes a range of days or discrete days. The days or day-range(s) are encoded in sub-attribute dayOfWeek. An indeterminate range may be indicated with a null value at the appropriate position.
• Multiple ranges or multiple days are allowed in one instance of this complex attribute, but mixing range with discrete days(s) is not allowed (encode another instance of this attribute instead).
• Product specifications may need to allow repetition of this complex attribute in order to allow encoding of schedules which vary for different days of the week.
• Ranges may 'wrap'; for example, the range 7-2 (meaning Sunday through Tuesday, inclusive) is permitted.
• To encode multiple intervals during the day, repeat TIMSTW and TIMENW as necessary.

Constraints: Duplicates or overlaps are not permitted.

Examples:

1. To encode “Monday through Friday” use the sequence: dayOfWeek=1, dayOfWeek=5 and set dayOfWeekIsRange=TRUE.
2. To encode the days Monday, Wednesday, Friday, use the sequence dayOfWeek=1, dayOfWeek=3, dayOfWeek=5 and set dayOfWeekIsRange=FALSE.
3. The sequence dayOfWeek=1, dayOfWeek=3, dayOfWeek=5 to indicate Mon-Wed and Thursday is not allowed. Encode the Mon-Wed and Thursday schedules in different instances of this complex attribute.
4. To encode times that are the same through the US/European work week (Monday through Friday) but different on weekends (Saturday/Sunday), encode two instances of the complex attribute tmIntervalsByDoW bound to the same object.
5. Office hours from 0800-1200 and 1300-1700 from Monday through Friday are encoded using one instance of tmIntervalsByDoW with TIMSTW=0800, TIMENW = 1200, and TIMSTW=1300, TIMENW=1700 (and dayOfWeek and DayOfWeekIsRange as in example 1 above).

Aside: This model could probably be simplified if we were allowed to use representations like ISO 8601 (which are like 'structured text'), or S100_TruncatedDate. S-100 Date/Time/DateTime/S100_TruncatedDate aren't enough for modeling time schedules.

raphael (talk) 07:45, 23 May 2018 (CEST): TIMREF can be removed from the sub-attributes since NPUB will now definitively use the Z suffix to mean UTC and no suffix to mean local time.
Camel case code needs to be update to match what ended up in the registry.

jens (talk) 15:38, 30 May 2018 (CEST) removed TIMREF and forwarded it to th "deleted items" section. CamelCase has been checked and corrected.