Open Telemetry Uncategorized, 15 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-11-15 meeting

Description

Instrumentation: Messaging

A

A

B

A

Hello nav good morning.

C

A

We can get started, I I, don't know if Ram or Martin are going to join.

C

Yeah Ramsay is going to be like 10 minutes late.

C

I guess we're going to go back another four minutes: okay,.

A

Yeah we can talk about his PR when once he joins, I have a bunch of questions on that.

A

But we can talk anything else, yeah.

C

I I haven't read all the comments. I I know we had a quick think in apparently tigrant saying we don't want to Define them here, but we will need to Define them some way.

C

um I haven't really made a lot of progress in the last week, considering I'm on holidays after this week for two weeks, um so just uh I've got a work colleague who's going to be taking over the the internal staff, while I pivot over to open Telemetry I'm, just trying to like solidify all that stuff before um before I go into on leave yes they're, currently out at the moment. So.

A

D

A

We can talk about the event.data um PR that you have yep um I I, read uh um quite a bit about Cloud events.

A

um I think it's uh it's good, we're aligning with the cloud events.

C

Yeah I do as well like, even if we go even further and say: okay, we're going to adopt Cloud events except we're going to like event dot prefix on the front of the I, think that would actually be a good place. You know for us to be anyway, yeah.

A

um Although the purpose of cloud events is is very different, um it is at least reading the documentation. It looks like their intention is to connect multiple Cloud providers.

C

um Yeah, but if you look at all the fields, um they're really it's very generic, so like it'll serve our purpose as well as a bunch of others um and like there's, there was a okay uh Ron yishi uh like in the spec meeting last week, I think it was, um they were proposing to effectively create a payload uh attribute um and I I brought up Cloud events and my event, data thing and they're now sort of aligning I think he even left a comment in the pr as well, because they have a payload.

C

So you know it's it matches in really nicely because they they wanted a generic binary payload, who.

A

C

uh Let me with this I just had the spec One open. Let me go back to last week again.

A

Oh, that's in the spec PR.

C

uh Not in the specifications um see uh two weeks ago, not this week but last week, uh but I think he did leave a comment in my PR. uh uh Where is it here? 11.

C

D

11 h uh working group.

C

C

Apparent base, where are you I'm not seeing it here in Windows, search, even discuss there? It is uh so 219 and it was one.

C

I think also linked it as well.

D

And take this question.

C

Yeah, that's the one okay, so let me drop it from the chat.

C

Yeah, so this was their PR um originally a couple weeks ago and I just linked it to what we're doing is the the payload and he came back um on slack and said yeah. He actually agrees with my feeling, for that is looking to move forward with it. So.

C

um And we I was hoping hope, it's not a plan, but I was hoping that tigrin would have had a little bit more comments, but maybe he's waiting for the log Sig um Assuming he's even had a chance to go and look at Cloud events um because yeah like if we can say we can form to basically the cloud event shape it.

C

It takes us quite a few steps forward from where we are and when we go to take it to the spec group and say this is this: is it we can just say well we're aligning with that I think the argument's going to be a little easier.

C

And then we have to say well Rams yeah. Where do we put that? Where do we go to find the events after we've got the shape defined?

C

Although we still do need to sort out the the yaml I, don't think I haven't had a chance to do that either we had um one of the members of my team um because apparently the build tools are in Python, so our python, a guy who's in open, Telemetry python, uh was going to have a look but I, don't think he's had a chance to look at it either.

A

Even to allow the any activity, any value for the yeah.

C

The Emmy and the map a string of any yeah, so so it's going to have to be added at some point. Someone's got to do it um and it's going to be painful. It's like I'm, already seeing like in the JS Sig that now dropping the metrics attribute and Metric Matrix attribute value the deprecating that so you just use the attribute natural. We can have the same problem once we start defining logs so which is the other PR's about.

A

Yeah I think what will be really um helpful uh is if, if the any value is supported for all signals, agree.

C

Which I think Ted and tigran I think tigran writes the pr and Ted's been coming trying to push it but I think it's again: Fallen flight.

C

So that was the 376 I think it was okay. uh It was like originally off my PR and we go final mine.

C

C

So I think this is the underlying one. That's been open since December the 6th 2019.

C

um And yeah and then pigman's got two Triple Eight he's got this PR to try and react like that, but I haven't actually had a chance to look at it.

A

Yeah um Laura.

E

C

A

