Difference between revisions of "Talk:NTCTIM"

From IHO Nautical Information Processing Working Group
Jump to navigation Jump to search
m
Line 11: Line 11:
  
 
But questions like this will arise in other places too. Can SNPWG or TSMAD provide general guidance about such issues? If not, should we try to devise such general guidance?
 
But questions like this will arise in other places too. Can SNPWG or TSMAD provide general guidance about such issues? If not, should we try to devise such general guidance?
 +
 +
[[User:Jens|jens]] 12:32, 12 May 2009 (CEST)
 +
 +
Raphael, Thanks for raising up your hands in that issue. We tried to develop understandable definitions. It could be happen that they are literally spoken not 100% waterproof.  However, at the moments, with data type String, we do have all options open. In your proposed def I see the problem of mixing the time and reg/rec/res.  What we should definitely try to avoid id to mix the time and the circumstances in the definition; one can be tempts to put regulations into this attribute.
 +
I can accept to add this to remark section to clarify that such statement is allowed too. 
 +
 +
What do you think? Is the remark section an acceptable place to clarify what is allowed?

Revision as of 10:32, 12 May 2009

jens 11:01, 13 August 2008 (CEST)

This looks perfect to me.

raphael 09:12, 12 May 2009 (CEST) : I am being asked how literal/precise the model's definitions are supposed to be. For example, the current definition of ntctim as "Span of time, prior to the time the service is needed, for preparations to be made to fulfil the requirement.", even with the accompanying remark, may be interpreted as not permitting mention of update times, or statements like "if departure is scheduled between 19:00 and 07:00, by 17:00".

For the case of ntctim, editing the definition slightly may suffice. I thought of changing the definition as follows:

Definition: Time spans when notices and updates must be provided and the circumstances under which the notices or updates are required.

But questions like this will arise in other places too. Can SNPWG or TSMAD provide general guidance about such issues? If not, should we try to devise such general guidance?

jens 12:32, 12 May 2009 (CEST)

Raphael, Thanks for raising up your hands in that issue. We tried to develop understandable definitions. It could be happen that they are literally spoken not 100% waterproof. However, at the moments, with data type String, we do have all options open. In your proposed def I see the problem of mixing the time and reg/rec/res. What we should definitely try to avoid id to mix the time and the circumstances in the definition; one can be tempts to put regulations into this attribute. I can accept to add this to remark section to clarify that such statement is allowed too.

What do you think? Is the remark section an acceptable place to clarify what is allowed?