Change of inclusion status for coordinate-related properties

[merkys]

Changed the inclusion status from REQUIRED in the response to SHOULD NOT be present unless explicitly included for the following structures properties:

• cartesian_site_positions
• nsites
• species_at_sites
• species
• assemblies

@rartino suggested having a general notice about the exclusion of all but essential properties as a general mechanism. However, I failed to locate a proper place in text (as well in hierarchy of descriptions) to do so. Maybe just changing the inclusion status is enough for time being?

Fixes #184

[rartino]

While I am in full support for the overall changes; after making these changes we are not so helpful on the underlying intent with what properties get included or not. The reader is likely to end up with the feeling that one needs to carefully consider each individual Response point in Sec 6 to decipher arbitrary conditions of when things should be included or not.

In reality, our rules are very straightforward:

• If response_fileds is not present: return only a small set of default properties.
• If response_fields is present, return only those fields requested.

I think the right place to say this is early in section 4.1, with maybe a callback from 4.2 to say that the same thing applies for single entry endpoints. Or possibly a new subsection. I started to formulate a suggestion, but do not have time to finish it now. (I'll get back to it eventually if no one else makes an attempt.)

[CasperWA]

Looks fine to me, thanks @merkys.

I am still not sure about nsites though (see my comment).

[CasperWA]

Again, for nsites this seems to intuitively clash with our MUST for queries (line below).
However, I am empathetic with your situation at COD for how you calculate this number - but that's an implementation issue. For the spec., this seems to be a bit counter-intuitive for me.

[rartino]

Oh, right, @merkys: how have you implemented filtering on nsites? Do we have to remove that from being mandatory as well?

[merkys]

Answered below.

[rartino]

Just so the above comment isn't lost (since it is inline in a change):

Can databases, such as COD, for which it isn't cheap to produce nsites really allow search on nsites?

If, no, then we need to remove its mandatory support in filters. This is urgent to fix before the v1.0 release.

[merkys]

Can databases, such as COD, for which it isn't cheap to produce nsites really allow search on nsites?

You are right, we cannot allow queries on nsites without calculating them for all the structures we have. And doing so is infeasible right now.

If, no, then we need to remove its mandatory support in filters. This is urgent to fix before the v1.0 release.

I have just now noticed that the requirement level for this is MUST. For sure we (COD) would require relieving MUST at least to SHOULD.

[merkys]

Opened PR #205 to relieve the requirement for querying on nsites.

[rartino]

@merkys Can this also be closed for now, until the resolution of #210 is decided (and re-opened if necessary)?

[merkys]

@merkys Can this also be closed for now, until the resolution of #210 is decided (and re-opened if necessary)?

Agree. Closing this PR for now.