So I still believe um now that if we get some TC member, um you know I think it will help move these things faster.

C

Yeah yeah um I did button, give an update on the issue they created for the TC. uh You said he was going to be out this week.

A

Yeah in in the in that issue, I paint Josh yeah, um but there's no response. Okay,.

A

Yeah I can I can ping them separately on slack, um but I I think they need to come on a meet in in a meeting, so we can explain to them uh our thought process yep.

A

um So far, all the discussions were only on GitHub.

A

So I think even this event.data is likely to get dragged because I think the attribute itself people might be open, but the any value type in a could could be the one that could drag it to it longer. Yeah.

C

um Which is why it's like off at the moment sitting in logs, but because, ultimately, we wanna have a mapping to us to a span event. That's that's where it could get dragged down. I agree, um which is why you know if we can say we're aligning with Cloud events.

C

um I think it'll help that a lot um it does mean when we come to map and say: okay, how do you convert a log event into a span event? It's going to have to be just serialized, so it's not going to be much option there.

C

C

A

Do you want me to proceed um uh on that build tools, change in the direction of getting that any value added for just the log attributes.

C

um That would be a start. um Ram do you know if lightning had a chance to? Oh, it's got some Cycles at all. Sorry who uh Leighton you remember. We talked about the the internal thing for the build tools and we nominated yeah.

E

I, don't believe so. The last conversation was during stand-up right, I, don't believe so we can check uh again today. I know he's busy trying to get. uh um You know other stuff moving along on things. uh The distro and.

C

Stuff, yeah, okay, um so yeah. If you've got uh cycle, centers um yeah.

A

Yeah I I'm thinking I'll at least open an issue yep um with with a pointer to my PR and asking for uh comments. Let's see what direction we get.

C

Yeah, because if we can make that generic, which would be nice but again as soon as you do, that I think we're going to get screamed down.

A

Yeah yeah I think generic uh I I don't want to I I, don't want to even start um otherwise. You know we'll not make progress, I, think I'll start with just for log attributes and then have people say that hey you know there is another um session that it's going to be applicable to all yeah.

C

A

Then I'll tell them like let's proceed with this for now, yep.

C

Which is exactly what we did in the JS one yeah yeah and then eventually they just become aliases to the underlying one.

A

Yeah so um I I want to understand your comment about uh the any value applicable to span events. uh Can you clarify? Are you suggesting that these pan events also today do not support Minister attributes and therefore, if we end up with this event.data, um we may not use it within span events. Is it correct.

C

Yeah, so at the moment, logs are the only place, an attribute can have a nested attribute or or any any object. That's not defined um so, and that includes a span of it. So if we were to say we have an event data of any, um then the you know in terms of mapping and event data, any two expand event: data.

C

The only transport mechanism would be well. The only semantic convention that we could say is that's now Json encoded or you know encoded as a string binary data which the cloud events sort of suggests that some things can do that anyway. So it's it's put in line with it and that's what the oh I forgot, the name, um there's a data format or something in Clarence that defines how the.

E

Data is encoded, a data schema or something like that. No.

C

The data schema is the uh is the individual field. I thought there was a. There was another one that said what the format was. That's my browser going again.

C

I've lost my link to it again.

C

C

Yeah, that was one of the fields in.

E

Here, data content.

C

Content type, that's the one yep, um so yeah that'd be where we'd have to have that in a span event. That said, the content type is, however, it's encoded, whether it's Jason or something else.

E

So I think this is what we talked about right there with two listed attributes then, and what would the content type be for necessary database like object.

C

um Well, we could say by default for us that the the pop content type is nested attributes for an event data um and if it's something different, that's when you would specify data content time, but in my original PR, all I did was implement or Define data. The event.data um with some default assumptions so like even like data document type, is optional.

C

But yeah it's yeah I, really like a lot of the wording. They've gotten here. It's it's way more than what we need, but I I think it's a good foundation for us for an event to be built. On top of.

A

So, do you want to make it part of your PR.

D

C

I I, originally pitched their data schema and pulled that out. For the same reason, I didn't want to overload um the discussion, um but you know I think you know if recall, tigrin's comments. Last week you know keeping the PLS all nice and small they blow through faster generally, if they're not controversial, uh that's really where I was going and why I only included event.data and why I also defined it as any or a map of strict of any.

D

A

I I feel um even if it takes more time, we should um align it with the cloud events. So so it's more of a thorough and complete mapping uh addressing more use cases on.

