Talk:WKDYWK

SNPWG 8 agreed

raphael 18:43, 10 June 2009 (CEST) : Just a minor note about weekends. Some places have "weekends" different from Saturday+Sunday, and some places have a six-day or 5.5 day work week, or complications like a a 6-day work week with a holiday on the 2nd Saturday of each month, though I am not sure whether they do it for port operations. I suggest deletion of the parenthetical notes about weekends in the "definitions" section.

Revision proposed to SNPWG11

raphael 23:50, 24 August 2009 (UTC): It is proposed to make this a complex attribute with two sub-sttributes, DYOFWK and DYWKRN. The reason is to permit more compact representations of working days and hours, assuming that S-100 forbids list values (see discussion at Talk:DYWKRN). Given this assumption, as WKDYWK is currently defined it would be necessary to code the working hours separately for every working day. This works, but may be cumbersome and susceptible to human error during maintenance because it would be necessary to code similar data repeatedly (for example, code the same working hours five times).

The specification is intended to allow coding of individual days, ranges of days, or some combination of the two, i.e., it would be possible to code the work week "Monday-Friday and Saturday" as:

DYOFWK = 6 (Saturday)

DYWKRN (DYOFWK = 1, DYOFWK = 5) (Monday - Friday)

The proposed definition follows:

Attribute: Working days of week

Alpha code: WKDYWK

Attribute type: Complex

Camel case: workingDaysOfWeek

Data Type: Complex

Definition: The working days of the week.

Sub-Attributes:

Name Alpha code Camel case Cardinality sequential

Day of week DYOFWK dayOfWeek 0..7 True

Day of week range DYWKRN dayOfWeekRange 0..* True

Constraints: Duplicates or overlaps are not permitted

Remarks: The total number of “Day of week” and “Day of week range” values must be appropriate for the number of entries in the corresponding Working hours of Day attribute, if present. Note that a day may have more than one working period.

DavidAcland 15:57, 29 March 2010 (UTC) I have implemented this proposal and we are nearly ready to agree but I have a question.

Can we tighten up on the multiplicity of DYWKRN? I cannot conceive of * ranges but have not really come up with a logical answer. Do we need at least one range? I do not really understand the relationship to WKHRDY. It seems to me that here we are only saying what the working days are. So if we had Monday to Friday 8-1700 and Saturday 8-1200, WKDYWK would pesumably cover Monday - Saturday. The WKHRDY would have to be able to explain Monday to Friday in one lump of 0800-1700 and Saturday as a separate item. Were you thinking of wrapping in the hours as a third attribute?

WKDYWK

   DYOFWK - 6
   WKHRDY - 08-1200

   DYWKRN
       DYOFWK=1
       DYOFWK=5
   WKHRDY - 08-1700

raphael 18:08, 29 March 2010 (UTC): I will think about these questions and revise the definitions if necessary. My response may not be posted until later this week, though - I will be off work on Tuesday and Wednesday.

raphael 02:14, 2 April 2010 (UTC): Concerning the 0..* multiplicity of DYWKRN: I used 0..* because it is the most general solution. The lower bound needs to be 0 because there might be work times which cannot be expressed using dayranges (e.g.: M, W, F, for which we can use only DYOFWK=1,3,5). The upper bound "*" allows capture of multiple ranges, e.g. "Monday-Wednesday and Friday-Sunday". However, making DYWKRN multiplicity 0..1 will be acceptable because we can still use DYOFWK to capture "leftover" days.

About WKHRDY: I was thinking it would continue to be an attribute of the SRVHRS object. So the encoding would be:

WKDYWK

   DYOFWK = 6
   DYWKRN
       DYOFWK=1
       DYOFWK=5

and
WKHRDY - 08-1200
WKHRDY - 08-1700

in that order. But the way you put it (making WKHRDY a third sub-attribute of WKDYWK) may be easier to understand, so I have no objection to making it so.

