 Hey guys. Yeah, T.O. Hello, how are you? All good. A bit of a funky weekend here. That describes it like on the weekend, 100 meters, 200 meters away from my house, another house exploded. Well, how did that happen? I don't know. It's not yet known. I guess everybody suspects a gas explosion, but it was a pretty crazy scene. So bit of an intense weekend. I mean, that nothing happened to us, but we are definitely sorry for something like that, but no one able to. Yeah, but other than that, I'm fine. How are you, Manuel? Oh, great. Thanks. What did I hear about a gas explosion? Yes, next to, it's about 200 meters away from my house, another house exploded. Bit of a sad weekend. Oh, we're getting some company. Gem, PayPal, interesting. Yeah, hey guys. Sorry, I haven't done all the background reading. Never mind. I'm on the cloud events working group. That's why I sort of sort of been trying to keep an eye on this. And so I asked Kathy to sort of forward the invite for me. Thank you very much for attending. And we have one more, Ricardo. Ricardo, if you're talking, I saw you unmuted and then muted again. Maybe, yes, trouble with his audio. Yeah, before we get started, I don't think Manuel will, if you want to drive this again, would be nice. Yeah, I just want to give it one or two. Yeah, yeah, I just wanted to kind of bring up, oh, you have to wait for people. Okay. I had a few positive responses on the invite. There is one more, Dan. Hello, Dan. Sorry, Tim, you wanted to say something? Oh, we still have time, like one or two minutes. I just wanted to bring up the TOC. If anybody, everybody has seen it. This is a big deal for us. We submitted a PR to the CNCF technical committee. And hopefully soon we will have an official review. And then we'll get feedback of what we have is good enough to move to a sandbox. This means a lot of things. Hopefully now I'm kind of new to this too. So Doug is, you know, is kind of needs to help us a lot on this. But from what I've seen, it means our own GitHub repository, which by itself is a big win. A new mailing list hopefully. And hopefully a dedicated host IP for a website, I'm hoping. Yeah, that would be great. Any ideas? I'm very new to the CNCF myself. Any idea how, what's the time range here? Is it weeks? I suspect this depends on how often the TOC meets and discusses this. And then we need to move through six stages together support for becoming a sandbox project. I will put it on the chat. We will get a date. And if you follow the PR, you'll probably see it yourself. The way I understand it is we have to wait for their TOC meetings. And we will get slotted into one of them to present. And then it's not a really presentation, so nothing you guys have to worry about. The most important thing for us right now is to show community. And to show progress in one way or another. And I think having a lot of people in this meeting shows that and I'm very happy. Or at least, you know, a number of them. Yeah, so also let me again try to welcome Dan and Ricardo. Hi, if you're there, feel free to just say hello. Hi Ricardo. Hi Manuel, how are you? Yeah, I'm working for Red Hat, I work for Jihou. And I will help him with the serverless thing as well. So this is my first meeting. Hello everyone. Hello. Yeah. Okay, thanks. You heard about it. Okay, thank you. Okay, so let me start. And talking about the TOC PR is actually a good thing because along the way to become Sandbox project. Well, we need to show of course this community will also a little bit of background or additional material than just the spec itself. We had a motivation from Doug. I think in November last year when there was the first vote on the subgroup proceeding as an individual group that we should come up with a primer very much like cloud events has done it. And the primer document is, as I understand it, it's not the specifications or specification would have a normative reference that would be maybe our JSON schema maybe something in a different format. We do have natural language specification as well. So these documents, they both describe the state of the current workflow specification, but the primer would explain the would motivate first how all of this is being done. And I know there are a few mentions of why we do this in form of goals or background information across the documents we've written. And it's in as the starting point of the primer to motivate why the specification came about. And then also to motivate the design of the specifications or why we have chosen to describe a workflow of states and this maybe requires us to name a little bit the roots of this specification so what concept. originates from to explain why we are adopting this weird terminology and one could argue that, well, we just sort of copy the Amazon States language, but maybe there is a little bit of background to that so people can build their this this understanding when they start reading the primer before actually diving into the specification. And then we can provide a little bit of explanation of the concepts that are recurring throughout the specification. Because I think there are a few concepts applied here, and then we can also point out the affiliated projects and how we or how the specification relates to these other projects I think this is very important also to show that it integrates into the CNCF and it's not just a project that stands on its own. For example, currently it is affiliated to the cloud events as cloud events can be used to trigger workflows, and also workflows can produce cloud events. This is specifically stated in the current specifications. If I can just can I just jump in for this a second please. Yes, two things for I've been thinking about this primer instance, since the scope of serverless workflow, you know, we have to see is much bigger than cloud events itself it's a format just Jason, however, they also have like 10 times the team that we currently have and have contributed. So I would really if possible put this if you guys agree in two steps one is a short term one is a long term the primer for this specification can be miles long pages long and very in depth if we wanted to go in there where everybody can contribute and we got some people in place like yourself and Falco and others who have very deep knowledge into this to contribute. However, for again going back to this TSC and short term we need some sort of primer for short term and that's why I put in a document we need something to show some background, I think they will look at that. And I think for that maybe comparing it, even stating like you said, yes, our, there is a lot of interest in this there's a lot of different workflows for serverless integration. We really have to say everything why and what was the reason and where, but comparing it two or three things, even if they're completely similar or which might people say they are some not, but giving examples currently in the short term I think is the best idea and then we can move and evolve this document this does not have to be a document that's set in stone right now. But if we can put milestones behind it, like let's say my stone one is eggs milestone two is why and stuff like that within that then we can all involve it but we need something. At the end of the month probably, which I assume we will get the TOC call to actually show and at that point we can just say yes we have a primary it's in its early stages but at least we have it, you know, because this can drag out forever right am I wrong. I don't think this needs to be comprehensive. It's, I agree that we don't need to be exhaustive here and write pages long documents I think books have been written on on this and there is a huge amount of research and but really what we need. What I believe we need to give is some motivation to why we need the workflow specification. It may be why, for example, it needs to be specific to serverless. I had this one comment from Scott that, yeah, why, how is your invocations that you orchestrate how are they serverless is this. And I think he was getting to whether this is just by assumption, or whether there is actually something to the spec and yes we can say there is something to the spec for example our embedding in our, sorry, interoperability with cloud events, something that makes this. Okay, then Scott might argue it's cloud events is not serverless but just by stating that yes. This is a serverless specification language without anything to any reason to why this is serverless we could just name it workflow language. So we need to put a little bit of motivation in here and I think we have all of this all of this has created the specification, which is great. But we need to get people from outside on board and give him a give him a little bit of reasoning for them to get the importance of this. Yeah, this is Falco. I also don't have any ambition to write a book about the reasoning for why we have the separate language. I think we should focus on one concise document. However, that looks like that describes to the to see why this matters. Otherwise, I mean, you know, writing a book about it that's nothing that's that's necessary. Maybe later on, one can have some more explanation the spec but for now. I guess we just put ourselves under some time pressure now right now we will get a slug very well and we need to produce something. Yeah, that was the whole point of this is to kind of keep moving us forward. We have to move forward in order not to stagnate number one. And number two is the main reason that I think and you got I guess this is a meeting for that. We the main reason to even do the specification regardless of we write why this is done like that or the other in much detail is because every month there is a new workflow language coming out and it called themselves serverless. And there is no standardization. So our number one motivation why this is even called the standard is to standardize XYZ 123, you know, so that's kind of like I think for a primer would be right now for the short term, kind of like the main drive where we can show the TSE why this is relevant. Otherwise, we're just one of many, many other workflow languages. However, we tend to standardize things across the board and this is why we're standardization we're not an implementation right here. So that if we can put in the primer as a top kind of paragraph and then evolve it into the future, maybe with some examples between what we have compared to to maybe that's enough for now. Other input model model workflow models, I will be very happy with that right now and then later on we can now we have a roadmap and put it on the roadmap and keep working on. That's good. I mean if we have that as the primer as the first version of the primer that's totally valid right and then the document can evolve. Yeah, I mean I'll be just happy to have it and then then I think TSE will be happy just to see that we're all working on this together and then keep moving forward and every every release we got to focus on also releasing versions 0.1 and I think having a primer is a big deal for that. So if we can have some sort of description of other languages how many that more incoming and why a standard is needed for portability vendor neutral model blah blah blah. That would be very good. So yeah the vendor neutral thing is sort of blah blah blah. If no vendor implements it then why have it so there is it needs endorsement and this is also I think why we should really motivate and give enough background and sure the specification that we have right now we can move this to version point one. And also the timeframe I think it's okay a little bit of pressure is always good. Put a deadline out and stuff will be will be done so. Is there a summary somewhere of what's necessary for this to see submission now that we are on the backlog, like is there any documentation of what are delivered deliverables there. So from what I understand. Presentation. Yeah, I think you if you if you look at the TOC, the governance and the project, how you can go from like becoming incubator project and graduate. You'll find enough information I don't want to discuss the TOC PR too much in detail here. I rather want to focus on what we should put in the primer. And how is it that primer goes into the PR as well or go somewhere separately and gets linked into the PR. Oh, no, no, I think the PR is just a separate process. And at some point the TOC will look at our project. And when we have a primer, it's nice if we don't then. And we have less to show for that's just so it's not mandatory, but there's something that seems to a little bit like best practice, or at least for cloudy when that works. Yeah. Doc mentioned it might be a good idea to have a primer document. And especially because we have some people saying they will do it like a year ago and we are kind of like right now still don't have it and apparently it's an important document that we must include. Whatever. I don't know. Great. So should we do some brainstorming on that. I think there was some something started already. Yeah, let me see if I can bring up the document. So maybe for the people who are new to this today's call was particularly scheduled for a working session on this design discussion or primer discussion. That's why we are not following the the normal agenda that you would be expecting from the regular monthly meetings. Yes, I haven't attended one of Clemens discussions on the cloud subscriptions that are currently also going on in the working group, but I think this is such a sort of breakout to to work on the primer document and I motivate everyone to comment or put stuff into this document. I first I put it out to be comment only but I opened it up because I found that yeah to me you wanted to add something you made suggestions as good I took them also Scott Nichols at a few remarks and one of them was that the document wasn't public and it's not allowed editing so I think I opened it now so everybody can suggest new text for not to clash or let's say for us to work on this. It might be good if we use the suggestion mode and discuss it or maybe I would comment on this and if people sign off then we we're okay with it if people have because if stuff is changing too fast. We lose people on the way so I myself I only maybe I can maybe spend one or two days per week on this at most already a big contribution so regards for that. So yes, I have started with affiliated specifications because I saw that these are very good to explain how the workflow specification embeds into the CNCF landscape and how it relates to two other things. And maybe we want to just don't be asking. Do you think it's good to adopt the the structure of the cloud events primer. I can take an action item and you apply the structure of that primer here. Yep. Yeah, just use as much as you can from there. Okay. It can be a baseline and if we need to change we can change later but that was proven to work. Let's start with that. It comes about with a history and so the history of this document we already have the original design document that Casey, I think she opened it up. At least I have read access to that serverless one function workflow. Design document it. Please try it. It, it's like a primer. It's like, I think it also served as the workflow. Specification proposal and it uses an example and already states what it is that the specification should cover. So, event specifications and cloud events and so on. So, but I, I didn't feel like copying this over would do any good. I will, I would start off with focusing of the current landscape which you've done a great job with carry over as much from the references document that you have already contributed with to describe the landscape. In a second I would focus on and we can go through that if you need to stateless versus stateful. I think that's a big deal because a lot of languages even AWS which is the leader has a separate implementation for one and the or the other. So, that's a big deal I think in the second of course the cloud events integration and not only integration but kind of the tie in that you pretty much have to, if you use events, you have to use cloud events or link the cloud event specification would be a good thing. And then focus in the beginning chapters I would say this is just my opinion you guys can tell me I'm crazy on describing or giving an example like you already have a BPM and to be AWS maybe conductor maybe you know the ones that you have found some good examples. And the another focus that you probably have to put a little bit, can you say, well, can you use other things to create serverless workflows the answer is yes, so we're not saying that there is no other options for designing serverless and specifically serverless workflows. However, given the state of the landscape currently. This is what people are using. And, however, this is why there is no standard and this is why a standard is needed, and kind of leave it at that for version one, and keep moving forward with with description of details. This is my opinion but but you guys can figure it out. I hadn't. I had a feeling that we might want to because there was a lot of discussion on the terminology that this has adopted right the way we called state states and using transitions is also nice because it's in line with the state diagram terminology but Yeah, we call the entire thing workflow. So do you think it makes sense to at least reference these concepts to describe to describe a series of serverless executions because this is what we want right without saying workflow or state diagram or pipeline. What we do want is to orchestrate serverless executions. Yeah, I think that makes sense, especially. I mean the terminology is one part but maybe we should really clearly state under which assumptions we are designing this and also what is the niche we are targeting because you guys keep saying that we are like a smaller targeted language for a particular niche and that should be well identified I think right. Yeah, basically what you can write their manual is something don't quote me but you know Currently you have to look at how people develop serverless applications and you can maybe define even I'll give you I think I did I share the slides from my presentations where they I think when I presented it. You had an example and you can show that similarly to typical applications they're non serverless developers have to write both business logic and orchestration logic in in the same code base maintain it. The problems around that are many the same reason by work was used in traditional development environments as well, but in typically in services you have this code that you deploy their code functions. And again, serverless workflow are specific for those environments to to to distinguish orchestration logic from business logic. So again, we're allowing developers to focus on their business on the core code they're wanting to develop and we're offloading all this other stuff orchestration data management control flow logic. You can say even all kinds of stuff in there from that base development effort the developers need to focus on. So that's kind of like the main topic on on on what we're trying to do and again say yes. That's a pretty good motivation serverless serverless environment where functions are deployed your applications are deployed as event driven applications small ones. So hi this is Jim I was going to make a big listing a lot and I think you guys are making valid points. I think the word when people see the term workflow orchestration they immediately will leap to you know large industrial scale business process automation. I think what you're referring to is really, and I think it's what the previous speaker was talking to you read about functional orchestration. Yeah, or micro process orchestration or something and sort of, if you can sort of couch it in those terms, I think it'll be more understandable and people will be able to reason about it a bit more rather than thinking of big long running sort of business transactions. Yep, exactly. Yeah, I think that makes a lot of sense to really say what is the particular niche and, you know, for example, on the one hand we want to explain the leverage from playing programming or having orchestration and code versus having orchestration extracted into workflows. On the other hand we will want also want to differentiate like which features of, let's say traditional workflow are not covered in here, for example, I guess human task management is something that we don't care too much about. But then we need to kind of prove that this assumption that we are taking a shortcut and making a smaller subset is actually valid and we will not have features creeping in later. Because we missed something and our assumption was maybe too little or something like that. You know what I mean? Not sure, I got your point. But I think the, of course, what we will also have from this is the non goals, right? The non goals and why it is okay to leave them out. I guess that's what I'm saying. Yes. Okay, this is almost enough to get me working for a while. So please, whenever, would you be willing to, would you summarize with the letting the developer focus on the business logic, offload or orchestration? Yeah, I'll help you with this. No problem. I'll put pictures in there and everything. It's just, we need to all together come up with, like you said, like those bullet points. This is perfect. And then we can all kind of dive in and contribute and then get together and talk about it. Perfect. What I, yeah, I think I missed Franco. Maybe I may have missed your point that the non goals we somehow need to make maybe a section for this regarding pictures examples are nice, but I think examples are very, they cover a lot of space. So if we can put this in a short paragraph instead of an exhaustive example, then it would be easier to digest the primer. So as you said, I don't want this to be 100 pages long document. This should really just be a short primer that gives the motivation. All of this and explains the concepts and the backgrounds. This is always, people always say pictures as more than 1000 words. Yeah. And you can, you can. Yeah, link to our use case document. I added some, I think nice looking images. I don't know if they're useful in this case, but you can say, Hey, here's some use cases for. Yeah. So yeah, you don't have to embed them in here, but link to the document will be nice. Just do that. Yeah. And I'll send you again, I'll put it on the channel, my entire PDF from the slides. So if you can borrow any text, anything from there, you're more than welcome to. Okay. I have started this references thing. So, as you said, there is a new workflow spec coming out every week. There is, there are a few projects and I, I don't really know how to rate them by importance. So, Scott mentioned, we should, we should have tecton in here. And I know tecton is a CI CD pipelineing system. And I know underneath it uses K native. It was very present in at last cube con. There were a few talks, IBM and the reddit booths, I think the post promoted it. If I remember correctly. And so within the CNCF, I think it definitely has some importance. There is also a cube flow, which uses Argo pipelines underneath. And what it is, is every step of their pipeline is an image, a container image. So they really model, they build the steps as launchable instances, pots, maybe all containers don't nail me down on the, on the wording. And then they orchestrate or they, they execute this pipeline. It seems very related to, and I know cube flow is gaining some importance, at least in the ML community. But do you think, or is there any project, so we named conductor. And I still have this on my to do list to look at the, which is the open whisk sequence or open whisk function serverless function orchestration, right there conductor. Is there any other project that you would team important. Well, how much work you're going to put into this, I think from the beginning, use the ones where the documentation is really good. Right. So if you look to go to AWS step functions, they have a bunch of examples, some of the examples I even use for our examples, you know, because there there's there, you can reuse it. Just Netflix conductor has one example in their documentation, which is also very good. That is kind of called the kitchen sink, right, where they use everything in every one of their constructs, so pick like two, just two that you can find good documentation for, and put it on there and then let's see how we can all work together to come up how we can And please guys stop me at any point I'm talking too much, but our goal for this is not an implementation based goal. We're not worried about implementation and quite frankly, I recently updated our specification to say we don't care. This whole argument between workflow versus state machine, we don't even care about that honestly at this point probably what we care about is that our specification model language. Can describe what other workflows are doing right because then that's kind of like the goal right now if if some languages out there have much better, much more descriptive manner of doing many more things that might not, we might not be targeting them. But we can target Netflix and we can target AWS 100% currently. So maybe let's focus on those now right and anything about implementation like context instances of workflows. Let's keep that out of here for now, because quite frankly, I don't think we're there yet. I just focus just on the model how can we describe this how can we describe that and then leave it like that. For now, which is invocation of functions alone so invocation of say serverless functions we can we have the your eyes so not even I think I had one. Yeah, it's right here. I mentioned services, but this is not to orchestrate. Or is it is it to orchestrate between functions. And services. And do we do we even make it distinction between something running as a serverless or not. No, whether it is a serverless function or microservice or anything we do not care, we should not even care and put down specific function, or one of the things that our actions can invoke our functions or microservices or whatever. The only thing that we are 100% kind of tied to our cloud events format and that's it. Everything else is whatever implementations want to focus on in this case, because quite frankly in our implementation, for example, we're working on we can invoke an HTTP request or we can call a web hook. It doesn't matter what this function invocation is, as long as it evokes something that you know you see what I'm saying. And it does need to provide a result right. It can if that function provides a result. Okay, but a function invocation does not have to have 100% result. Okay, I find this pretty interesting. So, you know, we say, and I agree with what we're designing here doesn't necessarily need to focus exclusively on functions. But then we are entering in this, the general space of service orchestration. And I think then it will be difficult to differentiate between other orchestration languages in this. So, not sure how to scope this. But we, the way we scope this is by our definition of a function, which has a resource location, right, and parameters so this is kind of like what AWS does to right. I mean, you can with AWS call a service or anything that's behind a, what is it called ARN, right in our, we do not know what that is. So we cannot say, but we don't describe our function execution with a class path. Okay, or some sort of other way we have a specific resource which is a string. We can define further if we want to, how we define this to make this clear. But currently we cannot say we only invoke functions because we might, we might need to be a bit more specific. Currently, the function ref only carries a uniform resource identifier. So similar like in ARN that's not even location bound. So it could be, it could identify pretty much everything. And we're not, so the invocation semantics, except for the parameters that are being passed, they are not covered by this specification. And so you said cloud events is, I know cloud events can trigger workflows and workflows can produce cloud events, but the function of vocation is not using cloud events or is it? No, what I'm saying is the only thing that our workflow definition understands is when it comes to event consumption is the cloud event format. For event states and stuff like that. That's the only bound that we're putting onto implementations because, and only because our, in our workflow model, the events are described using the context variables defined in the cloud event specification. So yeah, we actually tried how we implemented ASL ourselves and then what we wanted to show is like you could quickly convert from a step function definition to running it on our system, but a problem are ARNs, right? And that's why Amazon specific and this you cannot just orchestrate any set of services and functions with that because the ARN eventually you have to translate it to something that is known to your own system. As long as the lambdas are executing on Amazon, that's okay, that works, but And I thought cloud events was helping here for interoperability, right? Yeah, we specifically, if you look at the schema for functions and I'm sorry, this is sidetrack and we can take this offline if you want, look at the type parameter. We in addition to an ARN, which is kind of like the only thing that AWS allows you to do, we do allow implementations to put in a specific type. So if implementer says, okay, this is type is HTTP or this type is webhook, then they can use that in the model to further describe what the source string means. All right. So we do have that little bit of an extension to say that. I think because this is at the boundary of the workflow spec, much like the cloud events to invoke a workflow to produce. I think this is this needs some emphasis in this, this motivation. So just outlining what is the boundary between a workflow definition and and its execution and the outside world. Maybe we can, we can mention this along with the use of cloud events. That's very good. I was from looking at the spec. I didn't see what is actually behind that. What, what this flexibility means that it can be. That's cool. That's, I think that's very relevant. Okay. How do you feel about the concepts that we do. I mentioned event consumption and producing events. There is control flow, definitely. And the use of, for example, that the choice state or that the transitions that's the transitions are something that we have with every state. And I think it has its own explanation in this back. Should we describe the concept of states or pick up the concept of states and transitions between states, like in the finite state machine to motivate the design of the workflow specification language or do you think this is unnecessary. You mentioned earlier that for now we don't care for now we want just something that works. I wouldn't put this whole state machine in there at all. We're not a state machine description to begin with because we cannot invoke any state at any point in time we do have a dedicated starting state or node or whatever you want to call it. So we are not fully a state machine in my opinion. And that's a discussion that like everybody's going to have a different opinion on. I will keep that out implementation implemented whatever however you want, you know, implemented with FL statements. I don't care. The nice thing about transitions is that actually at the end of execution or evaluating every state, we can have a transition to any other state. And a finite state machine, more or merely automata they would define a starting point and then transition to states. The only difference here is I think there can be an end state, but this can go on like forever you could loop on purpose, if you wanted to. And I think what the cloud or what sorry what the serverless workflows back is trying to define is something that is that has a deterministic end. We want this to be some data flow with a result. Definitely I will definitely say that we describe something that has a starting point that has an ending point and is repeatable that I would like put in bold. Because that kind of implies implementation and actually something that can be executed in real life. Because that's what we're doing we're implementing orchestration logic which is repeatable. And yeah, I would kind of put it as a focus to we can be tested easily. We have some states already in place that are specifically designed to aid testing. So definitely, yeah, put that in there as well is something that you feel. What do you mean by testable? I will show one second my computer just went dead. You mean verifying inputs outputs that sort of thing that is also a very nice aspect of the specification. Yes, definitely and also if I'm talking can you hear me I'm talking specifically about, for example, the real estate right. Yes, that's that was specifically done in mind with thinking about testing so you can inject your own data into that you're testing with into your workflow. And see how your workflow behaves in different different conditions that being different data inputs. So that's another thing you might want to if you if we wanted to say that we're repeatable we this is good has testing in mind another thing that will bring into your document if you just want to describe what we're targeting is the extensible aspect of it. So in addition to, and that's something that a lot of people lack and don't have is that you get a model definition you have to use what they give you we also have the extensive extending aspect in our specification where you can define your own additions to the modeling language if you choose so that's similar to what BPMM also has. By the way, is there any kind of available for extensions. Since we are describing in Jason, there is no I looked into that there is no way of doing namespaces, maybe there is that I don't know off that would be nice addition. Yeah, that's what I expected. Then maybe the only choices use kind of naming conventions or prefixes of some sort. Currently, every extension has to have a unique ID. We also have a PR open for metadata, which extensions currently are extension elements you can think of those like, you know, the extension elements like DPSim, for example, but there was a PR to also do a property extension, which is on hold but if you guys want to resurrect that I think it's a good idea. We can resurrect that as well. I'm not sure I always disliked vendor specific extensions. I personally but this is just my personal opinion. I always consider the this standard body to be a little bit of a failure if you have an extensive use of these extensions. So, yeah, I mean, unless the standard can be just taken to the next version to include what people want. I don't see a point in overlaying it with with extensions. I mean, but this is grief but for example the function binding unless we define how any like every different serverless framework can be bound against our function definitions that needs to be some room for technology. Yeah, this is not the same as an extension. So if by function binding you mean the type of function invocation that it is and the realization of performing this function vocation then we do have a type field and everything used in there is already vendor specific but the property extension would be to introduce new properties of states. But for the function itself, if you need any metadata on the function that need would need to go into additional elements rate. Yeah, and usually you have elements where you do not specify further like there is a metadata element and then people can put whatever there or if you have some property that is just a string people might start abusing it to pass what they seem necessary. These sort of things. I don't know if because eventually what you want is to also verify a description and then having it extensible makes it very difficult to run the same verification on it over and over. So yeah, my personal opinion. Really, I don't want to stand in the way of I think first we need to come to a 1.0 and then we can also allow for extensions. Another point if you if I can just bring it up sorry that you can put down there what distinguishes this from let's say WS is that we describe our model via JSON schema. They don't. Okay, Netflix doesn't. So we have an actual schema description of our modeling of our model, which is very useful for implementation. You know, coding can generate code out of it in different languages and just general API creation. I wouldn't brag too much about it. I would consider that a given fact that every standard should do something like that. But otherwise, you know, hard to call it a standard if it's hard to verify and stuff. But anyway, for fair point, let's put that somewhere as a differentiator. It sounds like a pretty good starting point for a primer document. We're also almost at the top of the hour. So I would like to discuss one more thing and that is follow up call and then conclude maybe with a call to action, but follow up calls so this time slot seems to work for everybody. Unfortunately, next week I do have a conflict and you could just go on without me or we find a different time slot now. If you would like to. I'm pretty flexible. If you want to move to a different day. So I think we could use your contribution. You're doing really valuable moderation here. Wow, thanks. Completely agree. You should do this every time. How about moving it later into the evening. Oh, sorry, later in the morning. Closer to lunch for you guys in the US. Anything before midnight CT is fine with me. So I could think of some weekend also decided weekly but for next week would 830pm that is one and a half hours later than today. Yeah, so 1130. I don't know if it eats into your lunchtime. I don't care. It's fine with me but get her to say one more thing before we break. Yes, real quick. Thank you. Number one, please before the end of the month. Please look at the specification. If you understand it if you're new or not spell check it. If you find any issues or problems misspelled words, things you don't understand, either raise an issue or be brave and actually do a PR is mostly for the new people we really need right now. We're in the status where every small thing is formatting making things right. We'll make us look better for this to see a review. Please. I think nobody here objects to Ed Falco who has contributed a PR recently to Adam as a contributor. And for the new people here if you just do the smallest PR, there is any contribution matters and your name will be added to the list of contributors. So you'll have your name somewhere on CNCF. Hopefully soon sandbox project. So if that hopefully it will motivate the new people to look at it and contribute things. Yes. And I just joined the call to action. Please if you have comments on the document. Always just note it down. It's it's better than forgetting about it and then. Not picking up on it. I guess on the editor's side on my end or for someone to pick up an idea, develop it and maybe put something in the document. If some project comes to mind, I think we have already a few just to maintain this as a list also is very valuable. I think to show awareness of the world and not do our specific stuff here that is very niche. So please, whatever you feel like should be in the document. Any valuable comments always very, very appreciated. Okay. And then yeah. Any other business. I guess not have. Okay. No additional participants. I think we can conclude this and I'll send out the invite also for next week's meeting Monday 11 30 Pacific time or 8 30 p.m. Central European time. Thank you very much. Thank you. Bye everyone. Bye. Hi.