C

D

C

Where we got to at the end of last week, um I'm hoping more of the people in the log Sig specifically tigrin, have read it and if they're open to that proposal, then I'm I'm happy to change my PR and say: okay, we're going to get Cloud events and we're going to map it one to one um but I. You know when I first created the pr we weren't there yet but I think that is where we're heading and that's where I'd like to be.

D

C

Because yeah, apart from putting like event.prefects on the front of all these fields, yeah I think it really works.

C

um For logs, it wouldn't work for span events, but it worked for logs. Okay,.

A

C

Unless anyone else has you, but you know, based on what I've done in the past both front and back end like the front end, we don't need all this for back end, there's definitely stuff here. They could use um and I say, there's that other group, uh if I, can find my PR and I think he actually added a thing near the bottom.

C

uh Okay, no, he hasn't yet, um but yeah Ron Why by s-h-a-I is the person who raised that other PR that I the first one I posted the 219..

C

um They want to use this too so, but they want us to do it in spans.

C

Which licks everything together again, it was ran around the circles.

A

A

Do you want to go to the other topic on grants? Pr yeah.

E

Okay, so um uh I haven't had a chance to work on that too much. There's a bunch of uh you know overhead stuff going on here internally, um but did read the comments and I thought I know we could discuss some of the comments uh from you and uh tigran um Santosh yeah, uh the first things first I think the pigments basically saying this is not the right place to um spec report is not the place to maintain these things, and perhaps we should just do it in JS and stuff. Both of us had.

E

um You know counter arguments to that. um Should we continue.

D

E

Push this, uh you know, try to get it in December semantic convention, spec wipper, uh you know, I would like to hear your thoughts. um You know yeah.

A

Yeah I I, don't see, um I think we should continue. Okay and uh um it's not like this is the first time right. There have been semantic conventions specific to browser in this spec repo already and and like I said we are uh I'm I'm working with the iOS uh Sig as well yeah soon the Android team from Splunk is going to join, um so we will have mobile specific conventions too.

A

Okay, um so so I think more than um that, I think tigrants probably worried that uh there are not many people there who are knowledgeable um in the rum area and therefore may not be able to provide the best guidance. But then one could argue that for for anything right uh like I, could I mean things can go wrong and will go wrong and we'll have to um the entire lock signal was um I.

A

I think you know uh is in a state of confusion when it comes to events, I'm sure it we wouldn't have designed it. That way. If we had started uh with more support for events from day, one yeah.

E

C

Yeah I I agree with the so the specification repo is where we should Define the things which is where I'm trying to separate and saying we have the shaping of it. And then we have the detail of the event. um So.

D

C

Another proposal would be well rather than trying to put the event under logs. Do we propose it and say? Well, we have a top level so I'm looking at, we have like resources, schemas, Trace, metrics logs uh common. Do we say well, we'll propose an event and in there we can then say well under events. We then have we shall have like browser or whatever. So because, ultimately, you know we would like to define the event once and then it gets sent as a log or a span event like.

A

Yeah I'm, okay, with that yeah I, think I see that will be helpful because I think going forward. We we want to make events as an official uh Concept in hotel, yeah.

C

It's just the way we're leveraging existing transports rather than defining our own.

E

So don't you guys think uh you know uh proposing that I mean pushing. That forward is a little bit of a um a tougher battle to you know, get get through events as a separate thing. Potentiality.

A

That that um so so, even if it doesn't go into an events folder under locks folder, it should go yeah.

A

E

Our problem yeah, we can perhaps uh you know, uh push through the logs folder. You know defining events inside logs folder and then you know in parallel work on getting you know, pulling events up, one level or something you know uh that we could use for spans. Also as a a parallel thing or a separate. um You know task.

C

When the other stuff goes.

A

Yeah, um no I don't mean events at the same level as uh as logs and metrics and traces I meant events inside an events folder inside logs, because.

D

A

Know yeah because the event um are still represented using logs but are different from from logs a little bit right, so so not taught in the schema. So if you go back, go to semantic conventions and then go to logs- and here you know, we will create a folder called events and then we put individual things.

E

C

Yeah I was surprising when level up but um yeah.

A

We'll be I, you know great, but I think there will be bigger resistance and we won't gain a lot. But.

C

Yeah, if we start with several logs, we can always be moved later in keeping history. Okay,.

E

A

Seems like it might.

E