PS: The specification of WKHRDY needs a small revision either way - I will add a note in Talk:WKHRDY.

PS 2: I would much prefer to be able to keep it simple and define working hours using formatted strings, for example describe "Mon-Fri 8-12 and 1-5; Sat 8-12" by:

WorkingDays= "1-5,6" and WorkingHours = "[0800/1200,1300/1700],[0800/1200]"

but I suppose in S-100 this kind of thing is either discouraged or won't be allowed any more?

DavidAcland 08:41, 10 August 2010 (UTC) Changed DYWKRN multiplicity from 0..* to 0..1 iaw discusion above. This means that we can only have one main range like Monday to Friday or Sunday to Thursday. Left over days which include some work are separate.

Re Raphael's PS just above. WKHRDY specification changed.

I have added WKHRDY as a third attribute to link the working hours in the day to the working days in the week. I have made sequential = True, which I hope links the working hours to the range of working days or single working day. Raphael, is this right?; Is there a better way?

If we all agree this extension of the design of WKDYWK, I intend to take WKHRDY off SRVHRS unless anyone sees a reason to leave it there?

I have an outstanding worry about this design. Is it OK to have a stack of complex attributes containing complex attributes?

This change would beg another question. Should we change the Name of Working Days of Week to something like "Working week" , "Work week", "Working days and hours", "Working pattern"?

jens 13:39, 10 August 2010 (UTC) or "working schedule"?

Changing multiplicity of DYWKRN makes sense if duplication of attributes (in this regard WKDYWK is encouraged). Do we need to change the multiplicity of DYOFWK as well to 0..1. I don't see how we could have seven instances of DYOFWK there if the others have only one and WKDYWK is multiplied.

One solution could be to find a solution bringing WKDYWK, WKHRDY and DYWKRN together. I think it should be possible; the complexity will offer that.
dayOfWeekRange was been split up into ...start and ...end. The complex attribute below makes WKHRDY and DYWKRN as complex attributes superfluous. The model is simpler and the data encoder has all together. If multiplicity and sequential has been set up correctly below should be revised.

Sub-attribute	Camel Code Identifier	Multiplicity	Sequential
DYOFWK	dayOfWeek	0..1	n/a
??????	dayOfWeekRangeStart	0..1	n/a
??????	dayOfWeekRangeEnd	0..1	n/a
TIMREF	timeReference	1	n/a
TIMSTW	timeOfStartOfWork	1	n/a
TIMENW	timeOfEndOfWork	1	n/a

What do you think?

Referring to your concerns about complex attributes of complex attributes: I have introduced that at TSMAD in HRO and haven't got any objections or have cause frown. You should ask Barrie explicitly about that again. I have no mercy with the model and the software developer, rather I think we should find a good or preferable the best solution for the data encoder.

raphael 21:23, 12 August 2010 (UTC): "Sequential": True or False applies only if multiplicity can be > 1. Otherwise it should be n/a.

raphael 22:20, 12 August 2010 (UTC): Before we go on, we should decide if WKDYWK itself can be repeated (because the decision affects the allowed multiplicity of the sub-attributes). The alternatives are:

1. A SRVHRS can have more than one WKDYWK attribute. For example, one WKDYWK describing the M-Th period, another WKDYWK for Friday.
2. A SRVHRS can have only one WKDYWK attribute. The WKDYWK describes the work schedule for the whole week.

jens 05:02, 13 August 2010 (UTC) I think it depends on if S100 allows multiple instances of an attribute for one feature. My idea was to say i)if multiple instances are allowed SRVHRS is only be needed once or ii) if multiple instances are not allowed the feature associated with SRVHRS has to be repeated.
I prefer version i) if S100 allows multiple instances of an attribute.

jens 05:08, 13 August 2010 (UTC) I just amended "true" to "n/a". I can feel the pain in Raphael's eyes when he is seeing the totally wrong construction. So it looks better. We can amend it if necessary but we start the correct construction.