Syntax for observedProperty in Capabilities

[GoogleCodeExporter]

Within the capabilities response in the observedProperty element should we 
allow/require both the fully qualified observedProperties and the unqualified 
form and does the SOS GET KVP syntax allow for both?  

Original issue reported on code.google.com by dpsnowde...@gmail.com on 7 Feb 2012 at 3:28

[GoogleCodeExporter]

My inclination is that we should require only the fully qualified form, and 
leave the decision whether to accept the unqualified forms as arguments up to 
the individual implementations.

There shouldn't be any problem specifying fully qualified observedProperties in 
GET requests, except for maybe a URL length limitation when selecting multiple 
observedProperties.

Original comment by sh...@axiomalaska.com on 3 May 2012 at 5:33

[GoogleCodeExporter]

To restate the question more clearly:
Should GetObservation GET requests be required to support observedProperty 
parameter arguments that are fully qualified.
The consensus is YES, a service provider must support fully qualified 
observedProperty arguments. It's up to the service provider whether to support 
unqualified arguments; it's a convenience to a subset of users that is 
encouraged, though it could lead to ambiguities in the long run.

Original comment by emilioma...@gmail.com on 20 Jun 2012 at 4:42

• Changed state: Done

[GoogleCodeExporter]

A SOS server should only support what it advertises in the GetCapabilities 
document.  We can say that an IOOS compliant SOS server will advertise and 
accept fully qualified observedProperty parameters.  Anything else is out of 
scope for us!

Original comment by wilcox.k...@gmail.com on 21 Jun 2012 at 2:47

[GoogleCodeExporter]

"A SOS server should only support what it advertises in the GetCapabilities 
document.  We can say that an IOOS compliant SOS server will advertise and 
accept fully qualified observedProperty parameters."

Yes, nice way to put it.

I still think a number of users -- specially regional ones that may rely on a 
single SOS service -- will find it very handy not to have to use fully 
qualified observedProperty parameters. But I agree that if a service is to 
provide those, they should be advertised in GetCapabilities, too. We don't have 
to do anything other than say that providing such convenience is not disallowed 
or discouraged.

Original comment by emilioma...@gmail.com on 21 Jun 2012 at 9:32