Be okay: it doesn't mean that it's really a separate thing or whatever so laws and places. You know, resources are already there. So.

D

E

Okay, um that okay, it doesn't make sense, but you know we can start with the uh inside logs now I'm I'm fine. With that, that's what I prefer to yeah. Moving on to the next comment, then, from you sometimes like uh I, didn't fully, you know grafted, but I kind of thought. You know the yaml had a purpose and you know we would probably order it better.

E

Whatever uh I think we have a chicken egg problem sort of right, so we first need to get the yaml the um if data defined in other men's PR to get the data. um You know in data a necessary attribute in before we can start defining these yaml files for the schemas that we are working on so.

A

um I think is I think it is not necessary. um There are two distinct Concepts um here. You know one is uh the semantic conventions for the attributes, like what name do we want to use for? What is is one thing? Okay and second thing, which I think you're trying to say is that for which event type you know, which are the attributes right and and that um I think it is not uh so strong, uh not so strongly supported in hotel at this point.

A

um So so, just because uh an attribute is under um a given, it I think the the file names are only uh indicative of the name space, but each attribute goes in which event that there is no binding today.

E

Yeah I agree: I, don't think it is required today in a because.

A

E

Not defining uh not.

A

Even Ram, outside or from as well even in the back end I think the these attributes they go uh like different instrumentations all use uh any of these attributes.

E

A

It's just that you know when somebody uses an attribute. Its meaning is consistent.

E

Understood yeah, um so what okay? um So you you think we should first just Define the attributes that we're you know going to be. You know, fired from for ROM events somewhere somebody convergence because then stand alone, and then, where would we Define the actual schema or the type event type.

A

Yeah, so that um can be in the JS uh that that cannot be in the spec repo at this point, because the spec doesn't have support for it. um So I think that's a bigger topic, maybe I think um like I I, don't know uh nav. What do you have in mind long term uh in terms of schema?

A

um Do you want that schema?

A

um It could just be in the documentation.

C

um Yeah, which is what I did in mind, like I've, now ripped out the the events.yaml changes because of the no support for event.data um in terms of what's the format Within event.data.

C

um Originally I was thinking there would be attributes, but having a look at the cloud events, if we, if we say we're going to, we are going to support Cloud event.data, we could actually say well actually, if I'm, not data is just an object, so it's not actually an attribute at all, which means we can then get back to the the the case of saying we can just grab the your resource.

C

Timing, object, convert it into a nice flat object and then just drop it straight into event, data um which is not completely different from a lot of the other places where they don't actually Define the attribute. They say: um here's its name and here's its value.

C

So if you go look at the events.yaml, for example, for the name and domain, all it says is events.name events.domain are strings, so we could do the same thing, and um the only problem we have at the moment is uh like this file gives you an error because, like between line one and three, it doesn't have a type where that seems to be enforced with version 14.

C

yeah you can see on like online. Eight, it's saying name is a string and online 17. It's saying domain is one of these values, so it doesn't specify here that they are actually attributes.

C

It just says, apart from line six I guess um it just says these are the the field names the build tool enforces these as attributes um so yeah. Unless we can have another type. So, instead of six saying attributes, we have.

A

So so my suggestion is we take it up in two parts.

A

um uh Actually, if you go to the root folder of this repo uh RAM for a second I I want to point to something um so go to a folder called schemas uh are actually uh go and level back and then go to specification schemas in the specification, there's a schema uh and if you go into overview, uh so here I what is out of scope uh if you click on out of scope, um so here it says that uh yeah, the the second line yeah. So so this is currently out of scope.

A

So you know part two can be. uh You know that we, uh you know, think about how you know that uh shape of the Telemetry can be introduced, but part one I. Think we start by uh defining the schema in the uh there is a open schema there. Isn't there is an open specification for defining schemas, so we use that convention to Define schema and put it in the JS repo.

A

Under under some browser section and then put it push it into documentation or push it into some build some tools so that uh using that schema, we we generate the objects.

A

So in another tab.

E

Can you explain the last uh you use the schema to generate some objects? What do you mean.

A

um Yeah yeah yeah so open on another window. Another tab uh go to jsonschema.org, I, think Json schema single word, yeah Json schema; uh no, no! Maybe it's not org just say: Json schema, I.

E

Think I know uh what you're talking about just me once again, it should just automatically come here from Google studio.

E

Give it a second.

D

What the heck there.

E

