Conflict between DAP (and SIAv2) and DALI over interval-valued parameters

[gpdf]

SIAv2 and DAP have parameters such as BAND which take values that can be an interval (in the English and/or mathematical sense), represented by a blank-separated pair of numbers, but also a single number.

From the current DAP introductory text:

DAP/DAP.tex

Line 165 in 2febba0

Query parameters for numeric fields accept a single floating point value or a range of values with optional lower and upper bounds. Such range values are encoded using the VOTable array serialisation (space separated). If the lower or upper bound is not specified, the range is open-ended. In VOTable arrays this uses the special values -Inf or +Inf. For example, the interval [300,600] is:

And from the BAND definition:

DAP/DAP.tex

Lines 273 to 279 in 2febba0

	The scalar value 550, equivalent to [550,550]:
	\begin{lstlisting}
	BAND=550
	\end{lstlisting}
	Searching using a scalar value should match any data that includes the specified value; searching using an interval will find any data with energy coverage that intersects the specified interval.

The service-self-description for BAND (and its relatives) says:

DAP/DAP.tex

Lines 613 to 614 in 2febba0

	<PARAM name="BAND" datatype="double" arraysize="*"
	xtype="interval" unit="m" />

The key point is that it says that the parameter has xtype="interval". (Although it's also odd that it says arraysize="*" and not arraysize="2*".)

DALI 1.1 §3.3.4 and WD 1.2 §3.4 both say (emphasis mine):

Intervals with two identical values are equivalent to a scalar value but must still be serialised as a pair of values.

These are clearly in conflict at some level. I feel like although this may seem like being overly lawyerly, we are much more starting to take an interest in supporting applications (like Firefly) that take service descriptors seriously and build UIs directly from them.

There are cheap and perhaps less cheap ways out of this:

(1) We could say that the service self description in DAP is technically stricter than the standard; that is: a DAP implementation is required to support both the one-number and two-number forms, but the self-description documents only the latter, and is making the statement to users/clients "if you follow the self-description your query will be syntactically valid; in some cases there may be other valid ways of constructing a query as well, but they don't offer any new capabilities". So you can say either BAND=550 550 or BAND=550 and they are guaranteed to be equivalent, but the self-description would only offer the first form.

• In this case, I suggest that the DAP text be modified to make this statement much more explicit. Something like 'Searches on a single value may be submitted either using DALI interval syntax, e.g., "550 550", or alternatively as just a single value, "550" (which is not a valid DALI interval but is supported here as a convenience).', with something about this in the introduction to the service self-description as well. E.g. 'Note that the self-description technically describes only the strict DALI interval form for single-value searches, and does not document that the service also accepts single values directly.'
• Note that a sophisticated client could use the standardID to override the service self-description for the standard-specified parameters, and know that the single-number form is actually acceptable despite the self-description.
• But note also that a sophisticated client could also accept users typing a single value in the UI and simply silently convert it to the DALI interval form when submitting the query.

(2) We could redefine DAP to accept only true interval values. This makes it considerably less "use curl and type the query yourself"-friendly.

(3) We could redefine interval in DALI to explicitly support the one-number form.

[pdowler]

I think this happened because SIAv2 and SODA were written about the same time or just before DALI-1.1 added xtype="interval" and in that text we were thinking only about the SIA interface. Then we did the normal "refactoring" (pull interval up to DALI) and there we thought about it more generally and made it more robust and less flexible.

My initial reaction is to chose option (2) fix DAP because that's what you normally have to do after that kind of refactoring.

I don't really like option (3) because it implies xtype="interval" arraysize="2*" (1 or 2 values?). In the work on WD-DALI-1.2 we agreed that we do not need xtype="multiinterval" (ugh double i!) because given the fixed size that can be conveyed using xtype="interval" arraysize="2x*"... yes, that is still distinct and remains correct, but I don't like the complexity vs convenience balance of "2*". There's no need for the wire protocol to be that convenient and ever so slightly optimized.

As for option (1), it looks harmless enough for services to be more flexible when parsing inputs, but you did have to write way more text to describe that option and just like the text an OpenAPI spec might be a pain. When we move to having an OpenAPI spec + prose document, stuff like this that only gets mentioned in the prose document is probably sidelined/ignored or at best has very inconsistent support.

[gpdf]

I'm certainly open to narrowing down DAP; this is the benefit of doing a major change. If other interested parties are in consensus on it, I would not object.

On (1) perhaps we'd need a specific explanation of how the "one or two" definition of BAND-like parameters would be represented in OpenAPI.