Talk:NTCTIM - Revision history

Rmm at 03:28, 26 March 2010

2010-03-26T03:28:14Z

Rmm: /* Proposed revision to NTCTIM */ new section

2009-08-25T04:39:03Z

Proposed revision to NTCTIM: new section

New page

[[User:Jens|jens]] 11:01, 13 August 2008 (CEST)

This looks perfect to me.

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

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

[[User:Rmm|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<br>
 at least 3 h before arriving outer pilot boarding place<br>
departing, short haul or shifting<br>
 at least 3 h before departure<br>
 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 ==

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

Rmm at 18:24, 12 May 2009

2009-05-12T18:24:43Z

Jens at 11:21, 12 May 2009

2009-05-12T11:21:21Z

Jens at 10:32, 12 May 2009

2009-05-12T10:32:31Z

Rmm at 07:44, 12 May 2009

2009-05-12T07:44:26Z

Rmm at 07:12, 12 May 2009

2009-05-12T07:12:07Z

Jens: New page: ~~~~ This looks perfect to me.

2008-08-13T09:01:42Z

New page: ~~~~ This looks perfect to me.

New page

[[User:Jens|jens]] 11:01, 13 August 2008 (CEST)

This looks perfect to me.

← Older revision		Revision as of 03:28, 26 March 2010
Line 76:		Line 76:

	Notice time text NTCTXT noticeTimeText 0..1 n/a		Notice time text NTCTXT noticeTimeText 0..1 n/a
		+
		+
		+	[[User:Rmm\|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."

← Older revision		Revision as of 18:24, 12 May 2009
Line 21:		Line 21:

	2. I'm not sure which guidance do you mean.		2. I'm not sure which guidance do you mean.
		+
		+	[[User:Rmm\|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<br>
		+	at least 3 h before arriving outer pilot boarding place<br>
		+	departing, short haul or shifting<br>
		+	at least 3 h before departure<br>
		+	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.

@@ Line 14: / Line 14: @@
 [[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.
+Raphael, Thanks for raising up your hands in these issues.
 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?

← Older revision		Revision as of 10:32, 12 May 2009
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?

@@ Line 4: / Line 4: @@
 [[User:Rmm|raphael]] 09:12, 12 May 2009 (CEST) :
-I am being asked how literally/precisely 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".
+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:

← Older revision		Revision as of 07:12, 12 May 2009
Line 2:		Line 2:

	This looks perfect to me.		This looks perfect to me.
		+
		+	[[User:Rmm\|raphael]] 09:12, 12 May 2009 (CEST) :
		+	I am being asked how literally/precisely 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?