Talk:NTCTIM

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 these issues. 1. 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?

2. I'm not sure which guidance do you mean.

raphael 20:24, 12 May 2009 (CEST) : I see what you mean about mixing time and rec/reg/res. Yes, the remark section would be an acceptable place for a clarification. I intended "circumstances" to cover "approaching" and "departing", perhaps arrival delays and similar circumstances. For example, there is this passage in BSH SD:

approaching
 at least 3 h before arriving outer pilot boarding place
departing, short haul or shifting
 at least 3 h before departure
 if departure is scheduled between 19:00 and 07:00 by 17:00

I agree that making 100% waterproof definitions would be difficult, so I suggested providing general guidance. That won't solve the problem but should reduce it. General guidance may be something like you said above, that with data type String we have all options open.

Another example of general guidance might be "When encoding data into a string-valued attribute include subsidiary phrases that modify the basic content." This would permit encoding the "if ..." condition above in an ntctim string.