CWIC Start OpenSearch prototype January 28 th 2014 Calin Duma CWIC and GCMD OpenSearch Implementations

Agenda CWIC Start OpenSearch prototype High Level Goals of OpenSearch implementations High Level Phased approach to common implementations Phase I differences and issues 2

CWIC Start OpenSearch Prototype Developed to test GCMD and CWIC OpenSearch implementation progress – Web application using Ruby on Rails – User end goal is to view and/or download granule and/or browse data and metadata, accomplished in 3 steps 1.Search for datasets of interest using searchTerms and AOI and TOI 2.Search for granules in a dataset of interest using datasetId (identified in step 1) and AOI and TOI 3.View or download * browse data, granule data and granule metadata – Current implementation is used for testing CWIC and GCMD OpenSearch integration and individual implementations Uncoordinated and coordinated changes in CWIC and GCMD OpenSearch might break the prototype – Pre-release notifications with clear description and coordination of changes are needed even in the prototype phase 3

High Level Goals Seamless integration of CWIC and GCMD OpenSearch implementation:  Take advantage of developing CWIC OpenSearch from scratch while interacting with a working GCMD prototype  Use CSW and CWIC Start as a baseline for understanding the integration requirements and challenges  Address some of the issues encountered during the CSW implementation  Document the issues that cannot be addressed due to granule provider limitations or complexity/priority/budget 4

High Level Approach Phase I Phase I (current) Client interacts with GCMD and CWIC OpenSearch separately through distinct OpenSearch endpoints and corresponding handling of requests and responses Establish a common CWIC approach to namespaces, request parameter names and uniform / consistent responses among all CWIC data providers (test suite?) Establish a common GCMD and CWIC approach to namespaces, request parameter names and response contents Phased CWIC implementation of OpenSearch for data providers Identify the communications, knowledge sharing, issue tracking and coordinated releases approach 5

High Level Approach – Phase II  Phase II Client still uses distinct OpenSearch endpoints but switches to common handling of requests and responses CWIC finalizes support for OpenSearch for all data providers GCMD starts work on providing granule search URLs in their OpenSearch implementation by generating dataset specific OSDDs with prepopulated CWIC granule search URLs * GCMD and CWIC start collaboration on a shared testing approach given the tighter integration requirements CWIC Start OpenSearch client supports GCMD efforts by starting incorporation of a single OpenSearch endpoint in the web application 6

High Level Approach – Phase III  Phase III: CWIC Start OpenSearch uses a single/configured GCMD OpenSearch endpoint for all requests and responses Interactions with CWIC OpenSearch are transparent to CWIC Start OpenSearch and driven entirely by GCMD * CWIC Start OpenSearch client starts prototyping with automatically generated User Interface based on GCMD root and dataset specific OSDDs * CWIC Start OpenSearch client finalizes styling and UI experience 7

Phase I differences and issues 1  Namespaces: Almost there: – GCMD just changed opensearch to openSearch, we should keep opensearch unless there is a compelling reason to change  Error Handling:  Do not use status line 200 OK for errors (GCMD action item Q6 and Q10)  Pagination:  Doug will add best practice about supporting startPage and count and remove support for startIndex, which can be confusing  GCMD and CWIC will notify group when individual implementations are tested and ready to deploy  GCMD might consider DEV and TEST environments similar to CWIC for deploying changes before PROD  ClientId is required:  CWIC Start clientId is cwicstart_(dev|test|prod)_opensearch  GCMD and CWIC should require clientId and collect metrics based on it  GCMD and CWIC will notify group when clientId is ready to deploy 8

Phase I differences and issues 2  Contents:  Handling of optional response fields:  Removing non-compliant elements  GCMD: time:start, time:end, geo:box in favor or dc:date and georss:box (others?)  Correct / consistent formatting of the response: 9 GCMD PortalOpenSearch Response EntryId: SHADOZ_TAHITI Temporal Coverage Start Date: T00:00:00Z T00:00:00Z T00:00:00Z/T00:00:00Z EntryId: USGS_GFOI_Fiji No temporal coverage No temporal coverage and no corresponding XML in the ATOM response GCMD PortalOpenSearch Response EntryId: c4emas Summary at: GCMDGCMD Seems like inconsistent summaries are returned Summary 1: Summary 2:

Phase I differences and issues 3  Request Semantics:  TOI search:  GCMD: in controlled test GCMD does not return matches for timeStart+timeEnd, only returns matches for timeStart with no timeEnd  AOI search:  GCMD: returns error if decimals are present in the geoBox request parameter  Response correctness  AOI and TOI: we never concluded the investigation of GCMD CSW TOI and AOI based response correctness, we did find anomalies in the GCMD CSW TOI responses  GCMD should created test suites to validate response correctness for AOI and TOI  CWIC could state that they rely on correct provider behavior and therefore it is the provider’s responsibilities 10

Summary  Continue to work together on Phase I  CWIC and GCMD should continue to add functionality, correct existing issues AND document new issues identified during their individual testing efforts  Such issues should be provided to the current GCMD, CWIC and CWIC Start teams  Coordination among the three teams will not work without a professional issue tracking tool  JIRA should be used if available, Archie’s Bugzilla will also work, I created a github repo that we can use for issue tracking ( ) if needed 11