NavList:

Dear Paul,

Long, very long     debate ...

(1) - First, since accounting for Dip always involves subtracting some positive number from the Sextant height, Dip may easily be discarded from our discussion here (unambiguous mathematical operation here).

More on this in subsection (3) here-under.

(2) - Now we are left with only the very first step - i.e. the one freeing Sextant "raw" readings from Sextant mechanical imperfections - which is relevant here.

You are right : no "signage"/ standard or rigid procedure seems to exist here to take in account such mechanical imperfections.

So I would revert to some good sense definitions learnt from both high school and Engineers Schools: we REMOVE/SUBTRACT/GET RID OF an algebraic error, or as an exact equivalent : we ADD an algebraic correction.

This is why, when given a quantity labelled as "Index Error" or IE, I am to suppress/subtract it from the published instrumental "raw" result in order to get a "perfect sextant" reading. If given a published "Index Correction" or IC instead, I am to add it to the instrumental "raw" result in order to likewise attempt getting a "perfect sextant" reading.

This good sense rule assumes that BOTH :

(2.1) - The data Writer himself exactly knows the difference between an error (to be removed) and a correction (to be added). In this respect the NAL writing : H = Hs + I - D where I is the Sextant Index Error is certainly incorrect as you earlier noticed. And:

(2.2) - The data Processor himself too knows the difference between error and correction.

(3) - This now leads us to your initial suggestion for the data Writer to publish partially preprocessed data.

This is definitely a good path to follow. Thanks for it.

IMO it should involve only this very first step here-above, i.e. publishing Heights corrected for only overall instrumental error, including both eccentricity and index offset.

Why I am suggesting to NOT include Dip ? 2 reasons for that :

(3.1) : As seen hereabove in sub-section (1), the Dip correction is unambiguous.

(3.2) : To whoever may want to subsequently process again earlier observations it would already somehow "spoil"  the data to be reprocessed since it would prevent from using any [slightly] different Dip algorithm.

Best Friendly Regards from France,

Antoine