AsyncAPI Related to AsyncAPI Spec 3.0 release, 15 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Spec 3.0 meeting (February 15, 2023)

Description

https://github.com/asyncapi/community/issues/587

A

Hope you're ready because you have no choice now I forgot to ask.

A

I'm, just forcing you.

A

I know we're live nice welcome everyone to another spec 3.0 meeting, one of the last ones before the freeze. Actually, maybe.

A

The last one I can't remember whether we have one more before, let's see so.

A

um Does anyone have anything they want to start off with before jumping into the agenda Samir? Maybe you want to introduce yourself to the group.

B

Yeah so I'm a newcomer in in the smkpi postman side I'm here to to help the team and support them with anything related to it's. A Engineering Management um before I was uh um helping different organizations with their API program and strategy, and they will also contribute to a Sync API initiative um yeah. So I'm I'm really happy to be here with you guys so and uh I will just listen. I will learn from you guys and and see yeah. What I can help.

A

A

Thank you. Does anyone else have anything they want to add before.

A

No right um Lucas do you want to take your issue first before I can kind of recap afterwards, because I think it's a bit more important to bring that up.

C

um Yes, I can nice, um so maybe just a context and the issue that uh Jonas mentioned um so last time uh during the meeting we discussed I think at the end of the meeting, one topic that is concerning uh for uh three zero: if you should take it or not, it was related to schemas um two things in schemas.

C

First of all that there's no support for Proto or xsd or any other stuff that is not supported by a dollar ref and the other one was that currently um you can put schemas in components only if these are awesome, API schemas, if you have Avro or raml or open API or Json schema, um you cannot put them in components.

C

You can put them in separate files, of course, but you can't put them in components: components on the support, doesn't API schemas, um so I basically promised to Jesse that I'll take a look into the pending issues. We had related to it. So I'd like to talk about it now, but so that's the context in loud. Let me know first, maybe share a screen, so you have to give me a second because I wasn't I didn't know that I would show it now, but it's.

D

C

An excuse I wouldn't be prepared in 30 minutes as well. So.

A

You should have access to that.

C

Okay, I think I have it uh where's the bottom.

D

C

That's this, the one yeah. Can you see my screen.

C

Okay, so that's the um that's the issue I was checking out and where we are because, um like last time when we talked um I think the conclusion was that um adding support for Proto or or xsd or any other, not dollar ref supported formats is like in, like there's a high probability that it's not going to be a breaking change. It's just gonna be another feature. So that's why I was just looking into like from all the list of different issues.

C

I was looking basically on Old proposal from uh from Machi that was focused, I mean the discussions in the in the in the issue. They um drifted to some different topics, but, like mainly main goal of the proposal, was to actually support um different schemas in um in the components like different um schemas than async API schema, which is a superset of Json schema.

C

um So the the summary.

C

The summary at least my feelings about it is that I think we have to address for 3-0 um this issue.

C

um I, don't think, there's a a way to solve it without breaking the spec, so I think we should use the opportunity to uh to basically break this back uh now, because 4-0 I don't think when we'll find energy to work on 4-0.

C

um So um that's the I'll just share the final example and because I don't want to make it a boring statement from my side, so I'll just make a go through. The final example uh that I just read before the meeting changed from two zero to three zero and I'll. Take comments from there, so example shows um I. Think it's one-to-one actually proposal from Machi.

C

So basically the idea is that, like So, currently in payload, um do you want me to show current as well like next to maybe I'll? Show you one next to each other like do you prefer me when I'm gonna show the proposal and how it currently looks like in the.

D

C

I'll, do it yeah.

D

E

D

C

Is it still readable.

C

Okay, cool um I think I will be.

C

A good example: okay,.

C

um I mean I applied here, 3-0 structure, but like um what actually matters is the messages that um uh did not change much um in the in three zero so current. Currently, when you go to uh channels use a message, so let's take a look on the structure of the message.

C

um The payload is directly a schema right, so in payload you you either use a reference to a schema or you inline the schema directly um and then the same or the same as in in schemas in components. You just have a um it's a map of um string key, which is the name of the schema and then the and then the schema itself so far so good I hope.

C

