[Requests] Comments on PubSub

Stefan Schliebner stefan.schliebner at vermkv.rlp.de
Tue Oct 20 22:09:03 EDT 2015


PART A


1. Evaluator:
Stefan Schliebner, von-Kuhl-Straße 49
56070 Koblenz / Germany
Telefon 0049-261 492-452
Telefax 0049-261 492-492
stefan.schliebner at vermkv.rlp.de  

2. Submission: OGC 13-131, OGC® Publish/Subscribe Interface Standard 1.0 - Core



PART B

SRS 01
1. Requirement: [General] 
2. Implementation Specification Section number: General
3. Criticality: Major
4. Comments/justifications for changes:
An WMS-example: At time t0 updated raster tiles of a WMS let requests later then
t0 get them as response when these evaluate to true regarding the filter
criteria.
How does the pubsub-sender gets aware of a publication/a message that has to be
sended („newly published message“)? OK, the updated raster tiles fulfil filter
criteria but that does not explain the awareness of „newly published messages“.
There has to be something that creates publications/messages. I don't know how
this is done e.g. by a WMS. There has to exist something that „knows“ what is
already published to a subscriber.


SRS 02:
1. Requirement 21
2. Implementation Specification Section number 8.3.4 Exceptions
3. Criticality: Editorial
4. Comments/justifications for changes:
Table 9 Subscribe Exceptions
„The DeliveryMethod identifier is not unknown to this Publisher.“ is wrong.
„not“ is too much.
An exception is missing: What if deliveryLocation of the request cannot be
reached? Suggestion: Why not a test-reach?

SRS 03:
1. Requirement: -
2. Implementation Specification Section number 8.5 Renew
3. Criticality: Minor
4. Comments/justifications for changes:
With „Renew“ one single aspect of a subscription -the time-instant- can be
changed. Why not allow other aspects to be changed like e.g. deliveryLocation?
O.k., one could terminate one Subscription and create another but a
subscriptionChange may be useful nethertheless. The derivedSubscription (14.1)
just allows to change the filter criteria as far as I understood.

SRS 04:
1. Requirement 31
2. Implementation Specification Section number 8.2 GetSubscription Operation
3. Criticality: Major
4. Comments/justifications for changes:
GetSubscriptionRequest seens to me very dangerous. One can get all active
subscriptions with all deliveryLocations ... OK, security aspects are out of
scope but I prefer just to allow to deliver informations about the subscriptions
that the owner of the request owns himself.

SRS 05:
1. Requirement 34
2. Implementation Specification Section number 10.1 Pause Operation
3. Criticality: Major
4. Comments/justifications for changes:
Pause and Resume operations force Publishers to keep a history of deliveries
(see 10.2.1). Huge datasets can be the result of that. A Publisher should be
able to calculate if the amount of „historic“ deliveries that have to be kept
until the „Resume“ operation is acceptable or not, and reject the pause. This by
the assumption that the theoretically latest instant of time when Resume occurs
is the terminationTime of the subscription. Same thing about batching (req 46).


SRS 06: Lorenzo, that were nice sunglasses You weared at Nottingham ;-)
Lots of greetings
Stefan

Mit freundlichen Grüßen
Im Auftrag
gez.
Stefan Schliebner

--
Stefan Schliebner
Fachbereichsleiter

LANDESAMT FÜR VERMESSUNG UND GEOBASISINFORMATION RHEINLAND-PFALZ

Von-Kuhl-Straße 49
56070 Koblenz
Telefon 0261 492-452
Telefax 0261 492-492
stefan.schliebner at vermkv.rlp.de
www.lvermgeo.rlp.de


More information about the Requests mailing list