The Firefly TAP query interface should be accessible via a URL interface.

• The URL interface SHALL be IVOA "DALI-style", and in particular compatible with use with DataLink. This means that all parametrizable components of the interface must be URL query parameters (e.g., (instance)/portal/tap-search?service=...&table=...) ), and the parameter values should be chosen with a view to being values that could be found directly via other queries, so that they they can be used via DataLink "service descriptors".
• Where this makes sense, parameter values SHOULD have DALI types.
• When deployed in the LSST Science Platform context, the URL SHALL fit in the pathname space under (LSP-instance-FQDN) / portal/. The implementation SHOULD provide the flexibility to allow it to be deployed in a variety of ways in IPAC's own archives.
• The interface SHALL have a service_uri=(URI) parameter to allow the specification of a TAP service to be used.
• The interface SHALL be designed to accommodate a service_id=(IVOAiid) parameter to allow the specification of a TAP service to be used, via Registry query to translate the name to a physical service endpoint. It SHOULD be an error to specify both service_id and service_uri. The interface MAY be released without an implementation of service_id.
• When deployed in the LSST Science Platform context, when neither service_uri or service_id is specified, the interface SHALL default to the instance-local TAP service under (LSP-instance-FQDN) / api/tap/. The interface SHALL provide for an application-level configuration parameter override to this default. (This would be used, e.g., if a new TAP service is being tested, or a fallback to an old one is needed during integration tests.)
• The interface SHOULD permit a non-LSST-LSP deployment to set a default service. If provided, the configuration mechanism for this SHALL permit the use of a URI to set the default. In addition, if this mechanism is provided AND the service_id parameter is implemented, the mechanism SHALL allow an IVOA-id to be used to set the default (with registry lookup performed at run time).
• The interface SHALL have a table=(table-name) parameter which specifies a fully qualified ADQL table name. Invocation with table and the specification of a service (possibly defaulted) SHALL be sufficient to bring up the query UI for the named table.
• The interface SHALL permit invocation without a table specification. In the absence of any other (optional) parameters, this SHALL bring up the standard "top level" schema-and-table-selection view of the UI.
• The interface SHOULD have a means of initializing the target-selection field of the Spatial Search component of the UI. It SHOULD support specification by name and by astronomical coordinates, but the latter are a slightly higher priority. Please consult Gregory Dubois-Felsmann for more discussion of an appropriate parameter interface for this capability. The spirit of this, at least, would be to use DALI parameters drawn from those in the SIAv2 specification. This capability is specifically intended for use with DataLink, to permit a search to be launched with ease from a row in a previous search result.

The "SHALL" specifications above are sufficient for the initial release of this capability.