Difference between revisions of "DCP-5"
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
- Submitted on: 24 Apr 2012
- Review period: 24 Apr 2012 to 24 May 2012
- Revision: TBD
- Vote: http://www.doodle.com/rw4kg7w6yxc5yfdf - to end 2012-06-01, 12pm EDT. ish.
- Final review: TBD
- Ratified / Rejected: TBD
- Facilitator: Ian Truslove (Ian Truslove (Truslove))
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
- Terse - a single parameter's options fit into a single attribute value.
- Well-understood - this is the same mechanism HTML5 uses for input field validation (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-pattern-attribute). Implementors will undoubtedly be familiar with this web technology.
- Powerful - regular expressions are a powerful pattern matching mechanism.
Discussions
- 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 specification uses the 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
TBD
Voting results
TBD