 Hi Doug. Hello. How's it going? Doing well. Yeah. You know, while we get everything organized. I'll be offline for the first few minutes. I just wanted to check in, but I'll be back here in a few minutes to watch the upcoming topics, which I'm excited about. Thank you. Thanks. Hey, John. Hey, I'm really glad to have actually been able to do something positive this week. I didn't notice you were a little busy. That's good. Thank you. Well, it's, it's a matter of, I have something else to procrastinate against harder. I think this is actually a cunning management technique from my manager when he wants me to do the stuff that I've been procrastinating about on a medium level. He'll give me something that I want to procrastinate about more. So I do all the medium level stuff. I totally understand. Yes. I do some wonderful things sometimes. I guess. Meaning to procrastinate and then I don't get around to it. Yeah. Hey, Remy. Yo, Tommy. Lucas. Hello. I can't put my finger on it, but something feels different about the zoom. I can't. Just feels slightly off. I can't figure out what though. Scott. Hey, and Eric. How? I think zoom has been changing the way they display participants while you're screen sharing. If that's possibly what's been niggling you. Yeah, maybe that's where it is because it doesn't look like there's like different colors or contrast or something looks slightly different and not bad or good just different. Yeah. Like it's bigger or something or maybe it's just my eyes freaking out on me. I'm trying to think. I don't think anybody on the call yet isn't from Europe. Did they do their time switch this weekend or next weekend? I can't remember. It was last weekend. Oh, you are okay. Yeah, and you're the same as the UK. Was that was that universal for all countries? I thought like some of them like like Israel and whatnot were like in like a weekend behind or something like that. Israel has all kinds of interesting things in terms of time zone. I can just check. So I'm a time zone nerd. Okay, I don't mean to kill the car man, but I was curious. Sorry. Thank you. I'm so nerd. I don't think I've heard that phrase before. All right. Yeah, for some reason I've decided to almost specialize in versioning and date and time stuff. You know why would anyone do that but hey. That's interesting. We got out of a hobby ring. All right, let's see a class of you there. Yes, I'm here. Excellent Lance. Excellent. And Daniela, is that how you pronounce it? Yes, that's correct. Okay. If you want, if you want to be associated with a company, just go ahead and put the company name into the zoom chat and I'll make sure I add that to your name. You don't have to. You don't want to but usually people do that that way their company gives voting rights. Okay, I think that's everybody so far. We got a small group today so far. I assume that's JP Morgan, if I wanted to think of the long version of it. Yes. All right, cool. Well welcome. I think this is your first time in right. Yeah, I just discovered this. I was looking for a cloud events and I discovered this group. So, yes, first time today. Excellent. Well, welcome. And glad I got you. Manuel are you there? Yeah. Excellent. All right. Small group today but let's go ahead and get started since it is three after. Although we don't have Slinky yet and I was going to lean on him because a lot of his issues are coming up. Let's go ahead and dive right into it. So, John, thank you for taking care of some of your eyes appreciate that. Community time. Anything from the community people like to bring up that's not on the agenda. All right, not hearing anything. Just let you know we do have a discovery interrupt call after this one. So, I added one, which was just a nagging thing saying, okay, we said we're going to start testing at the end of March. Well, it's no longer March. So we need to find out where we are relative to interrupt testing. So, please join that if you're planning on doing some interrupt testing. We can find everybody's status. Okay. So, Kube County, you they did send that a note asking us to sign up for our sessions for the, what's called the office hours. I did pick late times in the day for Wednesday and Thursday. Please let me know if you're able to make those times and we'll start adding people's names there. What you need to do in advance is just basically show up and answer questions that people might have if they decide to stop by our booth and ask questions. If we don't get any way to sign up then obviously it will start nagging people but it'd be great if people can, you know, volunteer on their own to do that. I figured maybe two people would be good. One person can analyze because I don't think we get too much traffic but still be nice to have at least one person there for backup. I don't see him or I don't see him on the call. I was talking with him earlier today he didn't mention anything to bring up for workflow status so I assume he does everything new beyond last week. So, keep going forward. All right, anything else relative to any topic before we start jumping into PRs and issues. You can add the link I gave you yesterday for the slides so if people want to have a look. Yes, hold on let me do that right now as I'll forget. I'm representing this whole group so like don't hesitate to do any comments because I don't want to misrepresent you. So, refresh your memory. When is the deadline for... Monday. It's Monday. So I can need to start recording probably tomorrow. I have like a few things. Just I did like a slide this morning. I woke up with, I thought it was a good idea. So let's put a comment in here. Please get your comments to Remy by the end of day today. Because he'll be recording tomorrow. And like for Europe that means tomorrow is fine because I'm in California so basically I do the recording tomorrow so unless you work until really too late on a Friday night. Okay, cool. Does anybody have any questions if they've already looked at it for Remy? Well, we're just going through the agenda. Okay, not hearing any. Let's go ahead and jump into the real work items then. Lance, you're up first. What would you like to do with this issue? Because I kind of got the impression that maybe it's sort of faltering a little. Yeah. I commented just before the meeting. Let's close it. I'm thinking more than just adding confusion. Okay. What other people think? Any objections to closing? Let me just double check it, but I suspect I'll be happy for it to be closed. Yeah, just a reminder, but this is not changing the specification. This is just the primer. And we're looking to provide additional guidance, but as Lance said, it may actually confuse people more. I think it would be better to wait until we had another concrete example to leverage that we wanted to focus on instead of one that ended up being sort of a bad example. Is that a fair way to phrase it, Lance? Absolutely. Okay, so I'll give everybody a second to think about it. Yeah, I'm plus one on closing. Okay. There you go. Hold on, my mouse is acting up. What's going on here? Okay, so no objection. Okay. No objection to closing. Cool. Okay. Excellent. In that case, let's do this. John, you mentioned you had to leave early. So why don't we go ahead and look at your first, your two issues that way you can explain them to the group and get people to start thinking about that and then you can vanish on us. That's much appreciated. Thank you. Yep. So we discussed this, I think, three weeks ago. And Daniel Azuma and I had some discussions internally, and the result is this PR. Basically, it just lays everything out really explicitly. For percent encoding, you don't even need to refer to RFC 3986, because it's very specific about you must encode these characters, you must be able to decode things that have been encoded unnecessarily, etc. But it's still entirely compatible with RFC 3986 as far as I'm aware and someone who's smarter than I am about that RFC please have a look. So for the second part of the encoding so RFC 7230, it's a sort of interesting reference because it's non normative, it's kind of some fields maybe some header values may be defined in this particular way that uses double quoting. So what I've suggested is that the percent encoding that we that we require SDKs to perform will will avoid any double quoting by encoding space and double quote and percent themselves. However, because this is only happening now and cloud events have been out for a while. It wouldn't entirely surprise me if there are existing implementations that do double quoting so any implementation parsing an HTTP message should handle double quoting. But I've said do not have to handle comments because I don't think we expect any header fields to include comments within the attribute. That on it. If something's got its own comment format within the attribute value fine but no header comments, which frankly I've never seen an HTTP anyway. That's the sort of TLDR of it. I've gone into specifics about its utf-8. You must handle surrogate pairs or non lost the lost the plot non BMP characters in this particular way. You must reject things that have encoded surrogate pairs as two separate utf-16 code points. I think I've been reasonably exhaustive, but it's very easy to think that when not doing so. So particularly anyone who knows a load about Unicode please let me know, especially if I've misused the characters. Sorry, the terms I have a C sharp unmerged pull request that implements this. There was a hope that we'd be able to say, ah, we can use existing libraries in dot net. I don't think there's an existing library that we could use to do just percent decoding because for the encoding you'd need to say, I really want you to encode these things in particular double quote in space and for decoding it tends to be within URL decoding which will also decode plus as a space and I don't think we want to get as far as saying that HTTP headers are kind of URLs when they're not. So, I'm quite happy for the C sharp code to be used as sample code. It is, it's larger than we might like, but frankly a few hundred lines. Once per language, I think is kind of reasonable. Right. A quick question for you before you open up to the floor. Is it your, is it your assumption that what you wrote here from it. Sorry, I'm falling on my words. Is it your assumption that you did not change the desired semantics of what we're trying to do even though I know it's technically a change from what's there today. Is this do you think this is in line with what we intended to mean in the original spec. I had found it clear what was intended. I possibly wouldn't have raised the issue. I think there will be subtle differences in terms of, I'm requiring a few particular characters to be percent encoded. So my guess is that existing implementations may well not percent encode spaces. So a bunch of implementations won't then double quote context attributes that start with a space. So that space will be lost in many cases. So I think it's strictly better than and when and compatible with in terms of it won't start losing information that was previously not being lost already is my expectation. Okay, so I think it's then important that the in particular the STK folks in the group. Look at this very carefully to see what kind of impact does it have on their code, if any, because I think that should help us decide. One, if we want to go this direction and two, if this is actually a breaking change, and if so, do we want to do it now or not, you know, say later or that kind of thing so big decisions in front of us. I'm in under no illusions that this is about to be a rubber stamped through. I'm expecting quite a lot of discussion. Okay, so obviously, it's fairly large and you need some reviews I'm not going to even think about asking for any kind of approval today. However, does anybody have any immediate questions for john. That they'd like to ask now before the group has a chance to actually look at it in more detail. Okay. I see there was a comment of no quotes. I'm not quite sure is that as in, we won't end up with double quotes in the HTTP header, in which case, yes, I agree that was that was the desire so that we would encode them. So it was hard to get it wrong. As it were. All right, any other comments, chat or voice. Okay, not hearing any then please everybody take your time to review it very carefully. This could have big and big implications going forward, especially if it unintentionally does a breaking change that we didn't mean to. And I think this may end up being one of those things where we can agree on, it has this impact but can't decide whether that's breaking a breaking change or not because breaking changes and so much of buying everything as we'd like it to be. Right. And, and, and we had situation in the past where we put something in the spec and it just was not really what we intended. And so technically it was a breaking change but we consider that to be more in the typo category more than anything else because we did not mean it to be to come out the way it did. And so we this may be in that category so we'll have to say. And presumably there's the technically breaking change, you know, theoretically, if, if there's an SDK implementation that we're not aware of then it might be a breaking change but actually all the existing SDKs it wouldn't be a breaking change that could influence as well as influence us as well presumably. Great. Okay. Any other comments question. Go ahead. Yeah. Sorry, I didn't raise the end, but it will be a breaking change because one, one application built with the previous version of the SDK in the new version between the new version of the SDK is going. They are not going to talk each other. I would hope that. So, anything that already does percent decoding should be able to handle whatever the new SDK outputs and the, and the new SDK parsing an HTTP message. I expect to be able to handle whatever the old SDK put out as well because there's this business about you have to be able to parse double quoted stuff, but you should never produce double quoted stuff. And it may well be what's on the screen right now doesn't show all of that it's a long PR I'm afraid. So, think he please don't misinterpret me saying no I don't think it's breaking in that sense as a genuine, I'm sure you're clearly wrong. I suspect it's best to make concrete examples if you put a concrete example in the PR saying, imagine an old SDK that does this and the new SDK does that. And this is the attribute value, etc. I'm really, really happy to work through all kinds of things like that. My hope obviously is that it turns out it's not breaking but it's only through actually prodding it that we'll find out. Do you have a set of existing HP headers that may be influenced by this PR and if so, maybe add that as a comment in here so people are very aware of least the ones that are that you know about that may be impacted by this. I don't I have a bunch of tests in the new implementation. But I don't have and we would we would need to collect samples from across multiple SDKs I guess. So if if anyone else has examples, maybe from their existing integration tests and things that would be fantastic and we can just validate as we go. Well it's not so much a validation as much as you know something that looks like this before your change is now going to be parsed or put onto the wire like this you know in a different format. Sorry that's what I meant by validation as in this is what we would currently do and let's validate that it doesn't break. Okay. Yeah, please feel free to dump loads of examples in the PR. Okay. Any questions or any other questions comments. Okay, in that case let's jump over to your other PR. Let's give some background on this one to refresh people's memory with this one was about. Yeah, so we had a question actually in the C sharp repo massively coincidentally saying how do we go about version in cloud events. What happens if I want to make a breaking change in the schema, what changes are breaking, etc. And I gave my personal view, but we agreed that it would be good to have something in the primer moved it over into the spec repo. Three weeks ago we discussed it and I certainly went away with an impression of what the group expected or wanted to see in the primer, and whether I accurately remembered and then accurately expressed it is a different matter. The basic idea is this is only guidance it's not requirement. It's saying that once you've published something with a particular cloud event type, then you probably shouldn't unless it's clearly labeled as beta or you've got other documentation somewhere else saying stuff isn't stable yet. You shouldn't make breaking changes within a type. It's not free to version your types in any particular way. Data schema is more an informational thing so just changing the data schema you are I whilst breaking stuff isn't enough notice because you may well still have old consumers. It's generally nice if you could provide. If you're trying to change the schema, provide an old version and a new version at the same time and gradually deprecate the old type, however you want. We have a hand up. Scott. There's a few ways you could do versioning where like the schema could just be a partial schema that points to the version of the actual schema or something if that was encoded in your data payload. For example, does that make sense. Like there's a lot of ways to do this and I wonder if it's kind of a waste of effort on our side to even just prescribe how to do it. I think if I understood your suggestion correctly. I think there may well be some kind of cloud events that are handled very dynamically and will always be handled very dynamically and making breaking effectively making breaking changes but advertising that within the data or within the data schema is fine. I would expect in most cases, if people expect Jason with a field called name, and you suddenly change that to title, then, however you advertise that they've still got code that that's expecting it to be called name, and writing code that is extremely dynamic. If they don't know that it's going to be changing from name to title or how can they work out what to do with it. I'm certainly happy to maybe have a few more options for versioning and pros and cons, but I suspect that if we don't provide any guidance. A lot of people will either not think about versioning at all, which I suspect is going to be fatal, or come up with a zillion different, not quite compatible ways of doing things, but do push back. Any other questions, comments. Obviously, I think people need time to look this over. Providing guidance is always interesting. When it comes to areas where you have lots of choices, right, you gotta be, you gotta be careful so I think people need to think long and hard about this. There's one paragraph here that I would particularly like reviewed because I'm asserting something that everyone else in this working group will know much more about than me, which is the paragraph starting the data schema attribute is expected to be informational. I've kind of that's my understanding but I can't point to anything that says that. It makes sense to me but may well be completely wrong so we may just want to strike that paragraph edited, etc. And those with more history in why things are designed that way. May well have a fit when they when they see what I've written. Okay, we're thinking they're needed. Any other questions comments. Right, cool. Two interesting PRs require lots of thinking. All right. In that case, john, I think those are your only ones that were up for review. Okay, thank you ever so much for obliging me and doing those first. Sure. All right, in that case let's go back to the top start with the oldest one first slinky this one is yours. I think last time us is not to merge it. I think you made it made me some minor changes here but is there anything you want to drop your attention to on this one before I ask if there are comments or questions on it slinky you there. Yeah, well, for me this is good to go. Okay, I have so so well let me give some let me provide some context on why I opened so much PRs. I think it is here. So I went through this week and I implemented the whole language in Java in this decade Java and there is an open PR for it, and the end. At least I checked this morning game and it implements the full spec, including all the various casting rules. The old built-in functions and so on. What I produced out of it is, so first I fixed the grammar and the grammar now properly works and I tested it with there are several tests and it seems like it's working pretty fine. Then can you open the list of yes so. Oh, you want to yeah I'd like to go through all of this very quickly. Then I found out some minor things like the division by zero can return a better default value. There are some things that are not very well clarified like the in semantics, the function of reloading the concussion accepted the limiter and those kind of small things. So, I kept the splitter there in order to avoid one giant PR that fixed all the different things. So, if people is not doesn't agree with some, some of the specifics. We can discuss about it so yeah. That's pretty much the thing. So general copy editing, at least in my opinion can be merged if people is okay with it. So there is an order for merging things. We need to we need to merge the general copy editing first. Okay, so it sounds like. I'm trying to figure out do so do you. Do you not want to go through each PR today and let you look at them, or are you hoping to get the first day. We can go we can go through all this because they are all small things. So, some of these are obvious. So, okay. So, let's start with the first one. So in this one. Anybody have any comments or questions on the initial grammar one. Any objection to approving. Okay, so let's get that one out of the way first. All right, cool. Okay, so let's do division by zero first since that's your first one on your list. Oops. Okay, so before we jump into each one of these, let me ask you a question. I know that there are based upon our previous conversations. It led me to believe that there is not a single SQL standard, there may be a common pattern out there but there is no single SQL standard out there that everybody says yes this is the one and only one there are slight variants out there. However, in your opinion these changes that you're making here like for example how to deal with divide by zero. The changes you're proposing here, trying to follow what you think is the most common pattern or did you decide to pick a pattern that you thought made the most sense for cloud events. The ladder. Okay. So, well, for for the in. So the in PR. Yeah, there is an open pair about clarify clarifying the in semantics. That one. I took. Let's say I did so what made most sense for me, but it doesn't work the same as Oracle SQL so I tried it on Oracle SQL and it doesn't work the same. So, yeah, that's what I'm saying let's go one by one. Okay, so why don't you go ahead and explain your logic on this one. This one this one is basically so you know that the language is is total so it always returns a value, even if the parameters are valid. But if there is one of the parameters is invalid, it depends to the error list. So, in this case, when you when you divide by zero, it makes far more sense to return infinite plus infinite and minus infinite, more than returning to you. And in this case plus infinite is the maximum value of in 32. That's the change here. Okay. Any questions on this one. Because to me the entire question of what to do with air when you when you run into some sort of air condition is an interesting one right to you drop the events do you do something like you're doing here and pick a value for implementation in the implementation. When you execute evaluate it returns. It returns a type that contains both the return value and the error list, if the error list is is not empty then it means that an error app and then things went back. Right. Okay, so that's that's that's at least how I implemented. That's a list. And I think doesn't Clemens have an action item or something to get back on his with his thoughts around how to deal with errors or something like that I thought he was going to do some work on that but never got around to it. Well, I think he was fine with that with the way arrows works. So, what to do with arrows while filtering that's the thing. Okay, let's not forget language doesn't doesn't have anything. But it's not only for filtering so you're right I forgot you're right I forgot that we did you separate out the language from the filtering aspect you're right I forgot okay. Yeah. Okay, cool. Any questions on this one from the group. You guys are awfully quiet today so this was put out there six days ago so technically, it's within the time frame to get merged. Do people want more time to think about this, or is everybody okay with going forward with it. Don't hesitate if you want more time for me I don't understand how it can return and raise an error at the same time. That's maybe just me. I can, I can show you the implementation. So, it's easier to to understand you at least at least what's my idea behind this, maybe wrong, but I'll give you a link. Remy, are you suggesting that it makes more sense to either return a value or an error but not both. Yeah, I'm not a big fan of taking max integer, because it represents infinity but what happened if we go to 64 bytes or 20 years in the 128 bytes. It might change. I don't know. I don't understand the full context probably but he's just just that sentence as a programmer I find it weird. But that's just my opinion. In cases like this linky would it make sense to first get clarity and in a concrete decision on how to deal with errors. Meaning, are we going to are we going to stop processing on error and only return error or are we going to return a value and an error because I think that's a pretty high level decision isn't it. That's, that's, well that's that that was the, that's the point of error. We don't mandate what to do. Okay. So the implementation can decide to do whatever it wants. So it can decide to stop the execution. It can decide to continue the execution with the default value, or maybe there are some errors that are more important some are less important. Okay. And we are not mandating anything around that. And a filtering implementation might decide or maybe the, the subscription spec might decide to say a, if there's an error, it just has to pay. And we are good. Okay, but the language itself is subtracting from this and it's just saying every function is total so everything written something. Okay, there might be the side effect of finding to the error list, but still the result or value always. Yeah, so in my opinion, like, I would prefer to say like we define when there is an error that means the filtering is returning false completely like so we ignore that event. And then officially doesn't return anything because it raised an error needs. I don't understand why we make mandatory to return on a value because I saw someone else putting a comment where I don't understand the value of having like minus max integer, compared to zero and I must say that I'm with him on that one because obviously I don't really care. That's mathematically it's impossible to do that. So I don't even want to have anything further because it's going to stop being unpredictable like obviously my logic is wrong there. So it should just stop in my opinion because I'm doing a mistake. So, so Slinky you talked about how this specification is not just for filtering. Can you remind the group in with the other cases that it's going to be used where it makes sense to return a value and an error at the same time. Well, for example, the first thing that comes in my mind is the ability to template some specific attributes. Let's say I want to write an expression that returns a value string, for example, to set a specific attribute in the call event. In that particular case, for example, there, when you access to a value and that value doesn't exist. It raises an error. But maybe in that case, this particular can be just, we can just forget about it. So that's, that's an error that I can ignore. So that's the use case where I can, where I might want to say a there are some errors that I just want to ignore because I don't care about them. Maybe there are somewhere or maybe I just wanted, maybe in the filtering I always want to ignore errors or maybe they're again there are some else that might be not interesting so we can ignore them. They're accessing accessing a value is one of those errors where you might actually want to say, yeah, I don't care if there's an error when accessing a value because that value is not there. I stumbled across this exciting issue today, while I was testing one of the expressions from the spec working. So this one, this particular one. Maybe you can open this one, Doug. We're going to scroll to. Okay, this one. Okay. Okay. So this one is, I'm checking if there is first name and then if there is an last name are equal to my name and surname, or if there is a subject with me with my name and surname. I guess when I try to address an extension or an attribute that is not there. I raise an error. Okay, because of course I'm trying to access to something that doesn't exist. But there is a default value defined for this, which is, which is empty string. Okay, so when I try then to. I try to evaluate this specific expression, giving to it, giving to it an event, which doesn't contain first name and last name. This is this expression will fail. And, or better, will return a value, but it will raise an error saying, Hey, you're trying for this first name but first name is not there. Maybe you need to use exist to check if the thing is there first. Okay. And so, so I can see how in a filtering system. This kind of arrow is another that you want to be on. For example, in another, in another case, you may not want to avoid, you don't want to ignore these errors, but you want to handle them some way. So, this is an interesting scenario because I'm not sure I would have necessarily thought that anything on this line would have produced an error. Because I would have thought first thing not being there would be like, okay, asking if it's no kind of it kind of that kind of statement. Because if you introduce no concept is starts to be more complex. So there is no no, there is no no concept. And this one doesn't raise an error. You see it's the asset checks if it's not failed. But if you remove with extension the line. If you remove with a 80107, this one fails, because it returns an arrow saying gay you're trying for this first thing but first name is not in the event. Interesting. So, so Daniela would you like to speak up to join the conversation I know you're doing in the chat I'd like to get your voice on record to join the conversation. So, I know it's my first time here and I'm getting the middle of the discussion but I think that by assigning a value in an error, and if people suddenly decide oh let's ignore the error by mistake or whatever reasons. They can start getting wrong conclusions. And I think zero seems to, at least for me to be a more sensible default. And because it shouldn't be really ignoring their division by zero. It sounds like there were two different sort of comments in there one is just concerned about returning anything at all as opposed to forcing people to actually acknowledges an error and take an explicit action that they choose to ignore it that's their own business. But then in this in this specific case you're saying zero makes more sense than max and minute. Yeah, because people might take conclusions and I think it's working as they were expecting but actually they're having this silent type of error that they actually they're ignoring. So, we can create all kinds of unpredictable behaviors because of this. Well, but we are raising an error. So, we are not ignoring the error we are raising an error, and we are also turned value. I personally would like a little more time to think about this one not so much because of the value although I do, I do, I do understand Daniel is comment there. You know, maybe zero makes more sense than max and minute I don't know about that one. I personally would like a little more time to think about the case of just returning a value at all, as opposed to only returning an error. My inclination is to say that if we always return a value, even if there is an error. Then I think a lot of people are going to just choose to ignore the error. And I understand then then they're sort of hanging themselves and that's fine. I'm sorry, they're choosing to hang themselves and that's their choice obviously. I think it's almost like it's encouraging people to do it, in a sense, right whereas if you only return an error, then they can choose how they want to handle the error processing right maybe return zero or empty string or something in whatever case they have. But at least then it's their explicit decision to make that choice, and we're not sort of encouraging them to do it in a way. So that's what I'm kind of worried about right now so I'd like a little more time to think about it. Well, I want to add something. Yeah, I would love to, to keep. I would love to do a distinction here, and the distinction between how the language works and always then modeled in its interface. Okay, so in its interface, you can just when there is an error can just always return an error. That's fine. I was planning to do that in, in, in the reference implementation to having another interface that when there is a there is a failure there is a failure. That's it. So, I think, I think it would be nice to keep this error system for giving the flexibility to the user to choose and to the implementer to choose whether it wants to implement or not the system. Yeah, I could definitely appreciate that point of view. What do other SQL languages do do do most of them return values and errors or do most of them only return errors how do they deal with it. Do you have any idea or does I guess anybody else in the call as well. If you have experience I'd like to know whether we're, whether we're, whether we're, whether they're paving a new path here or whether this is well established for SQL to do. I can say he's well established enough for SQL to do, but for sure. There are there are a lot of errors and way to behave about errors that are very dependent on implementations. So, well, okay, I don't want to rattle on this I think I'd like to hold off on deciding this and at least personally I'd like a little more time to review it but before we move on to the next one. Manuel has a question for you. It may not be directly related to this but he said, why can't there be the concept of a null. Well, to simplify things. In short, in the null concept you, you start to have to deal with this with things like no assertions no checks. You know, all this kind of things. SQL has the notion of null in general though doesn't it. It does it. It does but I think it has a different purpose. You know, when, like, for example, we, it has the null type. Okay, well, for example, in the cloud event spec, there is no no no type definition there is no no concept in the cloud event spec itself. So why should there should there should be in the expression language. Okay, Daniela, did you want to say something because you kind of came up mute there for a sec. Just in the concept of no no it's kind of, you're representing the absence of value in the opposition to like a default or zero value so it's not really used for error rendering because here you're, you should have a value but they have like an exceptional route and as far as you remember like most of SQL will throw an error in this case and not continue to process. Okay, well, like I said, I don't want to write on this but it was a good discussion so please everybody think about this and let's move on to the next one. Hold on. Zero return and you guys take a look at this one. Yeah, I just want to add the last people is when I mean, if you want to reevaluate the errors, the way errors works and completely open to it so somebody has some concrete proposal. Okay, please open it and I'll be more than more than happy to look at it so. Yep, that's good. It's a shame that Clemens isn't here because I think he had some strong opinions about error handling and stuff like that. So, okay. Would you like to talk to this one. This is not a small one, actually. So this is this is actually saying that the expression character any type any value inside the type system. And while the previous assertion was that the expression is returning a bullet value. And this is very important for use the expression language outside filtering use cases. Again, going back to the previous example, let's say workflow wants to use this expression language to template a specific attribute or specific extension in the event. This kind of use case can be fulfilled only if the expression character and value and not just bullets. And then I specify that when using in filter in the filtering predicate, of course, any output value, either is a is already a bullet value or has to be cast to a bullet value. So when you cast type to the Boolean value. I'm assuming if it's original value or it's original type is a string. You'll actually do a string compare on the words true and false and make a decision whether it's bullying based on that right. Yes, below there are all the casting rules are definitely below. So anybody have any questions on this one. I think this one was open like six days ago as well. Or is it. Yeah. Does anybody want more time to think about this one. I don't hear anybody I'm going to ask for approval. Okay. Any objection then to approving. Right. Not hearing any is done. Cool. All right. So we're two days ago. Okay, let's see this one. Would you like to talk to this one slinky. Yeah, so this one to be honest, I'm not 100% sure. So, and the problem here is very simple in the implicit casting rules. We're not casting for the various operators by both unary and binary operators and then for functions, but we don't really talk about like exists. So for like have exist, of course, let's say it's natural. We don't need any casting rule, because of course it's just taking the, the, the identifier of the event called event attribute, what for like, there is no need for implicit casting rules because the left argument has always to be a string. So everything has to be custom string. But for him, the, the problem is different. So for him. Actually is not very, he's not even very well defined to be honest. So maybe we have to reiterate on the operator again, but the problem is that for in there is some need to, we need to understand if we need to cast. I mean, if all the elements of the set has to be cast to the left value type. So, this is more this PR is more a question that does all the, all the elements of the set has to be cast to the left. To the type of the left argument. Do you require them to all be the same type to begin with. Well, my, my understanding was that we wanted to try different types maybe. Well, and now that I'm looking at it to be honest, I've implemented it in a different way. So, so yeah, maybe, again, maybe we need to rate right over it. And yeah, I would love to understand what people think about it. Anybody want to jump in with a comment. Yeah, if you, if you want to cash or implemented it here. So these are the past cases. Whoops, window. Because I, I'll get right up front. I am not an SQL expert it just seems like for simplicity's sake, requiring all the wise, you have the same type could only make things easier for people, both from an implementation perspective as well as a user perspective. So for in Oracle SQL, everything is casted to the left argument type. So they allow everything on the right hand side to be different. Yes. Interesting. That means then they do have implicit casting. Yes, they do have implicit casting, which is the contrary of whatever it here. So. Okay, so why did you remove implicit casting just curious. No, I didn't remove implicit that wasn't defined. No, it was it wasn't defined as that's the issue here. Wait, I'm sorry, but this line here is removing implicit casting right. Yes. Yes, but it wasn't it wasn't really again in looking at reading the spec. I didn't really understood what was the the customer for the in so that's why I opened this because it wasn't clear to me so Okay. There's a wording that that makes specific how in BS, I think. Is there something in particular here you want me to take a look at since you pasted this link into the chat. Yeah, that's that's the way now it works so now it doesn't it's in doesn't work only for strings but it works for all the three types of the type system. And it doesn't allow implicit cat and it doesn't have implicit casting. So that's that's the way I implemented it but again, I think this requires a change. Anybody want to chime in. Okay, so speaking up. I personally would like a little more time on this one as well. In fact, I'd like to actually reach out to some of the SQL experts that I have within IBM to get their take on it because I have no idea to be honest whether this is a great change, or it's being too restrictive in some way or being too loose I just have no clue. I'd like a little more time to think about this one. Yeah, that's that's that's cool. Yeah. Yeah, please involve them. Yeah. Anybody else want to chime in. Before we look at the next one we have maybe time for one more quick one. I'm hearing anybody speak up. We just did in the Johns. Let's let's do the seven and 96 because it's faster. Okay, this one is pretty simple. So yeah, the call cut to the call cut function, of course needs a delimiter as the first argument. Does concat in normal SQL have a delimiter. You know, I don't recall it. But I don't think I don't think it's a standard function. Let's do a quick search to do. No, it doesn't. Well, hold on. I found one. I found one at W3 schools. You can. Yeah, me too. You can also concat with with the plus. Oh, concat WS is to add separators. Oh, okay. Maybe there you go. Yeah, I can add another one. Yeah, hold on. Yeah, you're right. Yeah, that's what I found too. So maybe that's, maybe that's the way to go. Okay, okay. Okay, cool. Okay, with that, I don't think I have time to dive deep into any others. So please take a look at the other ones in particular if you know someone who has an SQL expertise, I think it'd be great to get their opinion on some of these changes. But because I get the general sense from the group that we'd like to try our best to to adhere the most common use of SQL out there and not necessarily define something that has almost zero possibility of leveraging existing code. Okay, so with that, let's do this. Go back up here. And do final roll call. Actually, let me ask, is there any other quick topic people would like to bring up outside of PRs and issues? Okay, in that case, Daniel, are you there? Yeah, I'm here. Sorry I'm late. That's okay. Matthew or Matt? Yes. Okay, Grant, you're still there? Yep. All right. And Doug and Vanish. So did I miss anybody else for roll call? Hey, this is Jesse. Jesse, thank you. Anybody else? All right, in that case, cool. Okay. Oh, sorry. Go ahead, Grant. I had with other topics. I was wondering for the CI issue and comment you added, Doug, are using like conventional commits. Is everything okay there? Actually, I'm very glad you asked it because I meant to bring this up and I can really forget. I think it'd be really useful if on the next week's call, if you could give a very short little presentation or something to show what people need to do in their commits to use this stuff to get past the checker. Because I think for most people, this is completely brand new. Yeah, so maybe give us the bare minimum that we have to do to get through the checks. Yeah, I can talk about it next week. That'd be great. Thank you very much. All right, anything else? Okay, in that case, everybody's free to go except for the folks who are interested in the interop stuff. We'll start that call in about a minute or so once people leave. All right. Thank you guys very much and have a good weekend. Thanks, you too. Thanks. Actually, I'm going to go to the bottom here. See what I get to pick on. Scott Venice, I can't pick on him. Remy, you're still there. Cool. I haven't seen an Easter in a while. I wonder where he went to. And Manuel. Cool. All right. Let's see how we've been losing people. All right, Remy, since you're on, you came off mute. I'll pick on you. How you doing implementation wise. Like my focus right now is Q. So after the video, I think I'd be better, but it was great to work on the presentation because I like basically I never really dig enough into the schema registry. And so I had question around that too. I'm not sure it's complete because we are working on the discovery and subscription. But like based on the data schema. That for me potentially links to schema registry or not. I was thinking of maybe just doing a smaller schema registry, like walking schema registry. As well, because I think it can be done pretty quick. And then go back to the true development on what I was doing, because I know that I have some bugs that I need to fix. As I told you Doug, like my company just got bought. I had a few stuff to do. But I expect to have a little bit more time in like in the next week to code on that and like really focus on that. But before that, I really had to do the cube corner video. So I didn't. I picked my battles and it was more on the presentation. I don't understand. That makes sense. Okay. In that case continue to list for myself. I haven't done a whole lot of changes since then. I do think that what's out there today is at least workable for some interrupt testing. I don't have any of the stuff like the pagination and stuff like that but I do think I have at least a fair number of the features in there to at least do some basic interrupt testing. I do have more to do. And I'd like you I've been very heavily focused on some of the conferences that are coming up IBM has a couple in the next month or so so unfortunately that's taken up a lot of my time. But I am planning on finishing out at least to match some of the descriptions up here in terms of what we're supposed to be testing. At least I think what's out there today can at least do some testing. Okay. I'm going to go to your side. Oh, there we go. No update mostly blocked by internal corporate stuff. Still looking forward to get a client going. Okay. Yeah, I'm trying to get it mostly code generated and I think it's okay for discovery for subscription. I ran into that issue that I don't have any public endpoints to to get the MQP delivery point or two but or HDDP callbacks actually so I'm going to skip that. I can get some code running with the existing discovery at least and then for subscription. I have to wait. Okay. Um, I don't think we have anybody has any of us on the call like to chime in, who was thinking about doing some coding. Well I was thinking about it but I don't really find the time unfortunately. Yeah. So let me ask a broader question. I know everybody's really busy and the coding stuff takes time obviously. And this probably is actually a better question asked of the full group, not just this interop group but let me start here and just put an idea out there for a question out there. I do feel like we are moving kind of slowly, not just in the code but on the specs as well. I know most of us have just been kind of assuming that it's because, you know, we're all very, very busy right now, and there's a lot of stuff going on, you know, work wise as well as outside of work. Does anybody have any reason to believe that that there's that this is a sign that maybe these specifications are not. In other words, right, are maybe not that critical. Or is it just the matter of people finding time. Because one of the things I, one of the things I, I, I, I'm worried about is, while we can look at these specs and say, yeah, we see there's value in here. Is there enough value to actually go forward with them though, right, or is it just, yeah, it's interesting, right, because I think with cloud events. I'll be honest, it took me a little bit of time to completely see the value. I mean I was all in favor of from very beginning in the sense that it sounds like an interesting idea, but the value of it to customers really didn't sink home right away it took some time for me to understand it better. But then once I did I was like, all on board with it. And I'll be honest with you with these specs, I'm torn. Right, I don't know whether this is just a matter of time and at some point a label will go off in arm in my head and say yes, this this is this is great. This is the next logical step we definitely need this stuff. Or are we are we trying to push on a rope here so I'm trying to figure out the class you came off mute. So I started a while ago, and with this intention to do something for discovery and ran into quite a few things I'd like to bring up but just didn't find the time to do so. I think it will get quite important for what Clemens and I am doing but what I see at least around where I'm working is that people are really still busy. Now to first that I'm adjusting the pure cloud events back. So, I don't know for example I spent probably really weeks of my life in discussions about what sources and things like this. So it's just that a lot of people are just not there. That's my perception at least. For me, I think the subscription and discovery seems really like I don't see the system working without it because but so I didn't have much time but that's one thing and the other is like that's my first time really being in those kind of groups. And like I have like you'd respect for everyone of you in this group and sometimes I have the feeling that I'm kind of a fraud in that group. I don't know so it's kind of it's hard for me to push because I'm like, I'm not sure I understand fully what everybody else is trying to do. And I'm still like, usually on my project like I can make decision and I'm sure because it's my decision so I don't really care about the other people's opinions, which might be bad. But in that specific I'm like, wow, there's so many people who come from like different backgrounds and like different context like Clemens like obviously at Asia is probably not talking about the same size of my small company. And, and it's a little bit intimidating for me to try to drive some stuff because I'm like, maybe I'm completely wrong. Okay, so, so first one, stop that. Okay, please. Do not hesitate at all to speak up. I mean, you see, I mean you've been in this group long enough, you know that so many people are quiet, and I actually find it kind of frustrating. To be honest, I wish more people would speak up because I want the interaction because even if people. Even if what you say is true, right where okay maybe you don't have much experience as someone like Clemens or something like that. That doesn't matter. Right, even as they say in school right there are no dumb questions right. I have the same attitude here. Bringing up a topic that you either want to get clarity on or you think is the right way to go and just even having the discussion is moving the ball forward to me. So, don't hesitate to bring up anything at all because if the worst case scenario is it will improve the spec to make it more understandable for other people that come after you. So, don't don't have that attitude please because we want to have more discussions around this and if you, if there's a particular area that that you want to help drive, even if you don't think you're the expert on it. Sometimes just putting out an idea that even if it's a bad idea is a great way to go forward because that gets people thinking about it and talking about it. Yeah, I think I kind of miss also, but that's a covid stuff. I think it would have been super great at one point like let's say cubecon to just meet together like have a beer know each other. Sorry if people don't like beer. I'm from North of France. It's like beer country in North of France. But it's just to know each other and maybe like do some work session where we are like whiteboard ideas or just to make sure we're on the same page. So I'm probably old school there but I think the now that I've been in the group for almost a year and like tremendous welcoming group like I was amazed by that. Like really congrats to you because I think you really I'm really impressed with your skills on how to manage the community even if you don't have always lots of feedback. But I think it would have helped to just meet like it's same thing for Interrock maybe if we just be sitting in the same room for like a few hours. It would have been probably faster. And with the time difference it's hard to even do that with zoom. But maybe we should do those kind of work session sometimes if people are open to to just say OK like you know what we're on zoom but we could and we try each other service might give more motivation or find to find more time for everybody else. And I do agree with you that having a face to face. Not so much to meet everybody although that obviously that would be nice but having the face to face to have the whiteboard discussions to hash through some of these things in person would have been nice I agree at some point. And that's why we that's what we try to do with I think that was you know those marathon sessions that we had a few weeks ago to try to force through some of these discussions. And I think having a having a well defined face to face event for the interop would have been a wonderful forcing function as well. Because people don't want to show up and travel unless they have running code so that really forced them to do it. It's a little too easy to have other things take higher priority when you don't have a face to face meeting to go to. OK, so it sounds like people are saying it's just bad timing bad situations. People are busy with other things it's not so much the specs are are the wrong way to go it's just it's just it's just it's just bad timing for like better phrase is what I'm kind of hearing right. Yeah, because like when I was doing the presentation like for me. So I basically aggregate all the events possible in my company or trying to. And like, I'm so bored of like going and read the documentation of GitHub and then octa and then whatever other systems to try to understand how they do their web books. What is their events. What we should plug anything like that if I had like just a discovery and point where I can just eat that and get everything. I'll be like yeah cool like I don't have to to go through lots of documentation and my integration speed in my team to integrate other external system would increase largely. And then I can that way I came up with like this idea of gateway or like aggregators because then I can read this passion inside my company and make the developer life of my company simpler saying OK. You have our internal endpoints and you can get everything that happened in this company pretty easily. So that's my vision and I think it's a it's a neat things to have so I don't think we're on the wrong path. Okay. It's just a thought that there are different degrees of interoperability and I think we so the standard so far is nice because everybody can use the same tooling like the SDKs and so on. But with discovery and subscription it's I think another degree of interoperability because you really can also link different infrastructures. At some point and I think that's just something that takes more time until also the thinking evolves and those scenarios emerge. Okay. Yeah. Okay, maybe I'll just try to shelf my worry for a little while it's just, I guess I'm going to the whole coupon event maybe step back and look at this because I was looking at the charts that put together for the coupon Europe, you know it's coming up in a couple weeks. And I was comparing with the charts that I put together last time. And I'll be honest with you, they're basically the same charts. And that got me really worried that you know we've got an entire year basically and I'm not sure we have a whole lot to show for it. And that's when I started wondering whether we're pushing on a rope. And so, but if you guys have any ideas in terms of, you know what we can do to either speed things up or to change something to, to make things happen slightly differently. I'm all ears, basically, so I'm trying to say. So I plan or I'm currently collecting some ideas to increase that primer we started for discovery and subscription. In a similar way, scenarios claim is already outlined in the schema registry. I think it's still a request right with the authorities and the different replications and things like this. Yeah, so my ideas, perhaps we then again start also discussing a bit more discovery and things like this. Okay. Okay, well I don't want to talk anymore about this I mean it's just so kind of winding at some point I guess, but I just wanted to make to find out what you guys are thinking about it is at all. So thank you for that. Okay, in that case, in terms of going back to the interop then. I guess the best we could do at this point is I'll maybe offline poke some folks I know Clemens was supposed to work on some stuff. I think Scott is working on some stuff I'll poke both those folks offline to see how they're doing. And maybe we can quickly revisit this again on next week's call, even though we don't have a interop call schedule for next week maybe on the main call just ask people to update their status in this page right here just so we can see where people are. Yeah, because I think we may need a little bit of a nagging reminder for folks. So, okay. All right, any other topics you guys want to bring up relative to interop. All right, in that case we'll call it a day. Okay. Thanks everybody for joining and have a good weekend. Thanks. Bye.