um So the idea from Machi and correct me if I'm wrong but I, think it's the same as as you proposed, um so the payload, um or something that you don't see in this examples. Or do we have have row here.

C

uh Let's go to message again.

C

Oh so it's Kafka example without Avro, um so normally uh like majority of people in Kafka use Avro, um so what they have to do if they reference payload, that is a Avro payload. They also have to specify here a property which is schema format.

C

And yeah, it's excuse me um about my uh sound, so the the schema format um you specify like Avro, whatever blah blah blah the long string that I will never remember how to use or actually I can copy it from here.

D

I, have it here.

C

And it's uh is it.

C

Why it's showing the error.

C

What a known type.

A

Object: it's it's because when you I'm pretty sure that studio validates or the parser validates the message, payload.

F

Yeah, the Avro yeah exactly.

A

F

Define the average, but you define the Json schema. You have invalid cover yeah.

D

C

Oh yeah I'm not going to be able to use it because it's not possible um to inline afro in components. um So let's just ignore uh the arrows. Let's assume they are not there. The most important is how it was in the previous version. So um on the same level as payload, you specify the schema format and that's how it worked now.

C

The the idea of The Proposal is to have um actually so oh yeah and important to know that from the spec perspective, um this is called schema object uh if it like, we use terminology from the from the spec, so um you can have in a payload. You specify a schema object, but the idea is that a schema object um is not a async API schema, but schema object is an object with two values: schema format and schema. So, basically, schema format.

C

Moves inside the payload and payload is not directly a inline or reference to a schema, but it is a.

C

um It is a an object of with two keys schema format and then again you can put the schema so, like one level level further, you put the schema and in case of components the same thing. So you have ski mask key and then directly you don't see schema, you just say schema and if there's a schema format um needed, um you want to specify it's because it's specified, because it's because it's Avro for example, then you put it next to um the schema.

C

So that's um that's the um the core of the idea, um so schema object is not any longer a async, API schema um um and um and what else and yeah and the what we knew as um schema object. It becomes literally a async API schema object, as it's described in the in the spec and yeah the only disadvantage.

C

um We could say that it's a disadvantage, but it can be fixed with tooling. Is that the reference? Then, if we reference a um oh, actually, that's a I quickly, fixed it. But it's an error.

C

So this is actually um I added it later, but yeah. So basically, if you can see um the reference when you reference a the whole object, you points to a um to the whole schema object. But if you um the the disadvantages.

C

When you want to reference to a specific schema, so um then schema.

E

Yeah I guess the disadvantage is when you want to reference between schemas, so you have one schema and referencing another one. Yeah.

C

E

You basically yeah.

C

So, like you cannot have an a magical solution that can take the name of the schema from the reference um but like we anyway have these issues now with Anonymous schemas, and we anyway can uh in the tooling, assign the IDS like X parser ID, whatever extension to the to the schema, so I don't believe it's a it's a huge um huge problem, the huge disadvantage.

C

So when I, when I looked quickly on it and I, think it was reviewed by many people because, as I said, it's an old uh proposal from uh from Machi, so um I haven't seen anything bad about it. That would make cause issues and um the advantage is that like um then it's it's still ready for adding any other support for Avro or for Proto or or whatever else we want in the future and before I I. Let others to ask questions like Machi. Is there anything I'm missing?

C

Do you have anything to add to this initial proposal of yours.

F

No, but there are some problems that yeah maybe discussed later.

C

I mean other problems that the one with the reference I described or.

F

uh Yeah to to another problems.

C

um So maybe like I, don't say them now and then we.

F

Yeah: okay, no problem um because we had the discussion- uh I, don't remember when, but in previous meetings, maybe maybe in the previous year that the first problem is this nested uh referencing, yes, I mean if you want to reference the another Json scheme, another schema from the component schema. You need to use this schema, suffix, yeah.

D

F

You cannot use the schema with the schema and schema format instead and another problem accept payload message: payload. We can also use the schemas inside the headers and it need to be the Json schema, and people can think that. Okay, if I, can Define, for example, davor schema Ram inside the component schemas, maybe I have also ability to use the reference in the headers and also we have the parameters.

F

Channel parameters where you can also Define the schema yeah.

D

F

