Repository navigation
SR=0 wrt MAXREC=0 text clarification #43
Description
Activity
Re-opening the issue because of the revision 1.1 refactoring.
Can be closed once #57 gets in place.closed via PR #57
Actually, there's a rabbit hole here. I'd like to argue that 1.03 has made no requirement that SR=0 actually returns no records.
And there is a point why one might want to do that: a catalogue of extended objects. I have a few of those, and two that even overlap the coordinate system origin: ivo://org.gavo.dc/cstl/q/cone and ivo://org.gavo.dc/amanda/q/cone. These are currently caught by a validator that insists on SR=0 returning no records.
The way these services are implemented, they return whenever the objects overlap the search region. If the search region is a point, that's a simple area-contains-point test. Since the implementation is straightforward and it seems to me the expectable behaviour... Well, can we explicitly state that it's ok to return records for SR=0?
If not, then we'll have to make the prohibition explicit. That that requires extra code in my case, I'd at least request a good use case that induces that requirement...
I went through the v.1.03 and (current 2688499) v.1.1 texts (I report them below for direct check).
I agree v.1.03 does not require SR=0 to return metadata only, it simply shows a way one might want to use to grab metadata.
On the (current) v.1.1 side, the statement currently written within the MAXREC description does not mandate a metadata response when SR=0, it only has a SHOULD whether MAXREC or SR are set to zero.
Possibly we need a more clear wording: you MUST respond with metadata if MAXREC=0 (DALI rules), you MIGHT respond with metadata if SR=0.
Whatever the wording we choose for v.1.1 I think that for v.1.03 having records out of SR=0 cannot be considered an error in validation of the service.
The actual problem, for me, is not what v.103 and/or v.1.1 say, but what happens when you mix up servers and clients speaking different versions.
ConeSearch-1.03 [I think are the relevant pieces here]
Sec.2-1-IV
The set of query constraints must include [...] SR -- the radius of the cone to search, given in decimal degrees.Sec.2-1 (last sentence)
A query following this syntax represents a request for information on sources located within the specified cone on the sky.Sec.2-3
[...] in the case of error. This must happen if the three required parameters (RA, DEC, SR) are not all present, or if their values cannot be parsed to floating-point numbers, or if the numbers are out of range (DEC=91.0, for example). The service may also make an error return if the search radius (give by the SR parameter) is larger than the MaxSR parameter of the Resource Profile [...].
[...]
Other conditions may NOT be considered erroneous [...]. In particular, a zero value of Search Radius should not return an error condition. This is because an application may be more interested in the metadata than the data, and send a fixed query (for example RA=0&DEC=90&SR=0) simply to discover the fields delivered by the service.ConeSearch-1.1
Sec.2.1-5-MAXREC [This is under investigation]
[...] That means that a request including any of MAXREC or SR set with a value of 0 should require a metadata response.
- On Tue, Nov 11, 2025 at 09:42:27AM -0800, Marco Molinaro wrote: ConeSearch-1.1 Sec.2.1-5-MAXREC [This is under investigation] [...] That means that a request including any of MAXREC or SR set with a value of 0 should require a metadata response.I might add that I don't think any real SCS clients at this point attempt to do metadata discovery in this or any other way (except as far as they use the Registry). So, I guess we can essentially establish new practice for metadata inspection anyway, and my take would be to nudge people towards VOSI for that. If we find we need more than capabilities and tables can convey right now, let's add what we need (I already know one thing: column statistics, including existing values in enumerated columns).
- added a commit that references this issue
on Aug 5, 2026 closed via #69
In the porting of the REC-1.03 to the current document SR=0 was described as identical with MAXREC=0.
Since this is not exactly true the analogy among these two parameters has to be relaxed.
(anyway the actual goal is the same, thus MAXREC=0 is encouraged w.r.t. SR=0)