 All right, it's three after the hour. I'll catch up with Tim when he gets a microphone. Let's go ahead and get started. Let's see if we're up to 18 people. All right, anything from the community that people would like to bring up? All right, moving forward. Nothing, no updates from the SDK call. We did not have one last week. We don't have one this week, but we do, we are, I'm sorry, we did have one last week. What did we talk about last week? Scott or Mark, do you guys remember? Were you to talk about something, anything worth mentioning? I can't remember what we talked about. Yes, we did have one last week and we talked a little bit about being able to get additional contributors onto the SDKs and perhaps look at having more commonality between the SDKs and looking at the go SDK as kind of the current gold standard for how to do transcoding between versions, et cetera. Yes, thank you. Any questions or comments from anybody? Okay, we will have a call next week as usual. I think it's every two weeks now with the current plan of going through Clemens PR around that SDK sort of primer doc that we have or SDK guidance doc that we have. And hopefully by then Scott will have his AI because he's gonna make a whole bunch of suggested edits there. So keep an eye out for that if you're interested in that piece of work. So regarding that Doug, so I did do a rewrite and the advice that I got was that I should start collecting users of SDKs so that we can figure out what people actually want. So we could pull people that are implementing, people that are integrating with SDKs and then people that are choosing to not integrate with the current SDKs and find the reasons why they are and are not using them. And then we can use that polling result to figure out what the SDKs should do. Makes a lot of sense. How are you planning on doing that polling just an email to the list or something different? Yeah, let me send an email out to the list to see. Unfortunately, you can't really collect all the people that don't use it, but go and find potential people that are using the SDKs and see what exactly they're looking for and what they're not looking for. Yep, okay. Tim, to your question in the chat, the SDK guidance doc, if it's not in the main repo, then it's probably still a part of Clemens PR. So you have to look at the PR. It's just part of the main repo. Oh, it's part of the main repo, okay. In that case, take a look at Clemens PR as well, down here in the bottom of the agenda, because it makes a whole bunch of modifications to it. I think between those two, you should have it. Yeah, it's certainly not posted anywhere obvious if you go looking for Cloud Events SDK. Really? So hold on just one quick thing, since you peeked my- Maybe I was just having a stupid phase, but I couldn't find it. Yeah, so hold on. I don't think it has a link. It's just a protocol SDK. You're right. Okay, I will fix that. I will modify this table here to include the SDK doc. Wait, I thought there was an SDK link. Scroll down. There's SDK. A proposal? Well, I guess that does kind of point to it. Yeah, okay. Okay. So there you go. But so my question for you guys is, would it be useful to include it in here in our list of documents as well? I don't mind doing a PR for that if you guys think it's worthwhile. Might as well. Yeah, I don't see any harm under additional documentation. I'll take the AI to do that. If nothing else, it makes us stand out a little more. Links are cheap, right? Sometimes, yeah. Add SDK doc to table and read me. Cool. All right. Thank you, Scott. Any other comments or questions about SDK stuff? Okay, cool. Moving forward then, in terms of going forward with incubator status, I believe we have two end users listed right now, so we need at least one more before we can consider going forward. So please get me your information. Clement, since you're on the call right now, you don't necessarily have the answer right now, but if you can think about any possible customers using your implementation of SDK as part of your gateway product, that one I think would qualify as well, I think. Yeah, I'll hand that to Bahram. Okay, cool. Thank you. All right. KubeCon San Diego, new updates there. I am planning on putting together a proposal. My current thought process is to have an intro and deep dive for Cod events, but then a single serverless working group session, since I don't think there's a lot to talk about for serverless and maybe turn that into another birds of a feather kind of session, because I found that in Barcelona, to be actually really interesting to get feedback from the community about why they're not using serverless and stuff like that. But anyway, like I said, I'll write up my proposal for you guys to consider, hopefully for next call. All right, so with that, any other topics before we jump to the PR review? All right, in that case, first up, remove map. Just double check, see if anybody's added here, anything recently? No, okay, so we only had a handful of people vote. So let me just quickly go through the list of eligible voters to see if they would like to either modify or add a vote. Roberto, did you want to change yours? Oh, I do not. Okay, Tim, for Amazon, do you want to vote on the removing map proposal? Oh, I didn't, I didn't think we had a vote. Actually, you do. I believe, unless I, hold on, now you got me all worried. I thought I understand the process. So if we disagree, you're probably right. Well, I'll double check later, but if you do a vote, would you like to vote? I would vote against if I were going, sorry, I would vote against map, whichever way that is. Okay, that means vote yes to remove map, okay. All right, Doug, do you want to vote? Yes, yes, yes, okay. Google voter on the phone call, IBM will vote yes. Vladimir, would you like to vote? Yes, I would vote to keep the one level of a map. Okay, that's what I figured, thank you. Yep, William, for Red Hat would you like to vote? Yep. And, is that a guess for voting or a yes for the vote? Oh, yes for voting, that's the vote. Okay, Christian, would you like to vote? I have to abstain on this one. Okay, that's fine. SAP, Klaus, are you on the call? Would you like to change your vote? I'm going to assume no unless it comes off mute. Mark, do you want to change your vote? Nope, I want to keep a yes. Okay, that's what I figured. Vlad, I don't see him on the call. No, he's not on the call. And Eric, I don't see him on the call. Okay, so we have 10 to one. Anybody see any way I messed up there before I even moved forward? Okay, just to clarify then, I'll get that in there. So it's 10 to one, so the PR passes. We will merge that PR. Any last minute comments or questions about the PR before we move on to the next one? All right, cool. Thank you guys for that. Let's see, next PR. This one's a relatively straightforward one from a textual perspective. All I'm proposing is to rename schema URL to be data schema URL because according to the current definition, it is just for the data attribute. So for consistency with the other attributes in particular content type and content encoding, those are prefixed with data. So we should make this one about data as well or prefixed with data to be perfectly clear that it's not about the entire cloud event itself. In fact, there was some confusion in last week's call about whether it applied to everything or just data. And we just get to the text itself to make it perfectly clear. Where is it? Did it hold on a sec? Why can't I find it? Speck Jason, speckin' it. Okay, yeah, so the textual description makes perfectly clear this is just about the data. So we're not changing the semantics, we're just changing the property name itself. Any questions or comments on this? Shorter is better. It's a toss up right between shortness versus guaranteed consistency and understanding, right? Yeah, normally I would object because I prefer to make a few changes this late in the game because it's always a pain to go back to your implementation but in this particular case, I think it's worth making this for one change. Yeah, let me ask a slightly different question. Is anybody actually using this property right now? Can you hear this? Are you, what do you do with it? We put the schema of the data. Okay. Do you actually use it? Do you actually verify it? It's for robots to consume on the other side. Okay. The intent is to be able to like auto-wire things together. For what it's worth, we at AWS do plan to use this. Okay, that's good to know. By the way, as a web architecture patent, shouldn't that be URI? Oh, you're killing me. Yes, we should be. Would we like to make that change as well at the same time? Okay, so let's take this one at a time. I know there were some comments about keeping it shorter but were those comments enough to actually object to the PR or was it just, geez, it'd be nice if it was shorter? Okay, not objecting. Thank you, Tim. What about you, Scott? How about rename it to schema? Oh, you're killing me, Scott. I like that. I do too, but the problem is you yourself, Scott, were the one who said on last week's call you thought it applied to everything. Well, I wasn't sure. It could, depending on how you use it. I mean, when I have an integer variable and a programming language, I don't put int on the name of it, right? On the end of it. I know, but then why don't we have data on the other ones, right? Because they conflict with the HTTP headers. So, okay. I'm trying to figure out whether you guys are just having fun or whether we actually want to take this series or not, because I personally am very bothered by the inconsistency, right? That's the entire reason I made it. It seemed really odd that we had the other two that start with data and then this that doesn't. So, what do you guys want to do? My vote's called schema. Anybody else want to speak up? If you call it schema that, sorry, go ahead. Oh, sorry, I just said I'm good with schema. Go ahead, Doug. If you call it schema, it's not implied in the name that it's intended to be a link to a definition. It almost assumes that you're including in that attribute the actual definition of the schema. Yeah, though, that's a good point. Yeah, that's an interesting point. I'm trying to figure out what do we, do we have any other properties that are references like that? See, it is interesting, right? Because things like source is technically relative URI or URL, one of the two, right? But we don't put URL in the name. So I'm hearing some people have a kidney for just schema. So that implies just dropping the URL part of it. Anybody else want to speak up? I think if we're going to rename it, we should add data there for consistency. And I think people got confused before because they thought it's the schema of everything, including cloud event and it's not. So that, I think your original intention of adding schema to it is still valid. But I agree on dropping the URL part. Okay, so what do people think about, I know Tim says he's okay with data schema. What other people think, Scott? Okay. But then there is the problem that was just mentioned a second ago that people will think the actual schema will be right there, as opposed to a reference to the schema. True, but we do define it as, well, yeah, I guess the string could mean the entire thing is. I mean, it's three letters, data schema URI seems fine to me. Oh my gosh, it's these silly little things that are going to torpedo us. Data URI, I'm not sure what you mean by that, Tim. You could have a data. Data is a perfectly valid URI scheme which says, you know, it's right here. You say data colon and then the schema right there. I guess. Okay, let me ask you this question. Not having the three letters URI or URL in there. How big of a concern is that for people? Let's take these one at a time. Tim says no concern. I know there's, Christophe, how big of a concern was it for you since you were just mentioning it? Because we don't have URI or any other types on any other properties. Yeah, I'm fine either way, whether we have it or not. But I think if we change it, then we should add data. That's more the side I'm falling on. But it's also not a really hard requirement. All right, okay, so thank you, Wayne. Okay, so is there anybody on the call who thinks we should add URI or URL to the end or keep it in this case, I guess? Okay. I think we should keep it, but I don't feel very strongly. Okay, so we have a lukewarm yes to keeping it. Anybody else? Okay, one lukewarm yes to keeping it. I'm gonna assume everybody else is either doesn't give a crap or wants to remove it, one of the two. Now, in terms of schema versus data schema, is there anybody like to voice an opinion when we're the other on that? I know some people already said for consistency, having data. I think it's a wash. I mean, data schema is in fact more precise, but anybody who works with these things is gonna understand pretty quickly what it means, but. Okay, Scott says plus one data schema. Anybody else want to chime in here? Okay, I'm not sure how to interpret the silence on this one. I'd like to hear some more people. Christophe, I think you said you wanted data there. Let me pick on someone else who refused to speak last time, Ginger. You can't have a high column this time. I knew that was gonna happen. I don't ever, I don't use it. So I don't feel like I have voting rights. You know that's BS. You know you have voting rights. Most people aren't using it, in my opinion. So come on. I don't have an opinion. I'm sorry. Okay, that's fine. Okay, I'm seeing more and more police people for plus one in the chat for data schema. So let me be bold here and make a proposal for me going back and modifying the PR to be data schema post-op. No three letters at the end. Any objections to that? Okay, Klaus had an interesting comment in there about whether it's a URI or a URL. I suspect it probably is a URI and I don't mind changing the text to say that. Well actually it just said a link. So I could change that to URI. Would everybody like me to make that change? Scott at least says yes. Okay. Do we have URI as a type yet? I mean, that's... Absolutely, we do have a relative URI. Do we? We have a relative URI. Do we have an absolute URI? There you go. Well we have URI reference, which is sort of... Well it is already a URI reference. It's just called URL, which is technically confusing. So it's already a URI reference. I thought we want to make it only URI without reference part. We should keep it a URI reference to not introduce a new type and you can make a URI URL with your URI reference. Exactly, but then it's no change. If I was to keep the word link in there would that upset anybody? Well that implies that it's resolvable. That's true. That is true. That is very true, Scott. So imagine why somebody would want to use a URI but they might, you know, I mean... So that's not a link. I think Microsoft uses basically a hash into the known place that stores schema and you're supposed to append this to the registry to go and pull the schema out. Is that right, Clemens? I don't know what you're referring to. Oh, okay, sorry. So, okay, I got confused earlier. Were you guys saying that this should be just URI reference? I'm a little negative on URI reference because I think using relative URI references in here would probably be a bad practice. I would agree. Yeah. Doesn't the first three characters of the link indicate what type it is so you don't have to specify it in the, or constrain it in the document? Then it would be URI. Yeah. URI reference. To URI if it's okay. URI allows things like dot slash foo and that assumes you know what the base is which in general I have a process and you don't. Well, if we change this to just URI we probably have to introduce the URI type, don't we? Yeah, but that doesn't hurt, does it? It doesn't hurt, no, but just add more text. Sure. That's the nature of adding things. Thank you. I missed that, yeah. Okay. So, okay, I think, okay, I'm not gonna push to necessarily merge this this week but it seems like the current proposal is to change this to data schema and change this to URI and add the URI type to our type mapping or type the section, whatever the hell it's called. Is that the proposal? Okay, post one for Kristoff. Anybody, everybody okay with that? Anybody object to that general direction and I'll modify the PR? Okay, let's see. So, let's do data schema, URI. And add URI to type section. All right, anything else on that one if you wanna mention? I'm sure we could rattle more if we really tried. I'm so proud that I abstained from the naming discussion. Very good. All right, moving forward. This was another one of mine. Yes, that is very true, Cohen. All right. So, this one was, let's see what I do here. So, I added some stuff to the primer to talk about string values. I don't know actually what I said here, hold on a minute. Oh, this is talking about being smart in our string values. In particular, when we start talking about serializing them and things like HTTP headers and stuff, yeah, you may be able to use some really funky characters, like new lines and stuff like that, but it's just gonna make life harder for people and that's not the point of this. The point of this is interop. So, try to be smart in your choices there. I do also talk about URI reference values in here. I talk about in particular why we allow them to be really as small as things like just home, even though we would prefer things to be more descriptive like that, but we wanted to be really, really flexible. Talk a little bit about why we don't have a base URI in there, but the other chain that's normative that I wanted to really point out was, in, let's see what property is this, in source and in schema URL. I said they basically must be not empty URI references. Basically, obviously to avoid just empty string there. My rationale for this was because an empty string to me is about as useful as the property not being there at all, but if it's a required property, it makes no sense to allow it to be empty string. It's just, it's completely useless. So, in that particular case, if we're gonna require the property, it seems like it has to be not empty to be of some value whatsoever. Likewise, if you're gonna include a schema URL at all in there, or I'm sorry, data schema at all in there, then you might as well make it a non-empty value. Otherwise, don't even bother putting the property in there. It makes no sense to have an empty string. That was my rationale behind those two things. Any comments? Any objection to the PR? If you'll want more time to review, I think it's been out there for about two weeks. I think the non-empty is good stuff. The language about which characters to use doesn't really seem useful to me. I mean, if what you're really saying is, stay on ASCII, then say, stay on ASCII. But once you've gone past a seven-bit representation, you're a little bit pregnant, you might as well go off into the wilder rounds of the Unicode Astroplanes. So I'm just not sure if that's useful. Yeah, this is, so we have a few problems in terms of, so character encodings can be very tricky. And there seems to be a silent agreement amongst people everywhere that UTF-8 is kind of cool, even in places where it's not allowed. So you see UTF-8 floating around in HTTP header values, which are strictly ASCII seven-bit. And I've tried to stay away from policing that here as well because being lenient is not all that terrible. But if we want to make a statement about this, then this is why I'm a little nervous about this one. If you want to make a statement about this, then the only way to make this line up with the existing standards that we are mapping to is that we have to restrict this to seven-bit ASCII because that's the only character set that HTTP allows for headers. And so therefore we then are effectively for HTTP binary mode, that's what we would be constrained by. So keep in mind a couple of things. This is just in the primer, this is not normative. And my intention was not to necessarily restrict things any further because I didn't want to preclude someone from using things like Unicode and stuff like that if they really wanted to. And it made sense in their environment. But what are you saying here? What I was basically trying to say, whether it's set it properly or not, was basically choose appropriate strings, right? Don't choose strings just to try to screw other people over. This isn't about edge case testing, this is about interop. So yes, you can use- Is it umlaut okay? What? Is it umlaut okay? I don't know. It depends on your use case, right? But for example, Evan has a PR where the whole bunch of really interesting strings. And they're all technically valid, I believe. Oh. But, no? No, no, that's okay, go ahead. Yeah, and they're all technically valid, but it seems kind of silly to go out of your way to use strings like that if people may not be able to process them correctly. And I was just trying to give some guidance that says, yes, you can do a whole bunch of weird stuff, but this is about interop. So be smart in what you do. That's all I was trying to say. If you think it's useless, I don't mind removing it. But if you're Korean, then none of the Korean characters look weird. Right, exactly. Yeah, I think it's binary. You either are all ASCII or you're all Unicode. I don't know of any interim conditions. Yeah, that's, I agree. And so UTF-8 has become the way how you do these things and since if nobody treats things in a special way, if you stick UTF-8, it's an HTTP header and then you also read it out of the HTTP stack and nobody looks at it as ASCII, then it kind of works. Okay, so let me ask this question. Would you prefer if I just dropped that entire section on string values? Would be better for me, I think. I don't have any objection. Because it's like you're appropriate and you say certain characters could be problematic. Well, there's a whole class of characters that people use regularly because that's their language that could be problematic for others because they're outside of 7Badaski. I guess that I have no objection. I was just trying to provide some guidance if it was useful, if it's not useful, I have no problem with removing it. I feel like UTF-8 has to be the standard. That's what people use now. And we have to guide people on how to encode stuff into HTTP headers that don't support UTF-8. Yeah, but the HTTP team has already given, like HTTP, two, three, they haven't given up on that fight. And they said the only way to go is 7Badaski. So it's hard to go and override them. That spells time. I mean, we might decide as a consequence of this to say that extensions have to be 7Badaski since there seems to be a strong feeling that they should be encodable in HTTP headers. It would make me grumpy, but it would be the same thing to do, I guess. Well, it seems like if we wanted to head down that path, we're talking about a normative change here as opposed to just something in the primer, right? But obviously, once you get into the data payload, you can't have anything by UTF-8 there, seriously. So is someone, does someone feel strongly enough about this to actually make a PR to update the spec to require UTF-8? In the... I'll volunteer to do a quick PR on this one. Okay, if you guys want to, that's fine. Okay, so let me, I'm not hearing any objection to dropping that string value section. Is there value in the URI reference section? Technically, home is a valid URI reference according to the spec, right? Oh yeah, you can use it. And it made me perfect sense of some environments, but there's lots of questions in terms of, you know, whether people should or not. And I was just trying to find some guidance here. It says, you know, if you're in a closed environment, you know, on-prem, public, private network kind of stuff, then home may make perfect sense. And I kind of force you to do an entire long URL just because we think it's best practice. But if you're going to the internet, then yeah, full URL makes more sense. So do we have references to source field or are there others? I have to go back and double check whether there's another one. I know that source. Let's figure out the one. I think type is a reverse DNS. I think source might be the only URL I have to double check. We have source and the schema URI, which now changes. Yeah, so I think it might just be source. I don't know, is this worthy of keeping or dumping? I'm not sure how to interpret the silence. We sometimes risk primer fatigue from new users. Like if this document gets too long, people aren't going to look at it. Well, to be honest, I would think most people aren't going to look at it at all. They're going to look at the spec. And the only reason they would ever look at the primer is if they actually cared enough to understand the background, which is the whole purpose of the primer. That's the way I tend to look at it. Oh, the primer is to prime you for the spec. Yeah, if you want to know the history. I don't know. What do you guys think? I was just trying to be helpful, but if it's not helpful, then I don't mind removing it. My counter proposal will maybe be to use in the regular spec on the source attribute, say, if you intend or if you expect that your event is being used publicly to make sure it's not a relative URI one sentence. And that's a clear, clear guidance. I kind of like that better. Any comments on that? Okay, since it's my PR, I'll take that suggestion so that I think what I'm hearing is kill the string section, kill the URL reference section, add a sentence to the spec per Kristoff's comment. And I'm assuming you guys are okay with this non-empty stuff down here? Yeah. Yeah. Okay, a quick question for you. On Kristoff's suggested sentence, would you guys expect that to be a normative sentence like with a should or just non-normative guidance? In other words, do you want a should in there or not, a capital should? I'm gonna pick on you Kristoff, since it was your idea. Well, I don't know. No one's going to really enforce it. Well, yeah, maybe a should is good, yeah. Okay. Okay, I'll make those changes, internet. Okay, cool. Anything else on that one, can we move on? All right, now to the main show. Data PR. Unfortunately, I don't see James on the internet. I'll fix it. Okay, Clemens, would you like to emphasize the word briefly, talk to this one in terms of why you think this PR should be adopted instead of James's PR? And if possible, try to be as unbiased as possible in talking about his PR. I know it's hard everybody's biased about their own babies, but try. So these two PRs effectively capture the same rule set. They're just mostly structured differently. And there are a few things that I put in here in the, I'm talking about the normative section. So this is just the explanation. So this is the primary section of what we're looking at right now. Here's that piece that I just structured differently. In James PR, he starts out with talking about the other types, and then he puts the rules for the binary and for strings. He puts them kind of in the bullets that are at the bottom of the attribute. So basically just restructured that text. And then as I was writing that, I found a few additional little nits that I added that James didn't add. The rules that I think is the same. So what we had confusion arose, and this is a long discussion, so I'm trying to keep it brief and you guys can go and look at the discussion if you are not caught up on it. But about the rules of content type as it relates to the content of the data field. And so this is describing what data content type the rules for data content type. So it must be set for binary content and then it must have an accurate media type. Accurate media type then also means that the field, the data field must then follow that media type, which means if the media type is whatever image JPEG, then the data field must contain the binary. If there's no media type available for that, then you can also use an octet stream. If you have a string, then you should set it. And that much should describe the text format if you don't have like including application text. There, James had a rule in his PR where he says it must be text slash star, which obviously doesn't capture popular text formats as application XML, for instance. And then I make a specific rule if the character encoding is not UTF-8. So I'm already referencing UTF-8 here. So I'm already assuming, even though we don't have a rule about UTF-8 that everything is UTF-8, or one of its subsets, or if the character encoding of the overall event diverges. So if you encode your event in Epsidic, if you want to do that, then if that's divergent, then the character encoding must be declared and then the text is encoded as binary, which means if you want to carry some code page that is incompatible with the code page of the event per se, then it's a binary, it's not a string. And then the last rule is then effectively, you can set it for any of the other types, but then effectively it's encoded at the, according to the rules of the event format. And then for, so that's the rules that I basically said. Mostly it's bringing clarity for binary and for string and how the relationship is of data content type to data. All right. Now, on last week's call, we had several people, unfortunately I don't remember who their names were, promised that they would actually go off and read both PRs so they can comment on it. Anybody want to raise their hand? Anybody want to comment at all? I really want to pick on somebody but I don't know if I should pick on. Klaus, you're coming off mute. Yes, yes. Finally, unmuting worked. So I tried before and didn't work. So I asked it already, I think in the other PR where this was actually copied, I think. If the attribute is omitted, so let's say it's then transmitted via HTTP binary and then it comes over as the application JSON. You can't. There's a rule at the bottom that says for using the binary mode of any transport binding it must be declared. Oh, okay. So that's a hole we had that was pretty glaring is that because when you use the binary mode the event format actually no longer applies because there we have clear rules for how the attributes map to headers and how the body effectively maps to the entity body which means the event format no longer applies. And if the event format no longer applies well then the only way you can go declare a body is by using content type of the surrounding envelope and that's requiring you to, so you have to have that field. You have to have that data. Yeah. I think that's pretty much what I wanted to point out, yeah. But if, I mean, a producer does not always, I mean, no which modes will be used by intermediaries, so. Yeah, then the intermediary can't switch to binary. It's that's, if it has an event and the event doesn't have a declaration that it can't do that. Of course, if the event is all fully contained and self-contained in JSON, right? The intermediary can go and break those things apart and it can go and take the body, the JSON body and just then carry that in the binary mode and declare it as application JSON. That's something that it can do. So Tim had a question. He said he's not sure what quote, projecting an event onto transport frame, end quote means. Wanna collaborate on that? I guess my comment is, I think what we're really saying here is that there is a particular scenario in which you must provide the data content type. Yes. And I think there's probably a shorter way to say it. Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha. Yes, so the binary mode, the data content type must be declared. I think that is the difficulty is that we have this, so despite introducing this binary mode came with all kinds of interesting repercussions. For those of you who don't have the chat handy, Mark is afraid we'll have to ship a decoder into the translate Clemens' text. This is me securing, it's healthy knowledge. We're shortened to say the data content type attribute must be supplied in the event that X was like a couple of phrases describing what X is. I think that could satisfactorily replace. Well, that's the things that we do here, right? The attribute must be set, should be set, it may be set. And it's not there. I don't think we need this much text to describe the scenario where it must be set. Okay, so. Great. This is funny. So the obvious solution to that criticism is to have someone offer alternative text. That's right. Is someone going to take the pen and try to write some shorter text? I believe these are the rules that we need. Let's go this way. And then I have some inline examples. For instance, like an event might initially be published at the bottom, right? That is an example. Then I have the story with the character encodings that's, no, no, there's also a normative rule there. So I can see cutting a little bit of text, but everything else. Let me suggest this though. Without getting to whether the text is too verbose or not, what do people think about the direction that Clemens is headed here? Is there anything technically incorrect or people disagree with with the text here? Okay, because if the issue is simply Clemens is just too verbose, I would like to suggest that we vote on whether we approve this PR and then implicitly close the other PR and anybody who wants to propose shorter text can offer up a follow on PR to shorten this puppy down. But I don't think it'd be necessarily fair to Clemens to hold up his PR for alternative text that no one seems to be volunteering for at this point in time. Comments on that? Maybe, I think the cruisin' of the text is too long is maybe a bit unfair, but maybe just the logic is too complex. Like maybe the simplest rule will be it just required end of story or maybe quite there will be, if it's JSON, you can omit it. In all other cases, you have to submit it or something along the lines of that. We'll be in charge of that. Yeah, but there are good reasons to omit it because if you have an event that is self-contained and it just has a data attribute and that contains a map, that's fine. And that actually transcodes really well from JSON into Avro into whatever, into Brodebuff into all the different formats because we have an abstract thing that is a map. And we just dropped that out. But if you want to have the fidelity of the type system of any of those, like you like the Avro type system because you want to have a date be a date or you want to have a decimal be a decimal and you want to carry that, you don't want to lose it, then it's perfectly legitimate to go and bolt it down to Avro and say the body must be Avro but you transcode the rest of the event into JSON because that turns out to be what your intermediary can go and parse. So that's, I mean, there's, yes, you can make it simpler but then you also are trading features. Yeah, that's what I'm saying personally, I'm okay with trading those features. So, Christoph, I'm not 100% sure what you're advocating. Are you advocating that there's a way to just shorten it or are you actually concerned about the actual sort of normative language in there? I mean, okay, so maybe I should take a step back and say that for me, I'm mostly concerned about JSON and I just wouldn't care so much about the other formats. Well, for me, it seems like a lot of things to follow where it's sometimes the most, sometimes the short, yeah. So I think a clearer ruling, yeah, it's not so bad. That's what I'm trying to say. Okay, okay, so I think there's, there is fair amount of consensus that people would like a smaller amount of text. And I'm not even sure Cummins is necessarily against that, he just doesn't know how to do it himself. So is there somebody willing to volunteer to offer alternative text in its place? I can take it right out, if it's the reason you can omit it, otherwise you can't. I'm sorry, Christoph, are you saying you volunteer to take a stab at it? Yeah, I would propose a different set of rules or a set of rules that will also shorten the text. Of course they will, but we're losing things with that. And that's the, having always mandating the data content type loses the ability to easily go and transcode the structure. Well, we just dropped the map, that's just the vote we had, so the map is gone. No, no, the map is only gone for context attributes, but not for the data attribute. Okay, the data attribute, the data attribute can contain a map and can contain maps of maps. And so it can go in and it contains, it can contain structured data. And that structured data can right now, as the rules are, can be going in using JSON and then you deserialize it into whatever your in-memory type system is. And then you can go and serialize it back out into Avro and it will transcode because we have those rules. Once you mandate the data content type, you no longer have that. Which means you forcing the data content type on everything, you lose transcoding. And I don't want to lose transcoding. I want to be able to go and take a JSON object and be able to render that out into message pack or Seaborr, pick up the Seaborr thing and then render it out using Avro for storage. I want to be able to do that. And if I set the data content type, then I'm forcing through all those various steps, the data to be exactly of a particular encoding, which means then it's carried binary in all the other types of encodings. So in the worst case, I'm having a super compact thing like Avro or message pack or Seaborr, but since I've declared application JSON, I'm carrying the JSON text inside of that thing. That's a consequence of forcing is that's why those rules are there. Okay, I get, I mean, okay, what's your point? Why can't you also change the content type along with changing the format because JSON will be then forcing you to keep using it? Yeah, because then you're modifying the event. Yeah, okay. Because you can't tell whether you're using JSON because the other party you're talking to, right? The consumers of those events, because you already know that they expect JSON and that's why you're forcing JSON or whether you are using that just because there's no other way to express it because there's a must rule here. So I'd like to pick on Mark for a sec because Mark, after your joke comment there about the decoder ring, you talked about whether you basically thought people could actually implement this sufficiently. Is that a concern about sort of the technical direction that Clemens is going or just the wording that he chose? I think it's the wording that has been chosen while correct might lead people down different paths to implementation that make conflict with the intention. In other words, give this to two different people and they try to implement, implement code around it. They may make radically different decisions on how to implement. So I'm trying to weigh whether the spec should stay the same and really what my primary issue is around the primer and how that's laid out in terms of how to decode something. Interesting. Okay, because we're gonna focus on the spec. Well, when you have something normative like this, it's somewhat straightforward but it could still be confusing to people trying to decode that normative text. Yeah. Okay, so we're running a little on time here. As I said, I'm not hearing anybody necessarily raising their hand, volunteering to do a whole lot of work and there's a rewriting here. And I think that says a lot. But at the same time, I'm also not hearing people necessarily disagree with the technical direction itself. And so I'm still kind of of the mindset that says, let the PR through assuming people are okay with it. And if someone wants to take the pen to rewrite stuff, I don't think Clemens would object to it as long as it still meets the technical criteria that he thinks is necessary, because that's his PR. So, and because if we hold up this PR right now, my very large ask would be if we hold up this PR then someone has to volunteer to not only take the pen to rewrite it, but do so by Tuesday of next week. Because I really wanted to get this one resolved. And in order for us to vote on something next week, it has to be rewritten and out there by end of day Tuesday. And I have my very serious doubts that that's gonna happen. So in order to not force someone to rush it, I'd rather say, let's let the PR through now. That way you people who want to try to rewrite it, they can take their time to rewrite it, holding out too long, but at least they're not rushed by a four day deadline kind of thing or five day, whatever along it is, five day deadline. And we always accept and follow on PRs to modify this text as necessary. Nothing set in stone yet. What do people think? I need more than silence this time. Christoph, would you be okay with that? Unless you want to volunteer for a change by Tuesday. I don't want to complicate things. If other people think I should do that, I can do it, but I'm not trying to force the discussion on it. So if no one agrees with me, I just drop it. That's okay. Well, I'm not sure it's so much people agree or disagree. It's, enough people do have some concerns about the, the, the reverse city of the text. The question is whether you think you'll have sufficient time to, to do an alternate proposal, possibly talk to Clemens offline to make sure you didn't miss something and that kind of stuff and get it there by Tuesday or whether you'd like to have more time. I think I can do it by Tuesday. Clemens, you okay with that? Sure. Okay. But I would like to force a vote on Tuesday, next week's call, cause both these PRs have been out there for a while and it's been a real challenge to get people to, to read them cause they're non-trivial, but we do need to get this behind us. Okay. Thank you. Thank you, Christoph. Okay. With that, we only have three minutes left. I don't, I make some comments on Evan's PR. So we really can't talk much about that. And I did make a PR about modifying the governance stock. Please take a look at that when you get a chance. I think it's relatively minor, but please take a look. It's about people going out of leave of absence. I'd like to try to get that one in there sooner rather than later, just to get things behind us. All right. With that, are there any of the topics people would like to bring up on the call? So, so Doug, what's respect to the leave of absence? Does that beg the question as to whether we should discuss the voting rights in general? We definitely can. Does somebody want to- There have been other people that brought up whether this is the right governance or not. Yep. Yeah. We can definitely look for a different voting structure. We just need someone to do a PR with a proposal, to be honest. That's all it takes. I personally have been, I have thought about this several times in the past, and I have yet to come up with one that I thought allowed for the, to allow for the way this group seems to work, which is a lot of back and forth happens on the calls through comments and GitHub and stuff, and that doesn't necessarily show itself, or people's participation isn't necessarily shown through direct PRs themselves, right? For example, Clemens will open up to here like this one, and people will go back and forth on it, they'll make suggested text edits, and they won't necessarily be represented in a PR account, and I think that's a little bit unfair. That's why we have what we have. But if someone has an alternative, suggest it, I just don't know what it is. Okay. I think it might be worthwhile that we put on to the agenda just discussing whether we think this is the governance he's working for us. Okay. I can have that. I know that there's a PR that I'm suggesting there. I think it's just good to have a healthy conversation around it. Okay. That works. Sorry, I saw those two as being kind of intermixed. Yeah, no, they are. Yeah, because we don't need to keep track of attendance or if we have a different voting system, you're right. Okay, I'll, and we can talk about that in the future. Cool. Any other topics since we're at the top of the hour? Okay, did I miss anybody on the agenda for our attendee list? I think I got everybody. All right, cool. In that case, we are done. Thank you guys very much. We made it through almost the entire agenda. Cool. And we'll talk again next week. Thank you. Bye guys. Bye.