The next the problem, some some fields in the bindings like in the Kafka Kafka key as I remember- can be also described by the schema. Okay. So that's another problem that people probably think okay, if I use the Avro in the payload I, should also be able to use the Avro in you know the bindings or maybe also extensions, yeah and yeah, and that's the part I mean it's not the problematic in this way that if you define that in the given place, you can Define the schema yeah schema object.

F

You should be able to Define all formats, not only the Json schema and in payloads all, but in every place, yeah or format. So yeah. You.

C

Mean like for consistency, wanted yeah.

F

Exactly for consistency, yeah.

C

But would will anyone use Avro to describe headers, you think or parameters.

F

By, therefore, you can also describe this, you can use the type record. Fields describe the strings. Yes, uh but at the end, after parsing you will have the decision scheme, which will be the type object. So at the end, yes, you can also use them.

F

It's the another representation of objecting.

E

I mean with headers, it maybe even makes sense we let people use Abra or any other format to validate headers just for headers, um because it's part of the message it's the same as at the same level as a payload, maybe so so yeah, but for Channel parameters. For instance.

E

What I will do is uh we I will not support um this new schema object, but instead I will I will support just whatever you call it. 18 kpi schema object, or you know the the Json scheme, a specific type. You know like the one that we're using now right, so I will limit it. The one that doesn't have a scheme and scheme format inside the one that is in schema directly I will use this one for the channel parameters and I will make it clear like no.

E

You cannot, uh you cannot use, um or maybe we make it clear. You can reference. This kind of new schema objects with schema format and schema keys, but um we make it clear that only Json, schema or type of Kinder Jason schema that we have uh it's supported right. So.

A

What's the what's the reason for constraining parameters instead of and not both parameters and headers, to keep it simple? Basically,.

E

Because uh the parameters is sent in there, um it's strictly related to async API in.

D

E

Payload, it has nothing to do with its kpi. It is something that might be shared with other systems. How do you define your message in other systems like a schema registry, or something like that? So you might want to use schematic registry definitions using Avro for the headers and for the payload, but no one in the right Minds right. They will use a schema registry to define the parameters.

E

The you know the channel parameters because yeah it's it's only a concern not facing kpi, not it's not in any other tool in other in any other spec or anything right.

E

But you know, but headers and payload are a it's a resource that it's shared across multiple tools and services and included, including that uh you know the schema definitions, foreign.

A

Thought was that it was getting really confusing when you had to explicitly know in which parts one format was supported and where another format was not yeah like from from a from a user that probably haven't seen async API before.

E

A

D

A

E

User that haven't seen I think you played before it's going to be confusing for sure many parts of it. So that is not really um just not really solving anything.

B

Yeah, how many variation we have like how many formats we have uh like from your experience, uh do it like? We can have Avro and Jason schema in the same time, or we have only one single type of performance.

E

Usually, it's just been simple types, so whoever is using ever is only using abroad. Where he's using. This is schema.

E

They're probably um I mean there might be the case where some people are migrating from one um language to another and they might end up with a mix in the meantime means, while they're migrating from one to another. So.

B

Is this something that can then be defined at a root level like to say, okay I'm using overall, then it doesn't mean that you need. You need to have a per payload and I'm just asking. If is it.

E

D

E

Could be defined that uh Road level for the whole document, like.

C

You do with actually the entire default schema format.

E

Default schema format.

A

I think we have defaults.

E

D

C

E

Yeah but yeah that's a different, so so yeah so I mean in many case. We could have it as a proposed to important, like that's true, so that that will also probably help and that's another idea that we redefine it on the levels. The whole document will have to be either everything about Abra or everything about business, schema or everything about whatever format. So we don't have to be, including all this things, but.

A

One of the cool, but one of the cool things is that you can mix that you can mix them if you have different definitions of those types of components, because if you have an application that both uses rest and Kafka for example, then you might have a mix between open API components and Avro excuse, and you wouldn't be able to do that. If you just limit it to just one specific.

E

F

But we are talking about the one of Massachusetts and we know what now.

A

We're talking about having something like a default one, that's supplied across all.

F

C

For now, maybe, like so I, don't recall anyone asking for like having default schema format, but maybe they use they solve it with trades. They just have a trade where they specify schema format, and then they apply the trade everywhere.

