Talk:WKDYWK - Revision history

Jens at 05:08, 13 August 2010

2010-08-13T05:08:41Z

Jens at 05:02, 13 August 2010

2010-08-13T05:02:45Z

Rmm at 22:20, 12 August 2010

2010-08-12T22:20:25Z

Rmm at 21:23, 12 August 2010

2010-08-12T21:23:34Z

New page

SNPWG 8 agreed

[[User:Rmm|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 ==

[[User:Rmm|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.

[[User:DavidAcland|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

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

[[User:DavidAcland|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"?

[[User:Jens|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.

{| style="background:#ccc99; color:black;" border="1" cellpadding="5" cellspacing="0" align="left"
!Sub-attribute!!Camel Code Identifier!!Multiplicity!!Sequential
|-
|[[DYOFWK]]||dayOfWeek||0..1||True
|-
|[[??????]]||dayOfWeekRangeStart||0..1||True
|-
|[[??????]]||dayOfWeekRangeEnd||0..1||True
|-
|[[TIMREF]]||timeReference||1||True
|-
|[[TIMSTW]]||timeOfStartOfWork||1||True
|-
|[[TIMENW]]|||timeOfEndOfWork||1||True
|-
|}

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.

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

Jens at 13:49, 10 August 2010

2010-08-10T13:49:49Z

Jens at 13:48, 10 August 2010

2010-08-10T13:48:51Z

Jens at 13:39, 10 August 2010

2010-08-10T13:39:49Z

New page

SNPWG 8 agreed

[[User:Rmm|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 ==

[[User:Rmm|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.

[[User:DavidAcland|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

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

[[User:DavidAcland|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"? [[User:Jens|jens]] 13:39, 10 August 2010 (UTC) or "working schedule"?

Changing multiplicity of [[DYWKRN]] makes sense if duplication on 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 should have seven instances of [[DYOFWK]] there if the others have only one and [[WKDYWK]] is multiplied.

The best solution will be if we find a solution to bring [[WKDYWK],[[WKHRDY]] and [[DYWKRN]] together. I think it should be possible; the complexity will offer that.

{| style="background:#ccc99; color:black;" border="1" cellpadding="5" cellspacing="0" align="left"
!Sub-attribute!!Camel Code Identifier!!Multiplicity!!Sequential
|-
|[[DYOFWK]]||dayOfWeek||0..7||True
|-
|[[DYWKRN]]||dayOfWeekRange||0..1||True
|-
|[[DYOFWK]]||dayOfWeek||2||True
|-
|[[WKHRDY]]||workingHoursOfDay||0..1||True
|-
|[[TIMREF]]||timeReference||1||*
|-
|[[TIMSTW]]||timeOfStartOfWork||1||True
|-
|[[TIMENW]]|||timeOfEndOfWork||1||True
|-
|}

What do you think?

Referring to your concerns: I have introduced that at TSMAD in HRO and haven't got any objections or have cause frown. You should ask Berrie 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.

Rmm: /* Revision proposed to SNPWG11 */

2010-04-02T02:14:45Z

Revision proposed to SNPWG11

Rmm: /* Revision proposed to SNPWG11 */

2010-03-29T18:08:34Z

Revision proposed to SNPWG11

New page

Rmm: /* Revision proposed to SNPWG11 */ new section

2009-08-24T23:50:06Z

Revision proposed to SNPWG11: new section

New page

@@ Line 109: / Line 109: @@
 !Sub-attribute!!Camel Code Identifier!!Multiplicity!!Sequential
 |-
-|[[DYOFWK]]||dayOfWeek||0..1||True
+|[[DYOFWK]]||dayOfWeek||0..1||n/a
 |-
-|[[??????]]||dayOfWeekRangeStart||0..1||True
+|[[??????]]||dayOfWeekRangeStart||0..1||n/a
 |-
-|[[??????]]||dayOfWeekRangeEnd||0..1||True
+|[[??????]]||dayOfWeekRangeEnd||0..1||n/a
 |-
-|[[TIMREF]]||timeReference||1||True
+|[[TIMREF]]||timeReference||1||n/a
 |-
-|[[TIMSTW]]||timeOfStartOfWork||1||True
+|[[TIMSTW]]||timeOfStartOfWork||1||n/a
 |-
-|[[TIMENW]]|||timeOfEndOfWork||1||True
+|[[TIMENW]]|||timeOfEndOfWork||1||n/a
 |-
 |}
@@ Line 160: / Line 160: @@
 [[User:Jens|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.
 <br> I prefer version i) if S100 allows multiple instances of an attribute.

← Older revision		Revision as of 05:02, 13 August 2010
Line 156:		Line 156:
	# A [[SRVHRS]] can have more than one WKDYWK attribute. For example, one WKDYWK describing the M-Th period, another WKDYWK for Friday.		# A [[SRVHRS]] can have more than one WKDYWK attribute. For example, one WKDYWK describing the M-Th period, another WKDYWK for Friday.
	# A [[SRVHRS]] can have only one WKDYWK attribute. The WKDYWK describes the work schedule for the whole week.		# A [[SRVHRS]] can have only one WKDYWK attribute. The WKDYWK describes the work schedule for the whole week.
		+
		+
		+	[[User:Jens\|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.
		+	<br> I prefer version i) if S100 allows multiple instances of an attribute.

← Older revision		Revision as of 22:20, 12 August 2010
Line 151:		Line 151:

	[[User:Rmm\|raphael]] 21:23, 12 August 2010 (UTC): "Sequential": True or False applies only if multiplicity can be > 1. Otherwise it should be n/a.		[[User:Rmm\|raphael]] 21:23, 12 August 2010 (UTC): "Sequential": True or False applies only if multiplicity can be > 1. Otherwise it should be n/a.
		+
		+	[[User:Rmm\|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:
		+
		+	# A [[SRVHRS]] can have more than one WKDYWK attribute. For example, one WKDYWK describing the M-Th period, another WKDYWK for Friday.
		+	# A [[SRVHRS]] can have only one WKDYWK attribute. The WKDYWK describes the work schedule for the whole week.

← Older revision		Revision as of 13:49, 10 August 2010
Line 120:		Line 120:
	\|-		\|-
	\|}		\|}
		+
		+
		+
		+

@@ Line 100: / Line 100: @@
 Changing multiplicity of [[DYWKRN]] makes sense if duplication on 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 should have seven instances of [[DYOFWK]] there if the others have only one and [[WKDYWK]] is multiplied.
-The best solution will be if we find a solution to bring [[WKDYWK],[[WKHRDY]] and [[DYWKRN]] together. I think it should be possible; the complexity will offer that.
+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.
 {| style="background:#ccc99; color:black;" border="1" cellpadding="5" cellspacing="0" align="left"
 !Sub-attribute!!Camel Code Identifier!!Multiplicity!!Sequential
 |-
-|[[DYOFWK]]||dayOfWeek||0..7||True
+|[[DYOFWK]]||dayOfWeek||0..1||True
 |-
-|[[DYWKRN]]||dayOfWeekRange||0..1||True
+|[[??????]]||dayOfWeekRangeStart||0..1||True
 |-
-|[[DYOFWK]]||dayOfWeek||2||True
+|[[??????]]||dayOfWeekRangeEnd||0..1||True
 |-
-|[[TIMREF]]||timeReference||1||*
+|[[TIMREF]]||timeReference||1||True
 |-
 |[[TIMSTW]]||timeOfStartOfWork||1||True
@@ Line 120: / Line 120: @@
 |-
 |}
@@ Line 126: / Line 134: @@
 What do you think?
-Referring to your concerns: I have introduced that at TSMAD in HRO and haven't got any objections or have cause frown. You should ask Berrie 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.
+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 Berrie 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.

← Older revision		Revision as of 02:14, 2 April 2010
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?