*Operations/DAL Session: Service Compliance
*Friday 28 May 2021, 20:30-21:30 UTC

Participant Count: 53

Aim: report the current status of services in the VO and feedback from implementation work, and discuss particular issues with DAL standards arising from these. 

*Schedule
Renaud Savalle - VO Paris Weather Report
Tamara Civera Lorenzo - OAJ Publishing Registry and VO Services Validation
Mark Taylor + all - DAL Feeback: Specific Issues

*Notes

*Renaud Savalle - VO Paris Weather Report
validator takes 3-4 hours to scan ~20,000 services
new reporting web app presented yesterday replaces prior tool
SCS: steady increase in number of valid cone search services. ~97% of the services scanned are valid
common SCS error types - XML errors, UCD issues.
SIA: there has been a recent dip in number of valid SIA services, one provider started to use an invalid param type
SSA: evolution has been more chaotic, suspect if reflects complexity for both developers and operators
situation has been improving slowly, but still a large fraction (majority) of invalid services
SSA XML errors are declining but others ongoing.
SSA return should contain two strings for URI, many just provide one

Markus: schemaLocation needs an even number of URIs, so the validatoris right.

TAP service monitoring started more recently in 2019. number has grown >20% in 2 years.
taplint has been used for validation
TAP error frequencies - most errors in same few categories

Validator has API for retrieval of validator results
encourage providers to provide details on server software stacks - see the SoftID note, talk by Mark Taylor yesterday in Ops 1.

Weather: has been sunny with some clouds.
New, reporting server software stack info and http error codes
SIA2 validator still stalled because of resources
feedback always welcome
register services early to get benefit of validation

Marco: explain auxiliary validation capability
one is standard, that will be used as the primary validation
the aux ones are considered additional and expected to behave the same

James Dempsey: might be good to label SIA as SIA1 in the reports to prevent confusion with SIA2
JD: also interested in common error types for TAP
Mark Taylor - difficult to assign a score/rating to services based on error frequency, sometimes the problems are small and common but the service is actually mostly OK

discovering collections: https://ivoa.net/documents/discovercollections/20190520/index.html


*Tamara Civera Lorenzo - OAJ Publishing Registry and VO Services Validation

telescopes - JAST80, JST250
two main surveys - J-PLUS and J-PAS
variety of filters used, both ~8500 sq deg
portal https://archive.cefca.es
VO services, TAP, SAIP, SCS, HiPS
VO Publishing registry online this year Feb 2021
registered services are grouped by survey
validation by service type
HiPS: using Hipslint.jar, errors identified have been addressed
SCS - using Paris PADC portal, ESA Euro-VO validator
SCS errors reported when survey doesn't have data in those coordinates, but think that can be addressed
SIA1 - using PADC, Euro-VO. errors identified have been addressed. communcated with validator team for assistance.
SIA2 - used PADC validator. errors have been corrected.
TAP - used taplint, also Euro-VO validator. issues with UCD's and utypes have been corrected.
also errors with column names, and job management (action=DELETE)
errors with order of elements. not solved: use of custom enum structure to define filters.
TAP errors reported by Euro-VO, some errors not resolved, trying to understand
DataLink - used datalinklint (STILTS). no errors.
MOC - used MOCserver. no error.

lessons:
validation useful to make services more usable
sometimes difficult to understand the reported error.
could be interesting to have standalone validators for all the services to validate them before deployment
would be helpful for validator results to be machine-readable (assists re-checking regularly)

Christophe Arviset: impressed by perseverance, following up on all the errors. also contributed to improving validators. congratulations
Pierre Fernique: comment about adding .. putting resource when declared. how table is listed in registry for obscore usage. confusing how to declare same table used by several services (SCS, TAP). DACHS may be helpful in how to compose correct registry entry [sg: I don't think I captured this correctly, someone/Pierre maybe check?]


*Mark Taylor + All - DAL Feedback: specific issues

Summary  - feedback from operational activities on issues with DAL standards

Known standards issues:
1: trailing '?' for accessURL - unclear, contradictory. SSA,SIA1, SIA2 say different things
seems sensible to drop this? services adding the '?' to keep the validators happy, but purpose?
maybe worth erratum to clarify

Gregory D-F: using multiple params as OR vs AND. 
Marco M: have to clarify what SSA says, suggest we don't say anything about ? or &, they are delimiters

2: questionable MIME types 
VOTable-related MIME types
Markus D: My take: Let´s finally register VOTable with the IETF...
Theresa D: (we really need to register ivo:// with them as well)

Markus D volunteers to pursue registration for ivo://, Dave Morris volunteers to register VOTable

Use of UCD1's - archaic, use of UCD1+s are preferable. this is a common validation failure for SCS. long-running item
Tom Donaldson: reading of spec is not clear, how strongly should those validation errors be flagged?

Gregory D-F:  note VOTable 1.4 says “UCD1+ usage is recommended, but applications using the older vocabulary are still acceptable in this version of VOTable.”

SSA error response codes
how to report error status? SSA sec 8.10.3 suggests 200 OK, but DALI 1.1 sec 4.2 says use HTTP error code (4xx). ESA validator reports error on 4xx
Does this need clarification?
Markus: historical - original intent was returning 200, but modern view would be 4xx
Pat Dowler: think validators could be more relaxed on this, the standard predates DALI

Gregory D-F:
@tomD I don’t think it’s _wrong_ that we use the table-specific parameters, and in practice it seems unlikely that the base URL would contain parameters that are also documented as legal in a specific standard, but it *could* happen and I think in that case the “OR” behavior would be pretty counterintuitive.
+1 on PatD’s suggestion that we fix this by referring to DALI in the next SSA.

---post-adjournment---

Tom D:
@Gregory, ah OK.  I do agree then.

G. D-F.: So perhaps one way forward would be a warning to implementers that if they include URL query parameters in their base URLs, they SHOULD (?) not include parameters that are also valid in DALI or in the specific derived service that is available at that endpoint?
We don’t want clients having to feel like they have to back up through the URL and check for this themselves…

Brian Major: I wonder what UWS does on service error (rather than job error)

G. D-F.:  UWS 1.1:
    'If a request is made to a resource that does not exist (e.g. an non-existent job-id) then a 404 error should be returned, or if a request is made that is illegal for the current state of the UWS then a 403 status should be returned. If for some reason there is a complete failure in the underlying UWS machinery then a 500 "internal server error" status should be returned. However individual job failures are indicated by setting the appropriate parts of the job representation to error statuses and a request for the individual job object representation at /{jobs}/{job-id} should have a normal 200 status code response.'

== wrap ==