F

But still you need to apply them and that's the problem yeah and we're there. But still you need to.

E

Target this you seem to have to grab it.

F

Yeah, like great content like this, you need to write in every place, content and, if you don't have the default content right here, actually.

E

If we put it on the root level, a default schema format, not the default, we will call it default. We call it schema format right. So this is the one that will be ruled for the whole document. You can never write it on any single level, not like the content. So it's like this is a schema format. Then we will not need schema format and schema inside the payload or inside the schema definition.

E

We will admit that we could continue as it is, and the parser will interpret this this objects, depending on what it says on the root level. You know it will enter predict, that's the schema, uh schema object or Abra or whatever, depending on the roots field right. So it's a little bit less flexible, but the reality is that maybe nobody needs so much flexibility or.

F

Maybe we should touch something like the validation rule. I mean that you cannot Define, for example, payload in different. You know, format done, Json skimmer of Ryan.

A

I mean you could always offer it as a validation or I. Guess a spectral rule if you really wanted to as an end user, yeah.

F

Not not do you know more, this restricted specification in this way.

C

Just to clarify so we're talking now about default, schema format as a alternative solution for uh having support for afro, for example, in components.

F

Nope, you still need, for example, for channel parameters. You still need the Json.

D

F

C

F

Does the problem yeah because.

C

Channel parameters, they're, not a concern.

C

Why I mean it's just one schema adjacent schema, so we I mean we still have to have a pull request and fix it in the schema that it's not schema object, but Json schema object, but it's not related to the core issue that in.

E

Complex, it is because you cannot put them on their components. You cannot reuse these definitions. If you have multiple Channel parameters, with specific thing that you wanted to use on this schemat and component schema, you cannot put them under other component schema.

F

Or maybe maybe maybe we should have something like the schemas in components and payloads. So the palette is exactly the special schemas only for with this schema format and that's it. The.

E

Payloads will also be for useful for headers or.

F

Maybe yeah I mean, maybe you know the pillars.

E

F

E

That's the problematic.

F

Yes, because if people really say, okay, I can Define Avro in component schemas. Why I cannot use that in you know the the part Channel parameters.

E

My question is as well like what what is the? What is the probability that you want to review stuff on on components, parameters so think about it, like you, probably have a bunch of things on the components on the on the parameters, the material parameters, uh a bunch of parameters that are looking mostly the same or exactly the same right and uh but they're all from they're all scholar, values right, so they're strings, they're numbers, it cannot be an object.

E

It cannot be an array or anything like that because it needs to be inside the strings there.

E

um It has to be probably a string, a set of allowed strings, a string that uh has some bubble applied to it, uh um a number in between limits, something like that. Scalar values right so so, and we have components parameters right. So if the parameter is the same in every we do right, I think yeah, I.

A

E

Have components parameters so if we have four parameters that look the same, let's make them point to the same, parameter under components, parameters. What is the probability that one of these parameters inside inside components parameters is going to reference as schema on the under component? Schema? It's really.

E

It's really weird I, never I've, never seen that I've never had this need right. So probably we are over thinking the the parameters one here and we don't need to reuse there, because it's not uh we need to reduce, but the whole parietal, not chunks of of the parameter right of the parameter definition.

E

So I don't know, am I I, don't know if I'm, explaining myself enough I can I can type an example if you want, but.

C

Yeah, but what are you suggesting to do with like in we have in variables in server that we just specify which what are the limits that you can specify in them, that you can specify default, that you can specify const and string? And that's it.

E

Well, that was my suggestion as well, and another is that we don't accept schemas there, that we do some kind of just the subset of schema and we only allowed certain things that we're in there. But if we don't do it like this, in any case, we don't accept emails on the parameters. What we accept is a parameter.

E

It's a channel parameter which is under component components, parameters and that's completely another object right. It can be exactly what we have now as a schema looking the same, or it can be just as subset that we pureed on purpose just to make it limited subset of functionality.

E

But um but my point is in this case, it will not impact the issue that we're discussing here, um so that will not be an issue we can. We can still change this in any way that parameters will not be affected.

E

I'm, not sure if I'm, explaining myself correctly, but is anyone lost here want to you want me to explain it better or something.

