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