 Hey everybody. Good morning. Linus, are you there? Oh, no Micah. Linus, are you online yet? Yeah, hello. Hello. Good morning, Daniel. Oh, hey David. Antonio, are you there? Yes, I am here. This might be your first time on the call, correct? Yeah, it is. Yeah, if you want... I'm part of the serverless workflow specification. Tim told me that this is kind of a meeting where both groups discuss together. Yes. Oh yeah, it's great that you joined. In the Slack... I'm sorry, not Slack. In the Zoom chat, if you'd like to be associated with the company, can you just go ahead and put your company name in there and then I'll just add it? If you don't want to be, that's fine too, just in case. Yeah, it is. Okay, it is now. Okay. And this is a small typo in my personal name. Did I mess it up? I'm horrible at this. E, that one. There we go. Thank you. All right, cool. All right. Christian, you there. Hey Doug. Hello. Jesse. Hello. Lucas. Hello. Hello. And yo, Tommy. Hey, Ginger. Hey. Oh, hey, Remy. Hi, Christoph. Hi. How are you? Good. How you doing? And Klaus. Hey, Doug. Hey, Doug. It's Ginger. I'm here just having audio problems. I heard some weird background noises. I heard that's good enough. Hey, Manuel. Hey. Hi, Daniela. Hey, how's it going? Good. How you doing? Good. Good. Good. Oh, hey, Lance. Hey, how are you, Doug? Good. How you doing? Hello, Doug. How's everybody? That was a big sigh. It is. I don't know what's going on this week. It is absolutely awful in terms of meetings. I think it was spring break in the U.S., was it? Say that again? Was last week spring break in the U.S.? I don't know. We kind of end up with, yeah, we end up with a rolling spring break. It kind of goes from like the end of March to the beginning of May. Because something happened that it's like this week is completely jam-packed from like solid, solid, solid meetings. I usually don't have. Yeah, I don't know. With my son being at home from college or taking college from home, it's like, I can't tell the difference between spring breakers is not. So who knows? All right. Lucas, are you there? The other Lucas. I'm here. Yeah. All right. And Lou? Yes. Hi. All right. Cool. One more minute. Don't get started. Hey, Scott. And Slinky, are you there? Yep. Cool. All right. Three after. Let's do this thing. All right. Since you're on the call, Clemens, just a reminder, you have a couple of AIs for you, is if you weren't busy enough, right? Yep. Yes. Yeah. All right. Community time. Anything from the community people want to bring up? That's not on the agenda. All right. Cool. We do have an SDK call scheduled after this one. Scott, did you want to talk about that topic about the copyright thing or not? Yeah, sure. I was asked about copyright on the SDK in the Go SDK code because someone wanted to take one of the functions and fork the code, but there was no copyright header on the file. So I was asking Doug, should we go through the trouble of adding copyright headers to all the files so that people can do things like fork? Does anybody have an opinion on that one? I mean, technique is probably a good thing. I just don't know whether it technically matters that much. Clemens, you seem to have a legalistic type background in some respect. Do you have an opinion on that one? Sorry. Sorry. We need to copyright headers in the source files for the SDKs. I don't know, actually, whether the, yeah, I don't know. Okay. Whether that's important. Okay. So I just happened to have read through the whole... I'm sorry. Is that again Linus? Yeah. So I just happened to read through the whole GPL FAQs and they strongly recommend to add licensing headers. Okay. Lucas, you came up with me. Did you have an opinion on this? He said GPL, but we're Apache 2 and our stuff. Well, I think it does not depend. Yeah, since you have counsel. For what it's worth, Apache 2 also recommends to use headers. Okay. Okay. We just haven't because, you know, it's just, it's not something. Okay. Let's put it this way. Oh, let's speed this along. Does anybody object to saying we should put a copyright header on the docs and the SDK post can figure that out, whether it's the one that Scott put into the chat right now or a different one, the SDK folks can figure that out for themselves, but we should do question before us is yes or no, should we do it? Any objections to saying yes? Okay. Is that good enough for you, Scott? Yep. Sounds good. I'll work up PR. Cool. Thank you, Scott. All right. So I'll double check during the call, but if you have any of the topics for SDK, go ahead and add it to the SDK doc itself. Otherwise, it will be a very short call. Nothing for the interrupt call. I think we had a very short call last week, but if you are working on code there, please add your, if you have an endpoint, please add your endpoint to the end of that copy, to the end of the interrupt doc so we can start doing some testing as people come online. KubeCon EU. I have not looked at these links yet, unfortunately, to see what we need to do in terms of signing up, but I think we still have a little bit of time. Okay, Antonio, since I don't see Tim around here, is there anything you want to mention from the SDK side of that? I'm sorry, the workflow side of the house that people might be interested in knowing? No. Sorry, I don't have anything to bring here. Okay, that's fine. We'll just keep on moving then. Okay, PR process. So unfortunately, I did reach out to a grant about how we were heading towards Scott's proposal. He never actually responded to me, so I don't have a definitive answer, but I suspect he probably doesn't care so much about the process based upon his previous comments. I think he's just more interested in making sure we have some sort of human readable release notes type documentation and the actual mechanism to get that. I don't think he cared too much. So I'm inclined to say that we go with Scott's proposal that we tentatively agreed upon last week. Does anybody view things differently? Okay, so we'll go ahead and do that. So, Scott, will you take the steps necessary to do whatever is or to get us access to the tooling or to put the tool in some place in our repos? Yeah, we can do all of this magically. So I'll make an issue and assign it to myself. Okay. I'll start with spec and then we can negotiate with all the other SDKs. Cool, thank you. All right. All right, cool. Before we jump into the PRs, any other topics people want to bring up that we need to talk about? I just was struck by what Scott just said about negotiate with all the other SDKs. Is it important that we all have the same process or if the end result is the same, is that okay? Because like we already have a process with the JavaScript SDK that does exactly what we're talking about. That is a very good point. I believe most of the discussions we had until now were focused on the spec repo itself. So it's a great question. Yeah, that's why I said negotiate, not dictate. There you go. Okay, I'll make sure. Cool. Okay. I was just reading John's comment. All right. Okay, any other topics to bring up before we jump into PRs? All right. John, do you want to talk about this issue or are you unable to come off mute? Okay. We'll wait. Tell you what. Clemens, hold on a minute. I'm sorry, said again. It's all good. Keep going. Well, I was going to say, John, how long are you going to be? Because as long as you can eventually come off mute at some point, I'll just defer this. Let's wait on that one then because there were some changes there. And I just wanted somebody to talk to the changes to make sure people are aware of them before we approve it. Okay. John, do that. Yeah. I'd rather have John do it too. All right. So let's move on to Jim's issue since Jim, I just noticed you're on the call. Cool. This will be a very quick section though, because I haven't really had a lot of time to look at this on the free. Okay. Well, that's fine. We can say nothing, move on if you want, but go ahead. I think that's simpler. Yeah. I had a go at this on Friday, and I think when I stopped thinking about it actively, I think I had some ideas. So I will try and get those in for next week, or at least get a PR updated. Yeah. Okay. Cool. I did have one question for the group. Obviously, I've been trying to do an XML schema for this, because a lot of tooling would understand that. But I think what we're, or from the guidance from the group last week, what I'm trying to do is not really very schema friendly. Yeah. So I'm wondering if there's an opinion about, you know, ditching a schema and just making it just a convention. Yeah. So almost like a old school XML document where there's really no, it's just a document with an expected shape, but no specific schema that you could use to validate it. So I'll toss that one out there. Or does anybody care given its example? Anybody have an opinion on that? So Jesse says schema would be good in the chat? Yeah. Yeah. I personally would never use it, but I do think in general, a schema is a nice idea to have. Yeah. I mean, it has advances, obviously, because you can just, Jack's be it. And, you know, you've got a lot of code gen tools available. It's, when you get into using n is, I think the value of a schema sort of degrades a little bit. But I say part of this maybe it's so long since I've done schema design that some of the constructs I'm trying to use either don't exist, or I've forgotten how to do it. So Okay. Clemens, did you want to say something? You came up mute. If we're breaking into jail and we're doing the XML thing and we need to do it right. Okay. So I'm not here. Mostly we'll say go for it. Okay. Yes. All right. Thanks, team. Okay. Thank you. Slinky, you are up. Let's see what this one's about. There you go. It looks short. Yeah, nothing to say here. Anyone questions, comments on this one? Looks straightforward. I got a strong you had this one already. Or is this maybe I'm just never mind. No, well, to be honest, the most of the built in functions in the first draft were so okay. Yeah, I'm slowly chasing up and figuring out what we need what we don't need. So expect other peers like that. Okay. All right. Any questions, comments, concerns? Any objection to approval? Cool. Easy. I love easy ones. All right. Next one. Yeah, I moved this one up because I think it's trivial. So this is a, let's say, the bootstrap of the TCK. It includes a readme which explains how to use each file. And then I've extracted the files, the test cases that I've created in the reference to limitation. And I posted it there. So that's it. They should be all correct if they are not well yet pointed out. Okay. I believe this has been out there for a little while anyway. So any questions on this? Okay. Any objection to approving? All right. Wow. 18 file change approved. Easy. All right. Moving forward. This is so slicky. This is yours too. Yeah. So yeah, I'm sorry to capitalize this. No, no, it's all good. So I started looking a bit in the subscriptions API towards to see how we can shape the expression language in the subscription API. And there are some audits that are found in the filtering. This is one of the first ones. So what we are doing here is that we are basically claiming that we are basically imposing an implementation restriction when you're implementing the filtering logic. And I think this is too restrictive and logically not correct. So I propose to remove this restriction and just keep it simple without defining and without putting a strong constraint on the order of the evaluation. So I remember correctly, this included, yeah, so I had a comment in here. I was worried about the and case, right? I thought if you do some really weird stuff like this, yes, you'd get you'd get you'd get incorrect results. Yeah, that was the short circuiting is the motivation was the motivation for this. So in most programming languages, as soon as you are reaching the point where you can no longer can reach the desired result, which is that the outcome can no longer be true, you abort, which means you use short circuit. But for short circuiting, you need to have the order. So just as in C, C sharp, JavaScript, et cetera, the order of conditions in the conditional statement matters. This is the same thing. Yeah, yeah, yeah, now I recall, yeah. And the answer is that this in my opinion is incorrect for this kind of language because this language is more like a json schema. So in json schema, it doesn't matter the ordering of the evaluation of the keywords. And in my opinion, this is the very same because you first of all, looking at our filter dialects that we have today, there is never such condition like the one that you did you explain here. And second, it's because you don't have you can never have failures in a filter or at least in the ones that we have defined today. I can have I can have I can have 10 filter 10 conditions that are within all cause. And I put the I put the cheapest one on top. Well, yeah, that's that's exactly where I wanted to go. I want the I want my filter implementation to be able to put the cheapest one on top. That's exactly my point with this constraint. You are limiting the optimizations in the filter implementation. I may not have written this correctly, but it seems to me you could write something like this where something's going to value something's going to evaluate to an error, which implies, I believe, false. But something upfront may have blocked you from even evaluating that error that would have caused the whole thing to end up being true. But you can you can't express that in this language. In in in our filtering dialects in our filtering, let's let's name it filtering language. Okay, in our filtering language, you can't have such conditions and you don't have the concept of errors. So this this can never happen. We may not have the concept of errors, but that isn't that because all errors map to false? No, no, here we're not talking about the the expression language here. Here we're talking about the subscription filters, and the subscription filters. We don't we don't even have the concept of substring or we don't or in general, we don't have any concept of some filter that can fail. Okay, all all our filter dialects are defined to succeed and give you a value which is either true or false. Right, so but I guess I'm okay. So I wrote this as a single filter expression, but couldn't you have split these across two different filters and then join them together with the concept of an and filter and then run into the exact same problem? Well, then you need to define the concept of error because you have substring. Substring is an operation that can fail. So you first need to go through defining the concept of error, or at least specifying that errors equals to false and the filter can fail. So a filter can generate a side effect that that means an error. But we don't have such concept because I and there are guests. The reason is that we don't need that. I mean, what we need in the subscriptions filters is something very easy. Like, I mean, we just need there, we just need dialects that returns either to all fours. And then inside the dialect, like for example, the expression language, we can have more complex constructs like arrows and stuff like that. I personally would like more time to think about this because it hurts my head to think that we're going to toss out all programming language, all programming languages that have this notion of order, a precedent's order, and we're tossing that out and saying, yeah, it doesn't matter. That just feels so wrong to me. Schema languages doesn't have this concept. Yeah, but this is not a schema language. This is this is a logical expression. So it's very different. That's a schema language and that's true for both XSL as well as it's true for for Jason schema is more akin to a functional language. When you're doing effectively and Jason schema most pronounced when you're doing effectively power matching against of a schema object against candidates, and then you potentially end up with a match. But that's very different here we have a here we are literally have a programming construct, which is a DS, DSL here. That's not that's not that's not the same as schema. Well, I think I have to be honest, I think it's more like a schema than a programming construct, because then the programming construct is something that you can have inside the dialect, which gives you all the power you want to express complex expressions. But it's it's it's it's a special filter has to be simple. Yeah, but it's it called it causes it causes a logic graph, just like a like a like any any expression that you can formulate in in in JavaScript or in Java or in SQL or wherever else. I mean, you get you get a tree of logical expressions. And I would say that and I think that tree needs to be predictable anywhere and everywhere where it runs and it has needs to have the same order. So Linus, you can ask me for a second there, did you want to join in? So with the program land, which is like the order matters, because like what you put in the in the if state or whatever can have side effects. So you have this order and then it stops at some point if like the first thing evaluates into files. But I think in this case, you're just interested in the end result and we can't can't have side effects. So the order doesn't really matter. You could even like evaluate these different statements in parallel and then like merge them together later. And yeah, I agree that you shouldn't constrain the evaluation engine to to evaluate them in order, but makes sense to evaluate like the cheap cheap statements first and then there is like a reg X or something which is more expensive, like we can postpone it to be sure that all the cheap comparisons are are positive or true. Yeah, the way of these composites work, right, so there's all the money, they can they can take all filters. Right. So the filters that we have so far are simple, but they might quite well we might quite well have filters in the future or someone else might have a filter extension that has side effects that does, for instance, a look up to a reference database and and then I wouldn't be in control whether the look up to the reference database happens after I have checked the precondition. So I think the same is true as for any other language. It's a logic tree to get your hands up. I think the kind of use case that you have to describe it Clemens fits far better the special language itself. So when you use the dialect of the special language, you can extend the built in functions of the special language and you just have to use or use the special language and so you have more expression power, yeah, more, yeah, more expressivity and and I think just needs to a better result. And I'm going to give you an example of let's say an optimization that I can do to one subscription API. So assume that, for example, my messaging system indexes by, I don't know, by the code events type. And I'm able to, and when I read messages, I can just get the message. I define the filter having, I don't know, some, some dialect before some dialect after and then in the middle I have type equals to something. What's the point of doing the evaluation in order in that case, because I have already indexed and I already get the messages by type. So that's an example of how I've implemented filtering just without following the ordering. So I'm wondering whether it'd be more useful to have people write concrete examples into this PR that would break if we remove this requirement. And that way we're not talking in the abstract. Okay. Would that be okay with you, Slinky? Yeah, sure. Because because I the way you guys have described this is interesting to me and it's not a way that I personally have thought about before I my mind was definitely stuck in programming language constructs. And the things you guys have said it maybe rethink this and I'd love to work through the process with concrete examples to see because if I can't come up with one that actually fails and that order actually matters then yeah, then maybe it's not that big a deal. I just need to walk through it a little more based upon what you guys said today. So let's get some concrete examples in here that would fall apart if we adopted this PR and that will help us to make it a decision, I think. Okay. So let me make a comment here. I need to clear it for everybody. That's Slinky since he likes it already. All right. Anything else on this one people want to bring up? All right, cool. All right. Well, I don't opened up this one last week and I believe it's just typos, let me say. Yeah. So just missing an O, the description is misspelled. Yeah, I'm missing an S or the Sb evaluates. Yeah, these are just simple little typos and get rid of trailing spaces. Anybody seen anything weird in here that I don't see that is a mistake for his mistakes? Nope. Okay. Any objections to approving? Yes, of course. I have like easy ones. All right. Another Slinky one. Cool. What brings up exciting ones? All right. Slinky, you want to introduce this one? Yeah. So I think there were some misunderstandings of the error handling. So I just, so I rewrote a bit that part of the spec and I also added that to reference implementation just to show what's my idea around this. So my thinking is that the expression language can be evaluated into, an expression can be evaluated into modes. The first one is the fail-fest mode. So where an error is triggered, it just interrupts and records the error. And that's it. And the second evaluation mode is the evaluation mode where you continue the evaluation. And at the end, you have a list of eventual results. And you have the result. Sorry, you have the result and you have a list of eventual errors that happened while executing the expression. And I make very clear that the mode that must be supported is the fail-fest mode, so which is how most systems works. And that's it. So I did this PR because last time we talked about that, I felt like there were some misunderstandings about that. Okay. Anybody have any questions on this one? Well, do we have a definition for what is the result of a failed partial expression? Yes, we always have. In every single bit of the spec, I was very careful to add that. Okay. And the short answer to that question is the answer is false, right? Sorry? The short answer to Clement's question is yes, and the answer is that when it's used as a filter expression, the error implies false, correct? Yes, yes, exactly. Okay. Yeah, always. So it can happen that you have an error but still come out with true because it's just a branch that has a false, that has an error. Yes, yes. So every time you see in the spec that there is an operation that can fail, a built-in or a casting or whatever, it's defined what's the result of the expression. Okay. So you can, and the complete evolution mode, it's something that can be useful for doing complex error handling and stuff. In the TCK, if you go back to the PR of the TCK one moment, so because it also explains one of these concepts. Yeah, exactly. Okay. You see that there is a list of types of errors that can happen while you are evaluating the expression. And depending on the implementation, you can be specific about the errors or not. So that doesn't matter very much. And go below. Go, for example, below, below, below. Stop, stop. No, go below. Sorry. Below, below, below. Matt operators should, yeah, Matt operators. Okay. The last one, line 57. So line 57, that's you implicit casting within body stroke value. When you do an implicit casting and you're casting from an integer, so from a string to an integer, if it fails, it returns zero. So this expression evaluates to 10 because it's zero. But it needs to raise an error, telling A, there was a cast error, so that's it. And then again, depending on the kind of engine you are going to, you are implementing, you can either always return the result or you don't return the result and you just throw the exception. And yeah, if you want, you can also show the Java, the Java interface. I posted in the PR, that clarifier rendering, description of clarifier rendering. Yeah, this one. That link. Okay. Yeah. Yeah. Expression. Below, below. Yes. Expression. Expression has two methods. One always returns the result. And result is a type that contains the actual result and an eventual list of errors. And then there is the tri-evaluate, which just fails as soon as there is an error. I'm torn on this one. So I like the fact that you have very clearly well-defined semantics for where it fails and that you have a, there's always a defined result and that you return the result and an error together that I think that's, that is intellectually pleasing. So I like that. And what I'm worried about or what I'm struggling with is how do we use that? So I have a messaging engine that is still filtering. How does, how does that cope with, how does that cope with error? Now I have a filter result, I have a filter result, and the filter result is true, but there has been an error thrown, what am I going to do? Do I have to write now another rule set that says, right, so what am I going to do with that? What's the, what's my, what, how am I going to react to this? So my, the use case that I didn't mind for this in specific was when you do templating. So you want to use the expression language to, for example, write a template of an extension based on the other pieces of the, of the event. Okay. In that case, for example, returning always a result is something that may be reasonable. What do you mean with template? Sorry. What do you mean with templates? I'm not talking about the filtering use case. As I said, as I said many times, for the filtering use case, fail fast mode, if an error happens, then it's equal to false, and that's fine. But because I want to keep the language not tied too much to filtering. Because I don't want, I don't want to have this language strongly tied to the filtering, I believe this kind of evaluation mode may be useful for templates, for templating. So again, when you want to write a template for an extension. What does that template do? I'm just, I'm maybe confused about the, where do we have templates? I mean, you write an expression to define a value of an extension. That is totally reasonable. Because the language can return to, can return false, can return a string, or carry it on an end. Yeah, I don't know what you're referring to. Like, we have expressions for filters, but I don't know what a template is in your head. So what I mean with template is, yeah, template maybe it's the wrong word for that. What I mean is that, for example, an event processor that is able to modify the event based on an expression. Okay. Does that make more sense for you? There's able to modify it. Well, we, we can have to, wouldn't that have to yield? So that doesn't yield true or false, that use any number of, that use any value. Yes. The language already returns any value inside its type system. So either a Boolean, an integer, or a string. Okay. We don't have a use case for that though. Like in cloud events right now, we don't have a use case for, we don't have a use case for, for that load. So just to explain on this, I don't think this is outlandish because we have in our product, in service bus, we have actually the notion of filters paired with actions where if a filter condition matches, then you can run an expression, then you can run a statement that might then go and modify individual properties on the message with an expression. But that is bigger than that. There's actually more to this than, than the expressions here because we then, you then have to have some extra syntax, which allows you to go and, and actually modify, modify properties and select them, etc. So I think, I think, I think that mode here, that extra mode here is, is not sufficient. But we, so, so that's the, the, so I understand where we're going. I'm just struggling with the use case, because we don't have a mechanism where we can go and plug that into it. It's, it's, it's filling a requirement that we as a project don't have. I have a different question, but I'm not sure if you guys are done with your thread or not. I'm, I'm, I'm, I'm, I have, so let me, let me quit. I have, I, I think this is elegant. I think this is interesting. I just don't see what that, what that hooks up to. Well, let me ask my question because I'm not, this, this may sidetrack your, your concern. I have two, I have two questions. One is this, this right here. In fact, it says fail fast mode must be supported. It seems to me that's an implementation choice, isn't it? Sorry. You see right here that the fail fast mode must be supported by the evaluator. Yes. Isn't that an implementation choice? Because if I, if I choose to code up an evaluation implementation, whether I do a full evaluation or a fail fast evaluation, the user of my code should not know the difference as long as they get the right results. Right. So it seems odd to me that a spec would mandate that I have to do fail fast mode. Well, the user knows about that from the interface in the programming language where it's using the evaluator. Okay. Oh, we're talking about this kind of, we are talking about this kind of user. We are not talking about the filter user. Okay. So you're saying that in your, in your spec here someplace, you say there's a flag or something that says use fail fast versus complete? No, no, I'm saying, I'm saying that my programming language interface tells me which is the mode. I really think it should be the implementation choice. Like, I don't understand why we try to enforce the, what it results, apart from what you define that if there is an exception, it should be considered as false. So from the higher level. But in my opinion, that part of the spec is too deep into the technical part. And I don't think you should mandate that because depending on the language, there is stuff that will be done more easily. Like in Go, it's more traditional to give back the error. In TypeScript, you erase like, and I don't think you should mandate that because depending on the language, it's more natural to certain language or others like the way they manage exceptions and error. So if I were you, I will not put that. I like the, like the previous PR of this one, I think is a bit too, too deep into the implementation compared to what we're trying to achieve in my opinion. Of course, just minus your hands up. Yeah. So for me, it was down to the question if we specify the CSQL language, or if we specify like the implementations, like with the SDK, so if we want to specify how, how people should implement it, or if it's just want to specify what the language should do, because if you just specify what the language or how the language should behave, it doesn't really matter like if it fails fast or not. It's like in the end, it should produce the same result. And then, yeah, I agree that this is an implementation detail. And I'm not sure if you want to specify this on the, on this level. Okay. Slinky, your hands up. Slinky, you're still there? Oh, can you hear me? Yeah, now we can. Yeah, sorry. Let me ask something to you two then. Without line 358, wouldn't be better? So I just, so just take it as a recommendation more than as you must do that. Does that make sense? Would you recommend for me if you change it to like a non-normative statement that says, hey, it's a good idea for you to support both modes? I'm okay with that. I don't think the spec should try to mandate a particular implementation choice, though. Okay. And but the other question I had was up here you say they must always return a value and then down here you say without any result. So I guess my question for you is when you say return a value, is the word value here the same as result or a value here mean it could be an error? The previous sentence, the previous sentence was wrong in my opinion. So it was just plain wrong because it was mandated. It was basically mandating the complete evolution mode, which in my opinion is wrong. So this one is a bit more relaxed. But in general, yeah, I think that if we remove line 358, it becomes just more suggestive. No, no, no, no. Maybe it wasn't clear. I think you have an inconsistency. You say they must always return a value, but then down here you give an example where it doesn't return a result. And in my mind, I equated the word result and value to be the same thing. So here you're saying always have one and here you say you may not have one. So it seems inconsistent. Yeah, I'm using them interchangeably. Maybe I should stick with just one term. Well, even if you change, if you use one term that that'd be good, I agree. But then you're inconsistent because here you say always and then you say bit down here without definition doesn't mean the definition doesn't mean evaluator needs to work on that. That is the difference here. I'm saying a line 352. I'm saying a the language is expressed is defined like that. Okay. So there is a there is such definition. But then you don't need to to to actually evaluate and return. Oh, I'm sorry. I was reading wrong. They define a value. Okay. It's the word define as opposed to return. Got it. I'm sorry. Yeah, which was exactly my point. I apologize. I just wasn't reading it properly. Okay. Ignore me. All right. Remind me your hands up. Yeah, I remember we could use them. Sorry for before. Yeah, it's just like I read again, like for me, the whole PR is kind of trying to enforce some stuff on implementation more than what the language should be. Because my understanding was, if there is an exception, basically, it's false on your expression. If I simplify like oversimplify maybe. So whatever happens behind the scene should be the implementation choice. Like if you want to have a try catch that's written false in your catch. And so you use all the like normal try and catch like padding of your language or if like in go you return an error and that means that you throw away the result and it should be your implementation. But what you are really trying to define in my opinion was when I subscribe, what can I input? What can I expect from the language on the behavior standpoint? But really the what the API returns like how it's implemented at that point, like I don't care on my side. So I don't think we should be that specific. But yeah, that's my go ahead. I think you raise your hand. Yeah, then I'm going to ask another question. Are we okay with removing the pre I mean, if we don't want to upset this one, even without removing even with removing the normative sentence. The alternative is that we need to remove the previous sentence because the previous sentence as I said is plain wrong. If it was me, I would not even merge the PR to be honest, because I understand what you're trying. Like it's a good, it's a funny implementation. Like it might be a good idea. But like if I was coding it in TypeScript, I would probably tell you like when there is an exception, it's going to be logged. And in a way, or I'm going to raise the exception, but I'm not going to do any of that things. No, no, sorry, we misunderstood. So if we don't want to accept this PR, even even removing the normative sentence, I think that we should remove the sentence that I'm changing here completely. So the lines in red, because for me, these are plain wrong. Yeah, then I do agree with you. So either we accept this one removing the normative sentence, or we just remove the old sentences. I would have just removed the sentence. And you can probably keep it in your own implementation as explaining how you did it. Because like when I read your code, it was clear to me like what you were trying to achieve on your side. Because the thing is, I'm not saying that what you did is wrong. I'm just saying that I don't think it belongs inside a specification. Okay, so I'll leave it up to you. Eric, your hands up. Good. Yeah, I've been kind of head scratching around this language. Because it's anyway, and I wanted to share some thoughts. One of the things that seems to me potentially causing some confusion that a lot of us work in kind of cloud and user facing or some kind of software like that. And a lot of the ideas that are being brought up in this context seem to come from what I've observed in system programming or real time operating systems where part of the specification is that this method must return within some a period of time in milliseconds or whatever it is. And there's a really big problem in that if those are parts of your requirements, you really need the code to be formulated in a way that doesn't trigger exceptions or do anything like that. And this is just me trying to make sense of why this thing has got some of the constraints on it that it does. You can go one way. You can go from code that satisfies this kind of style of API and doesn't raise exceptions, always return something to a code kind of another layer and SDK or something that turns those errors into exceptions or something like that. So it's easy to go that way. It's really much harder to go the other direction. And so the utility of specifying, I'm trying to steal a man a little here, the utility of specifying all these constraints and strange requirements is it means that these SDKs then can be used in a larger set of contexts. I don't know, maybe that's just glathering and not very useful, but I thought I had to help me make sense of the whole conversation. Okay. Thank you. How do you want to proceed here? Because I think if nothing else, I think there's general agreement to remove this. Do you want to think about whether you want to replace the text versus just remove the text and then come back next week? Or do you want to vote on, right? Do you want to vote right now on at least keeping this and just dropping this text right here? I don't know. What do you suggest? I'm fine with whatever people want. Do you see value in this text or is it more important to you that you just want to get rid of these lines in red? So, for sure, we need to get rid of these lines in red. That's for sure. I think this one is, again, is a suggestion, but if, as Remy said, we don't want to give this kind of suggestions, then that's fine for me. Okay. So, let me pick on some people who spoke of that. I'll pick on Clemens for a sample. Clemens, you had some concerns about this. If we got rid of the lines in red, and that's the only thing we did. We just completely ignored the stuff in green. Would that address any of your concerns? Would you be okay with this? Yeah, I would, because I think how do you evaluate the language and whether you are okay or not with partial completion is something that is application-specific. So, let me ask that question then. Is there anybody in the call who would object to approving the PR if the PR was just removed the stuff in red? And that's none of the green text. Line us your hands up. Yeah. So, just have an additional suggestion. So, maybe we could just start the section with implementations suggestions or something and add this to there, this to like fast mode and complete evaluation mode. What do you think about that, Slinky? That's fine. Well, yeah, this particular section, I wanted it to be something like a suggestion section, but yeah, I can do that in another PR and then we'll discuss about that. So, you'd rather get this PR in with just the stuff removed and then do another PR with the suggestion section? Is that what I'm hearing? Yes. Okay. So, that's the... I think the suggestion section is kind of useful, maybe. Yeah, it's like a mini primer. Yeah. Okay, so I think the suggestion in front of us is for this PR, just adopt the removing the red text and then Slinky will think about creating a separate PR with the suggestion section where this new text may appear. That's the proposal in front of us. Any question? Go ahead. No, okay, okay. I said okay. Okay. Any questions about the proposal? Any objection to doing that? Okay. So, I'll write up in the minutes that we're accepting the deletion of the red stuff and the green stuff will not be part of the PR. Okay. Now, since we're almost out of time, I want to go back to John's issue. Since John, you said you can talk now. Hello. Can you get it done in three minutes is the question? Well, potentially it sort of depends on the comments, really. So, there have been some changes to the PR. They're probably smaller than they look because text wrapping. I apologize. In future, I will try to not bother rewrapping text to minimize changes as we go and then maybe we wrap at the very end. The changes in the PR do not affect the semantics at all. They are merely hopefully making things clearer. If anyone wishes to say they make things less clear, then I'm completely happy to go back to things. Doug, you had a comment about the paragraph just in the middle there, which is now when decoding an HTTP message into a cloud event, any HTTP header value must first be unescaped with respect to double-coded strings as described in, et cetera. Does that seem clearer to you than it was before? Yes, it does. Thank you. Excellent. Devons, I'm now slightly lost track of all the comments that you had, but I think in the paragraph just above, that was one of your unresolved concerns where I've now put the resulting string should not be further encoded and then a rationale that sort of was effectively what was there before. So, I did want to explain why we're not double-coding escaping because it's not necessary when you've done the percent encoding. Yeah. Okay. The comment stuff, Land. Sorry, the which stuff? The prioritized comments were somewhere. Yes, I've still got HTTP headers for cloud events, cloud event attribute values do not support parenthetical comments, so the initial unescaping only needs to handle double-coded values. I think anyone following the link to RFC 2730 will understand why that's mentioned. I sort of don't want to make too much of something that we're saying, don't worry about X. If it takes a whole paragraph to explain what X is, then it's slightly... Yeah, it's just a parenthetical comment that I think my reaction to that was simply that I wasn't... That didn't mean anything to me until I went back to the RFC to look at it. Yeah. Understood. It's just if we take a while to explain what parenthetical comments are, only to say, by the way, we don't care about them. If you have any suggestion for a better way of expressing it concisely, that would be great. No, I don't. So, I think you've done a good job there. And of course, if we're happy with the semantics, we can perform any clarifications later on. No, it's all good. Yeah, so my gut reaction is, I agree with you. Do you want to change the semantics? It was more word-smithing than anything else. While we could technically wait a whole another week, I suspect nothing will change between now and then. However, what I'd like to do is to get... See if the group is okay with approving this today conditionally, but wait until end of tomorrow so that people can do another round of checks. And if they have raised any concerns at all in the PR, then we'll hold off to merging until next week. So basically a conditional approval with one more day of review, if that's okay. That'd be fine by me. Okay. Does anybody on the call object to that? And please speak up if you want more time. I don't think there's any real rush to get this in. It has to be, you know, this week kind of thing, but it has been out there for a little bit of time. I don't want John to have to hold on to it long because I know you're anxious to get this in for other reasons. I've actually merged the C-sharp code, given that people seem to be happy with semantics. I've merged the C-sharp code anyway. Okay, good. Okay. Any objection then to conditionally approving with one more day of review possible for people? So end of day tomorrow. Last chance. Otherwise we're going to be approved. All right. Cool. Thank you all. Hold on. Approved again. Okay. Cool. All right. In that case, whoa, that was not what I'm going to do. Okay. In that case, did I miss anybody for the attendee list? Make sure your name's there. Scott, that link you just paste in the chat. Is that something we need to think about? Or is that? No, it's just me adding headers. That's all. Oh, okay. Okay. Did I miss anybody for attendee? All right. In that case, anybody not interested in SDKs free to go, but if you are interested in SDK, hold on a sec. Let's see if there's any issues or topics. I don't see any. Okay. Anybody have any topics for the SDK call? Otherwise we will cancel the call. All right. We are done then, both calls. Excellent. Thank you all very much. Very productive phone call and we'll talk again next week. Bye. Thanks for a minute. Bye. Bye-bye.