E

Okay, I have the feeling that we mentioned in a bunch of parameters, schema schemas parameters.

A

Yeah I mean the bottom line is that schemas are used across multiple properties right, it's not it's, not just payload, but up until now pale payload has been the only one where you could specifically decide which format to use so headers and parameters is not something that you can explicitly state that you want to use Avro as the schema format for defining what a parameter is or what a header is.

A

It's always been. The default async API scheme, object, I. Think yes,.

C

And we're basically saying that there would be a need for something like limit string. Only limited Json schema, basically yeah.

E

String or number or.

D

E

Yeah, maybe we want to include booleans, but yeah Boolean can be a string with true.

A

The reality is that it's only becoming a problem now, because we want to change how a schema looks, how the default schema formats or the scheme the default schema object, looks like where we want to merge both schema format, the property and the schema property together and form a single object that we can use in the component section, and the problem is that parameters and headers usually always reference down there as well, and that creates a problem, because, if you do that, where you reference a parameter schema in the schema section on the components now you have, the problem of you can also choose which schema format to use which was never an option before which now creates this kind of confusion.

A

E

But if we reference instead of referencing from the parameters, if we reference uh the components parameters instead of a component schemat, then the problem is gone right and, of course, component and components parameters. You only support one kind of schema, which is the schema that we support right. There.

E

A

E

Headers we said before, like headers in the same as failure, people want to Define them as other or as other right.

A

Okay, so you're talking about whether to limit that properties can only be referenced but not their schema.

C

What do you mean by reference.

A

So at the moment you can both reference: a property, that's under the computer, like the same that you have in studio at the moment where you have the street street light ID parameter, but at the moment you can also reference the schema of the property or of the parameter. Is that what you want to limit? So, instead of having a reference there, you cannot, you can only specify a schema or.

E

No, no, no! No! You can, but you cannot point to component schemats, because it will not be the type of schema that you you can put there right. It's not a valid schema, because that schema that new schema that we're introducing will have schema format and uh and the schema properties right. Instead, what you will have to do is reference from there from the line 147 in in that example, on schema, you will have to reference there uh some components, parameters right, which will be defined as the current schema that we have right now. Yes,.

A

D

E

Can reference, if you want you, can reference using the trigger slash, schema, uh let's game at the end, but only it will only work if it's adjusted schema definition right.

A

E

You know so so you're risking basically that at some point this stops working. uh You know like you're, not pointing to the right place. I think parameter definitions shouldn't be there so they'll, be um uh they shouldn't be on the on. Under um this definition, shouldn't be on the on the can I say.

B

E

No I think yeah I, think I know what you've been saying there.

D

E

Said yeah, you cannot reference a whole parameter here, because the whole parameter is description, schema and all this stuff, so so yeah. So probably what we have to do is we have to.

E

We yeah, you have to replace description, schema and type string there for a whole lot of to the parameter.

F

So also merge the schema of description. Yes, I mean in the same level or what.

E

Which, in the end, it makes sense, because it's already there right so student will also have a description.

D

E

Already faced that problem on the on the UI, when we referencing documentation, we have to check if there is a description field like the one on 146 line um or if there is a description field inside schema.

F

E

And then, in this case, which one is the description but.

F

We have still problem with this location, I mean equal, so it I mean location of the parameter.

E

Itself, it would be just a uh an object that we create ourselves like description, the type which could be string or number uh probably so.

C

So exactly exactly.

D

C

E

Exactly exactly which.

F

E

Parameters need location like where what is implicated. Maybe it's on the headers, it's on the payloader, so yeah.

C

So basically, basically you mean extending parameter object, flattening it yeah.

E

Flattening it and making it look like the server.

C

Like the server object, yeah.

E

F

It was everybody yeah foreign.

E

Yeah, we can add pattern we can use. We can get. uh You know the stuff that we know that is going to be useful, but then we don't have to deal with things like uh it might be an object. It might be an array, it might be a Boolean like how do you see her like this right? So um there are many ways to see your lights on that right and right. So how do you signalize this interesting um then and we're not defining this now?

E

So maybe we should simplify this object as well, because think about it. In most of the cases it's I wanted to be I wanted to be a pattern. I wanted to be a set of specific. uh You know right or options um a number in between two limits.