The schema that it usually shows up here um liquid is there in business.

C

Did you put try to put something invalid in there? It should pop up.

E

I think it's uh it's working on it.

A

What do you want to try so.

E

There's a there's, a link that pops up here in Visual Studio that takes us to the Json. The schema that you're talking about.

C

No I I think Santa's talk about a different scheme. That's not.

E

The first open Telemetry so do.

C

A

E

Link or something uh yeah.

A

I think just just put Google are doing for your Jason's camera.

B

A

So go to the uh getting started, link yeah in the bottom. What now there is a getting started, and it has some examples. So um so it's basically you you define for a given object. You know what are its uh pills going to be so for each event, we we just specify um yeah. So so here you know this this uh object. You know it has a property called product ID and it's required. That's all right um this. This um I.

D

A

Don't know if this is a cncf project, but I think um it it is. It is popular and it has support for a lot of tools in all languages.

A

um So my my proposal is that we Define our events using this format and keep it in the JS report for now. Okay, uh anyway, you know these are now JS specific um browser specific uh and for the mobile we'll see, um but for for browser at least the uh the events are our browser specific, so we can just put there and then build tools to generate classes in which you can you.

E

Know populate data yeah I, see where you're going with it yeah. It makes sense now, switching back there I'm just trying to see you know what what does it really mean to Define these attributes? Standalone Define, you know what this medical mentions around them are. Then it really means we take in our individual fields and basically just put descriptions around them, and you know data type and you know allow values and what else you want now, that's, basically it right and um yeah I know HTTP and other things. You know from instrumentation point of view.

E

They defined that um what is the you know? I guess that's where I'm having a little bit of confusion. So, for example, if we take um our.

D

E

Pick one of these things here um so, let's say foreign.

E

Just think it out loud and stuff right so, let's say refer you are we wanted to find that thing stand alone in um the spec repo right?

E

um What what's the scope under which you define it, you know: do we just yeah.

D

E

A

I think what I um think we could do is that in the spec repo we will introduce that qri under the HTTP saying http.referrer uh under the HTTP namespace in the trace in the in the trace Trace Go to http semantic conventions that.

E

Seems like you know how how yeah this is. So it's not it's. It's already saying it's a trace.

A

Yeah yeah, so so yeah I think uh that's what I'm saying so I think we should let go um of the fact that it is under Trace I. Think we only hold on to the fact that it is under HTTP, namespace um and and then um in the schema, which we will Define in our in a separate repo. We will, we will use it in a wherever we see fit. Does.

E

That uh you know some discoverability point of view. Let's say in a fast forward in.

D

Future somebody wants to Define I.

E

Think we had this discussion before what I'm, not you know completely convinced on. Is that and now we know that you know to Define HTTP, it's it's under Trace. You know somebody can go, hunt for that and figure out what that is and stuff. Without uh you know when people are creating new things now we know you know you know, and you know everybody else working on knows that HTTP lives under dress this, this polar structure, so to speak right.

E

They know that HTTP is there in future somebody's defining an event or come up with hey I want to start capturing this thing this new thing: how will they know what is inventory of existing attributes defined in semantic conventions like in a flat level? There isn't such a thing right so without that they could potentially go I.

A

I see what you're saying but I think it is a smaller problem, um because I I think in in general. um The confusion only arises because now we are starting to have events. But let's say events was not there.

D

A

Each um namespace generally fits into uh one of those three categories. Logs I think logs also only started recently, so uh either it's a metric attribute or it's a trace attribute or it's a resource attribute.

B

It boils out to the fact that the spans were the ones that was most mature first, so.

D

B

First Step everyone wrote of this specs based on how to make spans and, as other signals mature, it is more likely that they become more common. So maybe even move it from stresses folder into the common folder.

E

Yeah, if it is in the comment, follow then I think that makes sense. Is that something that we want to go push for uh I.

A

I think it will happen naturally over time, I I, think, for from our perspective, um it is sufficient to um say that you know we we want a certain attribute, it is under a certain namespace and it is there only at one place. So so that's good enough.

E

I see okay yeah as as long as it's there. We have that in the in the road map somewhere, I think that makes sense. Otherwise the the uh I don't believe that, if, if it's here we are, you know it, it's actually a bigger problem, I think uh for not for us, but for future state it will become super confusing, and uh you know we've had instances like that where people created the same thing.

E

