 Yes, do I dare Seems recording is on all of the time whenever somebody enters. Yeah, I think I think it kicks in by default. I Don't know if that's good or bad Hey, Kathy. Hi doc. Thank you. Me. Yes. I can hear you Hey Stanley, I assume it's morning for you, Doug Well, it's noon. So it's like right on the border. Oh I completely did not realize We're at Good evening, Raleigh. Good evening. Very firmly. Good evening. I like that Well, it's true. It's five o'clock It's just so you can everybody for like drink time That's exactly right Let's put it this way. You're not allowed to have a drink until we define source. How's that? And I would I would be super happy if that if that was the case. Yes No one in this working group is allowed Okay, well, then then I'm ready to have it defined within the hour. Let's do it. Yes five minutes Unfortunately, I actually need to drop at the bottom of the hour for the phone call. So I won't be able to join in the fun Okay, Sarah, I think is running a few late. I'm a little late Okay, so tell you what? Um, let me go ahead and share my screen Just we're all looking at the same thing. All right. Can you guys see that? like I have anything on that document so that It doesn't confuse that gets up doesn't get confused and everything Um So How do you guys want to proceed? Um I honestly while yesterday's conversation was really really good I do kind of feel like we could have gone a little faster If we didn't necessarily try to wordsmith every single word and rather Try to look at the more broader picture that you were trying to paint there. I agree um So with that in mind I'm wondering if we could just look at three and four and see if people understand the general concept and agree with it Or think that It's basically off track and then word leave, you know the exact wordsmithing for another time Yeah, I would I would prefer that Um, so, um, sorry. I didn't join yesterday's meeting. Um, I post some comments, uh, some suggestions on this, um, pr I think so. Oh, yeah, it's regarding the I'm wondering did were they I think they were all before number three, correct? Yeah, I guess so so do you Kathy do you think your your your comments are Did do they fundamentally change what clements was saying or do you think that they're more word smithing? Well, also, I I suggested some text But um, but that's a good question Yeah, I think you know I was just saying hey, sarah Let me just I'm just reading this we gotta have and see them before I know Let me just read that second paragraph Okay, so for to Kathy's, um, comment here um for her example one The event is submitted by the motion detector and the intermediate gateway that does the transformation of the request into htp Is the the gateway is an actor in here, but it is not changing the event per se and it's not the event producer It's basically just a translator that's for an spare um in the second example That's too in in my view. That's two distinct flows you have a you have a event that's being triggered by the the cap with the the motion detector the motion detector then goes and triggers something in a cloud platform Or stores does something something in the cloud platform the cloud platform reacts to that by emitting an event These are two distinct events in my view Okay, yeah, I think you know, I think I agree with that too. I think sarah's point is same, right? um So I think here I think the key point is you know, um, what is meant by semantic meaning change change a semantic meaning if we can clearly You know define that that would be good because these are these two are just examples, right? There are other examples So if we can define that clearly then people can't you know, um, you know can derive say which is a producer which is Then you know people will be on the same page. Yeah, that's my problem here with with with with length is I can turn I can turn the uh, the the write up that I created like this page I can early I easily turn that into 50 I have I have plenty of examples from from every part of this every part of the write up It's just not clear How much that contributes because we are looking for something that kind of frames the discussion And we're not making that part of the normative part of the spec So I'm actually very happy to write, uh, you know series of blog posts that go and and clarify the the intents of all events and details for the general public, um in in epic length But I'm not sure that we that we need all that detail, um in the discussion that we're having Yeah, so my point is that We need to agree and it looks like you agree with the stanza of having um, and or that we're having And um, so that is the consensus that's consensus That it's actually Already we have already achieved the purpose of that document No, I think you know the point is that you know these are just examples. We do not need My point is that we do not need to give the you know dive into each example. There will be a lot, right? But I would like you know We define the semantic change a semantic meaning Um clear in a more clear way. So now it's you know, um I think if we can define that I think There's no wording in here. There's no wording in here which allows Semantic to be even changed like this is something this is something where it's pretty clear That an event is originates from place and then gets handled by someone and gets forward by someone But no one anywhere is allowed to change the semantics of that event So I think I think I think you guys are actually agreeing and yes, they are Yeah, so Kathy I wonder if it would be useful if rather than um Rather than talking about what you'd like to see in terms of changes Could you actually propose some actual texts that you want to see in there or or minor wording changes to to to get the point across Because I I do think you guys are agreeing Yeah, okay. I I think that's fine. I can try to propose some. Yeah Uh, I think the another key point is in you know, is how we define the Change of semantics like even for hdb api gateway, right different implementation Could do differently some implementation might not change, you know the on the What we what we define as semantics, but some implementation will change it quite a lot so there is a So so okay. Anyway, I think the point is that we need to define that otherwise people might Reach might reach different conclusion about you know, which is a producer for some scenarios Yeah, I I do feel like this point Is the been the biggest confusion in our discussions over the past month? And so if anywhere we might add a little more Narrative to explain that I think this would be the section. So I think Kathy if you can, you know, I suggest it's I was the one who used the word semantic If that word isn't working for you, please just I let like Doug's suggestion if you could propose A modification or addition to this section that would clarify it. That would be great Okay, sure. I'll try sarah. And then you can you know, maybe later see Whether there's a better way to word it or to to explain it. Yeah. Yeah. Okay. Thank you Kathy On on the on the other request a comment from Kathy Replace replace applications with platforms applications platforms. We actually had we had the discussion yesterday on we landed on We're gonna we're gonna drop effectively as as you see the merger of here The proposed merger here is is the one where we landed and we were agreeing that platforms Are no different really from applications with respect to what we're building here Okay, so so my only um, um, my only concern here is, you know, sometimes, you know from a Surveillance scenario, right? There will be like Surveillance platform we provide, you know, the service Framework and then there are at the three service applications which use the platform And we talked about that yesterday and I don't want to talk about that again today Well, I think the point is is that if it's a confusion in the language that may be having a clarifying Point so that you show up or you don't Uh, that's not we're writing a document that's going to be consumed by a lot of people If we go and iterate over the same points again and again and again, we don't make progress So this is what we landed with five people So let me just ask a question because Kathy, I wasn't quite sure understood Are you saying that when it talks to consuming events we need to distinguish between the platform and the application? Yeah, but um, so I just feel, you know applications, right people could mean um Usually in the service scenario application means some software Um, the people develop that will use the service platform Which like, you know, either is uh, google google Cloud or like amazon or microsoft is your so that the I mean the Usually I think, you know, at least from what we have been discussing We call that service platform then the The software that's that's built on top of that platform to form a A new application or a new service That's called the application service application So if we're talking about service application, then I feel uh, it's not very clear. Um, so what I'm taking away from all of this Hey, sorry Kathy. Um, what I'm taking away from all of this is the the word here Right for individuals who don't have the context of those of us who have been on the calls Or just take it from the standpoint of just someone who's reading through the spec for the first time Like this this might rub someone the wrong way What I think we're leaning towards is even making it more generic like events are consumed For the purposes such as right like completely punt on the notion that it's an application a service a platform And just say whoever is consuming the event it can be anyone, right? That's really what we're getting are here Yeah, that's good if we can say that, you know, say just whoever consumed the events Yeah, okay, so so Clemens, would you be okay with that slight wording change? So I've actually proposed a um Change at the very top to say that in this context We use the term application to be inclusive of custom applications or platforms that host applications Or services, right? And that's fine. That would also be great, right? Like we're like It's very a legalese thing to do, right, which is to say from this point forth application means any of the following words But that's good too. Yeah, that would be fine by my perspective too I just don't want to see anyone get hung up on like what we're doing it again, right? We're getting hung up on very specific wordage because it does rub people the wrong way in different contexts So that was all I was suggesting Yeah, I think so, sorry. Sorry if I didn't read that That read what you just mentioned, but you know, I think that's good enough if you Have some word in say, you know application put me all inclusive. Okay service platform that hold. Oh, yeah, that would be good. Yeah Okay, I just added that based on your feedback. Oh, okay. I see. Okay. Yeah Cummins, are you okay with that kind of change? Yeah, absolutely. Okay All right. So scrolling forward in terms of other edits. I think we got that one That's from yesterday Oh, yeah, I did another. I think sarah. I did something and then I did something too Um, so I think the consuming application is also interesting in correlating event instances from multiple event producers Send them to the same workflow instance But so that's that's um, so let me let me ask you back Um, how do you do that today? Is that how do we do that today? How do you do that today? So so that's Okay, we currently right so we need some um So this is a scenario like, you know, for example, if like there's a burst of events And then you know that event will trigger many instances, right? Um, if that instance is like a workflow and there are many multiple steps And then you know if the second event comes then how doing a burst of second event comes many of that events How do we know which one which instances? That uh, which workflow instance that new event should be um sent to So correlation token there Correlation mechanism there. That's why we need something in the event information in the event data um Or the attributes metadata to identify, you know, um that event But that's but but so that correlation that correlation information. Yeah Where's that's what where's that coming from? Okay, that should be uh, you know So that okay So you ask the where that come from so for different scenario, right that correlation Token could be different as we said, you know, I gave just one example The the the other examples I give one is in my previous presentation in that, you know, burglary and detection So that uh event correlation token could be the house address So if like, you know, the service platform receive um, uh motion detection event or a door open event They're the same event. It's a door open event But inside that event that event and information that invention information carry a uh A correlation token a unique identifier, which will be the could be how the house address So we need to know which one is that that information needs to be in the event Yeah, so The reason why i'm asking that question is is whether that correlation information Is so generic that it would have to be in the standardized sets of properties and I'm gonna I'm gonna postulate that's not true that this is the correlation that you're seeking Is an is an application level concern That is specific to your app where you have a set of events Which are emitted from? multiple Related contexts where you define the relation the relationship and then you tell each of these contexts A correlation idea the idea they ought to be using as they're sending events And then they will be using that correlation idea and send that inside of the event payload So it's all okay. So first I think it's very um, you know a scenario that involves multiple events Is very common. It's not like a very rare. It's a common scenario Yes, okay. So you agree with that multiple events. Okay. It's common. So that scenario. I think we should consider that Yeah, no, I agree pardon So that's Identifying selecting the origin context What the producer assigned classification? Is is intended to cover this? Um, and that is effectively these are events which are kind of the same Um, and it apparently is not telegraphing that right So, so okay. So first you agree that you know A scenario that involves multiple events is common and we should consider that right? So I give you an example from from um, a storage service event The the commonality around storage services events are typically around a container So you have a storage container That is emitting events You're interested in all the events from that storage container And then each of these events from the storage container can have a further discriminator Which then tells you what what exact object inside of that service container just raised you that event Okay, so so this is a bit different So so you are talking so all these events are from the storage. So you are using some On some other fields a column number to distinguish them. Okay, whatever number whatever that storage ID So here i'm talking about is multiple event. They're not storage event For example a scenario could involve a storage event and another like api gateway event Or is another note. Okay. Okay. So so involve two from two different event sources Is when I say two different event source, I mean two different types of event source Okay, so wait, can I think can I just make it just for a second? I want to make sure I understand something because I think as sarah was saying in the chat I think you guys are agreeing and I think clements you actually might be okay with that text that she's proposing But you just want to understand whether Kathy's looking for additional attributes to be added That's that's what I'm And correct me my wrong here, but Kathy I believe you're saying you're not looking for additional attributes to the spec You just want to make sure that we're gonna we're not going to do something that precludes your use case Yes, that's right. Yeah I just want to add that use case and how we are going to do it. We can discuss later, you know Use what makes me okay, so I think so I think we can agree to add that one an extra bullet and then move on Okay So so that's from yesterday. So I think we're now onto number three So uh clements you want to briefly mention or highlight number three? Um Sure, so I'm here. I'm introducing the notion of middleware that is Trans it's effectively transparent to um producers and consumers so it plays a mediator role. That's why it's middleware Um, and it does a few things that the consumers that mostly consumers are interested in Um, where consumers having are having requirements And so I'm I'm expressing here requirements really that stem from the consumers, but I realize in middleware in that list um And enumerate them so versus management of many concurrent interested consumers for one or multiple classes of origin in context of events So you have um if consumers and producers requirements in that sense um, so here a Producer is creating is sending a lots of events. It gets a lot lots of interests from consumers And instead of having to deal with all of those consumers together Um, and and singly It basically delegates the management of all of these interests of consumers to middleware, which which takes care of that for it Second is the Consumers all of these consumers are given the the an opportunity to to be interested in the class of events um or in a certain context, but then That context itself or the class of events may be a little richer So there may be a a desire to go and filter that down further Um, and so that's a delegating that's also tasks being a frequently delegated in some middleware to go and out of a Initial selection that's built built built over a categorization That you want to go and filter out specific events very common in pub subsist Then you might in some cases You might have a middleware which does transcoding The example that I gave here is that you Event arrives in in json and say you want to have a delivered message pack That's something that some middleware middlewares do Um Transformation or you know for or you get just simply get compression over over the wire Transformation that changes the event structure like mapping from proprietary format to cloud events While preserving the identity and semantic integrity of the event also a very common task of middleware to give you a A semantics preserving transform from one Schema to the next Um, you also may get pushed out delivery to interested consumers So you give the you hand up the the event to the middleware in the middleware Then it takes care of delivering that out to interested consumers with retries and all the those whistles It might store events for eventual delivery. Um, if the consumer is currently offline Um, or um, if uh, there shall be a delay for that delivery, which is not rare And then um, the middleware may also observe Um the content or event flow for monitoring Or diagnostic purposes basically snoops on that flow and then reports on it Um to satisfy these needs. So there's there's these requirements There's a few things that the middleware now needs And that is Thank you because I'm actually reading from your screen. Yeah, sorry, I couldn't read it too many comments in there. Okay Um, so to satisfy those needs, there's a few things in middleware we need first of all it needs to have a metadata discriminator which allows it to credit to You know provide a coarse-grain selection of events that consumers can register interest in so you if you want to subscribe to a set of events you need to have a Initial pre-grouping if you want to build something that is reasonably scalable that's what I mean with The classification that's actually motivating the classification. It's also motivating More or less the the context and then typically if you have context like the example that I gave with the with the room and the building and the the Um, what did I have room floor building? um, these are um real You know structured contexts that um, you will be interested In depending on what your applications is and you want to go and and kind of filter in Um, but then there is inside of that classification or inside of that broader context that you're selecting and getting all the events from The middle where we then need a further discriminator that allows distinguishing the subject of a particular event for that Of the subject of a particular event of that class which means you're subscribing to events of The storage container, which is the first one. That's the classification or context But then now a file gets created and you need to know that of the file got created Um, but then you also need to know which file was created and that's what I mean here. That's the subject of That event and then you need to have an indicator for the encoding of the event of its data um, and Um, you need to have a because you want to you don't want to know that it comes in this application json And you want to send it out as as message pack So you need to have an indicator for this and then you also need to have an indicator for the structural layout scheme for the event and its data if you want to do a transform You need to know what the input schema is and then you will also declare what the output schema is if you are um a schema person um And then whether and then and I have another thought point and I as I had had on the on the other one on the previous one um Whether an event is available for consumption via middleware is really a delegation choice of the producer So it's it's it's in the hands of the producer how it makes its events known and um a producer always Have is in control of saying I deliver my events in the following way and I either you come here in quotes To wherever the producer sits Or the producer basically points people Also via documentation to a middleware where That holds events available on behalf of that producer Okay, so before we start into the discussions, I actually need to drop Um, so I'm going to stop sharing my screen clements since this is your pr Would you want to share your screen so that way you can guide the discussion through it? Um, yes Okay And before I go I did have a request for you guys if If after this call we don't have significant progress yet on the definition of source Can we set up another call either continue this one for How long people can stay on or set up another call for tomorrow and just paste that information into the normal agenda doc and Send that a note or something so people know Because even if even if we can't get an agreement today, I'd like to see if we can make more forward progress So I think this is tremendous forward progress and it will help the conversation of source If the whole working group accepts this pr and that's what we actually decided to do last week And we scheduled these meetings last week. So I I don't know whether giving people one day notice that we're going to Have that conversation tomorrow is like the best thing but um If other people want to get together and put together a proposal that's fine Well, yeah, I'm not I'm not so obviously if we come up with if we have another call tomorrow And actually come up with a the most spectacular definition of source It's too soon to vote on it Thursday, but that doesn't mean we can't make forward progress So people can be be looking it over in preparation for the following week's call I just don't want to lose the momentum we have as long as we actually finish number three and four here I have no problem with that. Yeah, I'm not yeah, like I said, if you guys finish the stock or the this pr and then Start have and then start the discussion on source. I want to keep the momentum going and say let's have another call tomorrow And see how much we can plow through But I need to drop off. So just like I said, just if you have another if you set up another call Please just let people know about it so people can join if they are able to Okay, thank you guys. I'll talk to you later. Thanks Doug. Yep. Thank you So we're on three so I had a question about the um Middleware if you can I just jump in with The consumption of the I like I like what you said about the like the producer decides like how it's going to communicate And you know, how its events are going to be made available. I think um, There's a nuance there, which is that like if the producer talks to a particular middleware Like in your presentation A while back Clemens like that middleware could talk to another middleware. So it's not really There's concern All the middlewares that might be in the chain So middleware routes events from producers to consumers or onwards of the middleware. That's what I started with Right, so I think I just um Maybe that could be clarified a little bit so that it's it's how um, so So I think that um Basically the um I'd like to separate The like how events get transported right from what the event needs like what the middleware needs to be about the event So you could say that the middleware Says how events, you know, how it communicates with source and consumer and or other middleware a producer Determines how it will make its events available. I I don't understand what you're saying What basically I'm Um, let me find the the actual point It is it Kathy are you advocating for a statement where like when a direct route From producer to consumer is not available or from producer to Destination is not available That the producer Can send data like route accordingly via middleware, right? Like so some destination has to be At least acknowledged on the envelope so that middleware can attempt to a route accordingly Actually, that's not what I'm saying. This is Sarah by the way. Um, but It takes a while to understand everybody's voices um So what I was saying is that I think the producer decides how it's going to make its events available Yes, some systems the producer just makes events available and the you know Any sort of classification might and filtering or whatever might be done by the middleware Depending on the event system in some cases the producer will do filtering on its own and in any case The producer doesn't Pick its middleware. I mean it might but it it's just responsible for how it produces events But what I'm asking clemen is to basically capture a little more of what you said Because the document seems to imply that the producer chooses its middleware My point is my point here is if middleware is in the picture at all That is covered by section three if the producer doesn't care Then it's not captured by section section three And the the there's a decision point that i'm and this is the last sentence that that I read right is The producer makes the choice of whether it wants to delegate these tasks to middleware or not But if they if they if it doesn't go and delegate those to middleware Then they become private concerns of the implementation of the producer that the producer doesn't need to share with anybody And therefore we don't need to look at them So the point three is is is all about middleware being in the picture already so Many weeks ago. There was some discussion about like a desire for there to be an ecosystem of things right and um So saying that the producer I mean, I think sure there are some systems where we allow for the producer to have some proprietary contact with some proprietary middleware Um, I just think that there are folks in the group who would like to see Interchangeable middleware. Yeah, but that's what this is about. What's your what's your I don't know what you're contesting What i'm saying is by saying that the Whether its events are in line 142 Saying I think we're agreeing on the content and I just want to it captured in the document It says whether its events are available for consumption via middleware is a delegation choice of the producer. Yes How's and and and that's true All right, if a producer chooses not to use a middleware, you can't get the events of that producer from that middleware and and the producer Goes and delegates work To the middleware for instance distribution of the events That's I'm not I'm not sure how that's false So I think that I guess I was reading So one of the things that we've been talking about is creating an ecosystem where you could have One party create a producer another party create middleware a third party create a consumer And a fourth party assemble all of these into an operational system, right? Yeah, but in which that case the producer isn't making any choices at all. They're producing something in some way that it But the reality the reality of Of systems is that the producer if it has events it has a choice of whether whether in which middleware uses And and we need to make our specification work such That a producer can go and make an event And can go and dispatch that straight to a webhook of a consumer without having anything in the middle Yes, and So then somebody Yes So if somebody were creating a producer They communicated with the consumer via webhook And those were the producer and consumer were open source software And that's then by definition over htp because that's what we make webhooks out of Then somebody could put a middleware in between right that acts as an observer Yeah, so it's not really the so basically the producer chooses how it will communicate events But not it doesn't actually choose its middleware No, it does choose his middleware because it will not talk to an untrusted proxy Does anybody else have any um thoughts on this? Yeah, I think sarah I think sarah's point is um From the producer's point of view It just um, it just knows, you know, how it's going to um Publicize or emit that event. It's the receiver side You know that decides um Whether you know, um, it's going to just act as a middleware or act as a consumer Is that what you mean sarah? Yeah The producer doesn't know who is going to consume that event or how it's going to consume it whether you just act As a middleware or it's the the real consumer of the event Okay, so I I think I think if I strike that entire sentence then we'll be we'll be happier Sure Okay. Um, I have a question here. Um, Clement could you scroll up? Um, so for the yeah So here we we talk about, you know, on the middleware all this, um Um, I mean the either is a transcoding transformation filtering, right? Can we add that, you know, it will not change the semantics of the or the semantic integrity of the event I see that you you you put that into the transformation But how about the the other Yeah, the other transcoding by definition only only changes the encoding of the event. So, okay So how about the other filtering? I see some filtering things uh So if the filtering if some semantics was lost if um But filtering only filtering only selects it only selects the event. Okay, right So how about the other like So metadata discriminator allows distinguishing the subject of a particular event of that class That means you you you either get that event or you don't but that doesn't touch the semantics at all Yeah, yeah, these are fun. Yeah. Okay. I see. Okay. So transcoding. It doesn't so implicitly It does not change and then filtering it does not change. Okay Transformation and transform Will Actually drop data that's efficient that's essential and that will change the semantic integrity Okay, that's fine. Yeah, I just want to make sure the middle where does not change the semantic integrity That that's the whole point. Uh, actually when I read through these points I think these are very good, you know points when I read through this. I feel the serverless platform. Um Calls also satisfy all this What do you think absolutely? Yeah, absolutely. You can't and that's the point the point is The point is it it's a it's a middle. It ultimately you have a producer That's a piece of code and you have a you have a consumer or a handler if you will that's a piece of code That are the outer edges of this whole thing, right? And then there's you you call the consumer is the consumer is the thing that goes and gets the event and then And then interpret it and then ultimately dispatches it into a function And the producer is the thing that kind of captures the state that's that's existing in its own system Renders an event and goes and sends it and then there's stuff that sits in the middle that makes sure that Those two parties can go on and understand each other and can actually You know see each other if you will so that that event can be routed and then all of that stuff that sits in the middle is middle Yeah, okay. So um, so are we going to so how we position the some Transport in the middle like some router which routes the event from the That's also middleware So our middleware. So the middleware here actually is very very broad. It could be, you know, uh, a transport Entity like a router Or could be a service platform which actually does much more than just, you know, it doesn't do transport I actually it's it does filtering it does, you know some It can be service mesh And if our service service broker bus, it can be an api gateway. It can be Um a message broker. It can be an event router. It can be an event gesture. It can be any of those things I think if we can clarify that that would be good, you know, because here actually I think you know the middleware what we want to define here is very broad can cover actually very different Entities with very different functionality I like what I what I in in standard documents What I'm trying to avoid is constraining the definition of a role to a particular set of existing artifacts because Um fashions change like like 10 years ago You would have you would have written this as the enterprise service bus does the following thing And today you might go and write this as you know in independent in certain quarters of the industry You might say an api gateway does the following thing The reality is this definition of middleware has been stable for the last 20 years Um, and you could go and apply this to ibmq from 25 years ago and it would still be true Um, and this will likely also be true in 20 years But the names of things that are implementing these patterns are all changing because marketing Yeah, yeah, yeah, I I think I understand that point. I think that's right I'm just thinking you know in order for other people to better understand this We can just give some examples instead of you know people are thinking you know Oh because sometimes, you know when people think about middleware people think about you know router Uh, you know some intermediate devices, which does not do anything about the you know the Event it just transport Some people to think of that way, but actually I think here it's not just that right I think give some example for clarification that's not heard We're not saying it's just restricted to these examples or these terminologies because they could change in the future, right? I agree. I agree with all of you all the things that um with pretty much all the things that you say all the time Because you're asking for more clarification Um and and more examples and I think that's that's great. Um, and we'll have to go and figure out how we how we satisfy that um In companion material to the spec so that we can make it clear to everybody Um, what we mean with certain things. It's just not that the spec needs to be pretty tight technical documents Um, and what we're trying to achieve is kind of consensus on on you know Where we're going and ultimately we want to go and speed up things to get to a stable thing So I think these are parallel efforts to go and write some more verbose material That illustrates more of the use cases and I can I can make a suggestion Can we just file an issue to like I'd like to see this proceed like this pull requests go across and write a separate issue to verify You know the the existing set and make sure it's legally You know but not limited to Yeah, you know like sort of thing because you do introduce a really interesting set of use cases when you talk about like an api gateway Versus like a message broker, right? Like you have implicitly changed a one-to-one versus like a one-to-many mapping of You know, uh, where the event could conceivably go You also impose things like well now is the transport like it like to get very specific right if I have Kafka in place Um, is the transport also concerned with ordering? Right like ultimately I think that ordering should be explicitly called out as out of scope But I think that is in a different document Right and and you get and you get if you look at api gateway versus Kafka you also get the Deliver ones or be able to replay forever and there's Delivery guarantees right like at least once at most once right like you can we can we can create this matrix But I think it should be very scoped and specific to Middleware right that's why I'm suggesting we write a separate issue to like kind of explore The definition and use cases related to middleware But should not be done in this context because this should move across and make progress And I agree we we can and the question is I mean well well as important. It was interesting to explore Um, I'm not sure how much that exploration is going to drive us towards Um The the first goal that we have and that's kind of the first set of core properties and all we're going to lock on So Kevin I had a quick question for you. It seems like you've got a couple of levels of discriminator. Yes, it's discriminator Yeah, one was sort of a coarser level which would indicate the Sort of a storage device and another one which would be finer indicating that a subject or a Piled within the storage device. Is that right? Yeah, I have I think I have Generally, I'm thinking about for Four of these discriminators that I have in my head The question is the sounds to me like the that first when you mentioned that that references sort of a storage device Isn't that the same as the actual source ID that we have already? So and that's Yeah, so thank you for raising that question because that's that's a great way to spend the last 15 minutes um So So let me talk about those force since you asked and I think that's that's that's where that the coolest comes from So the first one is it's one where we've been There have been discussions about and that's this this namespace thing Where I think we need to have a way to distinguish between Namespaces in the sense of vocabularies if you have an event that comes from azure or you have an event that comes from aws Or an event that comes from the ibm cloud Or an event that comes from the oracle cloud um You will have a Specific notion of you know what the other fields are structured like They're gonna have a And you will not necessarily all want to interpret them as completely opaque fields, but they may have structure in them But interpreting that structure You need to have an anchor for being able to interpret that structure um And having a disambiguator that tells you this is an event that comes from azure or this is an event that comes from the oracle cloud Will help you to say like if I if I see an event that's from azure I look and I look at the fields that we're currently talking about a source Then I know that that's going to be a azure resource identifier I just know because that's how we document is like this field will always contain that Which means I cannot start doing clever things with it But only within the scope of azure and cloud events gives me the the the the certainty that that the namespace field is actually meaning To be that discriminator for that And then for all for other all other cases right where I don't want to go and sleep inside and be intelligent about the structure I just take that as a Um as a field that I could go and You know just act on as an opaque string, which is also fun So that's why I care about namespace also I care about namespace because there might be clashes um In terms of womanclature for those Identifiers so you may have a you may have a notion of you know what the event type is And the event type might that I define for for Azure might might clash with an event type that is defined at aws and we certainly don't talk to each other Because we're not allowed to And so having that discriminator makes sense to me for that reason so So the namespace is essentially a top level identifier for the the whole context of the the message event I mean The rest of you know, once you have an identifier, whether it's oracle or aws or all the other Fields would be Interpreting the context of that that namespace value. Is that what you're saying? Yeah, that's that's that's what I'm that's Effective what I'm after to say Um, they all those events are having though having this their their meaning and their constraints as cloud events defines them But they may they may have the cloud event says, you know, this field is a string But inside of my and everybody who's processing in a cloud event in the standardized way will go and just say Hey, this is a string. I can go and use it But if I know that that's a string that has been emitted by azure I can also go and interpret that string in a particular way And I think that's fine And that's the the power that a namespace will a namespace declaration will give us is to say um, I now know What the what the structure? The substructure effectively of the data in those fields is And and I can tell you that we will likely so from in azure We will likely just have azure.com names in that namespace or something like this And treat all the events that are emitted by the cloud mostly the same Certainly for every day comes through event grade Um, let's say we wanted to have something, you know, so we don't want every device have to be able to have to Interpret the events in terms of say a azure namespace value come have also a more common Um, mechanism say, you know have a value for uh cncdf events or cloud events Yeah This is this gets into so the thing I want to avoid the thing I want to want to help with Want to help with and avoid at the same time is schema standardization So so what we're doing here is we're trying to agree on a schema For events of a few fields, which is already quite the thing Going a step further down and actually start defining what the events per se look like like what the standard storage event looks like That's gonna be even harder so um I think where we're at right now Is to say here's an identifier that tells you the context of that event That's actually pretty good And and the namespace the namespace is primarily there to avoid clashes So you get a storage event that comes from the auricle cloud And you get a storage event that looks from that that comes from the from aws one from azure Three storage events all of them are about a block being created because that construct exists everywhere You will want to be able to go to um the Um, you will be able to go to that respective blog account and pull the file out But there will be That you need to go and be intelligent about and will help you Be able to tell that this event that you're looking at just came from aws as a first ordered discriminator So that you can go and then dispatch into the respective code that deals with that Mm-hmm Right. Yeah. I mean, I think it's the right way to go. Um, how does everybody else feel about that that that I mean I think what we're saying is when we actually get down to Creating an event standard here or specification that we're really Opening up to everybody's individual Namespace essentially or encoding Um, as long as we have this uh namespace identifier within the event itself You know, so we can interpret all the fields of the event So I have another question here is so that uh, if that, you know, the namespace, we know it's either Microsoft or amazon or whatever, right? Um, but if it is like in I I'm still thinking about the iot scenario it's not like any um Will define um, you know, Microsoft amazon Then, you know, what is this classification and what is the subject you pick? Yeah, hang on We're we're I'm we're I'm gonna get there So the word select namespace namespace is so namespace is the top order the top order definition of All the events that you're gonna that you're gonna admit And if you and and this might be huawei dot cn for you or it's huawei dot com for you um, and For me, it's microsoft.com is azure.com and it effectively describes the You know a collection of of systems that are emitting emitting events kind of in a in a similar way It's just so it the primary the primary purpose for that is to avoid clashes And like if you are subscribing in a solution from x of these systems And you get events from all of them into the same place that you are able to go and dispatch them in a way That you can go and and and deal with them in buckets That's the primary purpose of the namespace. Um discriminator Yeah, I think that's good Go ahead. How about like for if it's iot device That you know And then to a api gateway The consumer uh-huh go ahead That has nothing so so so the namespace identifier basically just says Just says it just does a broad classification event. It has nothing to do with transport As it basically just it's just about how to how to interpret those events and how to How to how to cluster them as you handle them. It's not about where you go So the fact that there's the fact that there's a that there's the main name in there Is it's just the names the same thing as with the next mal namespace So in that case so that namespace will be that uh iot device Company, right? Yes, exactly. I got it. Okay. I see yeah learn that okay So then the next question is a subject. So now so now Yes I was so I was I said I said so I would I said there were four And I started with the first with the namespace and I and I want to start with discussion now comes a group of three And see all the other one. I don't understand how what you were talking about like the first one Related to namespace Yeah, so I was asked about the discriminators that I see Right. So you your first discriminator was usable for classification of events Such that consumers can express interest in one or more such classes. That doesn't seem like names I I I was I was asked broadly and so I tried to explain block broadly So now so now let's the other three are I might be in the wrong section of this topic subject and event types Is topic is I'm sorry. Can you just tell me where you which list I'm not looking at the document anymore I'm talking about what source is Oh, okay. So we're not um, yeah, I I'm pretty confused about what we're talking about but whatever so I was asked and we were we were trying I think I felt we were done with that part of the documents and then we're trying to get into a discussion Where source what source is? Oh, no, actually, um, so comments. I think I have the same confusion as sorrow So I thought, you know, you have the names. I thought you have the classification You have the subject and then we have a next one. So these you say are not related Then there's another they are but they play so so the requirements that the the the document that we have here Your requirements, that's right They're actually already already partially materialized in the document that we have in the forest in the four properties That I would like to get to to make some progress on So that's like we have so I'm gonna I'm gonna go on and and and tidy this up this part But that's already pushing for some properties and based on the discussion that was that we had just so far It looks like a few people were following that we were talking about the namespace property. That's defined in the documents Sorry, it's um two of I'm not sure that I completely I may totally agree with you plemins or I may kind of disagree And I had a whole bunch of questions about namespace So I'm not I'm I'm completely in support of there being a namespace field But depending on how it's interpreted. I might not want that definition for it Okay, but it is nine o'clock. It's I have a meeting in two minutes Did you want because of that because of that we should have another call Because I think we need to get to a point where we can have what we can have a discussion About source type source ID and source, which I believe should be folded into two fields And should be aligned with Can we can we talk about not the definition of source but the time for the next meeting? and What will happen between now and then so that we can make sure that people are aware of it Yeah, so how about we do it tomorrow? Yeah, maybe we schedule a tomorrow meeting tomorrow. So how about nine o'clock? So tomorrow At the same time tomorrow Nine o'clock tomorrow would be good for me. Thank you. Yeah, nine o'clock would be good to me, too And then will you be able to resolve all the comments in the doc today? I will do that to not today, but I will be able to go and do that tomorrow morning my time Okay, if you can do that before the call tomorrow, I think that would help people if they are coming new to the conversation tomorrow Yes, I will do that Okay, thank you. It's a good discussion. Yeah Yeah, I would like you to uh in tomorrow like what's uh, um The namespace and uh, you know this classification subject Or this how they relate to each other so we can have a better picture and then we can know whether you know Yeah, we are in sync or not for the subject for the subject you can look at the pr that I have for Yeah, so it's not very clear Also, what's the relation between namespace and what's that and the classification? And the subject. Yeah, look at look at um pr 95 Yeah, if you can put into the same document that would be good because the thing is here We're talking about the classification and then subject, right? But then we were discussing the namespace looks like namespace is our first level and classification is second level Is that what you have in mind? Yeah, go go look at look look at pr 95 and then look at um issue 112 So issue 112 actually lays this out in epic length What I mean with um and what what what topic is and what subject is why they exist and all those things That's a that's a multi-page write-up that I did just for the clarification and also site prior art On how a subject is being used in s and s and in grande in gcm and fcm and kafka and jms and nq and nqqt and nqp and all those things So look at issue 112 Okay, I'll take a look. I try to take a look. Yeah. I just want to make sure what we cover Whatever we here. I'm not we covered, you know the correlation Token which we talk about because that's I think you know Yes, and I think you will find your correlation totally in that write-up look at issue 112 Okay, let me take a look at that. Okay. Okay. Good. Thank you very much. So let's tomorrow now clock. Okay. Is that right?