FW: [swe.wg] confusion on SWE optional components

10 views
Skip to first unread message

Alexander Birger

unread,
Jul 2, 2013, 2:13:04 PM7/2/13
to ioos...@googlegroups.com, iooste...@googlegroups.com

FYI, I think that Dr. Botts’ message below is a pretty interesting reading, although the requirements are not fully relevant for IOOS Milestone 1.0 as we mostly stick to versions 1.x of everything at the moment. However, as soon as we start switching to versions 2.x, we should seriously consider those “three-tiered” requirements.

 

Alex Birger
Systems Engineer

Skjei Telecom

7777 Leesburg Pike, Suite 315N
Falls Church, VA 22043

Direct:   +1 703 917 9889

Main:    +1 703 917 4077

Fax:       +1 703 917 0098
e-mail: alex....@skjeitelecom.com

My availability: http://www.timebridge.com/mytime/alexanderbirger

 

CONFIDENTIALITY NOTICE: For intended Skjei Telecom recipients only.

 

From: SWE.WG [mailto:swe.wg-bounces+alexander.birger=noaa...@lists.opengeospatial.org] On Behalf Of Mike Botts
Sent: Tuesday, July 02, 2013 12:06 PM
To: Sam Bolling; SWE SWE WG
Subject: Re: [swe.wg] confusion on SWE optional components

 

Fellow SWErs.

 

I spoke with Sam Bolling about his questions on what was optional to support within SWE services and what was required. Sam is involved in helping define a SWE profile for the US DoD and IC so having a clear understanding of this and being able to decide which options to include in the profile are of course important to him. I can see where the confusion of Sam and probably others can arise concerning this aspect of our services. The Requirements Class divisions have allowed us to be more clear about optional implementation capabilities, but we have perhaps not been as clear on what these imply; that is, without requiring someone to read the policy document:

 

OGC® Policy Standard, The Specification Model - A Standard for Modular specifications, Version 1.0.0, OGC document 08-131r3

 

I believe my answers to Sam were correct but I need for you to look over them and confirm that they are correct and that this is how the specifications were supported in the documents. 

 

The "compliance" or Requirements Classes are the main and only (?) breakdown of what is required and what is optional for a service to support. These Requirements Classes are listed as separate sections in the document and each provides its own set of individual requirements that you must implement in order to comply to that particular Requirements Class. 

 

One (or more?) of these Requirements Classes is required by ALL SOS or SPS services and the others are optional. Perhaps I missed it but I don't see statement about whether any particular Requirements Class is required by ALL SOS implementations. By assumption, "Core" is a required class for all implementations. Is it only the "Core" Requirements Class that is required by all SOS or SPS implementations while all other Requirements Classes are optional?

 

So what I told Sam is at least for SOS, that the Core Requirements Class must be implemented in its fullest by all SOS services. The other Requirements Classes are extensions/optional. I also stated to Sam that once someone chooses to implement a particular Requirements Class that they must implement ALL individual requirements stated within that Class. In other words, there are no optional requirements within a Requirements Class.

 

As noted in some of the Tables that Sam provided from the spec documents, there ARE optional properties within particular requests, responses, and filters that a particular client can choose to not use, but these request or filter parameters must still be supported by the service if they are defined within a support Requirements Class. Is that correct?

 

Sooo …, regarding what is required and what is optional within a particular SWE service implementation or profile is really three-tiered:

 

1. The Core Requirements Class is required of all services. Other Requirements Classes unless explicitly stated otherwise, are optional.

 

2. Once one decides to implement (or include in a profile) a particular optional Requirements Class, then ALL requirements defined within that particular Requirements Class must be implemented.

 

3. WIthin a particular Requirements Class, there may be required and optional properties within a Request, Filter, or Response (?) but these shall be explicitly stated as such within the models and encoding rules of the Request, Filter, or Response (e.g. within the model or encodings multiplicity statement 0..1, 0..*, 1..*, 1, etc.).

 

Thanks.

Mike Botts

 

 

*****************************************

Dr. Mike Botts

Botts Innovative Research, Inc.

 

*****************************************

 

 

 

On Jul 1, 2013, at 4:18 PM, "Bolling, Sam" <SBol...@RiversideResearch.org> wrote:



Mike,

 

Retrying to send to .com!

 

Respectfully,

 

Sam Bolling

Member of the Professional Staff

<image001.png>

Riverside Research | 1400 Key Blvd. 12th Flr. | Arlington VA, 22201

 

From: Bolling, Sam 
Sent: Wednesday, June 26, 2013 5:42 PM
To: Michael Botts
Subject: confusion on SWE optional components

 

Good evening, Dr. Botts.

 

Thank you for returning my call, and I’m sorry for missing it.  I have been reading some of the responses to my inquiry that I posed to the OGC SWE users mailing list.  They have provided examples and clues, but I am still struggling with a particular implementation dilemma.  I was wondering if you could help me get to the bottom of a question I have been trying to resolve, regarding the SWE web services:

 

Which parameters described within the specifications are to be considered optional to the server?  Or perhaps more importantly, where can I find the explanation within the specifications that explains which parameters are optional for server implementers?

 

Below is an example that is giving me trouble:  interpreting whether a server implementer can choose to opt out of implementing the parameters used as filters for the GetObservation request or not.  If so, a server could be compliant without supporting the ability to handle GetObservation requests from clients that include filters.  If not, a client can rely on all SOS servers to support the inclusion of filters in GetObservation requests.

 

In the OGC Web Services Common Specification OGC 06-121r3, I found a table that does a really good job at explaining which parameters used as filters a server must support for the GetCapabilities request, which are optional, and how it should behave accordingly:

 

<image003.jpg>

 

In the SOS 2.0 Specification OGC 12-006, a similar table is listed for GetObservation requests:

 

