NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Stefan: One obvious case of service chaining that makes semantic sense to me at least is that of an FPS (Feature Portrayal Service), a WFS (as currently understood) and a WRS. The interaction is something as follows: 1. The client goes to the WRS and discovers a number of WFS as data sources. 2. The client also discovers an FPS. Note that an FPS exposes a WMS interface. 3. The client gets the schemas of the relevent WFS (the ones he/she wants) from the WFS or the WRS. 4. The client constructs an SLD and sends a request to the FPS (this is a WMS request). The SLD is =93filed=94 with the WRS. 5. The FPS uses the request to generate requests to each of the WFS referenced in the SLD. 6. The GML data returned to the FPS by the various WFS is styled to some presentation format (e.g. KML, SVG, JPEG) which is returned to the client to be rendered. The semantic distinctions are clear here. The FPS/WMS generates and provides presentations. The WFS participating provide data that is styled for presentaton by the FPS/WMS. The WRS supports the discovery of all of these services. Cheers Ron
-----Original Message----- From: stefan.falke@xxxxxxxxx [mailto:stefan.falke@xxxxxxxxx] On Behalf Of Stefan Falke Sent: May 10, 2007 11:46 AM To: Ron Lake Subject: Re: OGC Ottawa TC meeting highlights This is an enlightening thread. Removing the artificial distinctions between features and coverages and between the WFS, WCS, and SOS specs is key in understanding their relationships. I have to admit I'm one of the people John referred to as not fully understanding how "everything is a feature," but is seems that declaring one spec as the "front" to another, or that one is a "sub-type" of another brings these artificial distinctions back into the picture. I don't think absolute rules like this can be defined in relating the specs. As has been said by many in this thread, it comes down to your perspective whether one service sits in front or behind another. Simon's slides nicely depict a few use cases where multiple specs come into play (or don't come into play). It would be great if we could augment his start with other multi-spec cases driven by our respective implementation experiences. Exploring how specifications relate to one another in practice will help identify if and how the individual specifications need to be modified to support such relations. -Stefan
galeon archives: