Difference between revisions of "Talk:WKDYWK"
Line 58: | Line 58: | ||
[[User:Rmm|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. | [[User:Rmm|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. | ||
+ | |||
+ | [[User:Rmm|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 <br> | ||
+ | WKHRDY - 08-1200<br> | ||
+ | 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? |
Revision as of 02:14, 2 April 2010
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?