E

um I, don't know something like that, but how many times you will want to do more context that there on the on the channel parameter I, don't think we need it so probably, and if you need it, it's cool, you can request functionality there in the future and we'll add it, and it will not be a breaking change to the real extension. So we can keep adding more stuff on 3.1 3.2 if we forget about something right so so that can be. That can be done.

E

uh Basically, we probably have to see we we have to forget about uh Channel friends in this discussion in this whole discussion, because it doesn't have to be as clear it doesn't have to be pointing to schema at all right. It's sold them. It's not needed like we don't have several variables pointing to schema. It's not needed so so if we ever have a problem with what do we do with with the channel parameters?

E

That's not a problem anymore, so we eliminate this from the instructions.

E

Now what we were before is we have two ways of doing this so far, which is, we include, schema format and schema in each of the schema definitions all right or we make a default schema format or schema format at the root level right, and it's the same for everything in such a case. If we make it the root.

E

What if we reference from this file, we reference as key man defining another file, um I mean if they're not of the same format. If we're mixing the average schema I guess it will fail. So it's up to the user to make sure that, across reference between documents and.

D

Maybe only the default schema I.

F

Mean that you can overwrite it default, schema format.

E

To have I mean we do have default schema format, but if we- but that's the same as this proposing schema, the cool thing that I see about having this Global schema format on the document is that we will not need schema format, schema format and schema properties.

E

Everything can be put directly as it is right now under schemas component schemas. You know, as it is right now, because the type will be driven by the other property.

E

It's it's cool and yeah, that's and and on on the other hand, is a side effect that many people might not even expect right that um it's something that is defined somewhere else not even related to the schema definition and it's affecting the scale of definitions. So on one hand, it's like it's good, it's convenient and, on the other hand, it's like careful look same as with content content type right. We call Quantum type, but yeah.

F

E

Just summarizing it yeah.

F

We can fix that parameters, yeah I mean, but the problem is that, for example, here I posted in the chat in the zoom. But now um we support Interlink the parsing, the average schemas in The Binding scaffolding and my question. The people will also be able to use that schema format. The another one from Jason schema, invitings and extensions, because in some places you need in HTTP binding. Probably we have some place where we need to define the the Json schema, but.

C

But also for for the bindings it's going to be. Actually it's going to make bindings life easier as well, so uh there just like they reuse, schema objects. They can reuse the the.

F

C

That will be created for um uh for parameters or whatever so because the thing is like now, even now in the um The websocket Binding um yeah, you have the um it's not called path. I, don't remember. What's the name so like basically in The Binding, you can specify something that you can't do in the channel, which means the you know like query parameters, yeah, that's what I meant and.

F

Yeah, but if you need to Define, for example, validation, rules for some shape or something you need to Define, also, the object and array.

C

I, don't recall if there are any validation rules, I, don't think there are, because you don't have a message there in The Binding it's on the main spec level. So when you when it goes to schema object whenever it's used in the bindings or Kafka or or websocket, it's mainly for this simple values where, in the end you just use const or you know, and and nothing else,.

F

Like it can be, but you.

C

Know I mean why would.

F

C

Again, like it's the same situation like with the parameters like, why would you use uh type object to describe the um I mean I'm I? Think I did it in one of the examples but to create to provide the descriptions.

E

In the case of query parameters, it makes sense to have type array and type object, because it can be serialized Superior parameters. There are actually I think two ways to do it. Yeah.

F

Yeah and still but but you know the extension to, for example, to allow some uh this one, the tool.

F

But this explanation, so you can have everything you you want to and that's the problem yeah so.

C

We should clarify.

F

It schemas should be only written in Json schema or can be written in another formatting. You should clarify in the specification what schemas.

C

You mean exactly.

F

I mean extensions, for example, some extension in some field needs the the schema object has to Define, and then we need to clarify if, if someone, the creator of extension, yes want to add the schema object in some field, it should be the Json schema or can be the another format.

E

But that's actually the extension created right, yeah.

F

But then, how to you know handle that in the password in the tool, so.

D

F

Can say: okay, the the extensions is, you know, treated as the plane Json, yes, and that's it. We don't.

