[Esip-discovery] Datacasting custom elements proposal

[Lynnes, Christopher S. (GSFC-6102)]

On Mar 21, 2011, at 12:31 PM, Ruth Duerr wrote:

> This can't be limited to datacasting.  Whatever mechanism we all end up agreeing on must be the same for both datacasting and OpenSearch.  To be precise, the response to a parameterless OpenSearch query should be identical to a datacast for the same data.
> 
> Ruth

OK, in that case, I don't see any convergence imminent.  Deviating from the currently prevalent method of extending OpenSearch (i.e., elements) is a non-starter for extending the federated search.  However, if we define customElements as those elements not rising to the level of standardization as an Extension, we have a possible compromise:

(1) Define "Extensions" as specific additional elements proposed to the ESIP Discovery cluster for either query (for FedSearch) and/or response (FedSearch and *Casting)
(2) Define "Custom Elements" as additional elements that are used by "Special Arrangement" (to borrow from the GEOSS lexicon) between client and server.  
(3) "Extensions" in the Response shall consist of XML tags, accompanied by XML Schema to describe programmatically the type and valids of the tags.
(4) "Custom Elements" in the Response may use either attributes and/or tag contents to encode information.  Custom Elements shall be identified by the tag: <esipdiscovery:customElementAttr>.  Custom Elements using tag contents shall be identified as <esipdiscovery:customElementContent>.  Note that tag contents may themselves include XML elements (i.e., in a hierarchy).  Since mutual understanding depends on the Special Arrangement between client and server anyway, different servers may implement their own Custom Elements in different ways.  

Note that in a "compromise", nobody gets everything they want...So, have at it...
--
Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185