Difference between revisions of "DCP-5"

From Earth Science Information Partners (ESIP)
Line 50: Line 50:
 
* There are a proliferation of regex "flavors" - see http://www.regular-expressions.info/refflavors.html.  We should standardize on one of these flavors.
 
* There are a proliferation of regex "flavors" - see http://www.regular-expressions.info/refflavors.html.  We should standardize on one of these flavors.
 
** The HTML5 [http://www.w3.org/TR/html5/common-input-element-attributes.html#the-pattern-attribute specification uses] the [http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf ECMAScript flavor] of regex.  This seems a reasonable, standardized regex standard to implement as part of DCP-5.
 
** The HTML5 [http://www.w3.org/TR/html5/common-input-element-attributes.html#the-pattern-attribute specification uses] the [http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf ECMAScript flavor] of regex.  This seems a reasonable, standardized regex standard to implement as part of DCP-5.
 +
 +
* Having now looked at the OS Parameters extension, I wonder if it makes sense to piggyback on that. The good thing there is that
 +
for each search parameter there is a <parameters:Parameter> tag that contains multiple attributes.  One could add a 'pattern' attribute to contain the regular expression just as in the HTML <input> element.  Or put the pattern attribute in a namespace if we can't get the author of the Parameters extension to agree.
 +
 +
* My (small) objection to the current proposal is that putting the actual search parameter names as many new attributes in a <Query> tag seems kind of sketchy (risky?).  By having a separate tag for each one, there is always room for further extension using more attributes.
 +
  
 
== Consensus ==
 
== Consensus ==

Revision as of 18:56, June 7, 2012

<< Back to the Discovery Change Proposals page

DCP-5: Valids and restrictions for query elements

Progress

  1. Submitted on: 24 Apr 2012
  2. Review period: 24 Apr 2012 to 24 May 2012
  3. Revision: TBD
  4. Vote: http://www.doodle.com/rw4kg7w6yxc5yfdf - to end 2012-06-01, 12pm EDT. ish.
  5. Final review: TBD
  6. Ratified / Rejected: TBD


Description

Provide a mechanism to describe valid and invalid inputs for query elements in ESIP Discovery services.


Problem Addressed

OpenSearch does not have a mechanism for indicating valid options for search parameters. The OpenSearch Parameter extension (http://www.opensearch.org/Specifications/OpenSearch/Extensions/Parameter/1.0) has options for specifying the number of times a particular parameter may or should be included in the search request, but this does not meet our needs.


Proposed Solution

Add a validpatterns role to the OpenSearch <query> element, and specify valid values for attributes with a regular expression.

Example:

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
  <Url type="application/atom+xml" template="http://somedataprovider.com/?q={searchTerms}&datum={datum?}&gridSize={gridSize}&format=atom"/>
  <Query role="example" searchTerms="map" datum="WGS84" gridSize="1km" />
  <Query role="http://esipfed.org/ns/discovery/1.1/#validpatterns" searchTerms="WGS84|EGM96" gridSize="1m|10m|100m|500m|1km|10km" />
</OpenSearchDescription>


Rationale for the Solution


Discussions

  • Having now looked at the OS Parameters extension, I wonder if it makes sense to piggyback on that. The good thing there is that

for each search parameter there is a <parameters:Parameter> tag that contains multiple attributes. One could add a 'pattern' attribute to contain the regular expression just as in the HTML <input> element. Or put the pattern attribute in a namespace if we can't get the author of the Parameters extension to agree.

  • My (small) objection to the current proposal is that putting the actual search parameter names as many new attributes in a <Query> tag seems kind of sketchy (risky?). By having a separate tag for each one, there is always room for further extension using more attributes.


Consensus

TBD

Voting results

TBD