 I know I was gonna say I don't recognize that name. Yeah, I've been I've been really busy. So yeah, I think everybody's everybody's been real busy recently kind of sucks. Hey, Jesse. Good morning. How are you? Good. How you doing? Good. And David morning. Simon either. Hi. Yeah. Hello. Yo, tell me. Hamid, you there? Here. Excellent. Hello. So after last week's call, so I made some comment to me about how my microphone was really loud or there was a lot of static or something like that. Is everything okay right now or do I need to get a different headset? I think you sound great personally. But that's just me. Yeah, you sound great to me too. Okay, just want to double check. Thank you. Yeah, okay. I was joined. How are you there? Yep. Hello. Hello. And Lucas. Hey. Hello. Hey there. Hi, Mark. Hello. Hi, Daniela. Daniela, you there? I'm a teamer. Here. Hi, Doug. Hello. Daniela's hiding. Hi, Daniel. Hello. You guys are really nice and early. I like that. Hey, Lance. Hello. So, Lance, I did ping Grant. I don't think I actually did it till yesterday or maybe the day before camera for sure. To remind him that he agreed to sort of talk to the commit tagging stuff or whatever you guys call it. If for some reason he doesn't show up, do you think you could talk to that to give a quick overview of how it all works and what we're supposed to do? Or would you prefer to maybe wait till next week since I'm catching you off guard? I can do that. Okay. Thank you. I appreciate that. Sure. Christoph. Hi. Hello. Daniela, are you there yet? Yes. There you go. All right. Thank you. Where are you? There you are. All right. Just a couple more minutes and we'll get started. Howdy, John. Hello. So I'm getting the sense that you're trying to take the place of Clemens and be like the troublemaker in the group or something like that. Is that the way this works? Is that why he's not showing up? We can't have two of you active at the same time. I don't have to try to be a troublemaker. It just kind of happens normally. I understand. Okay. Let's see. Manuel, are you there? Manuel. Hi. Hello. And Lou. Hi. Hello. All right. Let's see. I think I got everybody so far. Slinky. Howdy. All right. One more minute and we'll get started. All right. Three after. Let's do this thing. Okay. We got 20 people. All right. AI is Clemens. Not here. Okay. Community time. Anything from the community people want to bring up? That's not on the agenda. Me? Anybody? Yeah. Very quick. As you already know, I'm working on the implementation for the special language and I'm going to extract from it a kind of TCK. So adjacent contain several cases and the expected results. So what I was wondering is where should I place it? So should I place it like in the spec repo or where? The implementation itself, you mean? No. I'm talking about the TCK. So it will be a set of test cases in a defined format that each SDK or each implementation can consume and check if it's compliant or not. So I can show you an example of what I have in mind. Yeah. Let me go ahead and stop sharing. There you go. You should be sure. No, no, no, no. Yeah, I have to share. Okay, that's fine. Hold on a sec. Yeah. Okay. Open this link. Yeah, hold on. And I lost all my windows. There we go. Yeah, if you're going tests. Tests. Yeah. Anyone in particular? Choose whatever version you want. Okay. Choose the last one. Okay. And yeah, these are test cases. Each JSON is the test case. It contains the schema and then it contains the test with the expected results. I want to create something similar. So description of the test case, the expression, the input event, and then the test result. Interesting. That's kind of cool. Cool. My initial reaction is this sounds very similar to like that conformance work that I know Scott's trying to get going. So I'm wondering whether this would be best suited for a brand new repo. That way you can do more than or you can basically do whatever you wanted in there and have complete freedom. Does that make any sense or not? I don't know. The thing is that we are already, I don't know honestly if it fits the conformance repo. No, no, no. Not that repo. I'm going to create another repo just for this. That could be fine too. Well, the thing is that we already have, you know, the grammar, I already PR the grammar in the spec repo. Maybe we should have a folder like in the spec repo, which contains the spec and the spec, the grammar in the test cases. Like a bit of the, a bit of reorganization of the repo because in the repo we also have like, for each subspec we have everything in the root of the repo. So like for example, that for the subscription spec, we have everything in the root of the repo. I mean, it might, maybe, maybe it's time to, to order a bit of repo. Yeah, I know that that's been my to do this for a while. I actually was hoping to get to it this week, but I never did. So, okay. Yeah, tell you what, since creating a whole new repo does have some overhead associated with it, let's do this. Let's, let me go ahead and take the action item to create a PR to reorganize the repo. And then if it turns out a folder is, is annoying or too big or whatever, then we could look at splitting out into a separate repo later. Yeah, for me, a folder should be enough. Okay. Okay, so tell you what, let me, and I think it makes sense to have this, to fit inside the process that we use to merge things in this side of this repo. Because you know, it's good that people takes a look at the TCK and check if there's something that doesn't make sense. So yeah, I think it's better to give it here. Okay. Yep. All right. Cool. Anything else in the community if you want to bring up? Any other topics? All right. This week we do have the STK call after this one. Oh, yes. Hi, Scott. What's up? Hey, so I did some work on the conformance tool this week. And you can now send binary and structure events. And there's a raw dump mode. So go check out the CLI. It's, it's, it mostly works. Give it a try. Cool. Excellent. Yes, agreed. Woot. Can we grab a link to that within the meeting notes? Hopefully it's, everyone else probably knows exactly where it is. Hold on. Scott, yeah, can you paste the link in there and I'll copy into the meeting minutes? Easier for you to do that. No problem. Thank you. My screen. Okay. Oh, sorry. One more thing. I also released the 2.4.0 of the Golang SDK. There are a couple breaking changes. Sort of. We had to move some packages. They're technically not breaking. They are technically breaking. Okay. Well, we chose to not bump it to 3v3 because they're very specific niche usages. So if you're upset, I'm sorry if we can talk about it and we can work around it. So reach out if you're, you know, pitch forks. Yep. Okay. And Mark just mentioned that there's a new PowerShell SDK out there. So thank you, Mark. Anything you want to say about that, Mark? Well, you know, it's the initial input into, initial commit into the repo. So your mileage may vary, but the team's going to be updating it and should be useful for people that like to use PowerShell. Yep. All right. Cool. Anything else for community time? Oh, thank you, Scott. Hold on a second. I lost my window. Good performance. There you go. There's a link to it. Cool. All right. Moving forward. We do have an SDK call scheduled for this week. As of right now, I think there's nothing on the agenda. So please add an item if you want to discuss something. Otherwise, we'll cancel the call. Interop. We didn't really have much of a call last week. There has been a whole lot of progress. So let me just take this opportunity to nag people if you've promised that you, or if you said you were interested in participating. We did say we're going to start beginning of April. So please put up your endpoints in that document so people can start doing some testing. Let us know your status, which things may or may not work so we know what we can hit and what we can't. So just consider this being nagged appropriately. Anybody have any questions or comments on either of those things? All right. Moving forward. Just a reminder, I just signed up for two 45-minute sessions. There's the times. Please add your name here if you can join. Remy did upload his video. So I think it's probably too late to make any changes to it. But if you're interested in seeing the video or the slide, I did include the links here. So he's doing our cloud events session for us. And Timur, anything you want to mention from the workflow stuff? Just more SDK stuff. We added a .NET SDK and a TypeScript SDK, and both were community contributions. So that was really cool. And other than that, yeah, I picked our sessions at KubeCon very late. So we got us to end though. So yeah, we're going to work on that and make sure we have all the content from that ready. All right. Any questions? Oh, go ahead. Yeah. Does the .NET workflow SDK depend on the cloud events SDK, .NET SDK? Because if so, in fact, I was just writing an issue for the PowerShell SDK saying, okay, you're depending on the latest GA of the .NET SDK. That makes sense. But it would be really good if everyone could be ready for when we're ready to do the 2.0, which will have breaking changes for .NET. I hadn't been aware of so many other projects that were depending on the .NET cloud events SDK. I would love to avoid breaking people or at least make it as short a break as possible. So we should probably all get together. Yeah, definitely. I think right now that the workflow .NET SDK does not depend on the cloud events one, but that would be really nice actually to kind of combine them together in both the Java and the Go and .NET. And I will definitely try to join the SDK meetings for those discussions if that's okay with you guys. All right. Any other questions for a team around the workflow stuff? Okay. In that case, Grant, I noticed you joined. Thank you. So, Grant, do you want me to stop sharing or something you want me to click on? How do you want to do this education session? Yeah. Let's maybe go to the spec repo on GitHub. Let me just go here. Quick is easier to get there. Okay. Yeah. So one PR that we added in the master branch is to add a GitHub action that gives a green check mark if there's conventional commits. The goal of this is to, especially for folks that don't actively look at the spec every week and sort of you want an overview, it's to enforce or at least encourage folks to use conventional commits when they're writing their commits. And so if we go maybe to like fix some typos, maybe the first PR there. So and we go press the red X under the fix or we look at that, yeah, under the details. You can see that the linter has ran and the commit message is like not a conventional commit. It says the subject may not be empty and the type may not be empty. And so the fix here would be to prefix with a type like docs colon and fix a few typos. And so then when we get a lot of these commits in our spec, folks can just look at while they serve can ignore the the like doc changes that don't really affect anything. And then if there's a feature, it'll have the feet prefix. And then you can look over commits more easily that way. Okay, Slinky has his hand up. Slinky, you have a question? Yeah, to be honest, I don't I don't understand why we need this. For the very simple reason that our Git flow is we do PRs, Doug merged them. So at the end of the day is Doug that squashes the PR and types the actual commit message, commit title. So I think what we need is just to have Doug adjust any the automatic message generated by GitHub when squashing PRs and merging them. Yeah, so that sounds fine. So the overall goal is when a developer looks at the spec, maybe a lot of developers don't look at it every week or even every month, but they'd still like to understand what are the top changes in the repo. So maybe the process is just if there are significant spec changes, when Doug merges them, they're like under Doug changes the commit message to like a feet or a fix or docs, depending on what the changes. But let me so okay, I have a couple questions, but let's go back to the queue. So Jim, your hands up. Yeah, and I think my question was along probably the same lines are slinky because I tripped over this. What I found myself having to do is, you know, as I'm iterating on comments on the PRs, I'm having to do squashes every single time. And so I wasn't sure if is it just the first commit in the chain that some that this rule applies to or every single commit that goes through. And, you know, is there an expectation that either I then when we're ready, squash the whole thing and give it to Doug as a single item, or the maybe a slinky said that Doug does it at the time that he does the merge. Because I mean, I think it's, it's, it's sort of affecting the way that I tend to work iteratively. So if people put some comments in, I'll do a, you know, I'll do another tweak and a commit and a push to address those comments. So you sort of get this backlog of changes, which eventually you want to squash. Whereas I think this seems to think that every commit I do could be the final commit. Yes. Go ahead, Grant. Yes. Let's get point. I think maybe we want to change the commit lead just to run when on the master commit, it shouldn't affect anybody just developing and trying to create a PR. Or, or, well, I guess, I mean, at least the goal is to the only real changes the squash commit at the end. And that's really where we care about if this passes or not. Cool. Okay. So, so let me ask a question. If, because I actually had a similar thought process to what I think Lance was saying in the chat, which is, I thought we were doing this to auto generate, in other words, like release notes, kind of stuff, right, change law, whatever I call it, right. And we don't have that process defined in here. Or, so I was wondering one, whether Grant, you were planning on doing another PR to introduce that process, whether it's simply documenting it or whether it's adding additional tools or whatnot, so that we can automate that process. But then also, do we want this, this change log stuff or this, this, this conventional commit stuff to apply to every single PR or just PRs that we think are significant enough to warrant mentioned in the release notes? Okay. So for the two questions, yes. So one is, you know, first, in order to get, to be able to auto generate a change log, we need to start using conventional commits so that the change log has something to work with. But yeah, the, the eventual goal is, okay, sort of like, yeah, the JavaScript SDK, if we start using conventional commits, then we can just auto generate the change log. And yeah, a further PR would introduce the auto generated change log. Okay. But is the assumption that if we need this on all PRs or just the ones that are significant? I mean, all, if, if we merge and have all the changes, all the PRs to have a conventional commit that would make it easier for the tool. Okay. Because I'd like to get a sense from the group in terms of the process everybody wants to follow. Because if we want to, if we want to be consistent, then it seems like every PR should follow the same process. And while I don't necessarily mind doing extra work when I hit that, when I hit the merge button, I can do that if people want. It also makes me a little nervous that I would be the one editing or typing the title that appears in the release notes when I kind of feel like it should be the author who at least does it themselves. And maybe I can, I could fix a wording, you know, a typo kind of thing. But I, I'm not sure I should be the one that comes up with that as opposed to the author themselves, because there's a capacity to get it wrong. So it makes me a little nervous. So I just want to make sure we're clear on what a process we want to go as we go forward here or what process we want to do as we go forward here. So Daniel, your hands up. Yeah, a couple of things. So first of all, there are, there are tags for commits that are meant to be like not this is this is not significant for the changelog, I think. But I think my convention chore is is one of those that generally is just kind of ignored by the changelog generation tools. So if we want to be consistent about having every commit be conventional, we can just, you know, have a type of chore or something that's that is used for, you know, things that are not significant. To the other question about whether we want so kind of having the commit author being the, or the PR author driving the, I guess the text of the line in the changelog, I think that's the that was kind of the point of having a linter like this is to kind of cause or force the PR authors to participate in that process and to get in the habit of writing a conventional commit such that their understanding that this is, you know, this is going to go into the changelog. And so I should think about, you know, how this should appear and write the commit message accordingly. So I think that was kind of the point of it is a tool to kind of force us to think in those terms. So that said, if there are issues with like, well, I want to add more commits to my PR and they're not, you know, and now it's forcing me to change my workflow. I don't know if there might be ways to to convince to configure the linter in certain ways. I think by default, it might assume that every every commit needs to be, needs to be conventional. But if we're going to squash, maybe there's a way to to configure it to only check the first one, because I think if you have more than one commit, then by default, Git uses the the title of the PR rather than the commit messages itself as the default, or as a starting point for your your final squash commit name. So there might be ways to to configure it to to know that, hey, we're going to squash, let's let's optimize for that workflow. Okay, thank you. Slinky, you're up next. Let's go talk because I think he has the same proposal that I have. Okay, Scott. Hey, so I've, you know, based on every other project to work on, we use a convention where we we use a special tag block. And then Kubernetes has this release notes tool that goes and looks at every commit that landed in that, that timeframe, and then extracts that, that little block plus potentially labels that were applied to the PR. And so it's, it has nothing to do with the commits, and the commit messages in the squashing, it has everything to do with GitHub and the description. So that seems to work. Maybe we would like to do that because it's a little easier for the both the the CI process that we use in GitHub and poor Doug to not have to rewrite commit messages on smashing because this is, so here's the text of what the commit conventional commits uses. So basically says it's Doug's job. You might want to comment on that. So, so this is correctly wrong here, Scott. I think then the, the requirement of the developer or the, the person who's submitting the PR is to make sure that they're, they have the proper release notes section in their comment, right? Yeah, that's right. I could maybe next week I could show a little demo and we have some some wrapper GitHub action tools that help you kind of like extract a markdown file based on two hashes. What are the people? Yeah. What are the people think? And, and, and I want to add that it's even simpler for you for users because if we have a template for the issues, we will enforce people to write the release notes. So it's even better because we kind of force the user to do that. Yeah, that's that's a great point. We can add a template that shows, you know, here's the section you fill in. He could even add a comment that doesn't get displayed in the PR description and kind of explain what this thing is. And then every time any PR gets opened, you go through that little template and you can fill out the release notes. Okay. Anybody else want to chime in there? Otherwise I'm going to mention a proposal then. Okay. So Scott, you asked or you volunteered to, to share that process with us on next week's call. So why don't we go ahead and do that? And I, and I agree with you, Daniela. Yes, we'll modify the contributing doc if we even have one or create one if necessary. But yeah, whatever process we come up with, we'll make sure we, we documented someplace. I definitely heard that. But so in the meantime, though, it sounds to me like we're agreeing that not necessarily every single PR is going to end up with a release notes type of thing. So technically for the PR is that we already agreed to merge that have this quote problem. If we don't think they're worthy enough to mention that in the release notes, I can just go to merge those and not worry about the bot complaining. However, if there is one that needs that we think should be in the release notes, what I want to do is make sure people understand what things should look like. So grant is I'm trying to figure out, is this a good example of what the commitment should look like? I mean, is this when I do a commit, I just put this in the first line and that's all that's needed to turn into a feature to turn into a chore versus a feature or something like that. Yeah, exactly. So you add a prefix of the type and optionally a scope. And so, as Daniel mentioned, chore ones will not be added to the change log. And so we can sort of ignore those. But the significant ones like the features or fixes can have those prefixes. Okay. So it is the first line of the commit message, not the title of the PR, correct? Yeah, for the current implementation. Yeah. Okay. Okay. Cool. Okay, so let's spend too much time on this. Why don't we go ahead and table this until next week and then Scott can talk about his proposal for a slightly different process. Is that sound fair? All right, cool. Yeah, sounds good. All right, cool. Thanks, Grant. Okay, so before we jump into the PRs, and I will merge this one now, Slinky, any other topics you want to bring up before we jump into PRs? Got a nice long list today. All right, let's go back to Slinky, because it is the Slinky show today. You are making me nervous. All right, back to this one. I believe a couple of people asked for this one to be held off a little bit. I think I might have been one of them. Personally, I did do some thinking about this, but I haven't changed my nervousness about it. But I also don't want to say block it since we can always change it again later. So I'm okay with this going in for now. But what do other people think about this one? Anybody have any concerns, objections, questions? Daniela? Yeah, just commenting that last time we had this discussion about how database process this. I did a few experiments on SQL FIDO and basically Oracle SQL Server and the major ones, they throw an exception. But I feel like I think was my SQL and a few others, they basically returned no. And I know we did have this discussion on whether returning no was a valid option. So there are a few databases that do that. So it could be a better alternative than this one. Slinky, did you want to comment on that or not? To be honest, I strongly disagree with that thing now. It adds a whole more complicated set of problems that I'm trying to avoid as much as possible. So I'll be honest with you. And if we want to add no, it's not just about adding no for this specific problem. It's about adding no in the whole spec and language design, which is the same thing I explained for the error for ending errors. This is a consequence of how ending errors is defined in this language. And I'm very open to change it or modify it. But then I think if we want to do that, we need to bring up the discussion at a more iron level. So how do we end up erasing the language? Do anybody else want to chime in? Okay. I guess my only question is, I don't have an opinion on whether we should have no or not. But I do agree with you that if we do choose to have it, that's probably a very significant change more than just this one operation. So my question is, and maybe you can refresh our memory, is if we don't want to support null or nil, would the next best thing not to be, wouldn't the next best thing be to just make the return value of this zero, even though zero isn't technically null, it's closer than max and min int? That'd be my only question for you. Well, the reason why I choose plus infinite and minus infinite is just because it seemed more reasonable to me. But we can go back to zero and that's fine. At the end of the day, this still raises an error and a user will still eventually end of this error. So anybody else want to chime in? Okay. Like I said, I don't have a huge feeling on this. My gut is telling me zero might be more intuitive for people if we're going to return any number at all. That's why he's running through my mind. But I don't want it to be just one vote either way kind of thing. Okay. Daniela says, I prefer not to change it until we have a clear benefit of returning something different than zero. Eric seems a little, he's towards zero as well. So, Slinky, would you be okay if we held off a little on this until we get more feedback? Yeah, sure. It's not a crucial part of the language. Okay. Yeah, it's not a big problem for me. Okay, I appreciate that. Again, I opened this just because it seemed more reasonable to me. Yeah. Okay. If you want to continue, it's fine. Okay. Is there any objection then to not doing this at this time? Okay. Let's move on to the next one then. Clarify in semantics. I think this was there last time. Yeah. So this one, we had the discussion of whether order databases act on the typecasting when using the in. And I, in the conversation, I wrote my findings. I tried with my SQL and Oracle SQL, I think. And yeah, it should be fine this way. So this way is more like order sequence, let's say. But can you open the conversation? Because if I click correctly on this one, Oracle SQL behaves differently from my SQL. This one? Yeah. Yeah. Yeah, because Oracle SQL doesn't have the Boolean literal stormfalls. And in my SQL, the implicit typecasting is only valid for binaries, but not for numbers. Here, I may be doing some mistakes here to be honest. So at the end of the day, they are not really the same between Oracle SQL and my SQL. So I just chose to go with what seemed reasonable to me and for the user of my SQL, which is just course, always the types to the left argument type. So that's it. And that's what I wrote in the spec. Okay. Any questions or comments? Nothing? Okay. Any objection then to approving? Done. Easy. Okay. Cool. John, do you want to refresh our memories on this one? Yeah. So this is replacing a fairly brief couple of paragraphs with significantly more detail attempting to squash out any ambiguity and also hopefully make life a little simpler and more reliable. So it's encoding and decoding HTTP headers that are meant to represent cloud event attributes. And it's basically saying perform percent encoding on anything that's not ASCII or is a space or is percent for obvious reasons or is a double quote. And the reason for encoding spaces and double quotes is so that we don't then need to perform quoting as per RFC 7230. But SDKs still must perform decoding via RFC 7230 for compatibility with previous versions of this spec. So my hope is that it is compatible. And it looks like the comments so far have been encouraging on that front. No one said, oh, it fails in this respect. I've tweaked a couple of bits of wording. Have folks had a chance to look at it as much as they're likely to? All feedback welcome. Any comments? Speaking just for myself, I have not had a chance to review it yet, but I was kind of encouraged by some of the comments I saw go flying by. That as you said, it seemed like most people were not too concerned about breaking things. So that was nice. And I'm definitely, while I would obviously like to get this in partly so that I can get the C sharp implementation in, although if the noises are encouraging, I'm happy enough to merge the C sharp implementation in a sort of this looks like it'll go in. But I definitely don't want to rush this. Let's get it right rather than fast. Right. I'm inclined to ask for just one more week, but then put pressure on everybody myself included to say, hey, unless you have concrete issues with this, we're going to take a vote next week. And that means it's probably going to go in unless people have some concerns. That would be great from my perspective. So anybody want to chime in at this moment? Okay. So let's do that because this is a significant change. So we'll vote next week. Whoops. Okay. It's sort of in one of my topics. I note that the expand versioning suggestions is in too new to vote. But it was from just over a week ago. So we might want to. Yes, I apologize. I where are you John? halfway through the two new to so up a bit. Oh geez. There. Yeah, I apologize. I was really slacking on my job in terms of getting the agenda ready. So you should see what we're like for the ECMO C sharp standards. And normally I do this stuff no later than Tuesday. And just this week just got away from me. So hopefully after next week, my schedule will get a little more normal and I'll be able to get back to getting this thing's done timely. So I apologize. As I suspect, most of these are not too new. So to forget this, I'll just remove that. Okay. Let's go back to slinky then. Because we like hearing from slinky. You want to, did we talk about this one? I don't think we did talk about this one last week. I think we didn't. Let me hide the comments. You could talk to it. Yeah, it's so this is basically putting some constraints on how bad you can mess up your engine, your expression language engine. So I'm basically explaining that the overloading is allowed, but the but there is limit on how you can overload. There is a sentence that is not completed because it was a casting functions with the same anyway. And so he puts some constraints on overloading and on variadic functions. So I'm just being more explicit on how you can define custom functions. That's basically or on how the spec can define functions and how engine can allow to define custom functions. So that's it. Any questions? Okay. I think this one's been out there for at least a week. Okay. Any objection to approving them? Anybody want more time? All right. Not hearing either. Thank you, Slinky. Yeah. Let me let me remove line 202 before merging. Oh yeah. Okay. Hold on. Hold for one typo. Okay. Can do. And John, I think you might have briefly mentioned this one in a previous call. You want to refresh our memory? So the the history of this is someone asked in the C shop repo, how do we go about versioning cloud events? And this is a topic I'd been working on internally within Google. And obviously had strong opinions because I tend to. But it felt like something that deserved to be in the spec repo. So we created an issue here, discussed it about a month or so ago. And I came up with this proposal, which I hope reflects the conversation from then. Now, given that it's a month ago, I suspect that almost everyone has forgotten what we actually said. But basically, this, this suggests that the, the type should be used as a sort of normative way of saying, do not expect these two to be backwardly compatible because they are different versions. And you know, you can define a producer can perform their own use of semantic versioning or not. However, they want to do that. But one thing I would like to be checked within this is the part around the data schema attribute. So I have asserted without any particular evidence other than gut feeling and previous conversations, exactly this paragraph that you're looking at now around data schema attributes is expected to be informational. So I can see it being really useful for tools that let you inspect cloud events dynamically. But my guess is that most code that is consuming a cloud event won't use the data schema at all. It will expect things to be as they were defined when, when the code was written or compatible with that. So please shout if I have completely misunderstood the point of data schema. I don't think I've had any comments on this one at all yet. I could be wrong. Again, I'm not in this is even less of a hurry to, to get merged. If folks could take some time to have a look and see whether I've written complete nonsense or not, that'd be great. Okay, any questions or in particular comments on that paragraph that's highlighted or where the cursor is? Just let me be even more forceful with that question because that is something I've often wondered myself because I tend to agree with you, John. I tend to think that people tend to like what a phrase sort of statically create the code that they're expecting to come in and the idea of dynamically changing what you're going to get and analyzing the schema at runtime, I just, I don't know how often people actually do that. I always had a gut feel like you that they probably don't. It's a little more static than that. But I would love to know, does anybody on the call have the opposite opinion that there are lots of cases where no people actually do analyze the schema at runtime beyond a superficial schema checker thing? Do people actually use it for anything real? I can imagine some cloud events with particularly dynamic data where the cloud event provider, producer, doesn't really specify the schema themselves. They just pass on data from something else. So you could have 10 different events all with their own different data schema attribute, but that would be for a very particular kind of cloud event, I think. Anybody else want to chime in with their experience? Okay. Can speak up for a moment. I was going to speak up and then you made that little quibble about using the schema for validation purposes. And I've been writing Node for a while. Because of the untypeness, there's a whole lot of code that I don't have to write if I use the schema validator to basically say this message that I'm receiving meets exactly the requirements that I have for that data. And so I don't think I don't see the scheme as informational as part of my security apparatus and everything. I don't know. I did a comment. Okay. So John, that sounds like maybe this paragraph here might be then a little too loose or something. Because it doesn't take into account what Eric was just mentioning there, which is, well, they may not necessarily do anything like dynamically create objects on the fly because of it or anything like that. But people may use it for schema validation at runtime. So it isn't strictly development time thing. Yeah. I'm fine with it being used at execution time, although I would have expected if you're trying to validate that the data you've received is reasonable, validating that against what the event itself says is reasonable feels like it doesn't buy you very much. It's sort of, do you say that you're okay? You do? Oh, that's all right then. I'm being overly flippant. But I would expect it to be more likely to validate against a schema that you have previously, that you knew about at build time. But I could be really wrong. I would be, I would love to hear more in written comments that I can then try to inwardly digest if possible. Eric, do you have any comments on that? I'd love to hear your opinion on that. I agree. I haven't accounted for dynamic schemas. And this is the first I've heard of it. So I definitely really need to actually read it before I make any more comments. Okay. Let's see. Why don't we, since John, you said this was even less of a priority for you. Why don't we hold off one more week and push for it to maybe get reviewed or voted on next week? That'd be fab. Thank you. Okay. Are we okay with that? Okay. So let's do that. Push for vote next week. Please review. Cool. All right. Slinky, you're up yet again. Yeah. These ones are quite easy. So this is concat WS. So it's concatenation, but using a delimiter. It's the same as anti-sequel. Just like you guys, what is WS stand for? Oh, with... Don't ask me. I'm not the one who choose such a bad name. Okay. Interesting. Yeah. That's what I was wondering too, Daniel. I thought maybe white space, but it seems weird that you can actually put in the delimiter. So it's not just white space. Interesting. Okay. Anyway, any questions for Slinky on this one? Any objection to... When did this go in? It's not too new, is it? Yeah, eight days ago. Any objection then to approving? With separator. Thank you, Lou. That makes sense. Doi. We missed the obvious there. All right. Just to double-check. Anybody have a... Anybody have an issue with approving it? All right. There we go. Thank you, Slinky. This one. Okay. You want to talk to this one? Yeah. This one, I basically simplified the definition of the casting functions. Semanticality are the very same. I just made the definition a bit simpler. Okay. Let me just give everybody a sec just to quickly scan these. See if anything jumps out at you. Seems fairly straightforward. Okay. Anybody have any questions on this one? Well, there is one semantic change, which is now... Is bull returns true if you pass a bull as a value, and then when you pass an integer returns the identity. Bull, when you pass a bull returns the identity, string, when you pass a string returns the identity. So that's the semantic change. Okay. Any questions on that? You guys are still going on about the concat thing. Oh my gosh. So funny. Okay. Any objection then to approving this one? All right. Done. All right. Next. Moving right along. Wait. When was the hell does this one... This one's eight days ago as well. It's good. All right. You want to talk to this one? I changed substring to look like SQL. Simply. What was it before? We're starting at the... Yeah. Ending with length versus length versus index. Got it. Okay. Yeah. And then it's one indexed. Got it. Yeah. And to be honest, this the string built-in functions were very drafted. So I scanned them, scanned all of them and checked if they behave like other SQLs. Cool. That's why several PRs on this subject. Okay. Any questions on this one? Any objections to approving? And back to our favorite XML. There was actually a small little Twitter thing about this over the last week. People were mocking things written in XML. So I pointed them to this PR. So, Gem. We're like a good mocking. I partly did this as a mental exercise, but there was an outstanding issue. So it does address that. Take it or leave it. I think that's what it is. I mean, this is... It shows a mechanism that you can express cloud events in XML format if you want to do so. Nobody's mandating that you have to do it. For all the XML isn't trendy. It's extremely well supported in just about every language ever. Exactly. I suspect it's actually far more useful than if we ended up with a YAML format or something like that. Cool kid stuff. Yeah. I was pleased to see this at which point I'll say I haven't reviewed it in depth, but I was pleased to see that it existed. Well, thanks, John. You're my new best friend. Well, you realize, of course, if we approve this, the next step has to be a soap binding. You're right. I mean, Gem, come on. No. No, no, no. No. Fine. Okay. Any questions off the bat? I mean, there's a little example, I think, at the end of this, which sort of will give you a glance into what the actual event structure would look like. Yeah, so that's what that's basically how you can think about it. I will admit, I've not written any XML stuff for about 10 years, but I do remember that it was much more efficient to be attribute heavy and support a more streaming style. So that's the model I went for. And I added batch support at the same time. Yes, I noticed that. I'll be honest, I have not had a chance to review this yet, so I'm probably going to ask for more time if you're okay with that. But one thing that comes out of me is, how can you do things like put VR instead of version or spec version to completely align with the attribute? Again, I think this is a constant battle I have. This needs to be humanly legible, but it's machine interpreted. So anywhere that I tend to try and be as efficient as I can, there's no need for verbosity there. So I'm all about bytes on the wire, essentially, especially when we're talking about XML, which is naturally a little bit verbose anyway. So I can show you if you want to see unverbosed, you should look at Swift messages or 6ML or something like that. Yeah, just the inordinate side of me likes consistency. That's the only reason I was thinking about that. So let me pick on some folks. Yeah, go ahead. Sorry, I was going to ask, is there a reason why VR is special for having its own XML element? So if you're stream processing, you need to get, in my mind, you need to get the version as early as you can, so you can then make assertions about the stuff that follows it. That was my only way of thinking. I mean, originally, this was also a way of enforcing the version to be present. I didn't go down the road that I did with the protobuf stuff of having all the required elements present, because it just looked a little bit messy. But having the version stuff there forces it. Oh, and having it as a sequence, so that has to be there. So obviously, you could say, well, the first atta has to be for the spec version, but that couldn't be enforced in the schema itself. Exactly. And depending what sort of XML generation process you're using, you couldn't always control the order which those elements are going to be emitted. Could you not have just made it an attribute on the cloud of anything? I would have thought this would be a version attribute on here. There you go. You see, man after my own heart, actually heavy. Yeah, I could do that. That's good feedback, Doug. Thanks. I'll make that change. My only feedback is at the utterly trivial level of there appear to be some extraneous blank lines in the schema. Oh my gosh. Yeah, okay. That's there for human readability. That's just me. That's my personal star, but we can rip those out. If that's all that's holding it back, John, I'm more than happy to rip it out. I will have a proper look next week. Okay. We're coming up on time, but Slinky, why don't you have the last word since your hands up? No, no. You said exactly what I wanted to say that you should have the version inside the cloud event. And to answer Slinky's comment, you would be surprised that I may already have a sort of rough support for it. Waiting for it. So exciting. Yeah. Okay. You can tell it's been a slow couple of weeks, can't you? Yeah. Okay, so minor changes. Oops. Okay, look to approve next week. Oh my gosh. It could be the fastest PR I've ever got approved. There you go. Okay, with that, we're technically almost out of time. I think I got everybody for the tenure list except for Klaus. Are you still there? Yes, I'm excellent. Could we do, could we, Doug, if we have a chance, could we look at the next one? Because it's really, really minor. And I think John was the guy who prompted me into it. Sure. Go for it. Here, let me hide the comments. Yeah. So just for reference for people, this is, for some reason, I had a mental brain fart and I didn't add batch support when we originally defined the prototype format. So this adds that. It's really simple construct, just a repeating set of events. John, does everything look okay to you? It does indeed. This one I have actually reviewed. I think even if I'm able to give approval, I think I probably did. Yeah. Basically, German, I had the same thought at roughly the same time and he was good enough to implement it instead of me doing so. Okay. So I think, Doug, you've made that comment. I can change that language. I mean, as I said, I was trying not to just blindly copy the language from the JSON format, but that is very similar language. Okay. Yeah. If we're inconsistently awkward, then that's fine. That would not hold up the PR. Then it bothers me that much. I'll open up a separate PR and try to dress both specs at the same time. Right. That would be a good, I think a good move. Okay. Because it is a bit of a struggle to read, but you understand the thrust of it. Yeah. Yeah. Are you hoping to vote right now? If people are willing to do so, or obviously, just give a thumbs up on the PR if anyone has an desire. Okay. Well, let me ask the question. Is there anybody who wants more time to review this? Any objection to approving? Even if you, well, I already asked if I want more time. Okay. I'm not hearing any objection. Especially since we have had somebody who knows this stuff like John, he's okay with it. I see no reason to wait. It's been seven days. So one last chance. Any objection? Okay. Cool. In that case, we are done. Thank you all. And last chance, did I miss anybody for the attendee list? All right. Cool. In that case, if you're not, if you're a non-SDK person, you're free to leave. Anybody have any topics for the SDK call? Otherwise, we will not have an SDK call. All right. Not hearing anything. We're then completely done for the day. Cool. Thank you all. We'll talk again next week. Good call. Thank you. Bye everybody. Bye. Bye. Bye.