 Mark. Mark, are you there? Yes, I'm here. Just had a hard time finding the mute button. Sorry. I just want to make sure that you can actually hear me. Yep. Sounds good. Oh, the other mark. Hey, Mark. I think Sarah made a mention that she can't make it. So hopefully at least Clemens can make it since it's really his PRs that we're kind of talking about. So let's give him a few minutes. Hey, Stanley. Morning. Afternoon. Thank you. Good evening for all our, for everyone else. Yeah. I wonder if somebody does that on a call. The first thing that went through my mind is just say hello. I'll cover it. I really like pink Clemens. See who's going to make it because I think he said he was going to make it. So we'll say, let me share my screen. So I had to leave early yesterday. Did any of you other guys stay on for the rest of the call? Yeah, I'm, I know I was there and I think Mark peak was there as well. Do you want to summarize what happened at the end? I know, I think what I heard you guys did make it through the other two points in PR 117. I guess talking about middleware and framework. What happened after you left that PR? What were the topics that were discussed? I'd be curious to hear kind of like Kathy and, and or Clemens and or Sarah's take on what was discussed, but it, it kind of felt like we devolved again, like things went off the rails a little bit. What was the, well, what was the supposed subject? Request and Mark, do you have anything comparable to So I was, I wasn't on the call yesterday morning. Oh, you weren't. Sorry. I popped on to the one on Monday, but not yesterday. Well, Stanley for 117, do you think there was general agreement on that call yesterday about its direction. And it was things only derailed once you left 117 or was it within 117 that things kind of weird. So we were talking about, sorry, I'm trying to dig down to where the points actually wound up. So you, you were there for points. One and two, you said, right, and then for three and four, we were going to continue on. Yeah, because I, yeah, well one and two were mainly the first day, which I guess is Monday, then yesterday I left, I think halfway through number three or something like that, if I remember correctly. No, I think we actually we did make some progress in the The assumption was we were going to so Clemens and or anyone else interested was going to write a separate action related to a right a separate issue related to clarifying middleware. That was really kind of where the things started to fall apart was middleware can be, you know, message brokers, it can be, you know, API gateways, it can be any number of things and part of the problem were you here for this by the way Doug, or had you left by that point when we started this discussion. Yeah. So I think I left when I remember it with one but either way like my in in kind of sitting through the discussion it felt like we were kind of mixing and matching use cases. And it's, it drives some of the confusion when we say middleware, I think, um, that there are so many things we're trying to consolidate until like this one statement. So there was a probably like there will likely be a separate issue filed to kind of clarify the different, you know, use cases and different potential implementations of what middleware will actually look like in the world, because it was driving you know, from an IOT perspective right like versus using message pack versus like a Kafka perspective using just, you know, schema, like obviously like validated, you know, messages say like the Avro or whatever it is. Right. Um, the idea just generally was that and then let me see. So, Clemens joined the call now so hey Clemens. I was just asking for status on where we left off yesterday since I had to drop early. Hi, dog. This is Kathy. Hey Kathy. Yeah. So I think you know we, we were in number kind of number three. You know, the could just screw up on we talk about the yeah I think I just follow up on the on the on the middle where I think we would always said we agree we will add some example there, like because you know, I don't know who was speaking before. Is it come to stand. Okay, so I think we were saying, you know, yeah, this middle where it's a very generic terminology would like more clarification that it could be some this definition of the middle where it looks like it could be, you know, a service platform, it could be a router and it could be many other things. So we're like, at least give some example. Okay, but it sounds like, but it sounds like from what Stanley was saying that that may be something that we can do in a follow on poor request, right? In the following, you mean in a separate document. No, no, in a in a in another poor request after this one. Oh, okay. Okay. Oh, another poor request. Okay. Yeah, just just so we can make some forward progress. Okay. But it's so hey Clemens. You there. Clemens, I think you're on mute if you're talking. Oh yes, I am. There we go. Hi, sorry, I was held up by technology. Not a problem. So we're just trying to figure out where you guys left off yesterday and what the next steps are based upon where you guys left things. So my understanding is we were through. There were also comments that were filed on this stock on this part of the document. We left and then I addressed them all. So I think we're my understanding is we're done with this. And then we have, we veered into a discussion of one of the items because someone asked like what the namespace stories about. So we talked about that a little bit. But what that might mean, we don't have a, we might do a clarification. I think what that ends is that we're going to do a clarification of the of the meaning of the field or probably have a discussion about that separately. And then I think that's where we were. Okay. So it sounds like 117 is kind of behind us and that we're moving on to a particular attribute whether it's namespace or one of the other ones right. Yeah, so I think I think the namespace is one where it's for me, it's it's a nice to have it's not so central. Okay. So would it be then wiser to talk about a different attributes that we can get hopefully quicker agreement on. Yeah, so I would like to talk about plus 95. Okay, what other people think about number 95 but I believe because that talks about that talks about specifically about changes to the properties source source ID source type and renames them. Right. And this is topic and subject. Right. Yes. Yesterday we were, you know, discussing what's a relation between the namespace, the classification and the subject right in the. Yeah. And the namespace, the namespace, I want to keep that out because the namespace is basically just giving out or framing to all those concepts. But I don't think you can really talk, argue about namespace unless the inside of it is clear. So which means the topic of the subject is cool. I would like to table the namespace discussion and talk about topic and subject first and then we can go and decide whether we actually need the namespace. Right. Okay, so what do people think? Is it okay? Or do people agree with the next step being to look at this PR and talk about topic and subject? Is that sound okay to people? Or is there some other attribute that seems like it should be of a higher priority? I think it's fine with me. But at a high level I would like to understand, you know, what's the relation between, you know, what we discussed the other PR, which, you know, mentions classification and subject. So that's what we're, that's exactly what we're here for. This one does that. Okay. Okay, so I heard Kathy speaking. Is there anybody else on the call who thinks there's something that's a higher priority? Otherwise we're going to keep hitting on this path. Okay. Not hearing anything. Go ahead and let me know where you want me to scroll to, Clemens. I assume. This is fine. Okay. Can we get a raw view of this? What do you mean? The complete view of it without the changes. The new one? Clemens, can I make a suggestion? Before we dive into details of, you know, on this, can you first give like a high level of, you know, maybe you have a hierarchy, you know, on relationship between these terminologies. I don't know. Just give us an idea of what you have in mind. I know that we can dive into detail of each field. Yeah, so that's why I actually pointed yesterday at the end of the call to issue 117, I think, or 112, which is a five pager that discusses all this. So I'm going to give you the short version of it. Okay, that's good. So there's a ration. So the rationale for introducing topic and subject is really anchored in the reality of the middleware landscape as it exists. More than my own creativity. So I'm just standing on the shoulder of a whole group of giants here who have been figuring this out for a long time ago. So I'm basically just introducing and reintroducing that concept into our space here that where that is also already been heavily used for event distribution. So topic. So it's a two stage. It's a two stage model. And that is very common. As I explain in that issue. There is ample precedent in existing infrastructures for having both variations of both of those fields that are always called that. But there's typically this two stage classification. So from a higher level perspective. The topic is a convention depth that ultimately from if you look at it from really high up. It's a convention that's the producer and the consumer arrive at for classifying events or classifying messages. So that the consumer has a reasonable way to go and select those messages. So I have a few examples here that are shown in the topic section. So let's go and pick. So the US city example actually pick right out of the IBM MQ specification where the and or actually IBM MQ documentation for the for topics and topic trees. Where you have it and you can go and read this and I can probably go and also get food notes if anybody's interested. But that kind of gives a topology classification of events based on US cities and they're grouped by country, state and city. And then you have a sheet component above that. That's something that you would find not necessarily in this nice format. It's a little bit more convoluted in OPC way, which is an automation standard where you have a robot. The robot has a number of drives, the third drive of the third drive. You want to know the temperature. So you have a logical path into that robot towards that drive. Then you might have a resource path and it's just just very generic. That's what most of the services that we run and most other people have. There's a graph of resources that exists and you drive you have a path through that resource graph. That's the top, the top example. That you're mapping and you are expressing as a consumer expressing interest as for events or messages related to that particular resource path. And then we can go through and, you know, for all of these examples, the theme is the same. There's some kind of a resource graph. Sometimes it's a tree. Sometimes it's a little more, sometimes it's more complicated. But you're typically cutting a path through this and this is how you are finding your resources or subjects. And you are registering interest in stuff that comes out of those contexts. Sometimes that context is a little bit larger. So I'm interested in, for instance, everything that that robot gives me. And sometimes that is a little bit narrower. Like I want to have everything that drive three emits from that robot example. And sometimes it's even more narrow. And I want to have a particular, the particular temperature reading only from that robot. So the topic, the topic is in the first place a convention that is being agreed upon, if you will, by producers, but producer crop population and a consumer population. It sometimes will precisely define the originator. But in more cases, it will define a more abstract concept like a, like a categorization. And even in the case of what I just showed you at the robot. The drive you're interested in in the temperature interest in of that drive, you don't actually mean the drive per se, like you don't care about that thing with a serial number. But if a technician goes goes there and exchanges the drive, which means the physical parts and puts another physical part in there, you will now still care about the drive as an abstract thing that you're watching, rather than, you know, the thing with the serial number. So it's a bit, it's a higher level abstraction model typically than, than having a concrete center that you care about. The reason why this topic concept is so successful everywhere is that it provides that level of abstraction that everybody can go and map their, their various contexts to. So you send, you send messages that are belonging to a topic into an infrastructure, and that infrastructure will allow then others subscribers to go and pick messages for that topic. Now, topic is still a fairly coarse, coarse grained grouping. So if you want to then further distinguish messages and more events that are coming out of that topic, which means let's say you want to have all the events that are occurring in the lighting system and the streetlight system of Juno in Alaska, then you will probably want to be a little bit more informed and filter a little bit more. What sort of what kind of event you're looking at. And that's what the subject is for the subject. The topic is the thing you can go and subscribe on to say, I'm interested in events from this topic. The subject is the thing you will then further filter on or that will describe what this particular instance of events is about. So the topic is the course, the course grain thing that you subscribe for and then the subject tells you what this particular event event is about. That's what these two fields are. And they completely replace the prior notion. So topic is effectively a broader definition of what we previously had a source and then subject kind of collapses onto each other notion of subject type insert the subject ID, whereby I have still not understood what the subject ID stood for. Any questions. Yeah, if I'm understanding properly the Rob the robot drive case, you're suggesting that the temperature and depending on how the user wants to model this the topic could actually end with drives three and then the temperature could actually be the subject. Absolutely. Is there any guideline to how to make that distinction or based on usage. Yeah, so, so I can give you a little examples of those things. So the typical way how you would do this in an OPC away for instance, which has a pops up infrastructure that we just added, which is where I can kind of give you the exact exact model. OPC way creates a graph over a composite machine. So it would actually look like this where you have a robot but the robot then has an ID, etc. And that may have a collection of drives on the collection of drive the collection is then the collection of drives is obviously a little bit more, you know, specific than what I have here. It has an identifier that's logical for effective the slot where that sits, and you would put a an observer onto that drive, and then the observer will go and collect the information items you're interested in from that drive. You would compose a message, and that message would then contain all the items that you have so your topic would be the drive in that case because you're particularly interested in stuff that comes out of that drive. And then you would have a message that comes out of that that then carries, you know, temperature and vibration and all those things so the temperature might actually just be in the payload. It seems like this gets into middleware specific issues as well though for cases where you can actually subscribe with wildcards on a hierarchical topic. Yeah, and I think that Matt that actually that fits the case. So, but let's see the topic concept exists in Kafka, it exists in Azure event hubs exists in an event grid exists in Apache ActiveMQ exists in RabbitMQ exists in IBM MQ exists in Mosquito it exists in IBM Q it exists. I like, basically you can go through every pops up broker, whether they're event oriented or whether they're message oriented, where I count versus the MQTT brokers as event oriented. And every single one of them has at least the topic concept. Then there's this the second, the second question is how common is the subject concept. The subject concept is also and I have that in the, in that, in the issue that I filed. I have a bit of a survey, we can, can you pull that up. Pull what up. I have an issue I'm issued that's called goals and etc. and kind of very to the bottom of that I have a list. Okay, I have a question on this topic. I think in the messaging event source. It's, can you hear me. Yeah, I can. Sorry. Okay. Yeah, it's, yeah it's there but how about like for some other type of event source like for example storage. Hang on. Let's, let's, let's get to that to go to the very bottom. It's a doozy. Yes, there we go. So, so here's I actually went and so this entire write up is about almost nothing but topic and subject. And that's why I wrote it to declare to clarify what I mean. And also, but I, I felt it wasn't a long to put in along with that pull request it also predates the pull request. So, SMS as a subject. GCM has a title FCM has a title but they're effectively the same thing. Functionally, Kafka doesn't have a subject as a second level a second order field because it after is gives you effectively your indication about the messages outside of the partition ID and that's a design choice that they made. And GMS has custom properties in instead of a standard as subject fields IDMM queue has also custom properties instead of a standard subject field. And the IDMM queue a MQP binding obviously supports a MQP, the MQP subject field. And MQT also has no subject field per se but also they add custom properties in MQT D five so whether there's a subject field or not is kind of the the the messaging community is split on that but they're not split on with MQT being effectively the last straggler is having a custom property set that you can dispatch on the only outlier and that is Kafka. Would it be horrible if we went with just topic for now and then save the discussion of subject later. Yeah. I still feel where I mean this topic and this terminology is very is very geared towards a messaging event source eventing event event messaging what what is messaging what is eventing if it's not messaging. Like for example if like you know for like give example of S3 like AWS S3 or Huawei's OBS right it's a storage. That's your they have it doesn't have call doesn't have you know topic it has column which column you know it shows which column you know file is saved or is. So it's like a bucket. The way the way how you get how the way how you get at storage events in AWS is you either get the press through SNS or you get them through the what's it called clouds trace not cloud trace watch. Yeah cloud watch I always forget the names. Their stuff is their stuff is always names of complicated and I can never never remember the container stuff. So, so you always get at those events through messaging system. No necessary actually you know, because sometimes you know the event consumer get that event directly from the storage. It doesn't message in system. It just how do you get that. So how do you get an event like this from from storage. You just register you know if there's a change right, you know, um. Yeah, and then you have an all of a sudden now you have a pops up you have a pops up middle where maybe. Okay, so sometimes it's like there's a, there's a push or pull model you just pull it, and then you get those information then the thing that you're interested in for a storage is a bucket. So thankfully, so thankfully, I actually went and did that exact case so go back to that to the to the issue. Who upstairs. Because. Yeah, no. Marks like to sharing his screen. I actually have to drop in a sec so Mark's going to continue sharing and sort of moderating the meeting. If possible, when the meeting's over, can someone write into the agenda doc. The minutes from today and where you guys left off so people can understand what was discussed. Okay, thank you guys very much. I'll see you guys tomorrow, but I need to drop right now. Okay, bye. My concern is I'm not sure whether you know we use topic and subject on. Let me explain that to you. Example, example, go go go up a little bit in that document. Further up further up. Okay, so this is an event as we have it in our is an alert. Okay, so this is an application insights app application inserts operational alert this has nothing to do with the messaging system. Right. It's, it's giving you an alarm, because the disc read was less than. So it's a slow disk. So what I'm doing in this example, I mean the fact that you're evolving this into a compliant cloud events event. So if you just scroll scroll down, I do the step wise so I can go in and tell you all the steps. The first, I'm taking that that event and I'm sticking that into a, I'm sticking it into a container if you can make this a little bit bigger. Okay, so now I'm effectively taking the event that I got and put that into the data field of that event that's the first step that I do. The first step is I'm now saying what that event that I just put into that container is I put the content type was is Jason. I'm going to give you the schema URL which points to the schema to the our actual schema for that event. So these are the first two steps. Then I go and give it an event ID. That's the literal event ID that I'm just pulling up from that event. So it's I'm using the event ID as the event gave it to me, and I also pull out the event time. Next, the event has a type and explain what that what the type is effectively. Every event so this is a second discriminator that I really don't want to talk about at this moment, but that tells you effectively what what kind of event that is within the topics let's scroll up let's skip this. And then now I'm picking now I'm picking a topic and picking a topic basically here means that I'm now picking from a few candidates. Right. What I think what the right resource type is and I'll make a discussion so for your storage for your storage problem. Right. So the topic really is the storage account and in that storage account of folder. So we would model. So in our world we would model this as subscriptions good resource groups my resource group provider storage account name slash folder. And then we had the topic name for for a storage account because we have a global resource graph in Microsoft and the global and in Azure and that global resource graph, you can go and cut a path right to a storage account and the folder in that storage account and that's what that would be. And that's kind of what I lay out here. So here in specifically I pick the the fully qualified path to the specific resource that's how I picked the top. So the topic is what you what you're what you're interested in right in a course grain fashion. So this could be a storage account. It could be a VM. It could be like all all of our 200 services that we have in Azure. Every single one of them has a recent is mapped into this resource graph and you basically pick a pick a place in that resource graph that can go in the middle that that is the model that we have. If you go down there's then a notion of a and I'm mapping in the subject. Because I need to know, for instance, in that context, exactly what is that event about so here in this case. And I wrote this down the alert and I'm subscribing for alerts from a particular VM. But or sorry, I'm actually from a from a VM slot, a runtime slot for a classic compute is instance. But I'm now getting an event that is about that resource and the subject is telling me exactly what machine in what slot is actually causing that alarm. So I'm interested in general in all the events that are flowing out of the the VM host. The event host is composed of multiple slots. In which maybe multiple roles. And so I want to catch all of those. And so I'm getting the information about which exact slot and which exact role this is about in the subject field. That's the mapping that I did for something that has nothing to do with an eventing system, but really is a real example and then if you scroll down, I did the same thing for AWS cloud trail. Where I did I take a cloud trail event as it is, and then did this containment mapping thing here as well. The same same principle, but took a, and I use this, I don't use substitute source for topic I literally use the source term as the for the top for the topic field. So here, the topic is. So this is about easy to it's about easy to Amazon AWS US East to and that's my easy to slot. The subject is the in the particular instance. It's the event type is soft instances or the instances that stopped so that's easy I can understand that without having to parse anything extra. And I took from software AG from velocity from an IT platform. A simple event, and that's the door sensor was triggered and not that in the exact same way. Again, I have the source source here is much simpler in the scope of the system because it's literally just an object. That's what they have they have named and numbered objects in the scope of their system. So that's what the topic would be. The event type is the sense that the door sensor event, and I don't even need to have a subject in this case. So the subject is something that's optional so I mapped this all out. Because that's just how messaging systems use those fields the subject is something that you sometimes need and sometimes don't because you sometimes need to have a further qualification that you can go in this patch on. In some instances, whether the context is smaller you don't in instances where the context is larger you do. And topic is the general model for how you map the resource graph effectively, or the topic graph in general a graph that you are interested in subscribing on to. So I think my. You talked early on about having. See if I can find it. So being able to pick a topic. You discussed here. Yeah. And then when you, when you were talking about the AWS use case, you said that the topic was just a source. Here. Right. And so how do you see the. As you as you're talking about wanting a topic attribute. How do you see that actually mapping. Are you just changing the name. I mean, where you have source there are you really saying we should be using the term that the keyword topic. Yeah, so this is, well, we actually wait. So I, and not only that changed the name I also changed the definition. So I've been using source here, because this, this, this issue predates my PR for changing the name to topic. That's the only reason. I wanted to refer to a term in the spec. Right. And that's why, but, but I think so source doesn't make sense to me as a term. Because in, in current in, in contemporary pub sub usage, as well as most of the eventing system that I've been confronted with the real source plays much of a role than the context you care about. And if you if the, the, the messaging protocol, like for instance, aim to pee as a messaging protocol has no notion of from with good reason because the problem is that data, where data comes from turns out to be enormously complicated. Typically applications there's an application at the application layer above that you have a fairly complicated complicated notion of data provenance with because that is if you build sophisticated systems, because that includes the, the identity under which the process runs, it might include the person who was operating that terminal. It might include someone who gave permit second permission for that particular operation. I mean it's, it's provenance is really, really complicated. And that's why most of the generic infrastructure folks just punt on that problem and just and punt that up to the app. Hey, Clemens, can I ask a clarifying question because I think if I understand this I actually really like the distinction here. Um, so the idea if I had a really like I'm going to create a really simple metaphor here like if I have to deliver a letter to you, and I can't reach you. I'm going to hand it to Mark and Mark is going to hand it to Kathy and Kathy is going to hand it to you. Ultimately the topic of that letter has never changed, but what presents some source of confusion is the source field because the source field when Clemens receives the message is Kathy, though actually there's a chain of sources along the way, which actually have nothing to do with the content or metadata related to the, you know, the message being the envelope that to be delivered to Clemens. So the idea of a topic here ultimately is a client to me a much more clear statement of as a consumer, you know, you are receiving some amount of information you don't care how it got to you. Right, you really care about the topic of what it is what what's it describes is that kind of what you're going for here. That is that is exactly what it is. So if you are care. So, so what you, you always need to look at this from the consumer perspective. You're, if you're interested in football results, right, as a real time delivered event driven thing. You never care about who typed in the football results, like at all. What you don't care about is the football results, which means you will be interested in a league, and you may be interested in the team, and then you may be interested in a game. But how that data was captured and how that data goes put into the system you don't care. And that's something that is doesn't matter and most use cases, most real use cases that we see are just like that where this actual number of events matters very little, but the context from which those events were sent or on on whose behalf that those events were sent is what matters and that's typically directly reflected in the topic. So if we can go and switch back to the to the actual PR it will be helpful. Yeah, so I think that's to take that I actually really like this distinction quite a bit on my question for you actually in some of the examples you've listed like we have like robots slash drive. I think what you're and correct me if I'm wrong here is robot and identifier because I so I have a little bit of confusion here right like USA Alaska Juno is very clearly country state city right like it's very US specific like that wouldn't look for something like Japan right where it'd be like country prefecture right like something along those lines on to really what you have here is it's robots slash robot ID slash drives right slash yeah slash temperature right so that's where my little bit confusion in here where you know if I were thinking about Kathy's example which is let's say like a you know I put an object into an S3 bucket. Really what that looks like is slash namespace slash namespace ID slash bucket slash bucket ID slash objects and maybe the subject is the file path of the you're you're exactly right so and that's the distinction that's the distinction that is really that really matters here. Sure, so the only thing I'd ask is maybe to clarify a little bit like as a consumer if I care about all of the events related to robot with robot ID. I'm going to just basically match on anything that's slash robots slash robot ID slash star right. I'm going to clarify that. But that's what that's the only thing I was going to say. There are identifiers versus like you are I like generic you are I said yeah. I'll clarify that Stanley when you stated that you you commented that namespace should be part of the topic. Was that like the more logical so whether the like the actual literal namespace right that indicates like if I were to go look at you know I want to go hit a describe API for slash namespaces slash namespace ID. Right I think that's what Clements is trying to say these are like not not generic or these are not abstract URIs these are actually concrete URIs. Yes, so there will be well they can be whatever you like whatever you want in this one I'm I'm composing a concrete URI for my example. Correct yes and that's what you would typically do. So you would typically go and have in a so as they say in patent speak in an embodiment of this. I will have a some kind of a structured identifier a URI that will this is why I think did I read this in here I think it should be a URI and I and I write this should be a URI specifically because I'm keen on having the structure the structuring qualities of URI in here and so and if we relative or absolute URI but I want to have the the structure qualities of your eyes. So you will have a yeah we'll have some the event will be about some context this the context can typically be expressed in some form of graph. And or being a location in some graph and that's true for all the things that are listed in here and the example that you did you just listed because the buckets clearly is part of the resource graph of AWS. You can go and formulate a path through that graph that hit that leads you to that particular bucket. In some other in all the existing eventing infrastructure that you that you will find or most existing eventing infrastructure that you will find effectively all the everybody who built something on an off the shelf open source message message broker or on top of Kafka will find a concept that maps to this. You pick a topic string topic string the topic string originates from a context in your application and typically based on some kind of an object that is in your context path. And that's what you're choosing and we have inside of that context that you're choosing which may be bigger or smaller. You're going to have another uri potentially a sub path, if you will, that then pinpoints the the thing that the event is about and that's how the split is between topic and subject. You will be interested in all the events that are coming out of that bucket. You want to learn about all the files that have just been created, because you want to go and download the jpegs, and you want to go and then turn them into thumbnails. So that's one of our canonical examples right you you're looking at a bucket. And now you want to be informed as soon as an object is created. And then you need to learn what that path is of that object. And that's what the subject is. And the reason why you need help from the middleware of this is that bucket may be large and you may be getting hundreds of requests but you're really only interested in the ones that have the suffix dot JPG. And to do this, you need to give the middleware a generic hint what to look for and the subject field is one that you can do a longest prefix match on or you can go and do a suffix match on and you can do all kinds of matching on. And that's why the subject field as one of effectively as a promoted as a field that holds data that's promoted from the event is super useful. So this is purely for the benefit of the middleware to enable filtering on a on a portion of the contents of the event. So Clemens so so if I understand you correctly so you are so this topic is subject is for the to assist the communication between the subscriber and the no between the what's that producer event producer and even consumer for for the consumer to get the needed information right is that for that purpose. Yeah, so it's for it's for the consumer to be able to pick a subset of the events that they're interested in. Okay, so it's not asking the existing event source to change their name, or, or to add a new field in their event record, you know, add a new topic field or subject field in their record. What the publisher, the producer will affect the report that they will. So think of it as a rendezvous model. Right, where you have some place that sits in the middle between between the producer and the consumer. That is, and that can also be a piece that lives with the producer where you have the ability to go and send, send messages to a path. And then, and that's what the topic really is. And then you can go and subscribe, you can subscribe to on that path. You either subscribe to something that's further down in the path and you get fewer messages, or you can go and subscribe to the roots of that path and you get all the messages. Okay, so basically, so for the from the producer, the producer, the even producer itself does not need to change any of its record, any of its event form, I mean format to add a topic field, you're not suggesting that right. But what you saw in the example, what you saw in the example that I that I that I gave that's in the item. The process that I'm suggesting even for people who to adopt cloud events is containment that you don't change any of your of your existing data searchers at all. But you take the existing data records as you have them you stuff them into the data field of a cloud event wrapper. You take the cloud and then you take fields from your existing event and just and promote them out into the cloud event wrapper. That's exactly the process that I've been been doing. So, if you look, if you look at an example again. So look at the here, here it is. So if you scroll up once. If you scroll down, that exact AWS event is verbatim contained in the data field unchanged. So all code that depends on the structure of that event will continue to work. And all I did is I took select field select data out of that data field and promoted it up into the event into the cloud event structure. So the that source field, how do you how do you compose that from the original content. Yeah. Now, how am I asking how do you actually compose. So I took, I took the, I took the here the The event source with the data center. Can we just say, can we use the term topic instead. Yeah, that's, yeah, exactly. So it's a topic. So what I took, I took from the, from the data, and this data is obviously just a log record from, from, from AWS. I took the their generic field event source, which is the EC2 system. It's really the source. It's like the system level EC2, I took the data center and then took the account ID, and that made a reasonably an identifier that I think if I was designing that at AWS and map that into a an event flow. That's how I would design that I would say, subscribe on on EC2 on this data center and in the data center on this particular instance slot. I actually, I'm not sure whether that's actually true for that particular for cloud trail, but I think what might be useful is if you could set up a set of examples that, you know, takes a AWS is three records, you know, Azure records, just a set of different sources and compose these headers that you show here as examples. I know you've done a couple of them, but I think it would be useful if you actually use the term topic and subject that you have here. And, you know, add a few more examples so people can kind of get a big appreciation of what you're proposing here. What I'm a little worried about is that so far, even though this document has been around for three weeks, nobody has looked at it apparently. I think that that probably shows, you know, because now we have a very generic way of, you know, like topic subject, right. So, and so when you send, for example, as a consumer, if I sense, I mean, a request say I need this topic and subject with that event that producer knows what that means what. So, so how could I say okay if I need this information I'm interested in a topic or subject. Then the consumer need to understand what, you know, and that meant what that means right so that need to be well defined otherwise because there are so many different scenarios. I'm just thinking, you know, how can you show, you know, people like to use this and then to be compliant with this we can really use. So the problem I'm so the problem I'm trying to I'm facing is that there's a body of work that has been done in the messaging field realized in countless products that are have all converged on this notion. And I'm having a hard time. I'm having a hard time basically communicating the industry consensus in the messaging and eventing space that already exists. On the particular topic of having a topic with an amount of examples. Because the reality is that what we're doing in the messaging space as we're building that infrastructure is that we don't take a stance on what the structure of these topics ought to be because we intentionally leave that up to the application to go and decide how it wants to structure those things. And that turns out that turns out to be to be beneficial. So I actually intentionally don't want to be prescriptive about how that ought to be looking. Because I'm not sure that helps. So the example that I gave with the so all the examples for Azure. For instance, we'll look pretty much exactly alike. The one that I gave you that that I've worked out and specifically didn't take an event that originates from my org. We'll look exactly the same across all of the same services because we have a universal graph across the entire platform where we can identify effectively each context. And so the natural topic path for that we're using is the read effectively the resource ID for for that resource. So I can give you 100 examples but they will all look the same. Okay, maybe I think my question is, okay, for example, if I'm interested in something, how should I feel the topic. And so that the nose. Oh, okay, you feel a terminology for some some topic act. And then, and the producer knows what X means and then give me a problem. I'll tell you. Well, actually, I like the idea I think this was the request. So you've done a really awesome job Clemens kind of pulling a bunch of different examples and let's take like one thing like let's say like doing a put objects to s3 Azure object storage like Oracle object storage any of the object storage is across all the clouds right like to fire base even and just do the the mapping of that one specific use case and show how topic and subject. So I have actually have one in the if you go to if you go to the issues. I apologize I haven't read this. This is good to the issues list. And there's an HPP mapping strong in. Yeah, because that actually has one in 93. Okay. Unfortunately, I have to drop off for 10am. But I actually really love the topic subject consolidation. I would vote in favor of this. I need to drop it 10 as well. I'd say, if there's some way that we could conceptualize, you know, this discussion, be able to have like a short presentation tomorrow on the call to discuss. Here's our thinking on this and here's why we think it's the right direction. That would that would be awesome. Is that something that you could pull together? Yeah, I can, I can do that. Okay. Yeah. And, and so here and I'm actually going to adjust because I can go and edit things. I'm going to go and adjust because this also predates my PR. I'm going to edit this issue. I'm going to add the other ones to go and make a topic and then, but I would strongly encourage people to go and just write read the the bigger issue. And I wrote, there's a lot of write up and there's a lot of industry context in there with, you know, quotes from existing system or or links out actually to existing systems. There's resource collections. In fact, you show see how IBM IoT does it how Microsoft IoT does it, AWS IoT does it and basically illustrate that there's industry consensus around that around those concepts so I didn't invent those. I'm going to, I'm going to have a like two or three slides tomorrow to nail down that concept, probably with three, three to four pictures. Stay help. Yeah, that would be good. If you can give examples, say, you know, for a like just gave, you know, use as a, as example, if I need some information, how, how should I, how should the produce, I mean, the consumer feel that topic and subject. How will the producer understands that we need to define some something there for the different something there or it just by different. I don't know. This was, this was really great. Thanks everyone. Thanks. Thanks. Clemens. Are you there? Yes, I am. Yeah, so I have a further question on this. Yeah, it's good. It's good presentation. So for the issue of the correlation, correlation ID, right correlation token. So how, for example, if I, I'm interested in something for example, for I3 I'm interested in the information safety in which column of that storage right. That's what I'm interested so that I can go the topic and the subject right we can go into another level of detail in that column which file specifically I'm interested. In addition to that, I would like to know like I mentioned before, if there are multiple event sources, why is, you know, storage, but the other could be another event source could be, could be another like for example, some, let me think about it. Some notification, you know, event. Okay, it's not a storage. Okay, another notification event. But these two event might, might be, you know, all about use a burglary system. Okay, from the same house. I would like to know there's so many houses sending me all this information right I would like to know. Okay, which, you know, which storage event is, and which, you know, the simple messaging event these two events are coming from associate with the same house. How could I get that information I think we need a correlation token there. You know, I can give you I can give you an example of some real examples for that from some systems that we have built and how this is how this is working. I'll give you an example from, I'll give you an example from Halo from the game, the Xbox game. Do you know that? No, I do not know that the game. Okay. Do you play online games? Okay, not much. So, so, so those problems happen quite a bit that you need to go and correlate events that are happening from different places at the same time. Yeah, we need to correlate those events. Yeah. Yes. So the biggest the biggest problem is that you often can't tell the producer that the context in which they the events are being fired. So having having the producer go and do and give you the correlation information is often not helpful. Rather than, than doing that what typically it happens is that people use a some some middleware to go and create that correlation that happens in middleware systems like sometimes you do this with with stream analytics, where there's a temporal correlation, which means you take multiple events and and map them on top of each other, because they're temporally related and you only want to have a view over the temporal stream so use the stream analytics system for this. And sometimes you have the problem that you have multiple events from different places that need to come into one place and with and go and and seek for them separately through from with subscriptions from different systems, and then you concentrate on something like an actor system where the actor acts on behalf of the context you care about. So you have a house or something or room in a house, and then you have an actor that that acts on behalf of that. What happens in the industry right now is the concept of the digital twin and digital twins are basically these these these objects which are standing in for any arbitrary context and often they they are reflective of factory floors or particular and most of what they do is basically they go and concentrate events from from certain sources, they typically will not do that though based on a single identifier that everybody knows, but they rather will do this from from different from different organizations because also those many of those events are also emitted from legacy systems that don't know about any of those things so so setting up a correlation field per se that all the producers need to go and set is something that I don't see as common enough in in factual usage that I would put that into the standard, but it's obviously easy for you like if you say that's the way we want to go. It's obviously easy for you to put, you know, a correlation ID into every Huawei event which flows in through the cloud event infrastructure. But you really have something like that. I see you've got a thing called a resource group, and you talk about it's a scoping construct that would, you know, fence or group up a number of different resources that belong to a specific solution. Doesn't that mean what you're at we're talking about here we're really saying we want these resources to be identified as a group. And that would map that in that case that would then map to the topic concept. Yeah, so so no okay so you just mentioned I agree with you that the correlation. Ask every event producer to add a correlation ID there it's not we can that's one way of doing but might not you know every part event producer would like to do that right. Okay, so I think you know that's of course if you know the event source can put a correlation ID there that's good. Okay, that's I agree with you that's what we're doing but might not be you know everyone will follow that another way is I think you know in the event. So the eventually, for example, for that burglary system right assume that the motion detector and the door open detector when the information they send out. There will be some like how not house a house number something, you know, a unique identifier for that house, there will be a information inside inside those event message. You know just different vendors, for example, the sensor different sensor vendors and different you know video camera vendors they might put into, you know, different places we cannot force them to say you have to put, you know, this ID what it's called or where you should put it, it's hard to force everyone, but they must be there. So if we can have you know in the, I'm thinking you know if we can define a way to, you know, we do not know where it is put right, but the producer knows, for example, they if they put a house number or high IP address to identify that house. Okay, whatever, whatever that thing, they know where they put it right because their equipment put that, but if they let us know where they put it. So there is that information we can, you know, put into the specs say okay. So I have a proposal for you that information. I have a proposal for you because I think that that problem that you're just illustrating is is actually solvable within the scope of what we discussed today. Because, because you just talked about because you just you just you just actually led with the fact that there's a there's a structure. So there is houses, there's buildings you care about. And each house hasn't hasn't has a unique ID. But let's say you have, you have country organizations, each country organizations issues house IDs. Right. And so, and in these houses interesting stuff that you're interested in so you're making a topic in your infrastructure in the way infrastructure that is that that has a number slash a topic that is called slash d e slash one, which is my house. Okay, and all the all the all the objects that are sitting in my house that are talking with your system will now publish their events to that topic slash the slash one, which now gives you a perfect place where you can go pick up all those events, because you only need to go and subscribe to slash the slash one, and you're getting all the events from my house and then you can in the subject is then the identifier of the actual sensor that gives you the information. Yeah. That's what that's what so that's how that solves your problem, your problem is solved by creating a a broad scope that you can go and subscribe on and it would not be as simple as it would likely not be as simple as slash slash ID but something that's a little bit more sophisticated. Yeah, yeah, yeah, yeah, yeah, I think we are along the same, you know, so I think you know. So we were like safe. But the thing is that when I, when I. So, actually, it's not like, you know, on the produce the consumer will send a message to the, to the producer say, okay, give me this information. I would like to say, okay, let the consume, let the producer feeling a information of that pass say okay, what is, you know, the correlation token where my car, you know, the house number is located. I receive that message right on that. I can just go directly to search, you know, inside that big chunk of you know event data plus its metadata. I can just, you know, based on that, I can just extract that information for example, if it's a say okay, it's a, it's a house number. That's a, that's a house number is unique. So I can just search, you know, house address, I can just search house address and then I get the value. Of course, the value could be, you know, comments house, that could be, you know, Louis house address or Kansas house address, the value varies. But I know what string I need to search. I just search, you know, house address. Oh, that's unique. And then for another use case, it could be, you know, I don't know. Oh, some like travel request ID. So I search travel request ID. Of course, the value could all be different. Right. Different people make travel request. But at least, you know, the producer should give me, you know, because he knows the producer knows right, the producer put that, you know, that value, that unique correlation token value inside of the event data so he knows what is That's what I'm trying to tell graph to you. So the, the, you have a graph that represents all the buildings that you care about. Okay, so all that. So you have, you have, let's say you have countries, and you have in those countries you have building IDs. Okay, you are no interested in your solution from all events emitted from one building and you want to have them in real time. Right. That's what this is about here. Right. It's about getting at that information real fast and being able to get some targeted messages towards you. Right. Just as a, just as a, as a reference number. We currently do 1.5 trillion messages a day. Just in terms of events. So you have to be able to get to get to a few events very specifically. So you need to go able to filter on what you're looking for here. So what you're looking for here is a bit is the ability for 20 sensors which are in one house. Exactly. And to be correlated together. Exactly. You can get the events for all of those 20 with effectively from one pipe. Right. Yep. Okay. So that's what the topic, so topic model allows you to do this because all of your, all of your resources exist on a graph. The graph has the first level and our graph that we're just talking about has two levels. First level of the graph is countries. The second level of the graph is identifiers for individual houses. And if you are interested in your system and events that are coming from my house specifically, you walk up to the topic and you say, I'm interested in everything that comes out of Clemens house slash D e slash one. And that will give you and that will give you all the events for all the devices what you need to do on the producer side, which means in the devices, you need to go and configure them to say, you're going to publish all of your events on this topic. You are sending to slash D e slash one. And once they all do this, then you have that correlation automatically. So, so when I send that message from the. Okay, the top pick. Okay. Do I need to space it so you say, as a consumer, the consumer should know what is a correlation key. The consumer knows the consumer knows the context it's interested in. It knows that it wants events from that house. It doesn't. In the first level, it actually doesn't even care what devices are in that house. It just knows that it needs to observe everything that's in that house that wants to talk to it. Yes, also, okay, let me explain a little bit. Okay, the scenario different. Okay, so I'm a service platform. Okay. So for service platform, it's going to handle so many different events, so many different uses scenario, right. So why use the scenario is interested in the consumer, the burglar system, the house. Okay, but there are many other scenarios. So as a service platform. So I'm the service platform. I do not know whether I'm interested because I do not really. I'm not service platform is not the application developer. When I say application, I mean the burglary system. Okay, developer. I'm not super the system developer. I'm just a middleware platform that you know, receive the event I routed to your function to your application, the burglary detection function, right. So, so as a service platform, I do not know whether I'm interested in, you know, a house, or I'm interested in the travel request ID, I have no idea. Yes, but what you know, what you know is, is that someone can can publish to a to a path, and you can provide them with everything that matches certain prefix of that path. Exactly. Okay, so, okay, so I would need the application developer, which is a burglary detection function application developer. I need him to let to tell my service platform say, Oh, I'm interested in, you know, in this house. So let me know what he is interested in here. Okay, what's the correlation token, his application needs. What, what the, what the, what the, you have a, you have a, the topic is a path. And you're always interested in either that exact path or prefix of that path. That way, there's no, there's no correlation token. When I say correlation token, so, so let me, when I say correlation token, that token can be a path. Okay, good. Okay, I'm just using that as the, you know, what I need. Okay, I'm not saying there should be a specific, you know, correlation token field there, of course, if the producer putting that that's fine. But it's just a string that string could be a URL, who could be like in JSON format could be a path identifier. Okay. And so my, what I'm saying, what I'm saying is, and my battery is just about to die. So, I have to switch computers this morning. Okay. Is, and I have no power here. So I have to hang up the, what I'm saying is that your notion of a correlation token is exactly what I mean with top with topic. Okay, so, so that's good. So let's see just, okay, let me remember. So then I need the, the application developer, the function, you know, logic developer to tell the service platform say, Okay, I'm, you know, my, the correlation token, when I say correlation token, it just means, it means, okay, is a house, you know, is this, you know, pass to that house number, or is a URI, you know, to that, you know, or is a travel request ID. So that's why I need a field, I need someone, you know, to tell the, the service platform need the function developer tell it what he needs. And then I can just, you know, when I get the event data, I can extract, you know, that message based on the specification of that token, you know, it's travel ID or it's what, and then, you know, to extract the value, right. If you say it's a house, I'm going to try the house number, or house address. But as the middle, as the middleware, you are just doing, as the middleware, you can ignore all the, all the specifics. Yeah, whatever he tells me. Yeah, it's a string or it's just a string, it can be your ID or it can be a path identifier. So I would like to put this inside, you know, this spec so that, you know, the function developer knows, okay, he needs to specify this and then the, you know, the, what's that, of course, if the event producer put the correlation token as a key, that's good, that's okay, perfectly, perfectly fine. But I would like that to be in this. So let me, I will try to make that a little clearer for tomorrow. Yeah, yeah, so let's just say, you know, you can use a string or use URI, but, you know, correlation token is the meaning, is what it means. Otherwise, if we just say topic, you know, the function developer doesn't know what's that topic, what topic you need. But it turns out a lot of people know what a topic is. The topic has to be specific, right? There are many, many semantics of topic. So one of the topic will be a correlation token. That's my point. Yeah, you can say the topic will be other things you need. Yeah, I understand where you're coming from. And I think your notion of a correlation token is perfectly satisfied by the concept of the topic that we have. So besides URI, I think let's just say it could be a path that I can file, because sometimes it's in JSON format, let's extend that. Otherwise, if we just say it's a URI, you know, in some cases. URI is efficient. URI covers pretty much everything. Okay, URI is good, but we give some example. And then because most companies use it's JSON, yeah, let's just, yeah, use that. Okay, that's good. Maybe we can discuss a little bit further, have a sometime sorting this out. I mean, how to write this up. Yeah. Okay, very good. Hang up. Have a good day. You too. Thank you.