uh Essentially, what we're trying to do is that next year, with the entire Community uh uses um this the same attribute for the same purpose across the board and things um if this organization doesn't help that it would it would not. um You know, satisfy that fundamental requirement right. We would always be Divergent, schemas and Divergent um attributes and things in one place. They call it Foo and another place, they call it Fubar or something like that. I I hope you sense um at some point.

E

We need to really push to get these things out of here inside Trace, especially if we start firing log events referring to an attribute using an attribute definition. That's living inside races. We should push for moving them to Common, but you know as a tactical step leaving it there and you know.

A

I I think I think they would not even allow that, and uh you know, given the current uh structure of things, uh you know any HTTP level attribute will. Even if you are using in in logs in events you know they will um I mean the spec team will ask us to put it under under Trace, because that's where the HTTP namespaced attributes are present.

B

A

So so one thing we can be sure of is things will uh be tied to the namespace, so there will be things uh in a namespace will be at one place, but whether they will be only used for Trace I think that will will see how it evolves. Okay,.

E

um What about this uh namespace again an apartment occurrence, yeah the net namespace right that? How would anybody even know that net actually lives inside HTTP, I know it's obvious and stuff, but from naming perspective and stuff, uh this one is confusing two namespaces. So to speak right strictly speaking, just by the prefixes.

A

Yeah uh they shouldn't have done that I think I'm sure it is duplicated it's present in a in in the net. Can you go and level up? uh Let's see, is there an space, Justin yeah.

E

A

Yeah, okay, yeah, and so then there is some.

E

Description that shows up everywhere.

D

E

So is it defined in common, then you know it's a link on scene or general attributes I see okay, so this is under common of semantic conventions.

A

uh It's still under Trace, but uh multiple domains, maybe multiple type of spans, I.

E

I think that this is fair, okay, so they're just blinking uh I think this is okay, all right, yeah, okay, uh we we can try. uh We can go that way, so the full structure, then really is not a you know yeah. So then the the comments that uh these guys made um I I, can't remember where that thing went um um the piglet made I think that makes sense right. So we don't need to push on that uh heavily. We can just Define the attributes.

E

B

E

What is saying is take these even definitions and put them in uh JS or something we should just do that the event even event definitions and continue with the attribute definition. Instead of that, that should have less of a pushback yeah, hopefully.

E

A

And and um so to go over uh some specifics, um I think the ones in the common they go under resource.

E

Once the comment that come under the resource- um okay, so these guys yeah yeah yeah.

A

Okay, so they go under resource.

E

uh Let me just bring up you know, just you know, why? Don't you tell me, uh you know what you have in mind so that way, it's uh I think.

C

Except like in the case of the varying attributes, we've got a.

A

So so varying attributes I think we shouldn't even put them, or maybe we can I, don't know.

C

One of our roadblocks and that we don't have a location to put varying resource attributes at this point.

A

Or maybe we can use the same um argument um earlier I made that just because these attributes are are here doesn't say anything about whether they are they're going to be used in in where aware they're going to be used. So so I think it's from that perspective. It's okay to get them added.

C

Yeah but then you end up with things like the fact that we have screen width and height. That means we've got to name space them, which means we've got to like put prefixes on the front of them yeah yeah, and for some of our events we don't really want that. So, like the resource timing, we don't want to have a prefix to find on the attribute, for you know: Dom loading start downloading ends, DNS lookup start doing it. Looking we don't want prefixes and all those I.

A

C

A

To look at this uh nav is that we will continue this work but keep it in draft form and see where let's say next, two months until let's say we give a timeline to let's say John and Feb. uh If there is no progress, then uh you know we'll come back and look at Plan B yeah.

C

Because I I guess coming up yeah I think interfer is probably more realistic than in the gym.

E

uh Sorry guys, the last uh a couple of comments, I, don't think I was fully following um uh I was reading, something else here so are. Are we saying uh you know you said screen uh width and height right.

D

E

C

We don't want to like effectively what I was saying is that I I don't want to see these having to have prefixes put on them, because they're made generic correct.

E

And it doesn't make sense now, even if they have the prefix template, which which domain do they belong to? um Where would we Define that, here in um in here, right, yeah, yeah.

D

E

Said resources right uh sometimes.

A

Yeah yeah yeah, um so uh so, for example, in the browser you added a browser.platform and I think the browser platform already exists.

E

Correct does the platform exist.

A