E

F

Any operation of it, but.

E

For extensions I think we had plans to incorporate like another format, to define the extensions.

F

So then you will have a place in.

E

That format in that place right, we will have a way to say this: is a diesel schema object, and this is the number object, and this is an acpi schema object or you know, like uh the Creator, the extension Creator will be able to say I want this to be of this specific type. That's how the parser will know how to particle right so because it will be defined there.

E

So I, don't think it's related to that. You know it's a kind of a problem.

A

From from a validation Point as well, it's rather easy to adapt the Json schema documents. We have to conditionally apply different schemas. So if the schema format is several, it's validated automatically against whatever Avro defines, and otherwise it's the other format. So it shouldn't be a problem. Yeah.

F

D

C

Yeah, basically, bindings have to adjust if we make a change of the schema. Yes sure as simple as that um in case of extensions yeah like they have to specify what like like extensions for me, it's not any different than bindings anyway same stuff, um but now I. What's the conclusion, because I lost you front when you were talking about this alternative, some solution with components, I didn't get this one. So.

E

Yeah, what I would say what I was saying before is that now we have two options right now, so one is the one that you send this in here that we have on screen and the other one is that the one that Samir suggested like? Why?

E

Don't we have it on the root level like we have schema format on the root level or the positive for not default, schema format but schema or root level of the document right, and if we do it like this, as somebody is saying, we just have to keep everything as it is. We just need to I mean the structure will still be the same, because that schema format will not have to be carried over the message, definition or the failure definition. It will be on the root of the document said.

E

The structure of 18 kpi will do the same, but the parser will have to look at the silver formaterial to parse schemas before, of course, so.

E

That's it but I think we have these two options so far, I was I, wasn't.

C

So but it's called like defaults component, schema format right or or it's a document on the document, level or components only for so.

E

It's saying to the document level: yeah components is for usable stuff, so it will be along with default content type and info and I think API property the most at the same level. On the root level, you have something called schema format.

E

Or message schema format or I, don't know whatever name. We can come up with it's a little bit attached from its origin, but makes things simpler. I have to agree.

C

But then you're locked to one format in your.

E

Document then you're logged for a single format. Yeah, that's the only limitation, but, on the other hand, is like how many times do you encounter people using multiple scale, foreign.

C

For the payload and passing API schema for the headers.

E

C

E

Headers and payload will be will be possible to Define both with you know, I mean unless yeah they will have to migrate them from the other side yeah before using the secretary yeah, that's not going to be flexible.

C

Yeah I mean not many people in like in production; people, probably don't in line too much. They reference yeah.

E

Exactly yeah yeah, that's the only problem that I see that right now the people that already have a bunch of executive documents as indicate two documents: they will have Agra for payload on their schema registry, and this is schema from the headers and they want to migrate to version three.

E

If we go for the solutions that we propose, then they will have to migrate all the things on their side. First, before referencing, either driver or to this is chemo. They would have to unify everything um as opposed to this solution, which will allowed them to to just point out to whatever they have. It will be adopting so yeah. Well, no, actually, no.

A

So that that recap makes sense, Lucas yeah.

E

Right now like on payload right now, if someone has.

D

E

Pointing to the schema registry right now pointing to an agrofile they will have to migrate in any way they will have to migrate their definitions anyway, they will have to add schema format and schema at the root at the root level of their definitions or add it here and move the dollar rep below the schema in a way.

C

They don't have to change the schema all right. That's a that's! A big difference.

E

They don't have to change the schema yeah yeah, so yeah I, don't know yeah.

E

I have a favorite, but.

E

um What do you think.

C

I mean I, don't like with default solution that we're looking like this. We are solving it.

C

Just like for a few cases like it's not a it's, not really a full solution.

E

That's what I think I agree that if we like this, this way that you have on screen is looks worse to me, because you have to repeat this all over.

E

Maybe we can complement this solution that you have here with default, schema format, so you don't have to repeat all over the schema format- property right in case it's abroad, all the time, then you can put it on the root on the document default, schema format to abroad, and that's it and you don't have to repeat form at.

A

All in every place, yeah so same behavior as content type exactly.

E

Same behaviors, if you want to override it, you still can but um yeah. We can complement it. Yeah.

