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.

Proposed revision to NTCTIM

raphael 04:39, 25 August 2009 (UTC): NTCTIM is currently of type string. Anything can be placed in it, but applications cannot parse the value. It is proposed to make NTCTIM a complex attribute consisting of two sub-attributes, one being a time value in hours and the second, optional sub-attribute being a text string qualifying the time value as needed. The intention is to allow applications to obtain a time and do appropriate processing (e.g., schedule alerts) often enough to be useful, that is, in a relatively high fraction of cases where NTCTIM is used. Given the wide variation of ways in which notice times are expressed, this approach will not work all the time, but it should work in enough simple circumstances that much useful application processing can be done for the simple cases.

For example:

"24 hours in advance" would be coded as: NTCHRS=24, NTCTXT="in advance"

or just NTCHRS=24 (absence of NTCTXT meaning the default, i.e., plain "in advance")

"On passing reporting line XY" would be coded as NTCHRS=0, NTXTXT="Passing reporting line XY".

This idea seems to be as far as it is possible to go in the direction of making notice time understandable by applications without a lengthy and complex effort at defining a parseable format for the notice-time string, but even this does not "solve" the problem. Comments are invited.

Attribute: Notice time

Alpha code: NTCTIM

Attribute type: Complex

Camel case: noticeTime

Data Type: Complex

Definition:

Span of time, prior to the time the service is needed, for preparations to be made to fulfill the requirement.

References: ?

Sub-Attributes:

Name Alpha code Camel case Cardinality sequential

Notice time in hours NTCHRS noticeTimeHours 1 n/a

Notice time text NTCTXT noticeTimeText 0..1 n/a

raphael 03:28, 26 March 2010 (UTC): For consistency with "sequential" in other defintions, in the table NTCHRS/sequential should be True not 1.

The remark should also explain what the absence of the OPERAT sub-attribute of NTCTIM means (discussed on the old Talk:Notice_time page), so the following should be inserted in the Remark:

"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."