[Esip-discovery] Datacasting custom elements proposal

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

If this is limited to datacasting, then I will happily butt out (again).  However, there may be downsides to forking the response standard.

My main concern w.r.t. OpenSearch responses is that the currently established mechanism for OpenSearch extension is to use XML elements for new response features, not attributes.  

Also, I'm not sure how you handle enumerated data types in the attribute scheme.  Can you elaborate?

On Mar 19, 2011, at 4:57 AM, Mccleese, Sean W (388A) wrote:

> Chris,
> 
> No problem! A great sample case is illustrated in one of the live Datacasting RSS feeds that has been implemented at PO.DAAC for GHRSST AMSR-E (http://ghrsst.jpl.nasa.gov/datacasting/AMSRE-L2P-gen.xml).
> 
> Basically, the example problem scenario is: PO.DAAC is casting out data granules for GHRSST AMSR-E. And, obviously, these data granules  have metadata that is specific to that particular platform such as, for example, "Max. deviation from previous day SST". PO.DAAC defines this metadata within the RSS channel items in the following way:
> 
> <datacasting:customEltDef units="Kelvin" displayName="Max. deviation from previous day SST" type="float" name="MaxDT_Analysis"/>
> 
> and then, in the GHRSST AMSR-E feed, it's used in an item as follows:
> 
> <datacasting:customElement name="MinDT_Analysis" value="0.00000"/>
> 
> This enables a Feed Reader to parse the "MaxDT_Analysis" tag with knowledge of the data type (floating point, in this case) as well as present some information to the user about the physical quantity being measured. In the GHRSST AMSR-E feed, this is done along with 10 or so other "custom metadata elements".
> 
> So the situation I'm proposing is one where each data provider may have metadata that is specific to the particular granules or data feeds they are casting out which are not known ahead of time by the particular Feed Reader or by ESIP. One can even envision a situation where Datacasting feeds are generated automatically as responses from OpenSearch or whatever and, in that case, the custom metadata may be specific to that particular query (though I would note this has never been implemented).
> 
> I do not think this *has* to be limited to datacasting, though for now I am only proposing it as a datacasting standard simply because that's how we've implemented it up until now.
> ________________________________________
> From: Lynnes, Christopher S. (GSFC-6102) [christopher.s.lynnes at nasa.gov]
> Sent: Friday, March 18, 2011 11:49 AM
> To: Mccleese, Sean W (388A)
> Cc: Mattmann, Chris A (388J); Hua, Hook (388C); esip-discovery at lists.esipfed.org
> Subject: Re: [Esip-discovery] Datacasting custom elements proposal
> 
> Sean,
>  Perhaps I need to take walk through a sample case to fully comprehend what you are proposing.  For instance, we are likely to propose a DayNightFlag as an ESIP extension to the main OpenSearch spec.  We also want to convey the fact that it can take only one of four values: "Day", "Night", "Day+Night", "N/A".
>  If we extend OpenSearch the way the OpenSearch folks have been extending their standard, we would add elements (cf. the Response section of the OpenSearch Geo Extension).  i.e., <esipdiscovery:daynightflag>Day</esipdiscovery:daynightflag>. Then we would use <xsd:enumeration> elements in the schema to communicate the four valid values.
>  How would that look in your attribute scheme?
>  Or are you just suggesting the attribute method for custom elements that are *not* proposed in their own right as ESIP extensions?  That is, custom elements that are strictly application-dependent?
>  Or are you suggesting this method only for datacasting and not for OpenSearch responses?

Christopher Lynnes     
Goddard Earth Sciences Data and Information Center, NASA/GSFC
301-614-5185