Talk:NTCTXT

From IHO Nautical Information Processing Working Group
Revision as of 21:22, 17 September 2009 by Rmm (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

jens 16:43, 14 September 2009 (UTC)

Should this and NTCHRS replace NTCTIM?

I like the idea of having two options for coding notice time, the numeric and the alphanumeric. That offers flexibility needed.

raphael 20:27, 14 September 2009 (UTC): Thinking about this...removing a complex attribute is good, allowing encoding of same information as in two places may be debatable if the attributes are not linked somehow. Might it make updates more error-prone, for example if someone encodes NTCHRS=24, NTCTXT="one working day", then someone else updates one but overlooks the other? (updated by raphael 20:39, 14 September 2009 (UTC))

jens 05:18, 15 September 2009 (UTC)

My first thought is that we can expect a minimum of encoder intelligence. But even than it can go wrong. However, the offer of numeric and alphanumeric is still good. Is the correct definition enough to ensure that both are not mixed together? Allowing only one looks different too if one has to encode "as early as possible and 48, 24 and 12 hrs in advance". Perhaps we can add a remark saying if one attribute is been set the second attribute must not cover the same information again. At the moment I have no better idea. Others please.

raphael 07:17, 17 September 2009 (UTC): Or the encoding guide could address this issue. The example could be encoded as 4 instances, if the multiplicity of NTCTIM in that class is 1..* or 0..*

1. as eary as possible: no time interval, so NTCHRS=null, NTCTXT="as early as possible"

2. 48 hrs in advance: NTCHRS=48, NTCTXT="update"

3. 24 hrs in advance: NTCHRS=24, NTCTXT="update"

4. 12 hrs in advance: NTCHRS=12, NTCTXT="update"

I would want to clarify the original text of the publication before encoding the last 3. Also, plain "as early as possible" might be a problem for both data capture and applications.

If we have multiple notice times then matching NTCHRS/NTCTXT might become an issue especially if NTCTXT is some other kind of satement (e.g., "to pilot vessel" or "by fax or telephone to the pilot station").


jens 07:36, 17 September 2009 (UTC)

How such things can go around. We discussed exactly the same problem this morning trying to encode "at least 48 hours or latest when passing the territorial border."
would be encoded as
NTCHRS=48, NTCTXT="at least to the stated notice hours or latest when passing the territorial border"

However, the multiplicity of NTCTIM should be IMO 0..*, because we can not guarantee to provide a time every time.

raphael 21:22, 17 September 2009 (UTC): I agree with the example. I agree in principle with the multiplicity statement above (but see below).

Multiplicity can be different for different object/attribute bindings, for example, the multiplicity of PLTSRV/NTCTIM could be 0..* and MRNSRV/NTCTIM could be 1.