[Esip-discovery] revisions to Discovery RFC

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

I got a batch of excellent comments from Yoshi Kudo that I have attempted to address in:
https://docs.google.com/document/d/1ymt5vsP2jw2YMVnc2B8uEI0BKTHcT4jSNVQzruLIFPA/edit

Yoshi, I hope you don't mind my echoing them here.  I think they are important to put the changes I have made into context.

Note that I have made some bold statements :-) in some cases to address the comments in areas that we never discussed before.  I would like to use this RFC as the opportunity to come to agreement on them.  However, if that is not possible at this point for some, I will extract them with a "deferred" note and defer to later discussion.

> 1) So the spec expects the use from scientists rather than IT folks in
> terms of building a client (chap.6)? Will they be able to build a client
> that can deal with 2 step search ? 

Revamped the end of section 6 and start of section 7 to scope back what we might expect scientists to be able to do.

> 2) In 7.2.4, last paragraph seems to be cut off.

This is now section 7.2.5:  added the note: "Note that the Dataset Query Engine, File Query Engine and OpenSearch Description Document may reside on different hosts. Thus this scheme not only supports a highly distributed system of data and search resources, but also admits for the possibility of cooperative or third-party search services."

> 3) In 7.2.3 about GeoRSS, whereas GeoRSS-Simple seems to be mandatory, GML
>    is also allowed to be used. How can a client expect which is going
>    to returned ?

Added clarification that client should always expect a GeoRSS-Simple bounding box if a spatial element is in the response.  Other elements may or may not be there.

> 4) In 7.1.2, the term "datacasting" is still hard to understand for me.

Added several sentences to try to clarify this (in my own mind as well!)

> 5) I personally want to stress the importance of freetext {searchTerms}
> . Does ESIP have any thoughts or recommendation regarding this
> searchTerm ?

Added section 7.2.2 to expand on this.

> 6) In terms of "understandable and comprehensive"-ness, I would like to
> see more clear appearence of what is requirement and what is option. You
> could use bold "Requirement" headings, or put together requirements into
> a table.

Added optional or required everywhere it seemed to make sense. It shows up in both section headers, where it is prominent, and as bold text within the text.

> 7) Compliance test suite may be useful.

Added a note to Implementations chapter that we are going to do this once we settle on the RFC.

> 8) I'd like to see how {searchTerms} should look like when dealing with AND/OR/NOT with
> multiple words.  My client is now talking to a number of OpenSearch servers but each has
> a different rule on this.

Good one!  Here's one of my bold statements:  
Boolean AND is assumed as default for multiple search terms, and servers are expected to support it.  (Hmmm...better go see if Mirador does...)  

Boolean OR and NOT are not yet part of the specification, requiring later discussion. (Support for these has to be either required or not-specified; there seems no way to make it optional and then advertise that capability to the client.)
--
Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185