Many SSA service have extension input parameters – in particular theory services are almost useless without them. However, without rules for what syntax these parameters adhere to, it is very hard to have interoperable clients.
Most of these parameters are float-valued, which means that clients will almost always have to pass in the equivalent of intervals. Different services have solved that in different ways, such as:
(a) introduce separate PAR_MIN and PAR_MAX parameters
(b) follow standard SSAP parameter and specify intervals in a single parameter in min/max syntax
(c) follow DALI's recipe and pass in intervals as a 2-array of floats (well, nobody actually does that, but I'd say that's the sanest plan.
We probably cannot make anything mandatory here, but a strong guideline would already go a long way towards making extension parameter actually usable (think: just use DALI with xtype="interval", so clients can work out there's sane syntax).
Many SSA service have extension input parameters – in particular theory services are almost useless without them. However, without rules for what syntax these parameters adhere to, it is very hard to have interoperable clients.
Most of these parameters are float-valued, which means that clients will almost always have to pass in the equivalent of intervals. Different services have solved that in different ways, such as:
(a) introduce separate PAR_MIN and PAR_MAX parameters
(b) follow standard SSAP parameter and specify intervals in a single parameter in min/max syntax
(c) follow DALI's recipe and pass in intervals as a 2-array of floats (well, nobody actually does that, but I'd say that's the sanest plan.
We probably cannot make anything mandatory here, but a strong guideline would already go a long way towards making extension parameter actually usable (think: just use DALI with xtype="interval", so clients can work out there's sane syntax).