C

D

C

Is the default schema format? It's a a feature: non-breaking, yes and the other ones.

E

Well, it's well well, if it's breaking no more I.

C

Mean you, you have to add it to use it, so it.

A

Acts it actually would be a break.

E

No, no, it is not. It is not if we make the default schema format to what it is today,.

F

A

Using it would break your document.

F

But it's a feature flag.

E

Yes, we're using it, we might break your document, but I mean like anything else right because, like content type, for instance, if you change it, it will break your decorative yeah.

A

All right, five minutes more.

C

No I have to go to another meeting, damn it.

E

So yeah, uh let's, uh let's not I mean we don't make decisions, say no, no pressure. So just uh let's just continue to discussion on the on the issue and let's try to be to have it to make a decision before the end of the for the end of the week, if possible, because we don't have much time left.

F

But about these parameters, we have another issue here: I posted.

E

Yeah yeah, okay: it was a globally address this one, okay yeah that will simplify lives in this regard, that if we address this problem or not I, think making parameters easier simpler. Let's say it's gonna be helpful.

E

All right, and if someone we can still leverage this and scheme on the on the coolant side. Even if it's not a property system, we can just create. On our side, we created the system and document type whatever we find there, enum, whatever we find there and so on, and it will validated and fragrance.

E

E

B

It will be interesting also to see uh from the like migration cost perspective like in any solution that we Implement. What will be the impact on the user if adopt the solution right.

E

So far, it's a huge cut, so really migrating conversion. Three, it's going to be a huge press, so you can still.

B

Make it I mean not implementing this feature, but what will be the added cost? So we already know that we have a cost and they yeah it. Can. It can also help on the decision making, so how we can make it even easier. uh No I mean not make it as complex as like. Moving from version two to three like.

E

A

Isn't that always a balancing Point anyway, like when you do breaking changes, do something that kind of rocks the boat? It's a balancing point between whether it costs a lot to do that specific thing or if it's good for the user in the end, because they might not be exclusively uh separated.

E

And right now the solution that Lucas was proposing. It might have a migration cost. On the user side, you might want to migrate every schema they had on a schema registry, but they have a limited solution, which is they use our uh converted tools and our they have a dollar rate pointing to a schema registry.

E

What they will, what the converter will do is they will move the dollar rep one level deeper inside the schema property right, payload schema property, but so whatever you have on the consumeration doesn't have to be migrated at all, as opposed to, if you have it on the root level, for instance, and you force everyone to be on the whole document to be on the same um on the same kind of format.

E

If some people have and I'm and I'm sure that some people have like this uh headers as using schema and payload as ever, then they will have to migrate everything that they have on the distance on the schema registry side to one of the formats, so the cost is going to be higher in that time in the case for all, but only for those for for everyone else, who's not mixing formats, then because it's going to be much less because yeah, like um yeah everything is as it is.

E

You just need to add one property on the top of the document or not even the edit. If it's the default, you don't have like content type like default content. You don't have to edit if it's the default default content.

A

E

A

Of speculation.

E

Yeah, so it's like yeah, it's always people, because we don't have numbers. So at some point we might start getting some numbers on how people are using it in kpis and then we can. We could calculate the cost, but right now, I'm, just guessing I'm, assuming that most people who are using Kafka are using Abra I'm, assuming this and I'm, assuming that they that they have Jesus schema either in line or reference on the schema live stream uh for the headers.

E

So in this case they will be looking for two and Kafka is a mayor? Is a mayor play in here? It's one of the main principles and the main formats here so I wouldn't be surprised. If that hits I, don't know 6 60 going 50 of the cases which is supported.

A

All right time, any last remarks or getting off.

E

Yeah I think we have a few conversations depending you know before the end of the of February and- um and this is our last meeting next, one is already on March 1st. Yes, so I think we should have this meeting again next week.

A

Suggested and I created.

E

Because yeah or we agree on a on, uh you know I'm postponing the the March first date the code freeze on the spec a little bit more until we fix this, and we agree that we just need to fix this and then the last time.

A

Well make a suggestion, rather than slack or GitHub issue, and let's take it from there I thanks. Everyone see you next week, bye, bye, bye, guys.