Proposed erratum to clarify arraysize="1"

Tom Donaldson tdonaldson at stsci.edu
Fri Feb 9 17:16:24 CET 2018


Hi Markus,

Thank you for the fast feedback.  I enthusiastically agree with you wording suggestions for sections 2.2 and 4.1.  I think the stronger language better captures the consensus opinions from the interop.

For the Impact Assessment section, your proposed additions make sense to me.  They do a good job of describing my sentiment that this erratum won’t directly make a client or service any worse than it was before.  The bullets I had there were essentially recommendations on how providers, consumers and validators should deal with this erratum.  Do you think those are useful sentiments, and if so, that they are appropriate in the Impact Assessment sections?

I will wait another couple days for immediate reactions, then update the erratum with consensus suggestions.  It would be nice if this erratum can be considered during the next TCG meeting, but only if people are comfortable with that.

Thanks,
Tom

From: <apps-bounces at ivoa.net> on behalf of Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
Date: Friday, February 9, 2018 at 4:12 AM
To: Applications WG <apps at ivoa.net>
Subject: Re: Proposed erratum to clarify arraysize="1"

Tom,

On Thu, Feb 08, 2018 at 10:31:04PM +0000, Tom Donaldson wrote:
Based on the discussion on arraysize=???1??? in Santiago (Apps session 1), I???ve created an erratum proposal for VOTable 1.3.
Please review the erratum at your earliest convenience and comment to this list (apps at ivoa.net<mailto:apps at ivoa.net>)<mailto:apps at ivoa.net)>:
http://wiki.ivoa.net/twiki/bin/view/IVOA/VOTable-1_3-Err-3

Thanks for writing this up -- I think this will be a useful
clarification for VOTable.

I would, however, argue that in order to have a clear standard, we
should upgrade the shoulds to musts, i.e., for sect. 2.2:

  Note: the arraysize attribute must be present if, and only if,
  each table cell for the FIELD is intended to be treated as an
  array. Hence, arraysize="1" must not be used except in the unusual
  case that the table cells contain single values that are
  intended to be understood as single-value arrays.

And for sect. 4.1:

  The arraysize attribute must be omitted unless the corresponding
  table cell contents is intended to be understood as an array.


Having "should" here is, I think, hard to interpret in terms of RFC
2119:

  SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
  there may exist valid reasons in particular circumstances when the
  particular behavior is acceptable or even useful, but the full
  implications should be understood and the case carefully weighed
  before implementing any behavior described with this label.

Applied to arraysize="1" this would mean that VOTable parsers would
probably need to let users override the behaviour that arraysize="1"
are arrays, and I'd argue that's not something we should impose on
implementors.



Finally, in the impact assessment section I'd start with:

  Since client handling of arraysize="1" was not uniform so far,
  VOTables declaring arraysize="1" for scalars have worked with
  certain clients (that are considered erroneous with this erratum)
  but broke with others.  Hence, while this erratum may lead to
  failures in specific combinations of client and server that worked
  before (specifically, when a corrected client encounters a
  still-broken service), the breaking services cannot be considered
  interoperably working before.  We therefore argue that this Erratum
  does not break existing, working serivces or clients.

  In any case, experience show that services are easy to update where
  they still use arraysize="1".  It is reasonable to expect that they
  will be updated by the time legacy clients with erroneous
  arraysize="1" behaviour are corrected.


Or something like this.

Thanks,

           Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20180209/4c89c607/attachment.html>


More information about the apps mailing list