Stream: subscriptions
Topic: Topic Resource
Grahame Grieve (Nov 22 2019 at 09:30):
I see that thet Topic resource has not been formally proposed. I believe that the name will need some work - "Topic" is too board a subject, since it is only one kind of topic. "SubscriptionTopic" or something will be required for FMG to accept it
Lloyd McKenzie (Nov 22 2019 at 09:39):
Need to figure out if it will also be used to drive messaging independent of a subscription. If so, name will need to reflect that scope.
René Spronk (Nov 22 2019 at 11:25):
A name with "Event" in it would probably be appropriate..
Jenni Syed (Nov 22 2019 at 15:05):
I worry about "Event" as that seems to indicate that you're looking for a specific action rather that specific state changes/categories of things
Jenni Syed (Nov 22 2019 at 15:05):
I'm also not sure how I feel yet about using this to drive messaging. Haven't let that sink in yet
Jenni Syed (Nov 22 2019 at 15:05):
It definitely wasn't designed for that - it was designed for the larger pub/sub concept of a topic
Jenni Syed (Nov 22 2019 at 15:06):
(doesn't mean it can't change)
René Spronk (Nov 23 2019 at 10:20):
EventCategory or EventType or TriggerType (as a name) might do the trick. The thing is that "specific state changes/categories of things" may be a cause/trigger of many other actions, such as Subscriptions, Messages, or Tasks. There may be others we aren't even currently aware of.
Mohammad Jafari (Nov 26 2019 at 04:31):
From developers' perspective, Topic is a more common and familiar term for this concept (especially in the context of webhooks), so there is an advantage in keeping the term Topic –or something like SubscriptionTopic as grahame proposed above.
René Spronk (Nov 26 2019 at 05:27):
Hmm - likewise I could argue that the plain old "TriggerEvent" has been used in (HL7) messaging for decades and that it would "therefore" from an implementers perspective be the best name. But I'm not suggesting that in any way.
Naming things is difficult, especially if they're used for multiple purposes. You tend to end up with generic names that aren't really liked by any party involved, but still kind of indicate what we're talking about. It's called compromise..
First of all we'll have to determine (as Lloyds points out) if Topic (mainly aimed at a subscription scenario) is the same thing as trigger event (mainly used for messaging), and whether there are other similar use cases that could be grouped with these 2.
Grahame Grieve (Nov 26 2019 at 05:43):
I strongly endorse Topic for continuity with existing pub/sub language. Just needs a qualifying word added
John Moehrke (Nov 26 2019 at 14:27):
I agree with Topic. That is the term IHE uses in DSUB (not FHIR, but XDS). Would be nice to have Subscription use similar terms. Yes these become trigger events, but that is under the Given-When-Then-SoThat pattern of action.
Gino Canessa (Nov 26 2019 at 15:58):
So, SubscriptionTopic?
Lloyd McKenzie (Nov 26 2019 at 17:49):
Except that the use isn't necessarily limited to Subscription - we need to confirm the scope before we define the name
Gino Canessa (Nov 26 2019 at 18:01):
Knowing that it's likely each name will have a singular vote... :rolling_eyes:
Gino Canessa (Nov 26 2019 at 18:02):
/poll Topic Resource Name Should Be (please add proposals if you have them)
Topic
SubscriptionTopic
EventTopic
NotificationTopic
TriggerTopic
StateChangeTopic
Lloyd McKenzie (Nov 26 2019 at 18:35):
I could be ok with SubscriptionTopic - but only if we've confirmed that it won't be relevant elsewhere.
Grahame Grieve (Nov 26 2019 at 18:59):
I'm feeling particularly decisive today !
Last updated: Apr 12 2022 at 19:14 UTC