So yeah that will make sense yeah, so only the screen, and uh so by the way for screen, width and height um under user action. uh We we defined. uh We, we agreed on using a Convention of using X like not presented by you, know, 100 type of format, just.

E

Use one attribute I.

A

Don't see coordinate the click coordinates. Oh.

E

Click audits, yeah,.

A

Yeah I know it is different, but I'm now wondering even for screen height and weight. We should use just one attribute with that: X convention.

E

Okay, this is this is interesting. I, don't remember. Maybe uh sorry if we've already discussed about it, I think coordinates should really be comma. Separated and um Dimension should be X separated if we are combining them.

A

E

They're not the same you're, not so uh width by height is with x, height is the normal convention and comma is the coordinate convention. That's what we should do, I, don't know why we did this for governments.

C

Because that's what we do today in in Atkinsons, let's look analytics. um There is an argument to be had to keep them separate um like if someone wants to do a query and say: okay, I want to find how my application's performing on screens less than this size. Okay, okay, but also see the same argument about having combined to so.

C

It again depends on the query language in the back end, whether they can split it based on an X or a comma or whatever else versus separate fields.

A

So um I I don't know if this uh screen heightened with the mobile folks need. But let's say they don't need it then I think we could even just put it under browser namespace, saying browser.screen dot with browser.screen DOT height.

E

A

Will go into the same file browser namespace.

E

I'm trying to see you know something special specific for page uh just a page view, and we can try and uh see where this will be defined. um um It's a page title for example right so I, don't believe it belongs to any uh namespace or something you know is that something that we would then Define just as part of the event schema in the JS cell I'm, a JS spec car.

A

Yeah yeah in the in that not in the spec but let's say in the JS Ripple open, Telemetry JS for.

E

The event events, events infrastructure. We would define those things yeah, so in my mind, I'm just trying to map you know nav. You know. If, if you clearly follow that, then you can help validate that right.

D

C

Yeah um I think I'd prefer to see screen width and height in that same object rather than having prefix with browser browser yeah. So.

D

C

If we say the page view event as part of its structure, so it's event.data, it would have you know, refuri title type, screen, width and height, and we have anything else in that list. Bringing up your screen instead of mine.

D

C

Was reading off your screen instead of mine? Let me go find the spreadsheet here um or, if you could scroll down, see if there's anything else in there, uh yeah user content content details, so they would all be part of the page view event. Data.

E

So then, if so, okay, this.

D

Is great, um let's.

E

Let's say we do that right, so there's a there's a so let me make that point now uh for sentences and uh Towers benefit right in in Microsoft. We have this thing called common schema where we have three parts per day: Part, B and part C I think we've talked about them before just real, quick, a quick climate on that part. A is almost you know it's like the semantic inventions query across the the entire ecosystem.

E

We Define something and everybody uses them exactly the same way for same purpose and so on and so forth, and Part, B and C. uh You know start becoming less and less structured. B is for specific domain. C is for anything um so the way I'm trying to map this, in my mind, is: let's take HTTP URL. This is a part, a field we're basically saying for the entire open, limited ecosystem.

E

Anybody who wants to use URL, you know that's a semantic convention, use it the respective of where it shows up traces or laws or browsers or whatever else it is anytime. You are talking about a URL, adhere to that HTTP that you are on convention.

E

That makes sense, then we talk about um the the thing like you know: user consent, for example. If we believe we don't have to strictly different for the entire ecosystem, it only applies to a particular um narrow domain, in this case um web browsers, uh JavaScript, only whatever Define them as part C, so to speak, custom things and Define them in the event schema now the my litmus test for pushing stuff into part, C typically is that is.

E

Is that event the only place where user consent makes sense right if it is then leave it in the event definition as a part C, but the moment the same field shows up in more than one events say: for example, user consent shows up in page view. It also shows up in user action and perhaps I, don't know something else right then we need, you know. It forces us to go Define it in a common place, more commonplace in a top level.

A

I think the event schema allows that Ram in in sorry, uh the the Json schema.

D

A

I think it allows you to Define common sub-objects separately and then refer them in in different places.

E

So in the so, in the event schema, then we need to have a whole structure where we also Define common stuff and then all the events use them and stuff. Is that what yeah? Okay.

A

Yeah we could do that yeah, okay,.

E

I I think we should do that. So that is something that we need to agree on right. So uh just.

B

E