<image005.jpg>

<image007.jpg>

 

The difference is that the table referenced from OGC 06-121r3 details the implementation of the parameters, and the table referenced from OGC 12-006 details the properties of a request (I have been unable to discern the difference).  Thus far, it appears that an “implementation of parameters” table does not exist for many of the operations for the SOS or SPS.

 

It appears that two of the filters for the GetObservation request are covered by requirements 14 and 16 in the GetCapabilities chapter of OGC 12-006; however, the other filters do not seem to have associated guidance (it is also unclear to me at this point if requirements 14 and 16 apply to both the GetObservation and GetFeatureOfInterest operations, or just the GetObservation operation).

 

<image012.jpg>

<image014.jpg>

 

Another clue to the mystery can be found in the DescribeSensor operation request chapter of the OpenGIS SWE Service Model OGC 09-001.  Requirement 35 states:

 

<image017.jpg>

 

This leads me to believe that a server can opt out of implementing, and thus supporting, filters described by the specifications, unless mandated by a requirement.  However, this is the only case where diligence in the SWE web service standards seems to be applied to parameters used as filters for operation requests; which could mean it only applies where it appears in this manner.

 

I apologize for the long winded email.  After I resolve this for myself and my team, I would like to share the results with our extended audience of users & implementers, as well as back to the SWE Users mailing list.  Thank you in advance for your consideration and time, sir.

 

Respectfully,

 

Sam Bolling

Member of the Professional Staff

 

Riverside Research | 1400 Key Blvd. 12th Flr. | Arlington VA, 22201

 

 

-----Original Message-----

Sent: Thursday, June 20, 2013 12:00 PM

Subject: SWE.Users Digest, Vol 10, Issue 2

 

Send SWE.Users mailing list submissions to

 

To subscribe or unsubscribe via the World Wide Web, visit

or, via email, send a message with subject or body 'help' to

 

You can reach the person managing the list at

 

When replying, please edit your Subject line so it is more specific than "Re: Contents of SWE.Users digest..."

 

 

Today's Topics:

 

   1. Re: server specific optional components of SWE (Alexander Birger)

 

 

----------------------------------------------------------------------

 

Message: 1

Date: Wed, 19 Jun 2013 12:53:20 -0400

From: "Alexander Birger" <alexande...@noaa.gov>

To: "'Bolling, Sam'" <SBol...@RiversideResearch.org>,

Cc: "'Rennemann, Travis'" <Travis.R...@QinetiQ-NA.com>, "'Hood,

      Ryan'" <rh...@RiversideResearch.org>, "'Mohan,  Jill'"

      <JMo...@scitor.com>, "'Henson,      Cory'" <che...@RiversideResearch.org>,

      "'Johnson,  Kylie'" <kjoh...@RiversideResearch.org>, "'Heidt,    Chris'"

      <Chris...@QinetiQ-NA.com>, "'Cooley,   William'"

      <wco...@RiversideResearch.org>, "'Kosey, Dan'" <Dan....@macb.com>,

      "'Adams, Wendy'" <Wendy...@macb.com>

Subject: Re: [SWE.Users] server specific optional components of SWE

Content-Type: text/plain; charset="us-ascii"

 

Hello Sam,

 

 

 

You may also want to take a look at the U.S. IOOS site

(http://www.ioos.noaa.gov/data/welcome.html) for the information on implementing SOS and SWE as a part of the IOOS Data Management and Communication (DMAC) system capable of delivering in-situ and remotely-sensed data for physical, chemical and biological observations as well as model outputs. U.S. IOOS Program Office works with its Regional and Federal IOOS partners to deploy SOS, SensorML and SWECommon to make data and products discoverable and accessible, and to provide essential metadata regarding information sources, methods and quality.

 

 

 

Regards,

 

 

 

Alex Birger

Systems Engineer

 

 

 

Skjei Telecom

 

7777 Leesburg Pike, Suite 315N

Falls Church, VA 22043

 

Direct:   +1 703 917 9889

 

Main:    +1 703 917 4077

 

Fax:       +1 703 917 0098

 

 

 

 

CONFIDENTIALITY NOTICE: For intended Skjei Telecom recipients only.

 

 

 

] On Behalf Of Bolling, Sam

Sent: Wednesday, June 19, 2013 8:14 AM

Cc: Rennemann, Travis; Hood, Ryan; Mohan, Jill; Henson, Cory; Johnson, Kylie; Heidt, Chris; Cooley, William; Kosey, Dan; Adams, Wendy

Subject: [SWE.Users] server specific optional components of SWE

 

 

 

Hello, SWE Users.

 

 

 

I am relatively new to standards-based software development, and am working on a profile of the SWE web services, Sensor Observation Service (SOS) and Sensor Planning Service (SPS), for a particular community of users.  I am having a bit of difficulty determining exactly what parts within the specifications are optional to an implementer of a server implementation.

Is there a resource that clarifies which components, such as operations and parameters, that a server implementer may elect to not support?

 

 

 

Respectfully,

 

 

 

Sam Bolling

 

Member of the Professional Staff

 

 

Office: 703.908.2114 | Cell: 703.203.5281 | F: 703.524.0025

 

 

 

Riverside Research | 1400 Key Blvd. 12th Flr. | Arlington VA, 22201

 

 

 

-------------- next part --------------

An HTML attachment was scrubbed...

-------------- next part --------------

A non-text attachment was scrubbed...

Name: not available

Type: image/png

Size: 239 bytes

Desc: not available

 

------------------------------

 

_______________________________________________

SWE.Users mailing list

 

 

End of SWE.Users Digest, Vol 10, Issue 2

****************************************

 

ATT00169.txt
Reply all
Reply to author
Forward
0 new messages