 All right, three after the hour. Let's go ahead and get started. All right, community time. Is there anything from the community in general people would like to bring up that is not on the agenda? All right, not hearing any. We have no updates for SDK. We have a meeting for the demo for KubeCon Europe. It's coming along fairly nicely. We are getting more than one participant involved now that we have the basic flow settled down. The document here is up to date with the message flows if you guys want to participate. This one, just to give you guys a heads up, is quite a bit more complicated than the ones we did in the past. So it would be beneficial if you do want your company to participate to get involved as quickly as possible. Not only because there's more coding on your side that needs to be done, but there's a very good possibility that there are bugs in the system. And we need to flag those as soon as possible, because there's a lot of moving pieces in this one. So you want to get those things ironed out relatively quickly. But all the information you need is either in the proposal doc here or in the demo Slack channel. So when we do have meetings after this call of 1PM Eastern to talk about anything KubeCon related, so presentations or demo related. So if you want to join that, feel free to do that. All right. Any questions or comments about the demo or KubeCon in general? OK. I guess I should say for KubeCon in general, the slide decks are out here. So the links are all in this section. Honestly, I don't think most of them have a whole lot of content yet. I know some people have been starting to add content. But if you're so inclined, take a look at what's there today. If you have comments about the direction people are going, please feel free to add comments in there or send out notes to them or us to whatever. I believe, try to remember, if I remember where the deadline is, unfortunately, I can't remember when it is. The deadline actually may be this week or next week if we're actually officially sending it in. But of course, people tend to wait the last minute anyway. But please do your reviews sooner rather than later if you're interested in sort of monitoring that. And again, we will have a phone call today after this one if you want to join that conversation. Any questions about that? All right. KubeCon China. We do have a 35-minute session for cloud events and a 35-minute for serverless. I personally will be there. I suspect Kathy might be there since that's close to Huawei. But anybody else going to be there who's interested in speaking, please let me know. I'm basically looking for speakers at this point in time. Anybody and everybody is willing or is welcome to volunteer. I'll take anything I get at this point. And what dates? What are the dates? It's in June. Let me see if I can find that on a second. It is the week of June 24th. OK. Thanks, I'll put that in here. Hold on a minute. That's always helpful for finding volunteers to know when that is. Yeah, that's true. OK, there we go. What else? Oh, yeah. So yearly review next week. I'm going to begin my presentation to the TOC on how we're doing with cloud events. While the presentation is there, there's nothing in there. So don't bother looking yet. Hopefully before end of the weekend, I'll have something there for you guys to review. And I'll send out a note for you guys to comment on it. I think May 7th is Tuesday, so there's not a whole lot of time. But I will at least send it out before the end of the weekend for you guys to take a look at it. I don't expect it to be anything controversial. So hopefully it's not a big deal. And with that, I think we can jump into PRs unless there are other topics people would like to bring up that I'm forgetting about. Do we plan to say we have three independent users to go for the next level? Oh, I wasn't going to bring that up on the TOC call on Tuesday. Rather, on Tuesday, I was going to bring up a topic of what do they mean by three independent users for a project like ours, which is just a spec. And I don't know if they're going to be able to answer that question, but at least we can start the discussion on Tuesday. And then, obviously, based upon that discussion, we can decide whether we want to go forward to be incubator project or not. OK. All right. I mean, we can already look if we have three independent users in our opinion, right? I mean, at least we had commercial tools. We use it a bit, or some of our customers used implementation with event grid. OK. That would be good to know. That's a very good point, because worst case scenario is they say end user means end user of a product that's using cloud events. And if you already have end users using it, and we can confidently say that they're real, and they're not just made up, and I'm not sure you actually have to have names, then, yeah, we can probably satisfy that requirement. So if you have that information, send it to me. And I'll definitely include that as part of the discussions going forward. All right, I'll do. OK, thank you. And I see that's true for everybody, not just Kristoff. All right, cool. Let's get into some PRs. OK, first one, hopefully relatively easy. It already has a couple of LGTMs. So this one, a couple of things. This is strictly a reordering of the spec. I noticed that the attributes we had were in sort of a random order. They weren't even alphabetical or required for a string like that. And in some of the discussions I'm having with some people relative to supporting cloud events, I thought it'd be useful if we grouped the required attributes together just so that there's a section that says, basically, here's the bare minimum you need to support to become a cloud event. And that's the required attributes. Everything else is optional. So that's basically what I did is I created a required attribute section, put all the attributes that are required to be implemented or supported in there alphabetical. And then I created a d-d-d-d-d-d, where is it? Where's my optional section? Oh, there we go. Then I created an optional attributes section and put all the other attributes in there in alphabetical order, obviously excluding the data section, or the data attribute, which has its own section, because I was always pulled out. I did not make any other typographical changes whatsoever, or definitely not symmetric changes either. I just reordered things around and created two new sections. Any questions on that? Any objections to approving that? OK, cool. Thank you guys. All right, it's Klaus on the call. Yes, you are good. OK, Klaus. Yes, I'm just joined. Yep, cool. So on last week's call, we actually approved this PR. However, afterwards, there was a couple of questions that were raised that made it clear that maybe we should have a little bit of a further discussion on this topic. So Klaus, I'll let you go ahead and drive this discussion. OK, so in order to later on come up with this other PR regarding the immutability of event context, I felt that I need some more terms, like, for example, the intermediary to better achieve this. So and then I stepped over, I maybe also need a consumer. Then I saw that source and producer are not really defined. I mean, source, the attribute is defined, but we are in many places of the document talking about producer. But it's not really defined so far. And what I came up with was that distinction between source and producer, so that the producer is the entity that actually puts together this data structure or data record that is then put on the wire transporting the event, while the logical source of the event, like could, for example, be a business process, or I don't know, a lot of things. Later on, then some others in the call stepped over logical inconsistency, so that this source definition does not really fit to the source attribute. And there was some discussion what exactly source is and then producer. I think the attribute is defined as the source as describing the producer. So basically defining source by referring to something else that hasn't been defined yet. So there were some discussions what exactly a source can be, if it exactly is something very specific, like a process or, I don't know, or if it really is something logical as I have put it here and what then is the producer. So I mean, I also have done some research. There is a book available. I think it's event processing in action or something on Manning. They also define terms like producer and source. And that's, again, a bit different. So I don't know. I like the distinction that you make here, because the source might really be a different system that's emitting some event that is not yet in cloud events form. And then the cloud event is produced by the producer. But if you have some kind of device that's talking Modbus or something, that's probably the source. And then you have the producer, like truly. And then you have the producer is the one that's creating the cloud event. So Klaus, did this text that I'm looking at right here, did that change from last week? Or is this still the same? No, I think there was something or some clarification I'm still supposed to make, wondering where it was. Somewhere about an external producer, I think it was. I didn't do it yet, because I think the whole definition was under discussion. So I didn't add that single word. I think Evan put it in the comments above. I'm trying to remember. I hear it was. Yeah, here it was. An external producer in the example, I think it was. So I'm willing to make, of course. But at first I would like to see if the direction overall is correct, or people can agree on this. I think that we need to consolidate this terminology with what's in the primer as well. Because for that intermediary, we use the term middleware. Yeah, that's true. And so I think we should think about that and be consistent across those documents. I think in other places also, I'm not sure if in the primer, but some of you also have seen intermediary. But yeah, should be consolidated. I agree. Yeah, I think I was able to agree with that, Mark. Thank you. So Topini, I think you had made some comments either after last week's call or in the issue here or in the PR here. Did you want to jump in here and say something? Sure. By the way, the change was, yeah. External producer creates the cloud event that was suggested by me last week. The bigger thing was something I realized while writing a comment on PR 3-in-9-1. I don't even remember what it was about now. I think the change to event ID and source or something. Now it was changed to the actual attributes to just think to get some clarification around the event ID uniqueness. Anyway, the problem is pretty well spelled out in my comment on this PR, if you can pull it out. Yeah, hold on a sec. The basic gist of it is that source is now defined here differently from how it is used as an attribute. So the attribute is defined as having both identifying information about the organization and the component emitting the event, but also some unique IDs, for example, for a file container in a cloud storage solution. But this document instead defines source as a logical system. So that would be, for example, the whole, to me, that implies the whole, for example, cloud storage solution or program instead of the individual file container. So when someone's talking about a source, it now feels unambiguous as to which what they are referring to the value of the source attribute or to the source as defined in this terminology. And I find that they are in conflict. And I gain multiple examples in this comment. If we were to use a different term in the terminology section, would that alleviate the concern? Yes, if we did have. So I was going to ask Klaus about the book defined because it feels like this should be a solved problem. OK, so in the book, I think they also had producer, consumer, and an additional processor. And the source was then always that entity that actually created the event. So a consumer producer was at the edge of the event processing system, how they call this. And a processor was part of that event processing system. And both could impact these sources. So that's how they put it. But it's, again, a different view. Oh, OK. So well, actually, they pretty much have them swapped around from what this terminology now says. In this terminology, the source is the edge. It's the system the event comes from. And the producer is the technical component producing events, unlike. The producer is more to distinguish from something that is part of the event processing system for them. But as we don't have something like this, this event processing system, and I'm not sure if it's suitable for us as we have those cloud interoperability scenarios, I don't know if that definition is really helpful for us. That is true. But anyway, I like the source attributes definition as having also defining not only the logical system, the event comes from, for example, a user service, but also the domain or more granular source, for example, a user account or a user address, if you did so. Exactly, this example with the domain was what I was thinking of. Because I think one of the favorite examples always is other GitHub events. And the source is then github.com-something. And maybe not the specific host actually emitting the event. So Tim asked a question in the chat. And I actually raised my hand because I had a similar thought yesterday. And forgive me, Tim, I'm going to misstate what you're thinking. But from a spec perspective, do all the various roles matter? Now, I understand that when we talk about things, it's useful to have common terminology, just that we're on the same page. But does it matter whether the producing side of a cloud event is one entity versus 10 different entities? And do we actually need to give names to everything? Or should the spec be a little bit more abstract and just say something's going to produce something on a transport? And this is what that something needs to look like. Well, we had this discussion about the event context and the mutability. And I think some strong feeling that at least middleware shouldn't just drop, for example, optional attributes. And then on the other hand, if you consume an event and really produce a new one, then you're, of course, free to do whatever you like. So that's what led me to this distinction. Yeah, but do we actually need to call out as detailed the distinction as that? For example, in the case where there's a piece of middleware that may or may not be modifying things, could we not just say that if there's a component that takes in a cloud event and then generates a cloud event, depending on what it's doing, it may or may not modify the data in there and whether that's OK or not. Do we have to actually get into the details of defining the various roles? Do we actually have any examples of middleware that's transparent that modifies the cloud event? I'm trying to figure out how that would work. So one example I was thinking of related to this and also the definition of source attributes, for example, ingesting application-specific events into a larger system as the source allows, and in my opinion, must allow, application-specific identifiers, which might not be globally unique, you might actually have to have a middleware that augments the source to include, let's say, a DNS component, or a DNS unique component to the source for which was, because the source was previously application-specific, not unique enough in a global context. Let me rephrase the question. Is there any particular value in keeping source and type the same when you go and need to modify an event in this way? Oh, OK. If you said, hey, when you do this, you have to put in a new type or a new source, are there middleware cases that would be harmed? I would think if you have a piece of middleware that's acting more like a proxy, you might. But then it's not adding fields, right? It could. In the same way an HTTP proxy could add some fields just so you know that it existed and how it went through that system. Then we have this discussion. I was speaking about the Kafka partition, something. Yes. And also open tracing, like this whole tracing stuff is basically morphing, changing the content of the tracing attribute as it passes through infrastructure. So there is stuff that's being modified on the way where you want to preserve most of the source event. But then as it flows through multiple layers of infrastructure, there is stuff that's being added or changed. I think tracing may be, I haven't looked at the implementation of open tracing. But tracing may be an example. But it seems like in most of these cases you care whether it's been transformed by the middleware or not. So in some sense, if you've got the original event instead of the enriched one, you'd be upset. Yeah, the tracing, think of tracing as annotations. Here, this isn't becoming as clear as it is in some other mappings of the tracing stuff. Like an MQP would make that pretty clear. But the way how open tracing works is basically that's an ongoing annotation as you go from hop to hop to hop, where you basically create a breadcrumb trail. And there it is pretty apparent that you have to go and modify the message as it flows through, even though you're not changing anything about the semantics of that event. So that case exists. You would be upset if you would materially change the event semantically. And in that case, I agree that that should cause a different event being created that is then somehow coupled, traced back to whatever the original event is. And that might be a rule that you have to go and refer to include whatever the original event. Not one that we have to go and define here, because that starts to then go into, that would be too complicated for me, for my test. So I'm trying to figure out if there's any guidance we can give to the class on this one. Yeah, sorry. Go ahead, Spini. I do think that we need to define something, at least for a producer, because it is used extensively in the attribute definitions. And it is a bit confusing if we don't define it in any way, because at least previously, there have been multiple users of it, or users in multiple different ways. And that might cause confusion. So, Kathy, I'll get to you in a second. I just want to clarify. So, Spini, if we had just this definition of producer and completely got rid of this source section, not gonna get that thing? Yes, because then the event ID, no, the event source attribute definition no longer holds, because it says that you must set a distinct source attribute value for each distinct producer. And that would be in conflict with the definition of producer here at the moment. I guess if you remove the current definition of producer in this PR all together and just define the value of the source attribute, and this producer has the same thing, then you would get a coherent definition, but that is not very useful because then you have the attribute source is reflecting something we define as a producer, and that makes no sense. Okay, Kathy, your hands up. Yeah, I share the same thought. I think we have two fields, like source and producer, if we define two, right? We have to clearly define the difference and how to represent them. I think if we define one is clearer, for example, the producer is very clear what we mean. And then we can also, I think we also need to add the type for the producer, how we represent it in the other section. Same for consumer and intermediary. Trying to figure out what to do with all this. Heinz, what's your current thinking? I'm sorry, not Heinz, Klaus, sorry. So I think around source, there's some perceived uncertainty. I also realized that while discussing it in the Canadian Event Registry, so I mean, it has some implications if you do source very specific. Basically, as describing the producer, it is defined here, or if you think it's more logical, identify where the event comes from. Also through the granularity of how to handle subscriptions and so on. So I'm thinking if we want to define both producer and source, so producer I think is very clear, at least to me what it means, right? And consumer, you already have a consumer, you have a producer. So what's the use of the source? What purpose does it serve? We define each one, and then we need to clearly identify the difference between producer and the source. So in which case we need this source. If we have a scenario, say in addition to producer, we also need this source attribute. Then we can add that source and clearly define the scope which will be different from the producer. Even the representation will be different. But if we cannot clearly define that, I think putting it there will cause more confusion than giving any benefit. So Kathy, I want to make sure I understand what you're saying. Are you suggesting that maybe we don't actually have source as a standalone term, rather as part of the definition of producer, we talk about how the producer is the creator of a cloud event for an event source and just leave it almost like that and not actually try to define it as a separate entity? Yeah, I'm thinking, yeah. I think basically that's right. So I'm thinking unless we can clearly define source and identify it's a needed field to serve some specific scenario, I think for producer, I feel it's good and we can clearly define it. What that producer mean? Then there's a producer that will be a consumer, right? If I would want it, we're going to define the consumer. Then I think it makes sense to define a producer. What's that source for? What purpose does it serve? Is it to pin your hands up and then Doug? Yeah, I just want to comment that if we do do that, I'm not objecting that, but then the event, at least the source attribute definition will have to be rewritten because it talks about producer in an incompatible way. Okay, I'll try to tell you. Yes, I think currently these two are not quite clear, the source and producer. Doug, I'll look for that attribute. Do you want to speak next? Yes, I work with GS1 on their event format that's used mostly for location tracking a product and they're extending into sensors and so they have two elements where the source could be the identifier of the sensor and IoT and then the gateway would be the producer. There would be semantically annotating what the sensor produced. Right. Yeah, and that is the scenario that I also had in mind when I spoke up last. That is an IoT actually fairly common is that you have devices which are connected through radio or through a field bus or whatever, which are not speaking even IP and which don't have to bandwidth to go and put something on the wire where if you want to have something that is the producer and that now needs to go and identify it towards an infrastructure with its own identity, et cetera, to be able to go and send events that is distinct from the source of events that it acts on behalf of. So I'm in favor of having really two distinct concepts here really along the lines of what Klaus has in his document here because that is the distinction that certainly in the IoT space people use. So Topini, am I correct that the short sentence here that I've highlighted is really the problem sentence? Yeah, that is the problematic piece. I agree. So if we were to do the equivalent of basically kill that sentence and maybe do a little bit of words or something on the rest of it, it sounds like... Also the last sentence. Well, actually no, wait. No, that isn't so problematic. David producer, although it isn't the actual logical system inside that is defining the source, it can certainly define the syntax and semantics. That's fine, sorry. Okay, so we can maybe do a little bit of words but basically get rid of that first sentence. If we did that, is what's in here bad? Well, there's still the conflict between that source attribute value and the source as defined here. That fixes the problem with the producer versus source attribute but it doesn't fix the problem between the source term as defined here and the source attribute. My comment in the PR still holds even if we remove that sentence from the start of the attribute definition. So somehow we have to consolidate the fact that this is talking about logical systems or services and the source attribute is also talking about identifiers within that logical system. Yeah, the thing that matters here is really the source which means the context for the event and what that event really just, the context that the event describes because that's ultimately what source means. And the producer doesn't play much of a role really other than being the one that's formulating the event and then in the case of middleware having a relationship with the first publishing point but that's really all role that it has. So in our specification per se, the producer doesn't really have much of a role in the design spec that would implement our spec it would have a bigger role because then it needs to be, then it has an actual relationship with whatever the intermediary is but our higher order bit here is the source. So Topini, is this sentence I've highlighted the problem sentence? That's but also these. So the whole definition is actually dramatic but from what Klemens just said, I propose that or something along the lines of not talking about logical systems but actually the context of what you talk about Klemens that's actually what makes sense and what the attribute that we have describes. It describes the context in which the event happened with the identifiers and everything. So these terms should just be redefined as what we use as the source attribute in my opinion. Then the producer can stay defined as is. It just plays a lot smaller role in the spec. For example, something so a producer defined but that's just left to the reader of the spec to decide what that means and that's fine but the source here should be defined in the same way as that attribute is otherwise we're in trouble. So if we just said the source is the context in which the event happened and stopped at that. Describes the context in which the event happened. I would be fine with that. Anybody else have any comments? Cathy, is your hand old or is that a new hand? I'm just thinking, unless we can clearly define these two maybe another way we can combine them and put that context or whatever we want to define the source into put them, I mean combine them so that people will not be confused. Well, I think we did just define them quite clearly. Producer is producing events. Source is the context in which that event happened. They are two very distinct things. Okay, Tim, your hands up. I wanted to say I love that phrase context in which the event happens. I fully intend to steal it. Thank you. That's good. Doug, your hands up. All right, so Doug, you had added a cause attribute for Kukan demo and so when you're starting to describe source the way you just did, it seems like there's overlap with that cause attribute. Slightly different and for the demo, cause is more like a related to ID more than anything else. It's not really the source of the event per se. Which other cloud event is this one related to? So it's slightly different but I can understand why you can kind of view it that way. So we are technically I think out of time on this one cause I did try to, I wanted to time box this. However, I do think at the end there we may have actually come to a possible direction. Klaus, would you agree? Yes, I wasn't never really happy with this logical system phrase but I wasn't able to come up with something else. So this context phrase I love, so that's great. Okay, so it seems like maybe it's modifying this as we just talked about and then also modifying this a little like maybe even just get rid of that sentence right there. We maybe have the direction that people can consider. That's not right. No question. So I'm going to define the title how to represent the producer in the following section or we just define source but we do not define the producer. Is there a need for a field for producer? Can you think of one? I'm not sure yet but I'm just thinking we define this. So what's the... Matthew, are you talking about having another field to the cloud event spec called producer? No, I'm just thinking whether we need to define anything. So we have a common knowledge here, right? The producer, right? Is there a need? We should define how to identify this producer. How is there a need? We need to access this. I think Topini's question is the right one is do we have a use case that actually needs it? And then we can talk about it in more concrete terms. Just because I can't come up with any reason I would want to know the actual bit rotting machine that produced the event. I just want to define the producer but I don't actually care about it after I have that event. I care about the source but I don't care about which machine actually created the event. That should be handled by tracing or something. Okay, we'll think about that, Kathy. If you could think of some use cases where it might be useful then I think it'd be an interesting discussion to have but within the context of this I do feel like we have a possible direction to go forward. So Klaus, are you okay with taking another pass at the changes here? Yes, I just wonder if I need source on the terminology section if I just adjust the field or the attribute definition. I think it would be replicated at least. Anybody have any opinion on that? Personally, I'm in favor of consolidating, if you can. But that's just me. No, I don't think there are many uses outside the source attribute for the term. So in that sense, I think it should be consolidated but if you can just like search through the spec where are we using the term source? And if there's a lot of uses then it should be defined separately, I think as well. Okay, so I think that the term producer might be used in many places and maybe not always in line with this definition. Yeah, I think there's a need to just go through all of the uses of source, producer, consumer and intermediary like when we are at ABS terminology so that they are not in conflict with the users. Right, okay. And I think with that we're going to call it time even though we're away for 15 minutes. The only thing I'll say is to address Mark's comment earlier about making sure we get alignment with the primer and other documents, I'm assuming we can do that as a follow-up piece of work once we get this definition nailed down. So I don't think class, you have to do everything at once. I think we can do it in stages, okay? All right, with that let's move forward to optional event ID. I don't believe, I think this is from Alan, right? Yeah, I don't believe Alan is on the call and I don't think he can make it. However, the general idea here is he wants ID, right? Yeah, he basically wants ID to be optional because he has some systems that do not need it and it's very costly for him to actually produce it in all cases. So I wanted to bring up the discussion here and see if there's a general direction the group can agree upon. In particular, let me get his last comment. If we, because Clemens made an argument for keeping it because we're actually operating at a different level and here was Alan's response back to that. I'll let you guys read that very quickly. But Tim, I would tend to agree. I believe that Alan was saying that in some cases for him anyway, UIDs are not cheap. I just don't know who to believe on that one, to be honest. So anyway, I'll let you read his comments here. Okay, let me open it up for discussion. What do people think about making it optional? Because right now it is required in the spec. Thank you. That's good business, Tim. So what do people think? I don't understand his argument. Because it's like, I don't understand the case where you would not want to make it unique. Like there's a, it seems like Alan tries to make a case where there is a case where you would explicitly not want to make it unique, which is a little strange to me. And then there was another argument made that is in the bug, where this comes from, where it's like, there might be sufficient information inside of the event to make it unique. And I agree with that, that there might be. But the point is to further, and that was the counter argument, that we want to have an interoperable way of ensuring uniqueness. And that's by introducing that field. So even if you have four fields that take them together, create uniqueness, then the way how to make this interoperable is to concatenate them and put them into a field where everybody can go and pick them up. Because the duplication is kind of the guiding scenario it seems like that was made in this thread. But there are also cases where you want to go and take a bunch of events and store them in a database so you can go and look at them later. And for that you need to have at least a primary key in addition to whatever keys you want to look up. And that is the combination of source and event IDs will be identified for that. Time was another factor that was suggested and of course clocks are terrible and you do great things in parallel and there's time or resolution. And if you compensate for clock skew then your clock may actually go backwards, et cetera, et cetera. So that's not a good way to go and create uniqueness. And as Tim wrote, UUIDs are cheap. So I'm not sure what the problem is. Okay. And I'm also saying a whole bunch of negative ones to make it optional in the chat. So thank you guys very much for speaking up. I appreciate that. So let me ask this question. Is there anybody on the call who would agree with Alan that we should make it optional? Even in the slightest? Just to throw a wrench in there. UUIDs are cheap. They are cheap, but you might not be able to guarantee a very strong uniqueness in some embedded scenarios. You might not have a lot of potentially. But you have a source that is scoping the ID, which means there you can go and just, you know, keep a number that is monotonically increasing and store that locally, your counter. Yeah, so I'm not hearing anybody jump up and down and say they want to keep it or change it to be optional. Is that a fair assessment? Okay. I don't think there's any point in us dwelling on this since I don't hear anybody on the call willing to advocate for Alan's position. However, what I'd like to do is go back to Alan and say basically, no one else wants this change. However, if you can come on next week's call to make a case for it beyond what you've already said in the issue, you know, willing to give you some time to talk about it, but barring that, it sounds like the will of the group is to close this PR and keep the spec the way it is. Is that an accurate representation? You guys okay with that direction? Yes. Sure. He said in the last comment he made two hours ago that he can't make it today, but he will add it back to his calendar because it fell off. So I guess he can be. Right. That's what I was hoping. I didn't want to just close this without giving him a chance to speak for himself as in real time, as opposed to through comments. Because I think he does feel passionate about this. And I don't want to miss out something if there's something he hasn't said in the comments there. So, okay, let's do that and see if he can come to the call. Otherwise, I don't think it's worth our time dwelling on it here since we all seem to be in agreement, I think. Okay, so let's get to this one. Now, as of right now, just to refresh everybody's memory, basically source plus ID defines uniqueness. And Scott, you are still there, right? Yes, Scott. I believe on last week's call, you were going to go off and think about some of the discussions we had last week in terms of whether you were coming around to saying, okay, ID is sufficient for uniqueness, at least within the scope of a producer. Have you had a chance to think more about that? Scott, is your mic not working again? He's having issues. Let's give him a sec. Well, I look forward to see what the next issue is. Unfortunately, the next issue involves Scott as well. You think ID is okay? Okay, is there anybody? Okay, so in that case, it sounds like we need to go back and just review Allen's PR here because I'm pretty sure this PR pretty much just says source plus ID needs to be unique. Because we spent so much. Sorry. I'm sorry, yeah, go ahead. There's great examples, new examples and source. I think the clarification of source is really good in this one. Yep, yep. So I don't want to try to close this one because I think enough people have kind of ignored this one while we went back and forth on whether ID is sufficient that I want people to have another week to review this. But otherwise, this PR, I believe is ready to go. And I do believe that we can, that's right, go ahead. I was just going to ask, the definition of source here seems like it's prior to the addition of subject. The internet-wide unique URIs seem a little bit strange for GitHub, where I just expect some part of that to be in subject instead. But I can follow up on the issue. Yeah. I think that's a great comment, Evan. Yeah, if you could put a comment in there and maybe Allen can make some changes here accordingly because you're probably right. I think this was probably originally written before subject. Can I stay comment on that? Because I don't think that. That's true because, for example, for GitHub pull requests, I would expect, for example, a comment to have that. That example as the source and the subject to be something about the comment. Maybe I'm wrong. But our experience has been that usually you're interested in all pull requests on the cloud event spec, for example. And it's nice to have that in a field where you can do a match that's not complex. Correct. That's where I'm coming from there in terms of usability. So, Evan, I want to make sure I understand. Are you saying that basically in this example, this that I've highlighted would be the source, but then the pull slash one, two, three would be the subject? The more pull one, two, three, hashtag comment blah, something like that potentially is the subject. But I'm saying that having the source be somewhat more consistent is helpful for many routing scenarios. If we scroll down in the subject, I should just go to stop. Oh, here we go. Or at least it did. Yeah, it's not expanded, so you can't read it right now, I guess. You put up a little... Sorry, I got confused. I was looking at the wrong section, sorry. And there's still a little bit left, but it's like 10 lines, so. There we go. Yeah, see, there's a discussion in the example. Okay, well, it sounds like we're all heading in the right direction. It may just need some minor twiddling to the examples. I mean, we can work that offline through comments. Does that sound fair? Okay, Kathy. I was wrong. Okay, that's fine. Kathy, your hands up. Yeah, I see here, you know, definition of the source and producer is mixed in this here. Which section are you referring to? Let me see, can you scroll up? I saw something before. So here is the event producer. This is source definition, right? Yeah, we're talking about... Yeah, we're gonna remove that. Yeah, and also it mentioned, you know, the process that produced the event. So based on previous discussion, looks like this should be the producer, right? Well, so, okay. So I believe that this text right here for the most part is untouched in this PR. So whatever Klaus comes up with for new text, we'll probably replace this if he touches this text. Oh, I see. Because I saw there's a minus and plus, so I... Yeah, and I think that's just reformatting, I think. Oh, okay. You could imagine it identifies the context in which the event has been created or something like this. Yeah. Instead of identifies the event producer. Right. Yeah, but I think just formatting this is the big issue there. I think this is the beginning of the new stuff more than anything else. Gasi did make a good point in that the specific part of the first paragraph, the process that produced the event, that is also in conflict. So... Yeah. Well, it depends on how you define event, right? Is it cloud event or... Oh my God. Sorry. I'll let Klaus worry about that. Yeah. Okay. Anyway, I think if you guys can make your comments on the examples in here, I think we can make some progress and maybe only get this one resolved next week. Cause I don't think really all headed in different directions. I think we all go in our head in the same direction. It's just minor tweaks at this point. And Scott, you can't come off mute yet, can you? Maybe. Maybe, yes. Excellent. Did you want to talk to this one? We only have like three minutes. Don't use quotes. Don't use quotes. Okay. Did you want to talk about any of the proposals separate, cause you made some changes in here. And I think you and I aren't necessarily too far off in the sense that ignoring maps for a minute for pretty much all other attributes, I think you and I are both saying, treat everything as a string, right? Yes, but only for the cloud event context and extensions. Right, not data. And I'm not even missing maps yet, just the other attributes. Exactly. Right. And so what I wanted to quickly get a sense from the group is whether you guys think that's an okay direction to go. I believe right now, integer is the only other type that we actually define inside of a spec. So I think we basically end up dropping the entire notion of types and then figure out what to do with maps later. But everything basically just says it's a string and to serialize it. However, strings normally get serialized in whatever transport you guys are sending this over. What do people think about a general direction like that? Clement, I'm gonna pick on you. I was waiting for that. Let me think about it. Okay. In that case, someone can think of another topic to bring up in like two minutes, which I don't think we ever can do. Let me go back and just do a quick roll call. Dan Barker, are you there? I'm here. Excellent. Javier, are you there? Yes. Okay. Is there anybody else that I missed for attendance? I think I have everybody else. Okay. In that case, you guys are free to go unless you wanna join the Kukla.edu slash demo talk immediately following this one in three minutes. But thank you guys very much. I know we dove deep on some issues, but I think it was all a good discussion. So I think we made some progress. Thanks guys. Thanks Doug. Yep. Thanks Phil. Clemens, you're gonna stay on, I assume, right? I will. Okay, good. Cause the reason I'm picking on you is because I know in the past you mentioned that you were gonna do an implementation. I wanna make sure you saw the way to stuff. Yeah. Yeah. I'm gonna be away for exactly three minutes as I'm listening to a message, but I'll be right back. Okay. Sounds good. We got time anyway. Do, do, do. Okay, it's 1 p.m. But I'll give people one more minute before we get started. It is time. Hey, wait a minute. We lost Scott. Let me ping him. I have returned. All right, cool. Well, let me ping Scott. Cause I think he's the only other person who might've actually had a running code recently. Okay, let's do the easy stuff first. Relative to KubeCon itself for the presentations and stuff. I know that some people have been putting in some slide information. Are there any topics people wanna bring up there? Any questions, concerns you'll have or is it just a matter of finding time to fill out the slide deck? You were going to slides. Can we do them PowerPoint? You know, I honestly don't care other than I think having someplace. Well, actually that's this question. Does Microsoft have the ability, sorry, does Microsoft, does Office Online have the ability for random people to make comments? For random people to make comments, you mean for anonymous contributors? Yeah, not necessarily make edits, but add comments. That I don't know, but I can go and find out whether that's a feature of. So it's either one, so I think if I give you an edit link on OneDrive, everybody can edit it. Who has the edit link? Yes. Anything is better than Google presentation, shits. It's like whatever. Okay, I personally don't care what we use as long as it's shareable by everybody. Because Vlad had the objection also in like, I don't know how to do this Google Docs thing. We're kind of the same in that one. Okay, honestly, I don't care. If you guys wanna switch over to Microsoft Office Live or whatever it's called, I'm okay with that. I don't care. Okay, great. So Clemens, if you can take the action item though to set up. Yeah, I will put this on my personal public OneDrive, which is the easiest thing. And there's the online thing, and then we can also edit in the app, depending on how you want it. I can send everybody this count code. So hold on one second. There is, where is it? Somewhere in my notes is the link to the actual PowerPoint slide deck that we're supposed to be using. Let me see if I can find that. Oh, you're telling me if the original is actual PowerPoint? Yes. Doug, what are you doing to me? I thought Google Doc was the easiest, but that's fine. Hold on. Where is this? Wait, this is, that's KUKON China. Hold on. KUKON China. Yeah, okay, I don't want to waste your time. I'll find it offline, but there is a real PowerPoint and I'll send that to you. And then if you can get that set up, I don't mind switching, that's fine. Okay, so anything else relative to the slide decks for KUKON and EU that I want to talk about? Please look over my proof concept example I still think it's a bit too small, but then again, initially it was bigger and I spent like 15 minutes of the, 15 minutes I had explaining it and that was not fun. So I really want to start working on it this weekend. So I'll need a couple of eyes on it. It's basically a Blanda with tracing done by Honeycomb which is going to be put in an extension. So it's nothing too big and I will be reluctant to make it bigger because again, I don't want to spend like half of the time explaining a convoluted demo and yeah. When you talk about reviewing something, is that the note that you sent or did you put something into the slide deck? I fought with Google slide stuff for an hour and I managed to put stuff in there. I'm very proud of myself. Okay, so I assume it's this presentation right here, right? Okay. Yeah, I think. Okay, let's just double check. One that has slides, yes, this is it. It's there, okay. That's the email I posted. Slide five should have had another logo but Google she doesn't understand SVGs. And if you scroll down there's slide 11, I think it is. Like this is the very, very high level didn't implement anything proof of concept background. It's basically gonna wait for two events to come. The events come their process on some kind of gate. They go through a Lambda that deploys to EKS using Helm because those needs compliance and you can do really nice stuff with Lambda and EKS due to the way AWS does authentication. The cloud events thing here is again saying, hey, cloud events are here, they're boring use them. And I'm gonna be using extensions for honeycomb context propagation. Again, this might change as soon as I start implementing it because I might have imagined it wrong but an early review would be good. Okay, so everybody when you get a chance please review that before the end of the weekend. Or be more aggressive. Yeah. Okay. Anything else relative to coupon then? Alrighty, let's jump over to the demo. All right, so Doug, I wanna quickly ask you the question I asked through Slack. And I know you responded by having a chance to read it yet. My biggest question was just, this is a good example, right? So the trigger for someone to know whether they're supposed to do something or not is they look at the source, the type which are both cloud event attributes but then here they have to actually go into the data to figure out whether it's something that they care about. Would it be horrible if we were to create either two new extensions for this information to go as cloud event properties or potentially even modify an existing property like for example, order to be just order.orderreleased. If we make those types of changes is that gonna break the model that we're trying to adhere to? Not if you separate them into two additional elements. If you tried to put it into types then it would break the model because there's three, there's the attribute value pairs that are currently in the data attribute. And if you just separated, if you took the attribute identifier which is tied to the semantic model and you put that into its own element, call it attribute or property and then you left data to just be the value of that attribute and that works. But then the way that we're using data currently is that it's supporting multiple attribute value pairs. So associated with the one subject within one cloud event, right? So that you can take that cloud event, go into data and see everything that you would need in order to conditionally react to it. And if you took attribute into a separate, if you separated attribute and value then you would have a separate cloud event for each one of those, which then you would have to be able to look at a collection of cloud events before you could react. Well, so wait, I think maybe some confusion here and I don't know whether it's on your side or my side. Let me ask you a question about this field right here, type equals order. If cloud events did not exist and you guys just said, here is a, here is a, what's the acronym I'm looking for? The heiress, no, aqueous. If I just said here is an aqueous event, is this what I've highlighted, the entire aqueous event or should type technically be in there? The event is really, again, we're using this right now to originate orders, which is gonna have a collection of attribute value pairs, that represent that order. But typically the event is just gonna be a state change of one attribute of one object. It could be the status of order 1234 is fulfilled, right? It could be the temperature of room 101 is 75 degrees Fahrenheit. Those are statements that include a value, like 75 or an enumerated value like fulfilled, but then the rest are tied to a semantic model, which would be the type or class, which would be room or order. And then the subject or object, which would be 101 or 1234, and then the attribute, which would be temperature or order status. So it's trying to take those components of that statement that's reacted to and separate them into distinct cloud event elements. And right now we're using data for both to store both attribute and values as pairs. But what I guess I'm trying to wonder is whether we have, whether the cloud event attributes like type are duplicating data, I'm sorry, duplicating information from data, or whether we have pulled information out of data and now only use the cloud event attribute for it. And the reason I'm asking this is because in my mental model of cloud events, they should not be modifying the original event itself. Cloud events is all about adding information to the event to make processing easier. So that may mean in some cases that you are seeing duplicate information, the cloud event type as an example might actually already be represented some place inside of the data attribute. And that's okay, because it means two different things two different people, right? The processor of the data section is gonna have one meaning for it, but at the cloud event level, it has almost a slightly different meaning sort of, but it's okay that it's duplicated. And so what I'm wondering is, when you talk about this field and our use of it, violating the accuracy model, that makes me start to wonder whether we've made a mistake and whether order should be in here someplace. So it should be type colon order inside here. That way we can modify this to be anything we wanted and it doesn't break the accuracy model because this is only used by the cloud event routing processor. It's not used by the business logic which cares about type equals order. You understand what I'm trying to say? So in the microservice that's going to act, potentially act on this event, right? And they would need to be able to look into data to say, okay, this is type order which that's important to me. And then I'm also looking for the order status is that's important to me. So the function or microservice would have to open up data and look at all of this criteria before it could know to react and produce a new event. But you're saying from a routing perspective that type could be used differently. Just to be able to route it to that function for consideration. Yeah, so in my model, the component that it's actually going to process this event should only ever, for the most part, look at what's inside data. The fact that there are cloud event attributes should almost not be known to the processing function itself because the fact that this was sent using cloud events should almost be oblivious to it or it shouldn't matter to it. And that's why I'm wondering whether we've made a mistake in pulling out some business logic attributes like type and only put them out here. Just nice. How would you format type? If you had it, I mean, you're putting order in there, which is obviously that in the semantic model is the class. So you want to say order released, but what's missing in there, you have the class and you have an enumeration of an attribute and you're not including the attribute. You're saying order released, like there's a direct relationship. I mean, there's only one status or one attribute of an order, right? Order.released. And what really it is is it's order status released. And you know what I'm saying? There's three parts to a semantic model. There's the, in addition to the subject, which is the instance of that class, order. Okay, let me pause here. What are the people on the call think? Am I headed down a really weird path or is everything okay the way it is in your guys' eyes? Because I was bothered by the fact that I advertise cloud events to people as we're adding metadata to help routing, right? And you can send any event you want and all we're doing is adding a couple of extra HTTP headers and life is great. Well, as I was coding this up and you come across things like this trigger line where it says, okay, how do I know as a retailer whether I'm gonna process this or not? Well, I can't just look at the source and type anymore. I need to crack open the data and understand the schema of the data to know how to go find order status and the provider fields just to know whether I need to process this or not. And I don't know whether that's okay or not. It looks like the order released is really what the event is, right? Is it? Is that state change that's significant? It's both, I think between type and order status and that encapsulates the state change, yes. And the provider, so the provider is the retailer. Who's the provider here? Remind me of that. So in this particular message a customer placed an order. Oh, I haven't looked at a different example because that's actually a very, very bad example. No, but bad examples are good. Well, let's do an easy one first. Okay, so let's look at this one. So a retailer is gonna be ordering more cups. So this event is supposed to be eventually picked up by a supplier, okay? So the source field is retailer. The retailer in question, type is order and then order.status is order released. So in this particular case, should this, is it okay that as a receiver, I need to look inside data to know whether I need to process this or not? Or is that just part of the business logic? And sometimes business logic is eh, I'm not gonna do anything. That's okay. For me, the question is, are there cases where you're raising the order events and so the type order event and that only differs in terms of what the order status is. Like, do you, because that's the question. Like, should there be an order.orderreleased event and an order.ordercompleted event? That because this seems like if I draw the parallel here to the blob store thing, right? Then the type is, if the type is just blob and then you have a blob status that is created and deleted and amended or whatever, that makes dispatch really hard. So I think the type should really go in fully enclosed and incorporate all the information that you need for dispatch. So the idea here was to tie cloud events to a semantic model that provided semantic interoperability as well as interoperability within the syntactic, syntactics of an event. And so if you look and looked at what schema.org has, right? They have a semantic identifier for a type or class called order. And in there, an order has certain attributes and there are semantic identifiers for each of those. And then if that attribute has values that are enumerated, then it defines each of those enumerations as a semantic identifier. And so the idea was is that if everybody was, if cloud events included those identifiers and everybody was adhering to the schema.org model, then everything would be understood inherently. And that's how the demo has been laid out thus far to adhere to that. If you go and put in type, something that is different than that model, you're putting in something that you're making up just for routing, then that's not tying everybody up. Everybody to the same, to a common semantic model. You're looking for everybody to react based upon something you're making up rather than identifiers that have been publicized for everybody to adhere to for semantic interoperability. The question I had was is order, what is the event? Is the event order or is the event order released? The event is the statement. The status of order one, two, three, four is released. You could have another event that said the shift to location of order one, two, three, four is something else that maybe it changed and that would be another event. So it's- So then the event type is really order.orderreleased because you are reporting out the status change and you're reacting to a particular status change. So within the order, and I think that's also what you just described, within the overall type order, there's multiple events that can be raised, one of them is order-related. So when you map that one, but when you map that to a cloud event, then the type that shows up in the cloud event is not the type, the semantic model type that you're referring to, but it's really referring to the status change event that you have. So it's kind of, the mapping is not direct from the business scope type to the event type, but really it's from the event that just happened inside of your business object to the cloud event. Okay, but you're taking, let's take the, you're saying order released is an event of an order, which is one type of an object, but if you were to say, you're going to take action on an event and do it the temperature change in a room, right? Yes. It's not just room temperature change. You know, it's going to be the temperature of the room change to 75 degrees. So it's trying to create a model that can accommodate all of these different changes. Well. In all these different events, right? And so you couldn't use what you just talked about where you put into type anything where you would take action. But let's see, that's what we're doing, what we're doing for instance in, let me map this to something we do in Azure, right? You can have a, in Azure in the blob store, right? We have a concept called blob. And you can go and create a blob, you can delete a blob, you can go and amend the blob, and you can change the properties of the blob, but let's stick to delete and create because it's easy. The create event is, the create event delete events are distinct, distinct events that applications are interested in separately and mostly all of the apps subscribed to create. So we're presenting this for practical reasons as distinct event types. Blob created is distinct event types and that is part of Microsoft.storage.blob. Blob created, so it has a hierarchy. It's kind of sorted into the general model of, yeah, this all belongs to Blob. So that's part of the type, but really it goes, it's scoped down to the event that was raised about the particular object that I'm describing with the subject and the source. It's a distinct thing that happened to that blob and that is the creation of it. And here you have a distinct thing that happens to the order and that is the release of it. And that is what that event was described. So it is, this type field here is about the event type and not about the type of object that the event is about. That's something you express with source and with subject. I'm still not sure how you, again, if you made type, in this case, order.released. Yes. Where it's the class and the status and the subject is still I assume the incident or excuse me, the instance of that type, which would be order. Yes, right. Okay, so if you, that this is one example where this seems to make sense. Now, go and how do you model a temperature change in a room in a similar way? Well, you will go and the temperature change. Oh? You would have the, if you want to, if you want to. What would be the type? What would be the type in that case? Sensor red. Sensor red or sensor change? It wouldn't be a change because you don't know if the actual temperature change. Exactly, it just changes the delta. That's the result. Well, you can go and do it and assume that there's some analytics and some state machine and the state machine has now decided that the change is big enough to admit you threshold, blah, blah, blah. So you can go and have a sensor change event. Think if you start putting things together here in type where you're constructing something that is arbitrary and not tied to a semantic standard, then you're disconnecting from the semantic model. But this no longer is. But I'm not. I'm, what I'm doing is- Can I try? I think what we're trying to say is it's much more difficult to not embed the state machine of status inside of the type because you don't know how to route the next state change. So order is the class, but order released is the state of that class. So it's not arbitrary. It's well-defined for this particular state machine. What if, just for kicks, add two other extensions here below type where you left type as order and then you put attribute or property, I don't care. It's just something, right? And then you put in their order status and then you put value, which I still think could be data, but let's just say value for it, right? And then you put order released. Oh, did that just go- Okay, if it was- Okay, sorry. So the thing you're conflating or it seems to be conflating is that you're interpreting type as the emitting class and that's not what it is. That's how I had used it as a placeholder for class. And the type here is really this distinct type of this particular event. If you were turning this into an object model, literally would have a class derived from a cloud event that would be called order released and it would have a different class that would be called an order shift. So you would have distinct events which are literally incorporating the thing that you want to tell which is the distinct state change that just happened. And if you go and take a look at you, if you visualize the state model, the state machine for order processing, right? There's the state transitions that happen on if you imagine in your head the state diagram then effectively all the arrows that go between the states, they're all effectively events that are being fired as an effect of that state change. They're kind of the photons that are being emitted from that operation and each of those has a distinct type and that distinct type is that type here. Okay, and that's fine, but let's just go back to how this model extends beyond just a, you know, or because you we could potentially under type keep the order part tied to the semantic identifier of the order class within schema.org, right? And then order released is pretty much a unique, globally unique enumerator, right? So we could use that, but then I still wonder, there are other events even in this demo that are tied to a value. So there's inventory level going down to zero, which is triggering something. So how does that get modeled in that case? You have an inventory, the inventory, like everything that raises events has a state machine and the transitions of those state machines raise events. And so you have an inventory, you have the inventory that goes down to zero, so you have an inventory that has a state machine around count and either you raise an event around the count change or you have a effectively an alert that's being raised, only when that count goes to zero, then you have an inventory, exhausted event that you're throwing. So it's scope, the source, so the source here is the source is the order system, the subject, so that on the inventory, the, well, the offer. So if you look at type, let's just put it in there and try to lay it out the same way. Go ahead and remove attribute and value from below Doug. So we don't get that confused. Okay, so we got, so we're gonna model the inventory level dropping down to a below threshold as an event that the action's gonna be taken. So in type below, you had, again, tie it to semantics, you had order, which is the class, and then you had an enumerated semantic identifier for an enumeration after the dot. Okay, so if we try to keep it a unified model, then you would put under type the, what we're calling offer, which is what we've been using, and then you have as an attribute of offer inventory level, and then which is not taking on enumerations, it's taking on just values and integer values, right? So how do I help? My point is, these are state changes that they're reporting out. And the inventory level, per se, that value is if you want to raise inventory level changed, which means if you want to go in and report out every time you add something or remove something, then that's what you would do. You would raise the inventory level changed event, and then you can go in and filter on this, and then you can look into the detail and find what the inventory level is, but you can go in dispatch on this, or you could also, you could choose to only have the inventory level exhausted event, and the inventory level replenished events, which is effectively just around the threshold zero, if you only care about that. And so all those things that you're calling it don't tie to the semantic model. Yeah, and at that point, then I have to say that the semantic model is then missing something that's important to build an app. Well, so before we head down the path of saying there's something wrong with the semantic model, I don't want to go there, but let me ask a slightly different question, because I still feel like that what we're doing today is we are mixing where information goes. I feel like we are putting business level logic sometimes in the data section and sometimes in the product, in the product section. And it feels like that's not appropriate. It feels like all the business level logic needs to go into the data section period. And anything that appears in the cloud events section is just extra noise, simply for the purpose of cloud event routing. But if cloud event wasn't in the picture, a receiver of what's inside data should still be able to get his job done. Am I incorrect in this? And the reason I'm, it's Doug, but what we have here feels like it's wrong in the sense that I think this should have offer type offer in there someplace. Well, what is in data currently are attribute value pairs, where those attributes are associated with the type offer. Right, but how? So they're not all at the same level. You're combining in data attributes in a class. Would this be more appropriate then? Yes. Would that be better? Yes, but then you have to open that up in order to know whether to take action, which is fine. You open that up and that's what goes through your rules within that function. Well, it depends on when you say take action, I think it depends on who you're talking about, right? When you're talking about business level logic that says, okay, I need to know that inventory is zero to know between more cups. That I agree, you have to open up this section to know how to do that or the weather to do that. But in order for, but when you're talking about the action is simply, is this an event in general that I may or may not care about, right? I don't think I should have to crack open this information to get there. I think I should want to explain what type of event is coming into me. And in this particular case, what the type of event is offered at inventory level. And that is a field that is 100% cloud event defined. So that if you're not actually using cloud events with the aqueous model, this field does not exist. It exists only because you're using cloud events. And therefore it's within our domain to define. Even if we call this the same, I'm not breaking the aqueous model. Okay, so what in this, that's fine. What you show there is fine because it's still tying back to, I don't think you need, I mean, if you construct type as being offer, right? And then dot, and in this case, it's the attribute identifier of an attribute of offer. You know, that works. I don't know why you need offer again and under data. I mean, okay, but if you change that to depleted, then where did that word come from? You're making that up. That doesn't, that doesn't tie to any, to the semantics within schema.org. Right. And the reason I added that was to make a point in the sense that we could make up anything we wanted here. And I don't think it violates the aqueous model because the aqueous model has total controller what's inside. And we, as a organization, if we could, for example, say, when you take the aqueous model and map it to a cloud events, this is what type is gonna look like in particular cases. It may, sometimes it may be exactly pulling in something from here, verbatim. Other times it may be no. When this value is zero, it's inventory depleted. In other things, it's inventory status. My point is the business logic from aqueous perspective should not care about this value because it should never see that value. Is that, does that make sense? It does, but you're still having all participants, that what you put in type are semantics, right? That everybody that is subscribing to this ecosystem would need to know about, right? And that in the, I don't know, I don't know what to say. I feel like there's two, you're trying to accommodate the semantics just throw it all in data just to say, hey, there's the semantics, but the whole purpose of the semantics identifiers was that it here to a particular semantic model and didn't get supplemented, which is what you're doing here. You're doing offer, which is good, but then you're changing it to inventory depleted, which you're making up. But the semantics model is a static one, right? It's describing the state of a thing. What events do is they describe the change of that thing. So there's a natural mismatch because you go in, if you look at the semantic model, you're really looking at a static state of the world right now. And what we're doing here is we're actually reporting out on changes from changes from one state of the world to the next state of the world. And that exact state change is the thing we're reporting out here. So- And you could say offer dot inventory level and that implies that there was a state change to inventory level, right? If you just kept it like that, offer dot inventory level, you know that changed. You can imply that it changed and if you want to know what it changed to, you got to look into another element and you can do this. I agree with you. So I agree with you for that particular instance here, that actually makes a lot of sense. And for order status, you could do the same thing. So for the one below, you could do the same thing. We can say order, order status and there's an order status change if you want to go with it. It changed, right. If you did that, I'd be golden if you could live with that. So we can, so when I'm pointing, so we can certainly live with the order status, the order status change, so, but. So, and here's where it becomes, here where it comes interesting from a practical building the application perspective. If you only wanted to, if you only want to react to the order status change of released and, or if you only want to react to the fact that the inventory level just dropped to zero, then you need to be able to go and filter at the infrastructure level over, which has no notion of what your data fields are. You should, you need to be able to go and filter based on that. And what you will want to be filtering on is some field that is well known and well understood in cloud events. So, so as just added, so you might have order, order status, not order release, that's a type that is now effecting distinctly saying, here's a state change that just happened, right? And that state change is the order release state change. And on the inventory level, since that's a number, you probably don't want to report out every potential value. I mean, you could as we discussed earlier, but inventory level depleted basically just means at that case it's zero, which is a distinct thing you might also be interested in. So, there might be a case here that for in the interest of the application and the subscribers of the application, you may want to go and take specific, specific stages and report them out separately. So, for the benefit of the application. So, what if we just did this, right? Because what's left in data up above under, let's look at the top one, right? There's a lot of things in there that we just used to facilitate taking action because we weren't persisting history, but let's say that's the only thing that data would be in this case, if you have offer dot inventory level and the type would be the number zero, which you could filter on. Because data at that point is just the value of your type, the state chains of the attribute of the class that you've got all in type. And is that adequate? Well, I have a, we have a, so now talking product. On the product side, in our world, we have an iron clad principle. And that is we never look into the message body for anything we do in terms of dispatching. Like my middleware would not be able to look into data. Okay, how about having an extension that an element that's just value and we don't even use data? But now you're just trying to accommodate the limitation that I've just put up. Well, so it seems to me there's a high order question here that's in my mind, which is at what point do we put all data into the cloud event stuff versus keeping it inside the body, right? When do we leave the boundary of routing versus business logic? And I don't want us to convert everything, because we could take this type into offered inventory level dot zero dot small, right? We can go really far in this thing and get rid of data entirely, but that's not really what we're meant to do here. So it feels like there has to be a line someplace that says you want classification, routing information where you wanna call it at the cloud event level, but business level logic that's more specific to this type of event that stays inside data, but it's the type of information not the event that has to go on. It's gotta be a balance. You want to optimize routing to a certain degree, but then you don't wanna, you've gotta be able to say, okay, I'm gonna route optimally to this point, but then after that, for those that did get it routed, are looking at that, that they got routed to, but they still don't know if they're gonna take action, some will, some won't, they got it routed to, right? So there's balance, I think. I just don't know where that line is. Well, I think that the way you have type right now, that represents a level of balance in my mind, so you're not having to go into data to go get inventory level as the specific thing about the offer that changed. Okay, are you saying that you think just this one is okay or this one is okay too? No, the one below would be just, again, you have to be uniform in the model, and so it'd be order.order status. You know that that changed, and so you would have to go in, you'd route an order status change to those that were interested in it, and then they go look into data to see that it was order released. For a particular application that might be a reasonable choice. Right, and so, because I was trying to equate this back to the examples you were doing, kind of a S3 data store kind of thing, right? Do you want to be able to filter on what creates versus deletes? And obviously for an S3 type of bucket thing, I think that makes perfect sense because that's what they do today, but maybe in this particular application saying you're going to filter on the order status, that's a business logic thing. That's not a routing thing. And I think that's a perfectly fine choice, which means if we get rid of this, then in order for someone to take action, they still have to go into the body, but we're going to mentally say, and that's not a routing decision at that point after a business logic decision. Yes. And I'm okay with that, as long as that's the way to be presented with some of the masks that's about to happen. Yeah, I agree. And again, type is not fully optimized for routing, but it's giving you a significant benefit and being able to support semantic interoperability at that point. Right. And that's a huge advantage for that trade-off. And I think what we have here is as I just said, excuse me, it's a fair trade-off because when we had type as just a single word, offer, order, that's not really a whole lot of information because there are so many different types of dog. I can understand that that would not be appropriate. Okay, so let me ask this. If we change these two type of things, what is, do we need this or can we live without that? Well, I'm sorry, I'm sorry. Just the word offer, just the wrapper of the offer because we don't have that today. You do not, you don't need the word offer, no. Okay. That's parsed out of type. Okay, good. Okay. So is everybody on the call okay with this notion of going through here and any event that has just basically a single word up top like order and offer, we're going to augment that with additional, with at least one more level of filtering capability. Yeah, that would be good. Okay, then it's worth looking at though and just for the order origination then, which includes multiple attributes, attribute value pairs, then I would assume that your type is just going to be order. Wait, which one, which example? Well, it's when a new order is originated by either the passenger or by the retailer. Okay. It's going to include multiple attributes. So here, customer's placed in order. So I would think that that should just be type order without an extension to a particular attribute. Would this not be at least be order released or order status change? Sorry, would it not at least be order status? Because that's what's happened here, like the order status has changed and that's the reason we're sending an event. In this particular case, it's a brand new order. This order, that order released. You need to know it's new. Well, I think that's what we're talking about really is where is mine, right? Is it, are we stopping at just the fact that the order status has changed or do we want to also filter and read on the value of the status? It would make implementing this much easier if the order status isn't the type. It may be, but is that business logic or is that routing logic? That's the question. It's routing logic. Well, go ahead, Collins. I'm leaving, especially for these distinct state changes on where you already know, kind of you have an enum for an order status, then I would say also, like you will have a, so for me, the question is, perspective of what the semantic model structure and consistency considerations are. Which, what are the handlers, the handlers, the handling code look like that you want to wire up? For me, if you have these state changes on an enum, you will typically have some code that is handling each of the different state changes. So for those, I would fire different events. For the inventory status, that's probably a different thing. If you choose to go and raise an event every time that number changes, then you will have one handler. So on the two examples that we have here, I would probably have a single event raised for the inventory level, but for order status, I would have distinct events raised for each enum option. And I'm fine with putting a dot after that with the specific enum. You mean like this? Yeah. Okay. And then you can just say the way we're implementing this is that if its type is gonna have both the ontology class and the attribute identifiers, and if that attribute is an enumeration, you'll follow it with the enum that you do there. If the attribute is just a value, then you have to go pull the value out of data. Yeah. Does that work? That would work for me. I'm not sure I followed the last part, so let's go through. So going back to inventory down below, you don't have a dot after inventory level because it's not an enumeration. It's just a quantity value. Gotcha. So if it's a quantity value, you go into data and pull the quantity. Okay. I like that. The consistent pattern, I can live with that. Scott, so in this particular case here, you just have to go into the body to look at the provider, but I think that's okay because that's more along the business logic side of things. I think. Okay, so let's see. So in this particular case, this one would change because that's an enumeration, right? Right. And here, I think this would change too from the action status, is that right? And this would be, is that correct, Doug? Yeah, I mean, what you're doing here, I don't even wanna bring it up. That's fine. I think it's, I'm good with this. I got a little nervous, but this is fine. It ties completely to the semantic identifiers. You're just, and you're making it easy for routing. And you're using it uniformly, you know, within here. Yeah. Okay. Okay, I'll go through and add these things. So this is action status. Okay. Anybody, while I'm doing this, changes anybody on the call? Have any questions, concerns, like this? Yeah, why don't we have action and order status? Just make it status. Oh, I'm not gonna touch that one. It's, it confuses the program a lot. Have those two things. But they make sense. Well, but you don't want to change that. You'd have to change the model. And I think that's one of the things we're trying to avoid, right? No, the model is wrong. It shouldn't have action status. It should just be status. No, I understand, but my point is actress, actress has a model. And I don't think it's in our preview, because they changed that model today. Well, and we're not even, these identifiers are coming from schema.org. So it's trying to align with schema.org, which everybody is familiar with, you know? I don't, I don't even use schema.org. It's trying to come up with a, I mean, I'm in the semantic world, so I know there's a lot of references to that. GS1 is, which is dealing with supply chain commerce. They throw things into schema.org. So it just depends on what world you're living in. I'm in the semantic world. Okay, I think I got them all. If not, we'll figure that out later. But is everybody okay with this direction? Okay, I think it makes it a little bit more clean model, because I was having a hard time distinguishing between business logic versus routing logic. And I think this makes it a little bit easier, at least in my head to understand. Okay, so we got two minutes left. Is there anything you guys want to bring up relative to the state of things? Ignoring bugs in the possible code, but in terms of the flows and stuff like that, and I'll climb into you, and I chance to read it yet, so hopefully you will. Yeah, I will. But anybody else have anything else they want to bring up? I think it's too late to change it now, but the controller being the central hub that makes everything flow is a little weird. Like it should be that the trucks get to say what they deliver to, not the controller. It tells the trucks what to do. Well, the reason we did that is because- Yeah, I understand why, but it's messaging. You made a very compelling messaging demo. Yeah, in a real-world scenario, I agree. The problem is we have that many participants and everybody has to be evenly distributed and it is what it is. So anyway, okay. Anything else? All right, okay, cool. Thank you guys, I appreciate it. And we'll talk again, I guess, on Monday. Hopefully between now and then more people will come online and we'll get the demo a little more solid, because I think there's still some bugs in there. We just need to flush them out. All right, I'll look at it. All right, cool. Okay, thank you guys. Bye. Okay, bye.