 Hey, hello, how's it going? Pretty good. Hey team, are you there? Hello I saw you send my messages. I'll take a look at those in a sec. I just Gotta get myself organized here. Hey Clemens. Hello I didn't do any more work actually. It's getting with that time of year where I don't think anybody wants to do their homework I have I have a good excuse. I have too much to do Uh, mr. Baldwin Good morning. Good morning. Tommy I'm sorry, I said you can tell me Hey, did you vote Tommy? I'm gonna go through the list here when we get there. So you don't have to jump over there. You don't want to But let's see who else we got. Uh, ginger Hello Um Lucas frank, are you there? Yes, I'm there. Just out of curiosity. Is this your first time in the call? Exactly. That's my first time and I'm from SAP SAP. Thank you. I was about to ask you that. Thank you. Well, welcome Thanks a lot. Hey, brian Hello, Doug. Hey mark Hello, Doug. How's it going? Awesome You got a dad joke for us. Yeah, okay Yeah, I haven't heard a dad joke from you in a while. Yeah Hey class Hey, Doug. Simon. Are you there? Yes I can't remember There was one person on last week's call who I did not get their company association. Um Just for fun. Simon. Who are you with? Um, SAP I was going to say SAP. It's okay I don't think it was you though. I think it was someone else Uh, Mr. Scott wasn't there last week. Yeah, okay. That was right then Hey Scott, how'd the thing go? Killed it Yeah, excellent There's the dad joke we're waiting for. Okay. Hey, Lionel Hey, no, I don't. How are you? Good. How you doing? Good All right, and Eric, are you there? Hello, and Daniel, are you there? Hello. Hello All right, just another couple minutes until we get started So for you guys in Germany, last time we mentioned the the virus stuff. I was hearing the things were Getting better. Um But now I'm Am I hearing things right that that things are ramping back up again? And if so, are you guys doing lockdowns? Or how are you guys doing with that? People are being stupid And uh, we have a partial I would say a partial lockdown. There's no restaurants are not open and uh, uh, you know the the all the services close to the body except for hairdressers Um at the clothes We're similar we're a similar place to where we were Um in spring except that the shops are open. Got it. Okay. The schools are open too. All right, the schools are open, which is important. Yes. Interesting. Okay All right, one last person then we get started. Well, here we go RDS Um, you're just are you there? Yes, I'm here. And which company are you with if you want to be associated with the company? HM Bradley Bradley like that. Yep. Interesting. Okay, cool. Welcome. All right, let's go and get started. Um Hold on a minute. We are I'm sorry. We use with the a instead of There we go. Oh, they mean like that. There you go. Cool. Excellent. Thank you. All right, let's get into this anything from the community people want to bring up. All right Not hearing any we do have an SDK call immediately following this one I've as of right now, I believe we do have One item on the agenda. So we are planning having the call assuming Lance shows up. Oh, and there's Lance um, okay, we had the Discovery call next week. I try to remember if we had anything worth mentioning from last week's call Although I don't think really had much of a discussion other than I do want to ask I know Who's been joining the call? So I know who to who's been kind of working on stuff For example, I know Scott you're there Remy you've been working on stuff Um, but there were people in the past. I think Clemens you might have mentioned it And I think I want to guess it Klaus SAP may have mentioned you guys were interested in it Has there been any progress? Do you guys need anything from the rest of the group to to jump start your work? Or is it just a matter of finding time to to work on the interrupt stuff? For me, it's clearly just a matter of finding time we've been we've been In planning and I've been just busy Okay Is there anybody else on the call? I'm sorry go ahead Okay, is there anybody on the call who'd like to join but needs more information or help or something? Okay um in that case, please um Hey dog, it's uh, it's Lou here Yep. Hey, sorry. I don't know why I did a copy or cut and then it didn't put on my clipboard. Okay. Um I was gonna say to do it. Oh, yeah So if anybody who wants to participate, but feels like they're stuck in terms of trying to figure out how to get started Just reach out to me offline with your slack probably and I hope to help you get you on board Okay All right, um, let's move forward. Uh, Timer anything you want to mention from the workflow side of things Hey, hey guys, um, not much. It's real quick. Uh, just from the specification side. We are Currently working on adding compensation to the workflow language And uh, yeah, that's about it. So I just didn't want to are you guys going to participate in uh, CubeCon EU or any planning because I think there's a week left to submit talks So I was assuming that we as a group would participate But that is a good reminder for the normal CFPs. There's one more week Yes, but I don't but I don't think we need to do anything from a working group perspective I think they'll reach out to us separately for that I assume anyway Thanks But that's a good reminder though for a cubecon So any questions about workflow from the group? All right in that case, let's move on to the next agenda item. So we started a vote at the end of last week's call And just to pressure everybody's memory. We made the default branch in GitHub be the current release which as of right now is one zero zero And we decided to rename the master branch to something else At least my understanding was we were doing it to make it clear to people coming to the group or coming to the repo that The development work is going on in this new branch name They're going to come up with and master didn't necessarily convey that thought process That's why I think we came up with dev versus next as the two options So some people have been voting. I I think I got everybody who's mentioned Who's made a comment to the issue itself Well, let me just go ahead and quickly run through the list here To see if anybody wants to change their names or if anybody did not vote who wants to vote I don't see Kristoff on the call. I don't see matt Brian, did you want to change your vote? No, we're good. Okay. Keep an eye on us. Clemens. How did you want to vote? Um dev dev. Okay. Uh ginger. You just voted so I assume you don't want to change your vote. All right Um, correct. Right. Manuel. I don't see him on the call Remy, did you want to change your vote? Oh, he's not on the call. There he is No, no, I don't want you know, okay Christian, I don't see you Klaus, you're okay with next I assume. Yes Okay, uh, David, you just voted so I assume you're okay with dev scott. You don't want to change, right? I'm honestly fine with either Okay, well pick one Main Pick never never next Name was not one of the choices we agreed to last week. Next. Next. Thank you. Eric. Did you want to vote? I don't care, but next is fine Next is fine. Okay Tommy Dev. Dev. Okay. Sorry. I couldn't hear you and Sanjay is not on the call. Okay. Let's see if I math can do here one two three four five six Correct me if I get this wrong, please one two three four four Okay, did anybody Did I mess up anywhere? two four six eight ten ten votes total adds up to ten. Okay Dev means it's under development Remy. How's that? Okay, so we have a we have a winner Okay, I'll take the action item to do whatever is necessary In the repo or the docs to do a PR or whatever to change it to dev I think it's just the The readme's and stuff like that may need to change. I'm not sure where the links All right Before I move on anything else people can think if I need to do relative to the vote Oh Sanjay, okay It's like post voting. Yeah, I like that I feel like there's something illegal about that, but okay um Let's see. Okay, one on one prep. So we have a couple of prs to discuss and one issue. So let's go ahead and jump into it um, I think on this one did it do So I added some text to the governance doc that talks about how we're going to use RC number meaning release candidate number for um For when specs become ready for review for the next revision And I think that's consistent with what we sort of operated in the past But then we also talked about how We made it clear that the spec version Is always just going to have the major minor version not the patch version number So for example, it'll be one dot zero not one dot zero one in the spec that way Things in the wire don't need to change and we're always going to keep it at dot zero um And if we ever do introduce a breaking change that's going to cause a major version bump So that's why I can always stay at dot zero okay, um And I think this this is just text in the spec itself that talks about that But I think those are the only changes I've made just to clear up our process so that people understand what we're going to be doing going forward So I did mention this last week, but it was too soon to vote on it. Does anybody have any questions on this? Any objection to approving Sanjay, did you want to say something you came up here? Yeah, um And sorry if I haven't you know read it here. It's already there. Uh, have we listed what are the breaking changes? uh and What would be non breaking changes? I know people would Know generally but have we listed those anywhere? I believe somewhere Excuse me. I believe somewhere in our documentation or governance. We talk about how we follow the semver rules So I think semver defines what's breaking and I'm breaking Okay, okay All right, anybody else any questions or comments All right any objection to approving then Okay, now I did reach out the gem offline to ask if he was okay with um Moving the protobuf spec back to one 101 dash rc one As opposed to making it a full fledged 1.0 Because it never had a chance to actually go through a testing cycle And I think we we talked about this in the past. There was a little bit of concern that we maybe made at 1.0 prematurely um Now he was okay with it and the reason I asked him was because he was the main driver behind the latest version of it um, but Does anybody else have any concern with doing that I mean there's a moving it back to be Release candidate 1.0 That way we can do some testing before we actually lock it in stone and say no more changes or these breaking changes Okay, so I will go ahead and make whatever changes necessary to do that Thank you all for that All right lance now, um In preparation for 1.0. I did send that a note to at least I think I did Uh with the url to the diff between what we have today Um at head Versus what 1.0 was and I asked everybody to go through over the last two weeks or so to see if there are any Obvious typos and stuff like that that we got wrong Now lance you then open up this pr. Is there anything in particular like to point out here is I think most of it was typographical type stuff Yeah, I think there was a pretty much almost all typographical and some word sniffing and stuff like that Okay, I'm just doing a quick scan I mean, I didn't change any semantic meaning. I don't think I did Yeah, I don't remember. I think there was one thing I did want to point out to people. Okay, so here this isn't Normative, um, it's just in the proprietary spec Read me in essence, right? I basically made these things too much just to make it clear that we really really need this from people Before it was a little bit lucy by saying needs to and should but as I said, it's non-normative But I think our intention was these things have to be there. So I think that's the only non syntactical kind of changes you made Let me just double check my scrolling forward Yep, I think that's it. Does anybody have any questions about this? um for lance Okay, any objection to approving? All right, cool. Thank you lance for the review All right, and then I did a little bit as well. I think mine was even smaller Okay, this was just it made it easier for me to see if we missed files on the read me by alphabetizing them and put them separate lines It's just strictly nonsense This one was doing a relative url instead of an absolute url So for consistency, I made it absolute just like all the others It just makes it easier as we make new versions um This protobuf was the only one that was doing Bookmarks so I removed them because that people I wanted to be consistent. Otherwise, we'll mess up We were missing the we were missing the php in the sdk doc Even though the php repo is actually empty. I thought in fairness. We should at least point to it just work consistent um Here the governance doc. I just lowercase things like may because this is technically non normative um, and I just cleaned up some inferences. Oh this um Out of this comment here about available at the root of the giveaway repository It wasn't clear to me which root it was talking about meaning the root of our repository I mean the spec repository or the sdk repository so um I just kind of tweak the wording there slightly to make it clear that it's each sdk made to find in their own contributing file and let's see Lowercase may here because again, this is a governance doc. It's not normative and Same thing here non normative these more non normatives These are governance docs and I think that was it any questions on those Nothing's in the no changes to the specs themselves Okay, any objections were proving All right. Why are they doing that? All right. Thank you all and Lance this one A little more meat to it. I think Did you oh lance did you want to deal with this or is it too? It's premature to vote I think it's premature to vote. I haven't had a chance to deal with that. Okay. I apologize. I didn't realize there are any comments So, okay, we'll hold off on that one All right, um, okay So in this issue Okay, close. This was something you raised a while ago You were concerned about a change that we made in 7 13 technically being a breaking change And when we talked about this a couple weeks ago I said I was sent on an email which I did asking people if they're okay with us treating 17 7 13 as a As just a non breaking change and I didn't get any responses. So either people ignored me or they're okay with it Um, so since we didn't hear anything though I believe the next step is to check if people are okay with that strategy going forward And if so we can then close 7 13 And assume that we're okay doing a 001 release And not worry about this as a breaking change. Is that your understanding is well close? Yes okay Does anybody want to speak up about that process or about anything related to this whole issue? Okay, any disagreement then with making that happen All right, cool. Thank you all Okay, so um Hold on a minute Okay, so I don't think we have any other issues or prs relative to zero to 101 or a potential 101 um Do people want more time to review the diff between what we have now versus 10? Or do people just want to go forward with starting a vote? Once I approve and merge the prs that we just did Anybody have a preference? Okay, not hearing anything What I'd like them to propose is that we merge the prs. We just approved today And start the votes on 101 Um, I'll have to go back and refresh my memory about the exact process we follow Um, I was in terms of whether I actually create a PR. Yeah, I think I create a PR Oh With all the changes to bump everything up to 101 and then people have a week in essence to to vote on that Does that sound fair? Yes Not hearing any connection. Cool. Thank you for speaking up All right Gosh, I can't type approved All right, excellent All right your dis um You reached out to me saying you would like to talk to the group about this proposal that you have for an extension Would you like to talk to it? Well, let me let's start with this text over here first Your dis either. Yes. I'm I'm here. Uh, yeah, so basically uh Trying to you know come on with some consensus and like align a little bit the ecosystem in how to like Generators So that way, you know, it's kind of like the same Goals of cloud events. So you you get you gain interoperability and as the case on tooling surrounded So at the beginning, I was like creating my own cloud events And then I realized like actually I can just create an extension. So I change everything So the things that I took into consideration is kind of like how you're gonna do internationalization in clients uniqueness between distributed system environment for their How you could correlate like particular tracing of an arrow back to customer support So we could even expose sometimes metadata to the clients Let the consumer the users to hold themselves with customer support documenting maybe some structure logging if you want to log their And for clients for the most part like how you aggregate validation or errors that happen for a particular key in a validation situation so Okay, so let's let's get down to the meat of the proposal. Yeah the meat. I just introduced a new type Which is the euro. I don't know if I should use one of the the other ones What we have already but basically that would be where the documentation is gonna leave so Everything else is the same only you're gonna have their message which is for the most part for developers So some people may use it in clients to display to the users. I wouldn't recommend it So that is introduced and then their link so you could find documentation about it So That's it for now and then everything else is just cloud events So I think you're basically your your extension would just be defining these two new attributes right here, right? Right I think above You're gonna see the two attributes that I added. So I have a section. There's as an extension context attributes so Those two are the only ones required for now because for internalization you would normally use the type For uniqueness, you already have the source plus id so you could you know correlate that for metadata around like Like an error. Let's say you have in In cases where you need to have more context in order for inter internationalize Or add more information of our particular or you use the the data for now So, yeah, the only thing you would need is these two keys to identify say cloud event error type of situation Okay Now technically this is not a pr and our project yet. So it's just You're wondering what you should open on right? Yeah, I I can open I was a I was working in this adr for Here and then I I thought about it and and here I am So if if everyone is cool with it, I can open it in cloud events and move on there Okay, does anybody have any questions or comments? Comments you came off mute. I do So this is something that I refer to you dog And I think what I think the initial story over how this started is correct me if that's wrong Is that you wanted to have a common way to express errors as if error events, right? and so And and effectively you landed on cloud events because Cloud events is already a framework That kind of lets you express most of that error But not all of it. Yes yes, so My suggestion would be to Do this a little bit differently and To make really the error link and the error message The content of the the the events per se So put that into the data section And what because because you're arguably Introducing a class of cloud events, right? You're not changing anything That all cloud events should be able to use that that that's what makes Extension would be but you're introducing a class of cloud events that are expressing errors So what I would so what I would do here is I would Define a Scheme for how the type is being expressed But but at that point I'm moving. Yeah, but that's a thing at that point. I'm moving like subject type source All those keys are moving into that metadata. Is that we just press no no no no no no Well, what I'm what I'm saying is what I'm saying is that you should write a rule for how the type is being formulated How the type field is being how the type field ought to be set when it expresses errors Sure, and how the source field ought to be set when it expresses an error And what the subject should say when is describing an error? And then I would also Make a jason schema That then Makes clear what should go into the data fields Okay, we'll be expresses an error. That's how I would approach that because You're effectively what you're trying to do here. I think is you're Defining a schema that sits on top of of cloud events Or a constraint that puts that sits on top of cloud events because you want to make sure that errors can be distributed in the system You're effectively as we as we were talking about it What you're trying to do is you create you're trying to create a A log format of sorts That's that's carrying cloud events how how we can go and distribute error information error Errors in cloud events so I would not use that as you use an extension because that mechanism is really meant to be applied to any kind of cloud event but really look at At do this as a meta schema. I think and and and I believe what you're the work that you do in the idea Is enormously valuable? Let's let just to just to make that clear And Because having errors are something that systems need to go and react to and something throws an error It's basically what you're doing is the you're you're defining what throws local. It looks like in distributed systems. Yep Right. I And so so I would take the I would take a bit of a bit a bit a different approach But don't be deterred. Um, you should go you definitely should go down that route Yep, no not at all. I This was something and this is actually what I wanted to speak to you because personally, I don't I don't mind if is An extension or if it's a convention inside the data and then add the two keys and the metadata key which It will behave as a data For me what I actually looking for for the most part is Alignment ecosystem, so we just can move on to the next conversation related to this So I'm I'm totally cool with it. I I'm I'm no I'm no married to to be an extension But it would be amazing to have like alignment that for sure And and I wanted to make sure that we have this discussion not Not offline, but really in the group and because I think this contribution is important And as you've seen there were There seems to be interest because there were some people just mentioning Engaged in the chats But if say people say plus one on things then they're interested in having these having this So, uh, um, I you should feel encouraged Yeah, absolutely. Absolutely. Yep And uh, this is Sanjay. Uh, just like you have been on error things for quite some time more from the hdp epi perspective But I'd like to work on that. I think it's very important the the schema for the errors How, you know, it should be conveyed and if cloud event can have You know, uh, we can have extensions there for that. So definitely very interested in working with you Perfect. Yep Okay, sorry. I'm just taking some notes here Okay, so I think what I'm hearing is in general. Well, actually being back up Does anybody else have any comments or questions? Okay, because I think I'm hearing in from plus ones is like the idea of looking at some sort of standard or recommendation or guidance or whatever you want to call it around how errors are Manifested themselves in cloud events, but would rather see it by using the existing fields as opposed to creating new extension fields Is that summarize it? Because that's what I try to say in here. I think that's uh, that's what I certainly what I want to express. Yep. Okay So is there anything else then you noticed that you need from us in terms of next steps here? Or do you feel like you understand where to go? I I understand where to go with changing the spec. I think I totally agree with with them I'm guessing I should create like a pull request against the spec and that's where I'm not really I I don't know what will be the next step in terms of like start the contribution with cloud event for sure Yeah, I think actually you're right on the money there It's create a pull request with where you think the changes need to go And that will force people to review it and comment Um, obviously if there are certain people like for example, Sanjay said he'd like to work with you You know through the chat Yep If there are certain people you'd like to reach out to in advance of creating the pr just to see whether you're Headed in a direction. You think the group would be interested in Okay, reach out to sanjay myself Clemens offline and and we can work with you on the pr itself But in terms of process a pr is the next step I think I think this goes logically Doug this logically goes into the The what did we have the profiles? You mean the primer? No, no, no, we have this we have this directory. I just lazy to look it up. Maybe um, the where we had the These github how the github events look and oh the adapter section or the directory. Yeah adapters Yeah, because it's it I don't think this changes ours The well this changes our specs this changes the core specs because this is really a layer that sits on top of it Yep, so I think this is a separate spec And it is more an application of cloud events than it is a change to cloud events So it's more something that sits like that's like what we have in the adapter section than than a change to the core spec Like if anybody wants to go and express errors as events They should use this format and that's then sits on top of cloud events. I think if this is a layer Yeah, interesting, and then I would not have thought of putting into the adapter directory But the way you described it does make a lot of sense. Okay, that's interesting Yeah, so take a look at that adapter directory and then you'll see what Clemens means Yeah, let me take a look because the last time I saw like an extension Directory maybe there's another one that I miss it there. There's an adapters directory. I think that's what it's called adapters Let me just double check Ah got it. Perfect. All right. So that will be the different between one and the other one. Yeah Yeah, so Okay, okay. Got it. Got it. All right. Yeah, that makes sense. I got you Cool Excellent All right, any other questions comments from anybody including yours All right, so you know where to go next then Excellent. Thank you. Yep. Thanks. Thank you for the proposal. This is this is exciting All right other prs and issues then um clements. I'm assuming There's nothing to do there for yours, right? Yes, sir Okay, and slinky. Is there anything you want to talk about relative to your pr? I think this one's yours, right? I was waiting for Clemens to To comment in there, right? Excellent. More finger pointing at clements. Okay Yeah, I'll I'll be I'll be there next week. I'm I'm just I'm just coming out of my hole here Okay, not a problem. No problems Okay Um, I'm trying to think of anything else. I think that technically takes us to the end of the agenda Are there any other topics people would like to bring up? Yes. Oh, yes, please. Oh, there is something from you, isn't there? Yes Oh They did it again. Is it a pr issue? It's an issue, isn't it? It's an issue. Yeah, we're at this one. Thank you. Yes. I'm so sorry All right, go ahead and use this one Slinky, did you want to talk to this one? Yes. Yes. So so last time We basically forgot to discuss about it, but I was wondering if we if the community is interested in developing a kind of expression language To express predicates on confidence so One of the main drivers as explained last time is the ability to Provide a powerful filter inside the subscription api But I foresee other interesting use cases with the workflow With workflows back and I guess even in discover api this might be useful We don't want to invent something particularly complex to implement or particularly fancy We the idea is to create some language which is easy easy to implement and Not particularly complex to reason about for developers that are going to use it I started drafting something mostly it's a brain dump of ideas. I have in mind. It's at the end It's like the last comment, I guess So Yeah, let me know what you think about it. Let me just open this puppy up Do you have an example? Okay, here are your examples. Good. All right, so What do people think? because I know we have the What is it the basic expression language now in the subscription spec? So this would be another variant I wrote I wrote the case insensitive section for this for for the sequel matching in aimqp That's a long It's a long thing to write Yeah, why not sequel well That's a good question. I guess I think I think one of So I to be honest I before jumping down on this idea I Tried to look around for different languages and One of the main problems that I found is that there are There are really really Just a bunch of languages that um That has implementations for like most of programming languages out there So that's one of the reasons why I came up with trying to define something new but not the new Also Maybe a short answer is the data model is not the same, right? We're not talking about the cloud event data model here not like a relational and and Francisco, I don't know if you said this but this is a language only to talk to to express predicates on the uh on the c e attributes Not on the payload Yeah, it's it's very it's very very constrained to call the events itself. So like one of the first things that is explained this document is that the input assumes that Uh, you get you are the input assumes that you are getting a call event So that's like the the biggest assumption right and like the and like the language can do even type static type checking on some on the code event attributes So the reason why I'm saying that is there's there is precedent in uh in brokerlands In the form of Java jms message selectors Which are using the sequel sequel 92 subset And we also have in mpp Very similar sequel subset. And so when you look at message brokers Every message broker that supports jms already implements a um sequel parser and Mapping a cloud event to one of those brokers is something that we have effectively so for mpp. We have already done the work um, so it seemed it would be I I think if we want to go and implement an expressive in language like this using One of those already existing specs Is something I would prefer over introducing yet another thing Which is um completely its own The advantage of using a sequel 92 subset is that it is footing on a standard So and and and the message selectors in jms do know also are constrained to The shape of a jms message And the mpp message selectors are also constrained to the shape of an mpp message and neither of them Are uh looking at the message body And they're and they're very related By by design So I'm gonna pick on team or since he made a comment in the chat I want to make sure we get people to speak up. So team or you want to vocalize what you put in the chat Oh Well, I mean I I know I don't well I don't want to say anything bad. I think I'm just seeing this the first time it looks really nice But I just know from experience that is like with expression languages when there's so many out there And especially like I just can compare to workflow stuff that we're doing Uh, we removed actually ability to select like things like a specific expression language because that's portability just goes away um, there is no two Companies out there are going to want to use the same expression language So on the one hand having something like this is nice to cover that Part but on the other hand, I think just using something that exists probably would make more sense Sorry So I I have a specific answer to to the jason but Thing and in general to the jason queer languages Because I honestly tried to look at this first and one of the problems of Those languages is that they don't handle very well Complex types like the timestamp. So like performing performing queer particular Developing particular predicates on timestamps or on your eyes. So that's that's one of the reasons why I I think jason part doesn't really fit there Also because in general jason part is really nice to To navigate through nested data structures but it's not really I mean I see as too much verbose when you need to just walk through a A data structure which is flight lack in this case Oh, well, I didn't say something important in this expression language We explicitly neglect the The payload filtering So we don't talk about payload filtering and we don't want to do payload filtering here Because we understand that for payload filtering there are better tools that does this job just better And because of the polymorphism of the payload too Okay, so my hands up um Okay, so first notice clements pasted a link to the The AMQP stuff that he was talking about in the chat. You take a look at that. I'll run that to the meeting minutes The document that let me just make one notation that document is is affected the final spec We haven't progressed this in the committee yet because we're slow but That's that's affected the final one that we're going to promote Okay, but the real reason I raised my hand is when we talk about You know creating something new versus using the existing one um If we looked at an existing one, whether it's the AMQP thing or sql or whatever I'm assuming that we would profile it right to limit um Limit it down to what cloud events actually needs because I would imagine most of these other languages are far are fairly Uh robust and probably much bigger than what we'd need for our basic filtering type stuff. Is that true or Or when you say no sql, you actually mean clements, we should support as much as the sql thing as we possibly can No, no, no, no, no, what what if you look at if you look at um, so the other spec is would be the gms 2.0 specification That is in so java message service 2.0. That's the specification. You can find that at oracle um And that that has a fairly compact definition probably a little bit more compact than the definition I have um in aqp, which effectively picks a subset of the sql standard Just so much that you can create meaningful queries over the properties of a message Um and and combine them with with effectively constants that you that you provide so it's a it's a fairly slim uh subset and it's effectively the subset you would put into the where clause of a of a sql um expression Rather than, you know, doing the select and group by and like none of those things exist Like literally just the where clause conditions those you can formulate. That's what that subset is. So, um The gms 2.0 spec and the spec that I that I paste it would be informative for that and that's That is what's common in um in messaging lands Okay, thank you and so active mq cupid rabid ibm mq Uh, the the s.i.p brokers. I'm sure are also implement the same thing Our brokers our service bus broker implements and all of those are implementing some some uh some subset of sql Yeah, uh, Lana your hands up Uh, yeah, so for the cloud event Filter language, it seems to me that we need an even smaller language. So I'm looking at the filter at the link you sent like for instance, you have the The the map and the least type, right? That's not something that I think Belongs to to the filter language here For instance, but we could take a subset of it Yeah, yeah, absolutely. It's it's um, I mean, I just gave you the link for the aim for for for what we need for mqp and This that can be further cut down, but the the the point is I From from from from my perspective as Trying to unify the world of messaging I would like to have Everybody speak sql And then there's obviously some some variation of of of sql that we speak, but I don't want to introduce entirely new Languages for doing that filtering work. So I think the net of what you're proposing then Clemens is to say Create a profile of sql or whatever language we choose rather than creating a brand new spec, right? Yeah, and that's that's that's the choice that we made for mqp That's the choice about the jms the jms folks that did and the reason is that Even though we had a we had a period of time when we were believing that no sql would be great So doing away with sql everybody who has been doing no sql is now back to sql. So apparently sql is still winning Everybody put a sql processor on top of their no sql database So slinky What are your thoughts on this? I need to read what what finance you just sent because it seems interesting I need to go through it. I have some Questions maybe they are in the stock maybe they are not but like One of the things that I thought about when writing down the stock is Is the polymer phasmo Of the of the extension attributes. So the fact that the extension attributes are We we don't we don't have a strict schema. So when I think to sql, I think to To something that always has a strict schema the input the input The every field of the input is typed. Okay Um, and my question is how does In your case, how did you how do you deal with with situations where The input where some fields of the input are not typed so Well, so a few of the input on there Then they're not typed is what he said. They are not tight. There are there's a whole section about conversion rules Okay And that's that is that was The those are the hardest those were the hardest pieces to write. There was like I I came I um the amqp tanking committee is unfortunately full of hawks um for for correctness um, which means I came in with a proposal that was kind of Um, let like at the level where you are and then they were all like no, no, no, no, no We have to go and think about all the conversion rules and and type mappings Etc because ultimately you're expressing you're expressing text here And that all needs to be mapped and there's some type inference rules, etc So just look at the look at the document that was a I I have purged much of that out of my head already because it's It was it was not pleasant to write at all Okay Okay, so it looks like a little more but effectively for you the um Just as as as as as helped as helped for for reference Um, there is some there are some property bags that you can reference like the application properties and the properties, etc And that's kind of you can you can think of those as being kind of the The areas where you can go and swap the predefined cloud events and the extensions in So you can kind of read read them like that Okay, and then what about the extensions Uh, yeah, so go go read this read this back and then and then it should it should hopefully be apparent how the The extensions might fit Okay All right cool Any other questions comments on that topic? All right. Well, thank you so thank you for bringing that up though I it does seem like we need something a little more robust than uh, than just a simple one So this would be good if we could get something in there All right, any other topics people would like to bring up I have one quick question. Yes, please go ahead Uh, regarding 101 release, is there a change log where we can Go ahead quickly and see what's what's No, so I sent out I sent out a note to the url that did the get diff between the latest versus 1o that go look for that email um, when we when we create um The next version i'm sorry when we create the next release I think somewhere in the the documentation talks about the process I think it does talk about creating a change log that goes into the pr itself I don't think we actually Create a formal change log document, but I'll have to go back and double check Okay, thank you very much. Yep Yeah, one thing Based on this flow today I was trying to see if I missed it But it would be good to talk about like contributing to extension on adapters And the difference between them. I don't know if that's documented or not, but I definitely miss it um Hmm I would be surprised if we had that documented Yeah, I know we I think we mentioned those two documents, but I don't think we talk about in terms of one versus the other right Which now is clear to me, but then now uh, yeah It's too late I think what you I think what you're bringing is is generally a new thing Yeah And so I don't I don't think any I don't think anybody has brought a Effectively a class of of cloud event schemas And that's that's ultimately what you're doing. So, um, I don't think we have a I don't think there's a slot for it But since you want to bring A pr the adapters section would be the best slot and you can still think what how we can think about the The whether we want to have these It's probably a meta schema that you're that you're a cloud event meta schema that you're defining Um, and then we probably need to go and find a right home for it But but before we deal with them formal formalities Um, let's let's get the gets let's get the proposal done first and then we can go and see how we slot it Yep All right, cool All right, any other topics if you want to bring up Okay, in that case, let's just do final roll call. I think I got most here's here's the complete list Uh gem are you there? I am and I've been listening. Yeah I'm listening. Yes. Okay. Um How ho I'm not sure how you pronounce it. I apologize. I'm probably uh, I'll have to drop off a bit earlier for a conflict Oh, is he from redhead? Uh, he's from google. He's google. Okay Cool, do you know his last name by the way? Lance Or is that uh, this is brian brian. Sorry brian. How how ling lin g Perfect. Thank you very much. All right. Um Anybody else that I missed for roll call Think I got everybody All right in that case. Thank you everybody We will have the sdk call out to this as I said lance had released one topic on there So if you're not interested in sdk call, thank you all for joining very productive meeting We'll talk again next week. Everybody else hang on the line for about a minute Thanks everybody Do All right lance, would you like to introduce this topic? Yeah, I mean, I think this has been talked about before but maybe preceded my Participation in this group. Um I was looking at the distributed. There was a An issue opened on the um javascript sdk Asking for us to support The distributed tracing extension um And reading through that uh, that spec to me it seems like if the sdk Supports extensions In the abstract then it automatically supports the Distributed tracing extension But it's not entirely clear to me because it's obviously the go sdk is doing something quite a bit more than just uh, like supporting the extension by Having it be possible on an event You see what I'm saying? Yeah We have been we have been discussing this the the topic of the distributed tracing extension to the point That dug at some point said let's throw this out um The so you're correct distributed tracing extension is an end-to-end extension um, which we have there to um effectively allow for a um A tracing context to be carried from the application to the application So from the the producer to the consumer But that tracing context is added specifically by either the producer or right So it's the sdk doesn't have anything to do with adding the context. That's And so and then there is a um um Then when you send a cloud event so when you kind of pop down on to onto the uh, um transport level Then the transport like the h like hdp Um also has these distributed These trace extensions. So there's the the the same properties effectively exist. Um defined in the in the w3c spec as hdp headers Which makes the whole thing a little bit confusing to me. Why do you need both? Ah, yeah, so because the cloud event goes into a broker Into some some uh event broker and then pops out against somewhere else The application the application which is the consumer of that event um, maybe Wants to write a trace that is then that is shall then be correlated with the publishing action That happens on the other side But without without having to worry about any of the transport stuff that sits in the middle Um, and um, so that's that's that's that's that's really purely application to application Relationship and then the hdp path is for tracing whatever happens between that exact client and the hdp server and getting that that Getting that event into whatever the the the event store is All right, there are so there you think you can think of those as two separate paths There's a path that goes from the publisher to the consumer application to application Really not interested in how that communication path happens and maybe even without um, uh, both either consumer or publisher Having to be or shall it should be in the know of all that happens because think of it as like um If you're so I run an azure event grid So you publish into azure event grid and then the message comes out of azure event grid There's a thousand things happening inside of azure event grid that are completely obscured to you because there are it's a past service So but there is tracing that we do at kind of at the at the level of of of where that event is being transported But you don't get to see any of that and you don't have to worry about any of that but I should I should please preserve um, the original trace context from the publisher so you on your side on your On the application can go knit those two things together irrespective of all the stuff that I have done to get that event to you So those are two completely different worlds And and for the application to application Route that is what the extension is for That's what those why those things are different Okay, that makes sense. Um, and and it makes my life easy to say that okay. We support extensions. So we support Yeah, the description expectation perspective if someone so so whoever wrote that wrote that um, um suggestion The right answer is use the same values for the cloud event and for htp So they have the the the trace parent trace context They have those two values and they they should they should use those and they they start with them Right, they set them And so they can set the same values on the on the event and on htp But they basically those those those two contexts basically then split and go into different directions One is end to end and one is really just from the client to the htp server and stops there right So so that's sorry. I'm sorry. Slinky your hands up. I apologize I have two comments about that one is that I still think we should remove that extension Because it's really just a source of confusion everyone's you know what somebody pops up and say hey, I didn't understand anything about that. So Uh It is an option Yeah, I mean And the the second thing is that Uh FYI lands I'm working on removing what we have in SDK go Because I think it's just plain wrong and too much opinionated so like we have this This integration with open chances, which is which by the way, it's a deprecated library and This integration is doing some funky stuff. It's basically taking Creating a new span Which then is it sent when you send the message and it's Taking some attributes Of the cloud event and put in the span And then what it does is that It sets the the value of the distributed tracing extension. Okay, but then when it receives The event it reads those values and that's wrong because of what clients just said that he Setting this maybe it's fine, but reading this and using this as tracing information. It's not what the spec is meant for So, yeah I just want to remove it So so Lance the I guess what I wanted to say was Ignoring that that particular extension itself. I was wondering whether you were just wondering in general What kind of support SDKs have to have for extensions? Is that true? No, I I think I understand that. Okay And and we have that I was just Trying to like it seemed to me in reading the spec that Well, we support extensions in the abstract. So we support this already Um, but it wasn't really clear from reading the spec whether that was the case. Okay, got it Okay, so is there anything else left to discuss on this one? Not from my perspective Okay, I'm cool. Anybody else want to chime in? Any other topics we want to bring up at all? Are we done? I think we are I think we are it's exciting only one minute late then Thank you. All right. Cool. In that case, we are done. Thank you everybody. I'll talk again next week. Yep. All right. Have a good week. Bye