TAP: trailing INFO element usage

[Patrick Dowler]

The usage I had in mind was limited to having:

 <INFO name="QUERY_STATUS" value="OK"/>
   <TABLE> ..</TABLE>
 <INFO name="QUERY_STATUS" value="OK"/>

meaning "go to the end of rows and still OK" (eg no failure while
processing rows). We don't add it if the first QUERY_STATUS is ERROR
and we never predict an OVERFLOW.

I kind of agree that if we had to carefully explain the meaning of all
the combinations of the before and after QUERY_STATUS it probably
wouldn't be worth it.

On 18 April 2016 at 10:29, Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:
> DALI 1.0 sec 4.4 specifies possible @values for an @name=QUERY_STATUS
> INFO element:
>
>    sec 4.4:
>       pre-TABLE: OK/ERROR/OVERFLOW
>    sec 4.4.1:
>       post-TABLE: OVERFLOW
>    sec 4.4.2:
>       post-TABLE: ERROR
>
> It does not explicitly outlaw a post-TABLE QUERY_STATUS
> INFO with the value OK.  Or the value "NOT_BAD".  Or the
> value "OVERFLAW".  But it doesn't say how to interpret
> those things, so taplint issues a WARNING (not an ERROR)
> if a post-TABLE QUERY_STATUS element is found with a value
> not explicitly mentioned in the standard.
>
> If DALI 1.1 explicitly endorses an OK post-TABLE value, I'll remove
> that warning.  Since, as you say, it doesn't add anything, I don't
> really think that would be an improvement, and in that case there
> should really be explicit text explaining what it means to have, e.g.
>
>    <INFO name="QUERY_STATUS" value="ERROR"/>
>    <TABLE> ..</TABLE>
>    <INFO name="QUERY_STATUS" value="OK"/>
>
> etc, or it should explicitly forbid such usages.  My feeling
> is it would be clearer to state that QUERY_STATUS must only be
> used with the values and meanings explicitly mentioned
> (OK/ERROR/OVERFLOW pre-TABLE, or ERROR/OVERFLOW post-table).
>
> Mark
>
> On Mon, 18 Apr 2016, Patrick Dowler wrote:
>
>> I was just running taplint to check ObsCore-1.1 compliance and I noticed this:
>>
>> W-OBS-DQU2-1 Post-table QUERY_STATUS INFO has unknown value OK is not
>> ERROR/OVERFLOW
>>
>> What happens is that we always have a trailing INFO element after the
>> table and if all goes well the value is OK. Clearly taplint doesn't
>> expect that... do I need to clarify WD-TAP-1.1 to allow more
>> flexibility or to explicitly forbid this?
>>
>> Details:
>> - This is an implementation detail of our streaming XML output; we
>> construct a DOM and it was a lot easier to add the INFO element up
>> front and modify the value at the end of streaming than to add it
>> during output. I could make changes to satisfy taplint expectations
>> but it strikes me that it should be OK to include such a trailing INFO
>> with QUERY_STATUS even if it doesn't say anything new.
>>
>>
>>
>> --
>> Patrick Dowler
>> Canadian Astronomy Data Centre
>> Victoria, BC, Canada
>>
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada