Difference between revisions of "ServiceValidation"

From Earth Science Information Partners (ESIP)
(Created page with " == Service Validation == Point of contact name (i.e., author name): Ruth Duerr === Goal === Determine whether or not my OpenSearch service or casts are compliant with some ve...")
 
(Reverted edits by 88.190.13.201 (talk) to last revision by Cwhite)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
 
== Service Validation ==
 
== Service Validation ==
  
Line 14: Line 13:
 
=== Actors ===
 
=== Actors ===
  
User - primary actor, someone with a service or cast they wish to verify
+
*User - primary actor, someone with a service or cast they wish to verify
ESIP testbed portal - the version of the Esri Geoportal Server that has been installed on the ESIP testbed and configured to be able to validate an OpenSearch service or cast
+
*ESIP testbed portal - the version of the Esri Geoportal Server that has been installed on the ESIP testbed and configured to be able to validate an OpenSearch service or cast
URL - the URL of the OpenSearch service or cast to be validated
+
*URL - the URL of the OpenSearch service or cast to be validated
  
 
=== Preconditions ===
 
=== Preconditions ===
Line 25: Line 24:
 
=== Triggers ===
 
=== Triggers ===
  
Here we describe in detail the event or events that brings about the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or when a set of conditions are met, List all triggers and relationships.
+
This use case is triggered when the user decides to activate it by going to the ESIP testbed portal and selecting one of the options for validating OpenSearch servers or cast endpoints.
  
 
=== Basic Flow ===
 
=== Basic Flow ===
  
Often referred to as the primary scenario or course of events. In the basic flow we describe the flow that would be followed if the use case where to follow its main plot from start to end. Error states or alternate states that might be highlighted are not included here. This gives any browser of the document a quick view of how the system will work. Here the flow can be documented as a list, a conversation or as a story.(as much as required)
+
# User points their browser to the ESIP testbed portal
 +
# User selects one of the validation options.  The options available include:
 +
## To validate a cast URL
 +
## To validate an OpenSearch server
 +
# User selects from a list the version of the ESIP specification to validate against (at this point I expect the list will include ESIP 1.0 and 1.1 specs)
 +
# If a cast is being validated
 +
## The user is asked by the portal to enter the URL of the cast
 +
## The user enters the URL of the cast and clicks the Validate button
 +
## The ESIP testbed portal, retrieves the cast at the URL entered and validates it against the selected specification
 +
## The ESIP testbed portal, summarizes the results of the validation, including
 +
### whether the URL passed or failed
 +
### which types of cast entries (collection, service, data granule, and/or events) were detected in the cast
 +
## If the URL passed validation, the user is asked whether they would like the cast to be added to the ESIP testbed portal aggregation of known ESIP-compliant casts
 +
## If the user says yes, then the cast URL is added to the aggregation (note this could either be to update the Esri geoPortal or a copy of the NSIDC aggregator or both - what does ESIP want to do?)
 +
# If an OpenSearch server is being validated
 +
## The user is requested to enter the URL of the OpenSearch Description Document (OSDD)
 +
## The ESIP testbed portal, retrieves and attempts to validate the OSDD
 +
## If validation is successful, the ESIP testbed portal
 +
### formulates a ESIP-compliant query to the service endpoint indicated in the OSDD
 +
### attempts to validate the response to the query submitted
 +
##The ESIP testbed portal summarizes the results of the validation, including
 +
### whether the OSDD was compliant
 +
### whether the query returned properly
 +
### whether the query results were compliant
 +
## If the OpenSearch server passed all tests, the user is asked whether they would like to add the server to the ESIP testbed portal list of known OpenSearch servers
 +
## If the user says yes, then the server is added to the list
  
 
=== Alternate Flows ===
 
=== Alternate Flows ===
  
Here we give any alternate flows that might occur. May include flows that involve error conditions. Or flows that fall outside of the basic flow.
+
# If a cast fails validation, the ESIP testbed portal will also indicate what parts of the specification the cast failed to meet
 +
# If an OSDD fails validation, the ESIP testbed portal will also indicate what parts of the specification the OSDD failed to meet
 +
# If the OpenSearch server failed to return a response to the portal query, the ESIP testbed portal will indicate that fact
 +
# If the response of the OpenSearch server failed validation, the ESIP testbed portal will indicate exactly what parts of the specification the server response failed to meet
  
 
=== Post Conditions ===
 
=== Post Conditions ===
  
Here we give any conditions that will be true of the state of the system after the use case has been completed.
+
After validation, the user will know whether or not their cast or OpenSearch service is ESIP compliant and if not, exactly what the problem is
  
 
=== Activity Diagram ===
 
=== Activity Diagram ===
  
Here a diagram is given to show the flow of events that surrounds the use case. It might be that text is a more useful way of describing the use case. However often a picture speaks a 1000 words
+
OK - so no diagram so far. Is one needed for this use case?
  
 
=== Notes ===
 
=== Notes ===
 +
Out of the box, the Esri Geoportal Server provides a mechanism for [http://sourceforge.net/apps/mediawiki/geoportal/index.php?title=How_to_Publish_Resources validating XML documents against a requisite XML schema].  The Geoportal can also [http://sourceforge.net/apps/mediawiki/geoportal/index.php?title=Customize_Metadata_Validation validate against an XSD or Schematron document].
 +
 +
* The development here would be to 1) identify schemas by which the geoportal can validate a cast/OpenSearch document, 2) configure the geoportal to use those schemas, and 3) ensure that casts/documents that don't validate have a helpful error message indicating the issues.
 +
 +
* Resources that are retrievable at a cast/document endpoint can be validated separately (e.g., a cast/document can be compliant even if the resources it advertises are not).
 +
 +
The Esri Geoportal Server has two interfaces for checking validity.
 +
 +
* The first is to validate the document itself - looks like this:
 +
[[File:validatemockup0.png]]
 +
 +
* The second is used to register the endpoint in a federated search list - with some changes could look like this:
 +
[[File:validatemockup1.png]]
 +
 +
Federated search to these endpoints is described more fully in the [[Query aggregated data and services]] use case.
  
There is always some piece of information that is required that has no other place to go. This is the place for that information.
+
----
 +
Back to [[Discovery Testbed Work Plan]]

Latest revision as of 21:49, September 4, 2012

Service Validation

Point of contact name (i.e., author name): Ruth Duerr

Goal

Determine whether or not my OpenSearch service or casts are compliant with some version of the ESIP discovery protocol.

Summary

I, someone whose organization is trying to develop an OpenSearch server or cast generator that wishes to be compliant with some version of the ESIP discovery protocols, use the ESIP testbed to test whether or not my service or cast actually is compliant.

Actors

  • User - primary actor, someone with a service or cast they wish to verify
  • ESIP testbed portal - the version of the Esri Geoportal Server that has been installed on the ESIP testbed and configured to be able to validate an OpenSearch service or cast
  • URL - the URL of the OpenSearch service or cast to be validated

Preconditions

The ESIP testbed portal is up and running and has been configured to accept a range of ESIP specifications that it can validate against. There is a publicly accessible URL for the service or cast to be validated.

Triggers

This use case is triggered when the user decides to activate it by going to the ESIP testbed portal and selecting one of the options for validating OpenSearch servers or cast endpoints.

Basic Flow

  1. User points their browser to the ESIP testbed portal
  2. User selects one of the validation options. The options available include:
    1. To validate a cast URL
    2. To validate an OpenSearch server
  3. User selects from a list the version of the ESIP specification to validate against (at this point I expect the list will include ESIP 1.0 and 1.1 specs)
  4. If a cast is being validated
    1. The user is asked by the portal to enter the URL of the cast
    2. The user enters the URL of the cast and clicks the Validate button
    3. The ESIP testbed portal, retrieves the cast at the URL entered and validates it against the selected specification
    4. The ESIP testbed portal, summarizes the results of the validation, including
      1. whether the URL passed or failed
      2. which types of cast entries (collection, service, data granule, and/or events) were detected in the cast
    5. If the URL passed validation, the user is asked whether they would like the cast to be added to the ESIP testbed portal aggregation of known ESIP-compliant casts
    6. If the user says yes, then the cast URL is added to the aggregation (note this could either be to update the Esri geoPortal or a copy of the NSIDC aggregator or both - what does ESIP want to do?)
  5. If an OpenSearch server is being validated
    1. The user is requested to enter the URL of the OpenSearch Description Document (OSDD)
    2. The ESIP testbed portal, retrieves and attempts to validate the OSDD
    3. If validation is successful, the ESIP testbed portal
      1. formulates a ESIP-compliant query to the service endpoint indicated in the OSDD
      2. attempts to validate the response to the query submitted
    4. The ESIP testbed portal summarizes the results of the validation, including
      1. whether the OSDD was compliant
      2. whether the query returned properly
      3. whether the query results were compliant
    5. If the OpenSearch server passed all tests, the user is asked whether they would like to add the server to the ESIP testbed portal list of known OpenSearch servers
    6. If the user says yes, then the server is added to the list

Alternate Flows

  1. If a cast fails validation, the ESIP testbed portal will also indicate what parts of the specification the cast failed to meet
  2. If an OSDD fails validation, the ESIP testbed portal will also indicate what parts of the specification the OSDD failed to meet
  3. If the OpenSearch server failed to return a response to the portal query, the ESIP testbed portal will indicate that fact
  4. If the response of the OpenSearch server failed validation, the ESIP testbed portal will indicate exactly what parts of the specification the server response failed to meet

Post Conditions

After validation, the user will know whether or not their cast or OpenSearch service is ESIP compliant and if not, exactly what the problem is

Activity Diagram

OK - so no diagram so far. Is one needed for this use case?

Notes

Out of the box, the Esri Geoportal Server provides a mechanism for validating XML documents against a requisite XML schema. The Geoportal can also validate against an XSD or Schematron document.

  • The development here would be to 1) identify schemas by which the geoportal can validate a cast/OpenSearch document, 2) configure the geoportal to use those schemas, and 3) ensure that casts/documents that don't validate have a helpful error message indicating the issues.
  • Resources that are retrievable at a cast/document endpoint can be validated separately (e.g., a cast/document can be compliant even if the resources it advertises are not).

The Esri Geoportal Server has two interfaces for checking validity.

  • The first is to validate the document itself - looks like this:

Validatemockup0.png

  • The second is used to register the endpoint in a federated search list - with some changes could look like this:

Validatemockup1.png

Federated search to these endpoints is described more fully in the Query aggregated data and services use case.


Back to Discovery Testbed Work Plan