TAP: trailing INFO element usage

[Mark Taylor]

I gathered that's the usage that you had in mind, but when you're
writing a client (or validator) it makes more work and/or leads
to less predictable behaviour if you have to second guess the way
that service providers might exploit available freedoms in standards.
So it's a good idea to avoid freedom to do things multiple ways
if that doesn't provide any value in itself.

On Mon, 18 Apr 2016, Patrick Dowler wrote:

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

--
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/