Difference between revisions of "Talk:Notice time"
m |
|||
Line 51: | Line 51: | ||
[[User:Jens|jens]] 07:40, 30 October 2009 (UTC) OK. Understand your ideas and advices. I changed the table content accordingly. The multiplicity was set > 1 because of the necessity of declaring several hrs for one single handling (e.g. report) is possible. An example is provided on the page. I placed remark that the ProdSpec should define whether the multiplicity > 1 for the attribute bindings is requested. I assume that is the right place. | [[User:Jens|jens]] 07:40, 30 October 2009 (UTC) OK. Understand your ideas and advices. I changed the table content accordingly. The multiplicity was set > 1 because of the necessity of declaring several hrs for one single handling (e.g. report) is possible. An example is provided on the page. I placed remark that the ProdSpec should define whether the multiplicity > 1 for the attribute bindings is requested. I assume that is the right place. | ||
+ | |||
+ | [[User:Rmm|raphael]] 17:06, 30 October 2009 (UTC): OK. I suggest changing the last sentence to make it clearer to some future reader who will not have seen this discussion. | ||
+ | |||
+ | "Remark: Product specifications which allow multiplicity > 1 for this attribute should state whether the order of values has any significance and explain the significance." |
Revision as of 17:06, 30 October 2009
raphael 22:54, 27 October 2009 (UTC): Here I have a question about the meaning of OPERAT in the context of notice time. "Whichever is more" and "whichever is less" are OK where they apply. But NTCTXT is also intended to qualify NTCHRS, e.g., by adding a phrase like "before reaching reporting point". "3 hours before reaching reporting point" would be encoded as NTCHRS = 3 hours and NTCTXT="before reaching reporting point". Possible ways to resolve this are by mandating a meaning for OPERAT=null or the absence of OPERAT, or adding another allowed value for OPERAT.
jens 06:21, 28 October 2009 (UTC) Does not multiplicity 0..1 solve the problem? Having no OPERAT defined the operation is absence.
By the way, reading your argument it seem to me that the sequential should be set. Otherwise we run the risk to see "before reaching reporting point 3 hours" which is understandable but looks strange. I will set the sequential accordingly.
raphael 18:58, 28 October 2009 (UTC): OPERAT multiplicity 0.. does solve the problem, the specification should state how the absence of OPERAT must be interpreted. E.g., "The absence of OPERAT or a null value for OPERAT means NTCTXT qualifies or explains NTCTIM. In this case NTCHRS and NTCTXT must be read or displayed together."
The definition of "sequential" in S-100 drafts is ambiguous, but after reading the remarks in V. 0.0.4 2a-4.2.13 and examples in Appendix 2A, "sequential" is just a boolean which applies only if multiplicities > 1 are allowed; all "sequential" indicates is whether the sequence of values is significant. It is left to the product specification to say what the significance is.
I see the point about specifying the order of NTCHRS and NTCTXT, but perhaps the data capture (encoding) guide should tell the encoder how to phrase NTCTXT? If I were displaying NTCTHRS/NTCXT as a table either order might be acceptable. Also, it is possible that the proper order might be different in different languages.
jens 06:39, 29 October 2009 (UTC) I hope the S100 text cause the same results in our both minds :).
OK I understood and turn back to sequential 1. I also set multiplicity to 0..* because of thinking that several notice times to one administration/service etc. are applicable. The order of information should be set in that case.
--raphael 05:12, 30 October 2009 (UTC): S100 also allows multiplicity > 1 for the attribute bindings themselves (Appendix 5A, figure in A-1 and table A.17). So an alternative might be to assign the objectX-NTCTIM binding multiplicity 0..* or 1..* and sequential=true, and keep the multiplicity of sub-attributes NTCHRS, NTCTXT, OPERAT as 1 or 0..1 (and therefore sequential=n/a for each sub-attribute) unless there is some other reason for multiplicity > 1 there. That is, we could code, for example:
Case 1:
PLTSRV
NTCTIM (1st instance of complex attribute)
NTCHRS=12
NTCTXT="before arrival at reporting point"
OPERAT=null
NTCTIM (2nd instance of complex attribute)
NTCHRS=6
NTCTXT="update"
OPERAT=null
instead of
Case 2:
PLTSRV
NTCTIM (complex attribute)
NTCHRS=12
NTCHRS=6
NTCTXT="before arrival at reporting point"
NTCTXT="update"
OPERAT=null
OPERAT=null
or
Case 3
PLTSRV
NTCTIM (complex attribute)
NTCHRS=12
NTCTXT="before arrival at reporting point"
OPERAT=null
NTCHRS=6
NTCTXT="update"
OPERAT=null
I think there is less chance of ambiguity with Case 1...
jens 07:40, 30 October 2009 (UTC) OK. Understand your ideas and advices. I changed the table content accordingly. The multiplicity was set > 1 because of the necessity of declaring several hrs for one single handling (e.g. report) is possible. An example is provided on the page. I placed remark that the ProdSpec should define whether the multiplicity > 1 for the attribute bindings is requested. I assume that is the right place.
raphael 17:06, 30 October 2009 (UTC): OK. I suggest changing the last sentence to make it clearer to some future reader who will not have seen this discussion.
"Remark: Product specifications which allow multiplicity > 1 for this attribute should state whether the order of values has any significance and explain the significance."