 All right, it's three after why don't we go and get started? I assume you guys can see my screen, right? Yeah, okay Actually just in case right ginger you have you have the company yet yet. Okay. We'll go circle back around All right first on the agenda community time. Is there anybody? From the broader community who isn't usually part of this call who'd like to bring up a topic for discussion or ask question If I feedback anything on those lines, I think everybody's a regular unfortunately All right, not hearing anything. We'll keep moving forward Next week is the 4th of July week or our holiday in the states. I believe I'm just double check what day of the week does it fall on? Fourth of July is Wednesday Now sometimes you will do take vacation Before or after that date, so I'm wondering whether we're gonna have enough people on the call next week Or whether people are gonna make I'm gonna be on vacation and we should skip the next week's call So, let me ask this question Who will be on the call next week? I would like to be able to skip but I won't skip it. We have a call He said you'd like to be able to skip. Yeah, because I will be on vacation Okay, I can volunteer Clements. He should be back next week Okay, so we have these one person from Microsoft to be there What about other people? I'm sorry, is that again? Whoever that was speaking it's very hard to hear there's a lot of background noise Sorry Doug, it was a read. You're on and I can attend the next meeting next week as well. Okay What about some of the US base folks? off Alibaba can attend a call too. Okay Some of us are reporting in the chat to Doug. Oh, there you go. Thank you I missed that Adobe the whole week. Wow. That's pretty cool Okay, um Aside from Adobe and I end Google Seems like a lot of fair number of people might be able to make it I'm inclined to to keep the call Just because I know that we tend to be US centric on things But in this particular case, it sounds like uh, we may actually have enough US based folks And it's obviously the non US based folks will probably be here I'm inclined to say we keep the call What do people think So Doug are you talking about the July 5th call? Yes, July 5th. Yes. Oh, okay So I will be on vacation for the two weeks after that Okay, lucky you. Yes All right, um, I don't know. What do people think? Um people okay with keeping the call I know it's not ideal for some of the US folks, but um Hopefully if there's something that uh, you'd like us to skip you just mention it and we'll we'll try to skip that particular topic Would people okay with that? Okay. I'm not hearing any objections. So we're going to keep the call Sorry guys All right next on the agenda new logo Austin We gave you a week to create a pr and you said you've not done it yet Now does that mean that it's still Only you want us to hold off on or should we assume that we should go with it? It's up to all of you I I would love to do this. I just haven't gotten to it this past week But at some point You have to call me out as a blocker and just move forward I love one one of this show week to give this a shot and if I if I don't deliver Then you should move on without me and that that'll just be the way it is Okay, I personally I'm okay with the logo as it is, but I'm also okay with giving you a week. Um Is there anybody on the call who objects to one more week? Yeah Or is there anyone that feels the same way and could work with Austin to Come up with a PR report Yeah, people want to submit other ideas. Um, absolutely. I'm sure I would welcome that What is the objection with the current logo? You know this personal opinion it it looks a little Unmodern And I think that there with a few tweaks, especially around the font It could look maybe a bit A bit more modern and a bit more fresh So I I'd like to try that and I I gave myself one week to deliver and then I I did deliver Because I've been swamped so I'm asking for for one more week And if anyone else feels like they want to contribute some other Some other ideas, I I think we should absolutely welcome that But after next week, we we should just move forward with what we have if we don't have something else that we'd like more by then Okay, so let's do this. Let's give you one more week And if somebody wants to join in the redesign, please ping Austin offline As I mentioned in the agenda, I did get a coupon code for 100 free stickers So obviously I'm not going to do anything with that until we resolve it next week Um But I guess that's about it then Any other any comments questions concerns about that plan? And luckily we don't have a I don't think we have a conference Coming up in the near future that we that we might that we may want those 100 stickers at so I think we do have some time But I do want to get to resolve sooner rather than later Especially since once the new design comes forward, we will have to go vote and that will take some time too So okay any other questions comments? All right Moving forward then Austin sdk sub work group. I want to bring us up to speed on what happened there Absolutely on Monday this week. We had the uh an initial call around designing the cloud events sdk Um, it seemed like a bunch of people were already working on this independently and a bunch of different companies Um, so we said hey, maybe there's a maybe we should do this together And then that kind of inspired this call Um, so a handful of people jumped on the call vmware sap red hat google And uh, we chatted loosely about this. Uh, we were able to draft out use cases features goals for the sdk We were able to rank them by priority We were also able to organize them into uh potential versions of the sdk And lastly we found volunteers for implementations across various languages Those languages being java go javascript and python right now So pretty good progress. Um, we've tracked everything in the cloud events sdk design proposal google document Which you can see I think that's in this working group Um google doc, right dug. Maybe I just put the link into the agenda. Yes Cool Um, every you know everything that we discussed has been organized into this doc It should be pretty accessible for everyone who wasn't able to attend To quickly check it out and get up to speed But that's what we were able to accomplish. I think next steps Uh, that we decided were to present these kind of use cases and priorities to all of you the broader working group And get some feedback And once we kind of get that feedback and you know, I agree on these priorities I think we still need to do some work to clarify the scope of each of the initiatives that are listed in there um and so anyway, maybe I'll I'll stop there and Um, we could kind of go over I could go over the the priorities that we came up with real quick and if anyone has any comments Um objections or other ideas maybe we could time box this and Um, have a quick discussion about it. Yeah, I was going to definitely start a time box if possible. Um Do you have any any initial questions comments for austin? Okay, maybe quickly go through the prioritized list you guys came up with Sure thing and again, this isn't a google doc Uh, a lot of people are already commenting on it. Um, so you don't have to speak up within this small time box You could always speak speak up later. Um by adding a comment on the google doc Uh, number one the first initiative that we felt was the most important was to simply be able to instantiate cloud events easily in code uh per the current cloud event specification Um, and have some simple apis around those instances that you create to get and set Uh data on the cloud event instance um and work with the cloud event more easily Um, you should be able to you know, also kind of mock these things out for testing um In addition to that we we like to figure out how to design this stk to support Um different versions of the cloud event specification You know, we think we're still going to be iterating on the on the core spec for a while And the sdk needs to think about that from the beginning Um, so there should be a way to easily set the the cloud events Specification version that we want to work with Um, or that the user wants to work with within the sdk Um, so that was the first priority and then we felt was kind of the simplest thing we could do today to get to enable Users to start using cloud events as fast as possible Um, the second big priority was to assemble cloud events from various Transports and encodings and have the sdk help with some of that work Um, and to do this adhering to the various kind of transport specifications that we're working on right now like hdp amqp nats webhooks mqtt That was the second priority we felt was was important third Instantiating cloud events easily via event schemas Um, and this specifically means the schema of the data within the cloud events data attribute and not the entire cloud event itself So being able to pass in an event schema and and using that to create, you know easier defaults of cloud events to do some validations To be able to validate the cloud events by that schema And even more easily generate mock events from that schema as well Uh, number four fourth priority was transforming existing events into cloud events via some type of transformation mappings Um, you know, there's a lot of popular events that are out there whether it's they're on a big cloud provider Um, or maybe it's just a webhook from a popular sass service um If there's a way that we could kind of build some intelligence into the cloud events sdk To be able to work with those, you know popular events and easily convert them into into simple cloud events We felt we could kind of integrate into the existing ecosystem more easily and Make cloud events have kind of a broader appeal right away lastly, there was a creative suggestion to Have the cloud events sdk Sort of have an add-on or a module feature that could work with some of the options That are part of the cloud events core specification So within a cloud event specification, there's an option to add on custom data For different use cases And we think the sdk should also have a story here Where you know say that there's a piece of data You know within the cloud events envelope that seeks to solve kind of tracing problems um If there was a way that the cloud event sdk could kind of have an add-on module That helps you, you know work with that data with the sdk. We think that would be Kind of have a nice offer a nice extensibility story You know enable end users to kind of build their own To use their own extensions with on the specification and kind of Integrate that into the cloud events sdk as well as vendors. You have vendors who might have some Um, some kind of proprietary things that they want to put on the cloud events envelope and also have a nice story with With inside the sdk So that was the fifth priority. We felt was important That's everything we're able to move these into cloud events sdk versions Which you can see in the document below that And these are kind of replicated here within the specific versions and some of them have a bit more detail Um, so that's it. Maybe I'll I'll pause if anyone has questions or comments Let us know All right, any questions rosen So when will the um code uh implementation um be started? Good question. Kathy. Um A lot of people have already started these So, uh, for example, matthias matthias over at red hat and his crew Um are our crews and along on the java implementation I know mark peak and his crew over at vmware and dispatch have a go Version in the works. Um, there's a python version that has already been started And I think that it's Yeah, this is one question that I wanted to raise to this group Um, you know, we've laid out the milestones and scope for the cloud events sdk version And I think that's an important exercise Uh to kind of stack rank where we think the priorities are and get aligned on what the On what the sdk design should look like across languages. However, I'm not Personally feeling like this should be used to block anyone I think if people, you know, who are doing the implementations working together on the implementations within various languages want to move Potentially faster and get to some of these later stage features faster faster. I think they should be Perhaps free to do that So related to that though us and you guys talk about where the code for these things would actually sit Oh, yes, um, we discussed it. Uh, the cloud events get have repo Um seems to make Make absolute sense there. Cool. Okay. Yeah, I agree. Just want to make sure. Okay This is like likely we will stage in uh external repos and then Have a have a review of it before moving it into something like cloud events Okay, cool. Thank you mark. Rachel. We're gonna jump in there. Yeah, are there going to be future meetings? Or was that like the kickoff and you feel pretty good about the design and now you're fully implementing it Yeah, that was going to be the last item I was going to bring up here after just getting some feedback on those priorities. Um, you know, I think I think that We should do an additional meeting just to clarify some of this the scope of the initiatives that we've prioritized because some of them can be quite broad and hopefully align on design patterns Um, so that these these implementations can look more consistent across run times. So I think that would be Um, that would be a good good subject matter to discuss in an upcoming call But perhaps after that, I'm not sure if we need to do a recurring call I think we should let people implement for a little while and then do kind of a check in You know once we think we have a few implementations on the table So when are you planning on having the next call then? Um, I was going to put out a doodle poll again Get people's input see when they're available. We do have this holiday coming up next week So I wasn't thinking it's going to be next week, but maybe the week after next Okay So Austin so after the call, uh, I assume you are going to post On the design patterns back and so that we can take a look It it should be in the Um, in the service working group meeting minutes, right Doug Uh, the link to them to the um to the design doc. Yes Yeah Yeah, it's right here Yeah, it's right in there Kathy. So it's it's already linked Oh, so this call is a design Okay Okay Any other questions or comments on on all this? All right, I guess I'm hearing any cool. Thank you guys very much. I'd like you made a lot of good progress. This is exciting Yeah, everyone's already kind of jumping into implementation people are moving really fast You know, I'm personally really excited about this. I think we've We're doing some important work here. We have a great spec on the table And now these stks are going to make it more accessible and make it real And allow people to put this into their you know start actually using this stuff more easily than ever So I'm excited to see the enthusiasm around this and I think we're going to make a lot of progress quickly All right, any last comments questions All right. Cool. Moving forward then Kathy On the workflow working group Um, I know you set up a doodle poll and you're meeting every Tuesday But did you meet this Tuesday or is or is the first meeting next week? The next week is the first meeting. So I just want to let everyone know everyone know that, you know, it's every Tuesday It's starting July 3rd. I believe correct. Oh, yeah. Okay Good thing Kathy like I I've kind of struggled a couple of times to figure out what's happening I didn't know how to get in touch with you. I was trying to reach on slack I brought on the doodle I don't know what's the best way for us to kind of communicate to kind of make sure people know This is happening. Obviously this meeting is One way to do it, but I don't know like But it's taking meetings. I know when they were happening because they all pushed in slack Yeah, maybe you could send out a note and put some more messages on slack making sure everybody understands that the first meeting is next Tuesday Okay. Yeah, I will do that And I'm happy to jump in and help as and when you need so feel free to reach out Okay, so who is it, please? You know, sorry, this is this is what run Yeah, from where Oracle? Yes. Oh, okay. Yeah. What time Tuesday? No, it's as yeah, it's 10. So this is support 10 30 a.m to 11 30 a.m Pacific time Pacific daytime That's the most that's uh the time slot that gets a majority vote Is that also going to take place over zoom or is there another place for them to take place? Same zoom channel Cool. Yes Keeps it easy All right, any other comments questions also I think you know for people who are Interested in this topic I have a google doc and that drafting the and that drops the Kind of overview of the Workflow, so if you can take a look that would be good Can you be fair Kathy? I just put a google doc comment or a bullet on that work item I'm sorry an agenda item. Can you add the link to there so they can easily find it? Thank you. I could yeah Thank you very much. Okay. Welcome Hey Doug. Yep. Got a just a quick A quick announcement Since the idea of doing kind of logo iterations was brought up earlier on the call a few a few people have reached out to me On zoom who are also I believe design neurotics like myself and They're asking where they could post potential suggestions. I'm going to make a Issue within the cloud events spec repo right now. It's just going to be called logo improvements If you have suggestions for logos, I recommend just putting them just pasting the artwork right in that issue thread and Hopefully doing this all before next Thursday in the next Thursday. We could kind of look at these and uh and vote on them together That sounds good. Thank you, sir All right Any other comments questions on the workflow working group from Kathy? All right moving forward then So we have two issues which we said we're going to close unless someone spoke up to That's weird. There we go unless someone speaks up to claim To be a champion of these two issues So the first one was this conformance with jason api spec. I haven't seen anything Claiming to be an owner Is there any final objection to closing this one and just remember this doesn't mean we can't reopen it But at this point in time without someone willing to champion less moving forward on this It doesn't seem like there's much interest in it, but we can't reopen it if that changes in the future So any objection to closing this one with no action? All right. And what about the other one alignment with itf security event token again? I don't believe There's been any interest from anybody in this one Any objections to closing? All right done. Thank you guys very much All right moving on to the bulk of the meeting prs The first one the primer. I don't believe this is had any comments in quite some time. It's been out there Um Yeah, I think there was a one minor typo from mark they noticed besides from that it's basically been untouched so as a Just as a reminder, this is not meant to be the final version of anything There's like all the other specs in our repo. This is just sort of the first draft For the most part. I just rearranged things. I tried to move things like use cases references to existing Um event formats and stuff out of the main spec itself into the primer and to add a little bit of Text try to explain some of the history of the group itself where we're going design goals It's like stuff like that and this way it will keep the spec itself focused on sort of the normative text itself and any sort of ramblings or background history that kind of stuff we can move into this primer doc and have it all in one spot for people to read as background material Um I don't want to necessarily go through it all right here But as you can see most of it is just moving stuff around for the most part. That's why you see a lot of deletes Um, and then copy it into the new doc itself Are there any questions on this any concerns for any reason people want to wait a little bit longer before we Accept this or discuss the only thing I see is where did all of the stuff that's deleted go to Actually, you know what I thought scrolling I was wondering where the big chunk of green would be and I didn't see it So hold on a minute There it is. Oh, that's why you have to load the diff there we go I got a little panic there for a second Yeah, so it's all there's all the green stuff So so doc I see that, you know, the use cases are removed, but I didn't see it was it is, you know, those are added Yeah, they should be they should be in this primer doc itself. I may have called it Uh, I think I might have changed the title from use cases to roles and proposition and value proposition more than anything else Oh I just changed the title, but the text itself should still be there So it's called roles now the use cases. Um I can't remember which one went to which section to be honest. I think part of the use cases did go to roles and then And then some of it I think pop showed up under value proposition Because that seemed to be more appropriate title than use cases But obviously you can change the titles if you guys want that I don't I don't really care that much about the titles But the text itself should still be there Okay. Yeah, the reason I asked is because I did not find the use cases use case I put in before so maybe because of the title change or yeah double check, but I'm pretty sure I did include everything Okay Hey dawg, I think given that the questions are being asked perhaps This is called action for people to review it and then we can approve this next week That's that's fine as well. I've no objection to waiting. That's just um So people have a week to review and make sure that the section's got trans transposed forever Is that okay there everybody? Yeah, okay, so please review it or we'll vote on next week All right, any other last minute questions or comments on that? All right, um actually Thomas is traveling I was gonna say yeah, thanks a little bit Well, let me do this Let's let's take a look at them because they seem to be fairly straightforward prs if we people are okay with that I wouldn't mind accepting them, but if there's any concerns that we can wait So fact distributed tracing extension into a new dock Basically on this one. I believe what Thomas did is he took the current text from the extensions that MD doc Moved it into its own Distributed tracing doc in a directory called extensions. So he just basically moved it into its own doc And then he added Some boilerplate text in the extensions that MD doc Um, basically talking about Uh You know how the normative I'm sorry the the rfc keywords Apply only within the context of the extension itself meaning for example Um, believe down here just keep a concrete thing Down here when he says this is required That means it's only required if you're choosing to use the extension It doesn't mean it's required, you know for all for all uses of the cloud event thing spec itself But for the most part, I don't think actually made any real changes It was more moving text around than adding some explanation around the rfc keyword stuff As I said, I don't I don't want to rush this, um, but it did seem fairly straightforward to me I was wondering if people need more time to review it people are okay with it But it was the current thought process here So is it is it correct that in the future all extensions should go under the extension directory? Correct there will be Basically a like a table of contents right here in extensions md And then yes, its extension will have its own file under the extension directory Any other questions? Do people want more time to review it if you're looking at what that as is as the first pass You guys are kind of quiet. I'm okay at proving it, but I don't want to rush people Yeah, I don't want to rush people either but as I said, it did seem fairly straightforward to me So let me pose the question and please if you want More time to review it to speak up. There's no there's no concern there But let me ask the question. Is there any objection to adopting this br going once? All right, we'll approve it. Thank you guys. Um, next one is again from thomas This was an action item coming out of our face-to-face. Correct. Yes Really straightforward. He just added some items to our roadmap Just he basically I believe here the point is he wanted to add um The idea of making sure we actually looked at the specification from a constraint perspective, you know, our Are we do we need to add limitations on sizes to uh to values and stuff like that? Just wanted to make sure that the real world constraints actually were reflected properly in our analysis here So we just wanted to add these to our milestones or to our roadmap And it's fairly straightforward and short list It looks like that's to zero dot three Yes, let me just make it a little bigger. Yes, 0.3 I'm fine with it. Okay. Any other comments questions? Okay, let me ask the question that if there any objection to adopting this pr All right, I'm not hearing any. Thank you guys very much All right next one. Um, Vlad asked that we not vote on this one But I do want to bring it up just to ask if there are any questions or concerns on it This pr is related to something we talked about I believe at the face-to-face and actually probably even before that if the idea of removing the The bag that we had for extensions or the map that we had for extensions and treating extensions as top-level entities Um, so the bulk of the pr is actually right here And here's the only real new normative text basically Um, then producers may include additional extension attributes and then If you're typing can you please go on mute? Okay So then producers can include additional extensions. They appear as top-level attributes but the The definitions for the serialization and the transfer bindings will actually specify how extensions will appear in that particular context so the main spec itself basically avoids that issue or punts on it Um, and then the like the hp spec itself will define how extensions will appear As I said, I don't want to vote on this because Vlad did ask for another week or so Because he's doing some work, but I wanted to ask if there are any questions or concerns that we may want to discuss right now We did discuss Objections to this in the face-to-face, right? Um, I know we talked about this at the face-to-face. I don't remember Are Many objections, but I'm just not remembering correctly. Okay. I'll go look at the notes. Okay Are there are other reasons why I'm sorry, are there arguments why this is a good idea? Basically because There were multiple. I'm sorry if we have a a bag for extensions You're then left with the situation where you have multiple places for extensions. So for example In the Jason serialization You could have the bag for extension at one spot But then Jason at the top level would allow you to add additional properties in there So then the question comes. Well, do you put extensions at the top level Jason or inside the bag? What if things appear in both places just one over at the other? And just it just seemed like it was going to be a point of potential interoper confusion So we're trying to reduce their extensibility points down to one So are we talking about extinctions or talking about providing some hooks To override values Just extensions. We're not talking about overriding things So a good point that the pr raises is the path to stabilizing a experimental extension Basically promoting it to your first class is essentially a api breaking change if we use this bag of extensions Um, and I think this is kind of a more general problem It would also affect things like the job stk because the way you access extensions I imagine would be different from you know actual getters and setters Um, so I just wanted to raise that point. I don't really have a good solution for it yet So it sounds like some people may not have had a chance to think about this one. So which which is fine Since as I said, we're not going to necessarily vote on this today. So please take some time to review this comment in the pr itself We don't want to wait for this phone call to go through Larger issues around this. I'd rather do it offline in the pr itself So please speak up in there if you guys have any concerns or questions I do like people are very quiet and I just kind of wonder like what people's temperature is around this one like are people Like being quiet because they agree or being quiet because they disagree. I guess it's my question Both Yeah, it's for the sake of talking. I can say that I'm being quiet because I haven't actually read everything yet Is that fair? That's very fair. Yes. All right, cool. Cool. Yes So anyway, obviously this is this is kind of a big one in the sense that it's it's a it's a it's a key design point Right, so please take the time to review it Look at the discussions that are going on in there and and comment on the pr So we can get some feedback on either way one of the one of the Objections from the notes from the face to face was that it would be difficult to do in proto and I imagine the google cares about that more than other places. So I will take it on as a ai to figure out What are like what google stance is going to be on like how we can do this Okay, great. Thank you. I'll be helpful Yeah, but it's kind of interesting about that because if if the answer comes back and says well We need it in a bag Then I'd love to know how they handle just jason extensive building in general then So But thank you All right, it sounds like people need more time to think about that one, which is obviously very fair So we'll keep moving forward. I'm hearing big discussions right now So Okay, next one kathy application properties attributes. Would you like to talk to this one? Yeah I think this one has been iterated multiple times and so I wrote it up I modified it based on Our consensus in the face-to-face meeting so people can take a look to see whether this is okay Are there questions to comment on this one? Man, you guys are quiet today Markdown kind of likes more spacing between the titles and the explosion There's more more new lines. I think Okay, well, I think that's a general concern because I don't think kathy changed the pattern That may be something we want to address at a broader scale than scott but so Kathy Couple things first I'm not sure we want to allow spaces and names Oh Yeah, I can put a dash there. Yeah. Well, no, it's not just for the example. I think we may need to add text um But it's a string, right? Um, so well, definitely a string But you may want to make sure that the name can't have spaces in it because right now they always say is that it's a string I believe So are what is what you're saying is that you want the values to be usable as variables? No, no, I want the names to be non-spaced because on some cases these are going to get mapped hgp headers and I think spaces might have a cause problems there So if that's what you say you should probably say something that's suitable for users in hgp header Yeah, that's why I have my suggestions to say it has to be alphanumeric I'm fine. You know if we have that restriction say no space Yeah, is that okay with everyone? Yeah, I think you want I don't want to think I don't think you want to just call it spaces in particular I think you rather I think it'd be better to focus on what What are the valid characters as opposed to what's invalid? So say it can only be alphanumeric, you know or something like that But the other thing is um, I had a question When you say flat structure Is that does that imply the same thing as the value must be a string? No, no, that's different That's different. So flat structure means, you know, we do not have hierarchy remember in the Yes, there's a proposal which has hierarchy um It's actually these properties Right, but if the value can only be a string and it can't be an object Then you can't get a hierarchy. Isn't that correct? We have in you know, like embedded, you know several layers, you know One is another in embedded layer So this what this means is, you know, it's all flat. It's the same level Yes, but when you say that only string you're saying that you cannot have an object inside only strings So it implies that's okay Yeah, that's why I was confused because it those these two sentences seem to be almost saying the exact same thing And I want to make sure that That they actually are repeating each other. And if so, we should probably just reduce it down to one sentence Yeah, I see. Okay. I see your point. Right. Okay. Yeah, I've just You could probably say it must be a string and then give the example of We we we don't want to have structures underneath I think, you know, we say the value is string and then I think it's I I feel this is okay Right. It should be a flat structure Which means when the value is string cannot be a not flat Yeah, oh, we can just remove that. That's fine. You know, if you think that's duplicate Yeah, I think if you just move the sentence, I think that makes the problem go away. Okay Okay So there are some changes that people want to see made are there other questions about this then I Want one comment though. I think that that just making a string accomplishes the goal But I think you should capture the group's decision that the hierarchy be flat someplace, but it's not already captured So what's that again? You see I think you should capture the the the groups Goal that over time As a spectator is looked by on by other eyes That the goal is to keep the structure flat It's easy. You just merge the two sentences Therefore the string must or the value must be a string making sure that that sentiment is captured you know, even though grammatically And it's going to be effective by changing to string Matt, could you provide sample text in in this pr? So I'm hearing that you would like the To be a flat structure. I think that the request I think it could be if this is what I'm hearing from the group I'm not participating in the discussions. If you want to if there's text there that are way that can be preserved Please do so. I mean if someone else's hands are going to be in this section and it's just a sentence I really don't want to become involved But I'm just making a commentary So Kathy I think what Matt is suggesting is that you could say the value must be a string and then maybe add In parentheses or something here that says Because we want to keep it as a flat structure or something like that just to give a little bit of rationale to explain Why we chose to keep it a string All right, so what's then I think that's what currently This text said right the key value pairs is a flat structure Well, I think the point is you don't necessarily want this this one didn't have to be a must because then People are going to wonder what's the difference between these two musts I think what Matt is saying just explain why this must here exists I mean I I I watched I mean that's the same thing we've reached in other event standards Is a flat hierarchy. I think it's important to state that as as a goal as a goal as a goal for that for the structure of the schema Okay, so we don't rattle on this call about this to Kathy. I'll I'll work with you offline to see if we can come up with some alternate text. How's that? Okay. Yeah, that's fine. Okay. Thank you Okay, any other comments on this one Yeah, I think I must have missed the discussion about The name becoming application properties. Um It was just curious. I believe it was simply properties before That's right. Yeah, but you know in the face-to-face. I think we agree to change it to application properties Yeah, because this is for this this properties will be used by the application Right. So this actually goes A little bit to my comment that I didn't make on the PR itself in the body which is here I I I given the text that we have in this PR As as somebody coming new to the spec and I would read this I would still be very confused as to when I would use this versus extensions And I think we need some more clarity there if we're actually going to keep these two extensibility points Because one of the things we did agree to at the face-to-face was we were only going to have a single extensibility point And now we have two that seem like that they're almost the exact same thing Yeah, I second that it's still to me. It's a still bit confusing Because this seems to be a place you can put a lot of things into it and what can be put into that and when What should not be put into that is not clear to me Right Because really one thing we have in here that says these are used by an event-based application Well to me all these properties are going to be used by an event-based application Yeah Oh on the other side, I can understand that a many application may need something other than the top specs we put Um, but I'm not entirely sure What should be put there? Yeah, see I and the other thing that related to that is, you know, take for example the sensor location That could appear as an extension And there's no guidance in our specification today as to why it should be in one spot versus the other And I think that's a very large confusion factor at least for me Yeah Yeah, I guess as long as it seems that the decision to move extensions Up-level properties and why not make all Additional properties at the top level it's already going to have to be dealt with in terms of serialization There's a there's a lot of background noise if you're moving your phone. Can I guess can I ask guys to go on mute? I just feel we are like going around the loop again. I think you know in the face-to-face discussion We already discussed this right? On how we should restrict the scope and then we come to consensus and say, you know, um, it's for Originally, I was thinking this is just for a correlation purpose But then, you know, we think we're going to is I mean, it's finally He said it's used to buy application Make it broader Right, but Kathy one of the things that we also agreed to at the face-to-face was to make sure that there is sufficient text in here to explain Why we have these two different extensibility points and when one should be used instead of the other? And I don't think the text in here does that yet. And so I think we need We need additional explanation text in here. There's not is the point. I'm trying to get to Yeah, go ahead I would also agree with the point that if If we're making the move towards moving everything to the top level that this property kind of becomes pointless at that point It might as well just move everything to the top level and and have it be on a use case basis so So Kathy, I think it might be useful if you could work on adding a little bit more text here to explain Why this property or when this property should be used and that's whatever other extensibility mechanism we have in the spec Because I don't think it's clear right now Yeah, like the original ones I remember in the face-to-face. We say there's correlation tracing And Uh, one more thing That will be there and then this kind of becomes Whatever thing can be there That's the part I didn't really follow I don't think you know the tracing at my understanding the tracing was moved, right? Was maybe not there's correlation three things I remember No, I think we clarify some of those are not really Correlation it's maybe different, you know, it was the same same, you know Same syntax same word, but the semantics is different I'm actually I personally would like to just this is for correlating, you know multiple events from different event sources For that purpose. I can restrict that Because I think you know Yes, there's some kind of restriction would be good say what should be put into this part Either whatever you can say is Then we can take a look see So what what people's what have the people what are your suggestion? You think, you know Should be putting here because there's so many examples Yeah for correlating multiple events. They are, you know Different use cases you can put different things there. I don't know, you know How we should, you know restrict this I think maybe Kathy if we could just use the what you just mentioned before it's to say it's to To correlate events from multiple event sources. Just have have some text in there to as way of explanation Does that sound good if we just restrict to that use case To correlate Actually, that's my original thought to correlate multiple events, you know from different event sources That will be used by the serverless application workflow But I think in the you know, um, we cannot restrict it anymore or because they Different use there are many such use cases Which were going to there are many different types of events different types of event sources We cannot pre-define like, you know, what What properties will be used for correlating those events? So It's quite open to whatever part whatever the I mean the the developer They can put in I mean all the event Event vendor they can put any properties there, which they think could be used to correlate multiple events All right, I thought that Thomas in particular was hoping to use this property as a space to put What was he calling it? I guess he was calling it labels, right? I think you know, we already agree on it's called properties. I don't think I don't want to go back again to No, no, I'm not I'm not just changing the name what I meant was he wanted to use it for more than just correlation He wanted to put labels in there So so that's that's why, you know If we just put correlation, it's already big enough, right people are already thinking some people I guess some people will think okay, it's still not clear what should be put there If we extended or expand it to to include, you know, more Use cases will be even harder for people To understand what should be put there To clarify, I think that labels were brought up as an implementation of For correlation not a goal in and of themselves. So it's fine to Yeah, I think the problem is even for correlation we cannot Like give up more restriction on those things can put into this map The the biggest problem at least for me is this map is pretty much open You can put whatever into any any key value pairs You're right. I think yeah, we're right It's kind. Yeah, it is kind of open even just for correlation because we cannot restrict the the event vendor down to a few scenarios say we support Like we can think of a few things that can kind of be general enough but not like totally open Um, there are so many use cases, you know, we cannot say oh, we include some of the use case For correlation, but the other we do not I don't think that's the right way to do it This this issue itself is open right because there are so many different use cases Correlation We cannot even predict they all what even we can say, okay With all we exhaust all the existing use case in the future. There will be more use cases But that kind of also apply to the cloud events spec, right when we define specs there can be things Happen in the future not included in the spec That's why we have the extensibility point Yeah, then we have extensions So this thing If something that we really don't know if there can be Different use cases we never we cannot predict which is to definitely What what what should we do? I I'm not clear on that I think you know, we I think you know, we We can just put the I like here. I already put say one usage usage example Is application workflow can use this key value pair to call it multiple events Or social resources application, right from different event sources I think this itself by itself The nature is is quite open I don't think you know, we really need to restrict it because if we restrict it will be wrong, you know If that's not its nature for this So if a field is normally but I feel it feels required and normative It needs people need guidance on how to use it So You might not know the full set of examples that people might use it for at least they need a guiding set to give them idea Why it's required Actually, I just raised something else matt. I'm not sure this should be required Because what if I don't have any Is there any reason why you make it required kathy? You always have something to correlate multiple events, right? Well, what if it's just a single event that lives on? Just like Yeah, okay. So if it's okay, I think this is a little bit complicated. Let me try to clarify Even it's a single event, right? So that event if that event from application perspective From an event source perspective every event is a single event, right? But from application perspective That application could use multiple events Which includes that So-called single event You know, you know, I'm not sure whether I can get this across, you know, um This is not from an event perspective. You know every event is a single event So the event just put whatever. Yeah, so from the event just put whatever which can uniquely identify, you know, it's It's properties is how to say uniquely identify itself Put whatever there And then it's up to the application To choose this So I mean if it's not explainable to this group then how we're going to give gizmo guidance on how to fill in the field If the if the application isn't trying to correlate like if the application Just takes an action when it gets an event and it's not trying to correlate events What would they put in this field? If the application is trying to what they put okay, yeah, um, so So the application of what it works is This event source event vendor put this information there, right? Like this public address or the floor or apartment id And then the application workflow will say, okay I'm going to choose, you know, this um, like for example, this uh sensor location On plus apartment id and process for building address all these as my Cartesian id and then for another event. He's going to use the same information But if so that's in one application and if I have another application that is not correlating Events at all like the application um It gets it gets an event and it performs some action But it doesn't need to classify the events in any way What would they since this is required? What would they put in there? Okay, so that application does need to put any To select any attribute any I mean field Any keys from this properties, but that's the application level Uh, it's optional But from the event source level is required because if there is an application that need to do correlate If this information is not in that event then There's a problem. So there's two aspects, but that's a very good question Rachel you asked So from the event source perspective It's required because if the event does not have it if application needed It cannot do it So I'm gonna have to call time here just because we're out of time basically. Um, but People please add comments to the pr itself asking all these questions because these are all really really good questions that we need clarity on Um, but please put them into the pr itself so we can get some conversations going We shouldn't be Doing as much deep dive on the calls. We should be doing this on the pr itself So please take time to review this and we'll revisit this one again next week Um, I think you know doc. Yeah, we're running out of time So I I think this this thing itself by nature is really open. So, um I think when people post questions, uh, yeah, I'm going to try to answer But if also I would like people to post suggestions Because I think it's open. I don't know how I should put any So I need restriction or anything there. Uh, yes, please. Obviously. Yes for I think this goes for all prs You know, if you don't like a piece of text or you want to something added, please add the specific text You'd like to see But Kathy, please try to look for comments on the pr that way you can respond as quickly as possible. Um Because we want to get the conversation going and if people wait until Uh, you know next wednesday to respond to issues raised Then we're not going to get the back and forth that we need and come to resolution quickly and this we may have to Wait another week or so to try to find a resolution. That's good. Oh, maybe I suggest maybe we have a Discussion again next because it still has a confusion. I think we need more time to discuss this, you know Um, not just a simple pr this one. That's fine But let let's try to get as much we can inside the pr itself at least then the the discussions are Documented inside the pr. Okay. Sure. So with that we are taking a lot of time But let me just quickly do the roll call for people who are late ginger. Did you come off mute yet? Yeah, okay, great And mark fisher You there Yes, I'm here. Okay, Dan Barker here Simon. Yep, and stevo Excellent did I miss anybody else on the roll call? All right, cool. Thank you guys very much. We'll talk again next week. Bye everybody