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