uh Semantic conventions will will put all the common things like part, A stuff, we'll use semantic conventions, put them in the right right domain, so to speak, namespace, so to speak, anything that is not uh worthy of that. We will follow another hierarchy inside of Js specifically, so the events can share some of these common things, but they're, not the semantic convention. So two levels of parenting um is what we we are going for. Yeah.

C

So so probably another way to look at this. If you look at the cloud events, assuming we end up going Cloud events, um part A would be the common attributes, so the the required attributes.

E

um So let me just bring up and then you can talk about stuff, okay,.

C

Yeah so probably the the spec one you had yeah so in here it talks about you have uh event.data, and then you also have common and optional attributes. So I I see the the common and optional attribute to really the part. A is the required ones.

C

um Part B and a little bit of part C is event.data. That's conceptually the way I'm looking at so yeah. If you scroll up a little bit uh the context attributes no, no, not that far.

E

C

It was just above the.

C

Context attributes is part, a uh data is Part B and maybe part C. Okay, that's generally how I'm sort of thinking.

D

C

Where part A is semantic conventions, it is the existing. You know, attributes top level attributes as defined today um and then, as we Define the event, that's really the event data and all this extra stuff, um like we still have the custom stuff, I I, see part C, mainly, as you know, user custom data.

C

um We haven't really defined where we want to put that unless we say we want to put that in a base, data or properties field in inside of data like we do for us.

E

um Do we want to go to that level of definition, or we say anything that we don't know, that's not already defined in the schema. That's basically custom.

C

E

We could we could create another sub-object and say inside inside the data field. uh There is this thing called the properties, a specific, a special key called properties and um anything that you stick inside of that is not defined and it's custom for the customers.

D

E

Or we could just say anything that is not defined is just viewed as custom yep.

C

Yeah I think we really need just to find a and basically yeah.

E

Okay, so um I think I'm clear in my mind what what we are attempted to do. Yeah I can go uh update uh that we are working on that. So that's basically, you know.

B

E

I think we we pushed back on tigraine uh for defining these things in specs and stuff, but you know I think we're gonna just accept his proposal. Is this the one? Not this uh I think we're gonna accept this proposal. You know don't Define them at this level, right um yeah. That makes sense you you with me Satish, because you and I had um you know, arguments against difference. Yeah.

A

Yeah I know I think uh he didn't say anything. uh You know, after that, I think it should be okay,.

E

Okay sounds good.

A

um Actually uh Could, you um uh just put one line summary of this a you know the ABC steps that you mentioned yeah.

E

um In here right, uh okay, yeah I can I can put some notes. Here Yeah Yeah.

C

I was wondering what you were following, because it is a strange concept.

C

It's it's straightforward, but if you don't know it like we're, only just introducing you now to it so yeah.

B

A

um You could you could put it there and then we can review it uh and and refine tomorrow.

C

um Which I guess brings me to my agenda item which I have the same one for tomorrow in terms of like um the spec meeting uh overran as well, uh and this got raised at the very last thing directly cancel the spec meeting next week because of Thanksgiving uh I I. Guess what do we want to do? I I'm not going to be here. So it's going to be up to you guys whether you want to meet or not.

E

um Next couple of weeks is what we're talking about right, yeah.

C

So so Martin was out this week. I think he's back next week, so I I, don't know so he's probably around um but yeah.

A

Next week, I'm not uh I will either yeah yeah.

E

So I was I was thinking about taking a couple of days to make that uh you know longer uh vacation time too uh holiday times, yeah so yeah next week, um uh modern and uh double um uh Martin Liners in the back travel. Do you have a preference.

B

On European, so we don't have all it is reason in next few weeks.

E

You're not available next week.

B

No I'm a parent, so we don't have holidays for the next few weeks. Oh.

E

E

Then uh you know I think we can leave it up to um I.

A

I I'll I'll see I I'll, try and join the calls, but I I won't be able to do any work. Okay,.

E

A

Can listen, you will do right Ram. uh If, if you um need anything you know, I can make changes to this PR2.

D

A

That we talked about, do you want me to get started on that? Sorry, uh which one say again, the I don't know whether it was part BRC, but the the schema in the JS report. Yeah the event schema.

E

Yeah we could do that or you know give it. You know, give me a day or so see. If I can, uh you know, spend some time on it. If not um yeah yeah.

A

E

A

E

A

E

Cool thanks folks and tomorrow, I'm, not 100 sure, if I'll be able to make it uh I'll. Try then, okay, letting you know: okay thanks a lot cheers.