Session Date/Time: 22 Jul 2026 09:30
[00:00:05] Paul Hoffman: Preliminary slides, and then we're gonna just drop right into the main part of the agenda. And, yes, thank you, Elliot. So like I said, I see a bunch of new faces in the room. For those of you who aren't familiar, there is a note, well, I'm gonna show it next. But in fact, you already agreed to all of it, so please, you know, do be aware. Mostly here, the biggest issue is behaving in a professional manner, acting like you these are your colleagues. These are people who you want to listen to, and you want them to listen to you. So please do that. So then the official note well, which we're supposed to show, which is in text that you can't read. But, again, you've already agreed to this. So if you do want to refresh yourself, please look at you can either follow the QR code or as I said on the previous slide, there's the information that you want. Okay. Thank you for trying to get that to work closed because trying to get people to be quiet outside would be silly. So you've unless this is your first meeting, you've probably seen some of this as well. The most important point is in the bottom corner that you wanna be with using the on-site tool. And since there are a lot of folks here who don't know each other, another important thing is when you get up to the mic, please state your name. Even if you stated your name at the mic two minutes ago, please state your name again. And these are the normal resources and such like that. Is this anybody's first IETF and this is the first working group that they are sitting Okay. Is it who's who's is this the first IETF that they're at? Well oh, a couple of you. Welcome. So we've got we only have an hour, and that's probably just fine. We have a very direct agenda. I have just pretty much finished the first bullet. And for those of you who haven't been following this closely on the mailing list, we have one document. Our biggest challenge on the document is, in fact, our charter limits us to following not to not be developing the document as they often are developed in the IETF, but to actually hew fairly closely to the input that we got. And so that the idea is not to add a whole bunch of new ideas and such. Lisa will be covering that today. And then we we finish one document, then we might recharter. We might do something else. But, really, our our goals for the working group is to get this document complete even though it came into us fairly complete. We're already finding some good changes and stuff like that. So with that, I'm does anyone have any questions? Questions are fine, but I'm sort of expecting that we won't have questions on the introduction. Lisa? That should work once I, in fact, select you. Oh, and then here. Let me yes. I believe you are controlling slides, and I'm not.
[00:03:49] Lisa Dusseault: Great. I have found that working on JSON Schema is a very self referential activity. It's very meta. I got into an argument about the semantics of the word semantic, and I was
[00:04:03] Henry Andrews: like, this
[00:04:05] Lisa Dusseault: is it's turtles all the way down. So I wrote up a JSON Schema for describing the JSON Schema standard or spec. That's that's what that is. It's it's useless, but it was it entertained me. The work in the last couple months of on JSON Schema since it was adopted as a working group document is I just started plowing through the document in order, making sure we had examples for every single keyword that illustrated not just how to use it, but ideally why in a in a kind of example that would would give people a a reference point that they could grasp. So not an arcane example, if possible, something like points in a two d coordinate space or inviting people to a meeting, things that many of us will have encountered. And and you and and if that example requires a certain feature from JSON Schema, then it's a then it's a good example. So that's been my goal there. And I've finished sections four and five, which is probably the bulk of it, and we'll continue just adding examples. I've gotten very few comments on them, but I have had several readers say that they had wished for examples in previous versions of or they'd wished for more examples in previous versions of JSON Schema specifications. So and I myself had. So I I'm I'm hoping this is useful into the future. Oh, and along with that, by the way, I defined the readers of the document as in in again, in order, first of all, authors of JSON Schema. As an author of JSON Schemas, to solve particular domain problems, the first place I went to was the official JSON Schema spec. Not a tutorial. I always go to the spec. I wanna know what the spec says. Go to the source. And certainly not to the documentation of an individual implementation because I'm I'm a standards geek. But I'm not the only one who goes to the standard, goes to the spec when trying to understand how to use something even when I'm even when I could go to a tutorial or some library documentation. So I I I think that we need to continue answering the use cases of that readership. But then after that, the readership becomes people who are implementing JSON Schema, who have a set of requirements that authors may not care as much about. And then after that, people who are extending JSON Schema. Not people writing a schema for their domain, but people writing a schema for schemas or writing requirements for schemas. So again, this is where it gets very meta. And so that's the third audience. And I've tried I've I've begun the process and not completed the process, and I'm not sure how far we'll go, of of ordering the document by those three readers so an author can read up to there and then stop, and an implementer can read beyond that to here and then stop. We've had some lively discussion on the list already about terminology. The first point was we should use JSON text, that terminology, as defined in JSON, and I've attempted to do that. But not all the places where we had JSON where we had JSON document, was it legitimate to replace that with JSON text Because JSON text really does seem to imply, like, a byte sequence, a byte stream of some kind. And there were cases where the document can and did benefit from a more accurate delineation between content that an adjacent schema can apply to or data and the input. We need we need to talk about both because if we don't talk about text and byte sequence inputs in a very precise way, interoperability is hard. But if we don't talk about handling things that have been translated into Python dicts and arrays, then we are leaving out a huge constituency on how they use JSON Schema in practice in the world. While I'm asking this, has anybody used in the room used JSON Schema in the context of writing a spec? So just for other people to use. Great. And has anybody used JSON Schema in the context of publishing an API, especially with tools that publish APIs? Yeah. That's awesome. You'll understand that there are use cases that people who write specs here and put JSON Schema into specs here may not be as solidly aware of, But we'll get into those with the annotations discussion. Another goal with this terminology, again, not to rule out the programming language uses of JSON Schema, is I propose to reference ECMAScript or ECMA standards to say, here is informationally on example of a mapping between JSON byte sequences and a programming language structure. You don't have to use JavaScript, so it's not a normative reference. But it's informative to say, if you are interested in using Java JSON schema operating on programming language constructs, you'll need to refer to something like this that tells you the mapping between the byte sequences and the language constructs. And then the last part, which I hope people can decide what they can live with, not what they would necessarily be most in favor of, can we live with some terminology that describes the thing that is the programming language construct when it's not a byte sequence? And the the I think my preferred I used structured document last time I revised the spec. But I think now that I've seen that it's used in RFC ninety five thirty five that I prefer JSON value. And a JSON value will be defined as something that might have come from a JSON text in in in after being parsed. But the I I believe we can say JSON value without completely ruling out data that might have come from YAML or might never have come from byte sequence. You can construct a Python dictionary by shoving stuff in it starting as a dict, and then you could validate that against adjacent schema. So it never came from a text at all, from a from a byte sequence at all. But I think saying something JSON value might have come from a JSON text is probably an adequate definition, and it's in use in JSON path. Should we get a sense of the room with that or take
[00:10:38] Paul Hoffman: Let's it to the do that. Or let's just do it at the end once we're sure how much time we
[00:10:41] Lisa Dusseault: have. Great. Annotations. So this is that feature I was foreshadowing that people writing a RFC and putting JSON Schema in to define what a protocol message looks like have probably not really wrangled with what annotations can do that makes them really cool for extensions and and implementing things like pipelines. And so I wrote an email to the the list on July 2, and there's been a few more really useful emails since then talking about how an annotation can just be a comment to the reader. But that's not really as useful as when as when it, defines, additional leafs in the result info set that if you if everybody follows the standard, must be there. And that means that software processing the results of a validation step have extra information they can work with because that annotation is in the schema. I think we are making progress and still have progress to make on making this all more readable. For example, I think Henry and I were talking about how we really ought to talk about this as the cross product. The result info set is the cross product of the schema. Austin. Thank you, Austin. The cross product of the schema and its annotations and the particular input is a is a good metaphor for quickly understanding what the result info set is and and how annotations feed into that. I swear I went two months thinking that annotations modified the input, and they don't. So if anybody else still thinks that, you're not alone. I thought that for two months. A result info set, has an output that can be either a JSON value, if that's the term we adopt, or a JSON text. Presumably, most of the time, whatever input a JSON Schema tool is accepting is what it will output the result info set in, although, of course, that might be configurable. A tool might be allowed be able to say to have programming language things in but be configured to save its validation results to files. Great. I don't think we need to be concerned with the interoperability of that, but I do think we need to be concerned with the structure of the result info set. So there's a chance that I could swap out my Python JSON Schema Validator with a Rust JSON Schema Validator, and then my pipeline tools that accept the result infoset and do more processing, maybe even do some transformations or some auditing based on that, might still work great. Any immediate clarifying questions on annotations? I've started thinking about security considerations. Yeah. Based
[00:13:59] Paul Hoffman: on the person who you live with? No. Yeah. That's true. Darwin doesn't care.
[00:14:09] Lisa Dusseault: The in fact, I've I've I've had a grand old time, building a strict meta schema for JSON schemas. One that will do a much more restricted job of taking your JSON schema, you feed it into the strict meta schema, and it tells you not just is it technically valid XML schema, but also does it break some of the common, best guidance for avoiding dumb mistakes. It's really easy. Again, see the mailing list. There's a good example or in the GitHub repository I have on strict JS meta, there's some examples of a JSON schema that looks like it ought to validate things like the length of a movie, but actually it's just validating the length of a string, which since the length of the movie is not a string, it does nothing. And a JSON schema validator of your movie data will just silently ignore the fact that you've validated the length of nothing. I even I I even have thoughts for a severe meta schema that would go even further. But I think that kind of thing is what we need to understand when we talk about security considerations. And I don't know how we end up referencing that kind of thing, probably informationally, because a strict metaschema is not always appropriate. Lots of things need to operate in a fast, high performance context, and it's it's really at the author's decision to do a strict validation of their schema. Oh, and then once you're applying the schema to data, the the fact that it's strict or loose, shouldn't matter because you're just applying the schema. But, yes, I'd love other people to have a look at the security considerations. Security considerations is one of those things that really benefits from a lot of eyes. Please look and think about what is important there. And then my next work that I've planned, that we've planned, is to redefine the default keyword. It's not really an annotation. It doesn't really work as an annotation because by the time you apply default but remember, the annotations in the schema and the data in the instance, if you're doing a cross product of them, well, if the instance doesn't have a field, then the annotation for default for for something like default doesn't ever produce. That data is missing in the instance, so the cross product kind of zeros it out. So default can be just defined as a keyword. It's fine. Like required properties or additional properties. It can work just like those things and not have to be treated as an annotation, and that just makes it a lot clearer. Might have a few impacts on processing and validation, but it might not. Like if anybody is using default annotation output based on the language in the last version of the spec, well, they could always define a, like, my default and and make that work again.
[00:17:24] Paul Hoffman: You wanna? Yeah.
[00:17:29] Austin Wright: And and some of this Austin, right, by the way? Some of the use of default as an annotation probably goes back to some of the earlier drafts that I put out where we there was the idea that annotations could also just annotate an entire set of JSON documents, including all of them or something. So and that the default keyword in this case could tell you, here's a sensible initial default if you're creating a document that a user might wanna start editing from. And, obviously, that concept of an annotation doesn't really work well if we're talking about the output of a particular validation result. So how we want to define annotations might also be in the scope of our discussions. Like, can you have annotations that annotate a set of documents?
[00:18:26] Lisa Dusseault: That was Austin Wright, coauthor at the mic. Henry?
[00:18:35] Henry Andrews: Yeah. Oh, hi. Yeah. This is Henry Andrews. Just to comment on on that, yeah, I I think the the term annotation, as Austin mentioned, like, the the definition there, that has, I think, been a little bit confusing, which is why I've started drifting towards, result info set, which I've been experimenting with reworking the, the specification document around that terminology. And I'm personally finding it rather clarifying to talk about various things and when it gets added to or removed from the result info set. And that's kind of taking a lot of complexity that was scattered all over and consolidating it in a much nicer way. And then if we, yeah, if we wanted to distinguish between annotating the potential set, which is kind of more of the generative case of, well, what do I wanna do if I'm creating an instance? Yeah. We have kind of floated around that that concept a couple of times, but never really nailed it down. And and it would be good to have distinct terminology, I think, there. Yeah. Yeah. I'll stop there for now.
[00:19:52] Lisa Dusseault: Excellent. We can have lots of discussion on that in the next forty minutes because I'm almost done. We have a bunch of document, you know, tidying to do, such as removing the footnotes, which don't really display properly, but I need to consider each one and figure out if it's text that needs to be that that is highlighting an issue or should be moved into the main text, or sometimes a footnote can be deleted, but I need to decide which or propose which and get feedback. And then the big issue that I know we're going to have to tackle and is going to cause, I hope or fear lots of discussion, is extensibility mechanisms. I meant to say dollar schema, not not dollar ID in the last line here. The dollar schema is a way to say which meta schema the current schema depends upon, and so it's both a flag for how to validate a schema and a versioning marker. And then the ID of a schema is its way of say it can be a versioning marker as well. So if people modify their own schemas, frequently they update the ID field of the schema to be technically a whole new URL Even if sometimes it's just a a version number inside that changes, there's no distinction between a completely different schema and a small version number bump. So versioning is not semantic versioning, although people sometimes put that inside the URLs that's they're just URLs. And vocabularies are a way of defining because you can't so it's multiple inheritance for meta schemas. So if you want to take twenty twenty twelve as your base schema language, but also bring in all of the geofence schema stuff that has been developed in in those communities that are developing quite rich and extensive schemas for geographical data, then you could say, this my schema is based on twenty twenty twelve meta schema and this geo geographical vocabulary and this geospatial vocabulary and bring in those and state exactly which schema features your schema depends on. So this is some some advanced usage, but, you know, getting it wrong often affects even ordinary users in annoying ways. So it'll be important to do our best on that. I'm not sure if I'm the red queen or if I'm Alice, but, anyway, let's go.
[00:22:49] Paul Hoffman: Great. So that for those of you who aren't noticing, that's the last of Lisa's slides. We still have about forty minutes. Two things here. One is to remember that our our our restrictions in the charter are that we get to start with the base of what's already there even though there's lots of ideas. Oh, let's extend it this way. Those are not for this. But at the same time, things that are appropriate are things like, this isn't clear, and you might need to add a bunch. Not just text, but we might need to do things. We might need to come up with some new vocabulary. We might need to fix the old vocabulary. Those are definitely in scope. What's not in scope is because you didn't do this thing that I wanted, and it's a simple drop in. Simple. Yeah. Right. That those are not in scope. The other is let's remember. This is a face to face meeting. Everything needs to be discussed on the list. This happens to be a working group that I think has a healthy mailing list. Lots of discussion, not a lot of disagreement even when there is disagreement, not with people saying you're wrong, but what I really meant was blah blah blah. That kind of thing is really useful. So we can certainly use this time now for some of the open issues and all here. Why I just go back to Let's see. I guess this was your first one. We can do this, or we don't have to have the mic time right now. Mic time is most valuable for, I said this on the list, and I'm not sure if people misunderstood me or whatever. That's really good for my client. New ideas, especially for something as complicated as this, are most likely best held for the list. And, again, I think that I would only say that in a working group that's doing average or better, and I I think that this working group is. So, with that, the mic line is open. Elliot.
[00:25:09] Elliot: Right. So, again, thanks, Lisa, for for all the work on this. Alright. Can you go back to oh, you're there. I'm there. I was gonna say slide three.
[00:25:20] Paul Hoffman: I think it was You are here.
[00:25:23] Elliot: It was the so for JSON value, the I I I have two points. First, for JSON value, I think, if I'm if I'm understanding correctly, is this this is not necessarily something that is schema driven. Is that correct? It could be just any random JSON.
[00:25:42] Lisa Dusseault: Yes. We need a word for the input to a schema or, in some cases, the output of a validation process to and JSON text is not always quite the right word because that's defined in terms of a byte sequence. And so the output of a schema validation is JSON value or JSON text. The input to a schema validation, like, a restaurant description that is coming through my restaurant schema validator, the restaurant description could be a JSON value and never have had a representation as a byte screen byte stream.
[00:26:20] Elliot: Okay. Yeah. I I this is a I understand the the difficulty. Okay. I'll leave that one alone for the moment because it's gonna as Paul, you said, it there's something that's gonna have to get into more on the mailing list or maybe just, you know, informal discussions.
[00:26:38] Paul Hoffman: I think it's not only gonna have to happen on the mailing list, but I think this is something where we're gonna have bumped versions. Happen on the mailing list, changes are made, comes out, and people go, oh, wait. Wait. You didn't get this part. So Yeah. I'm okay if we end up at draft o eight with the end of this, if some of them are around that.
[00:27:00] Elliot: My I have a general comment about annotations, which is I really I think you've given it the good college tribe, but, actually, I think they're still way too confusing for the average reader to understand exactly what's going on.
[00:27:16] Lisa Dusseault: The IANA registrations?
[00:27:17] Elliot: No. Annotations.
[00:27:19] Lisa Dusseault: Oh, the annotations. Yeah.
[00:27:20] Henry Andrews: For sure.
[00:27:20] Elliot: And so my I I only have, like, one suggestion there, which is I I this might be one of those cases where you might wanna do a build out of saying, here's the simple you you know, when you introduce the concept, here's the simplest example of an annotation, and literally use, you know, arrows and pointers and say, this is what things are. And then build upon that and say, here's how it's used. Because I I like it's I don't consider myself a complete idiot, maybe mostly an idiot. But I I really I I just get lost through the annotations.
[00:27:54] Lisa Dusseault: And so you mean do that in the spec, not just on the mailing list?
[00:27:56] Elliot: I think in spec is important. And I I would offer you text except I'm lost.
[00:28:02] Lisa Dusseault: No. It's gonna be a long spec with all the examples and motivations. But
[00:28:07] Elliot: Yeah. And I'm the guy who said, oh, let's bring a scissors to it. But this is the point where I think the scissors isn't needed. Right? Because it it it it's something that's carried forward from the original spec, and it's an area where some clarification, I think, is in order. Or, you know, or either that or if we think it they're not being used heavily, there's a different discussion to be had.
[00:28:31] Paul Hoffman: Elliot, before you go, so Lisa does the build out that you asked?
[00:28:36] Elliot: Not entirely.
[00:28:37] Paul Hoffman: No. No. I'm no. No. I'm saying if she does in the
[00:28:39] Elliot: future Oh, oh, if does
[00:28:40] Paul Hoffman: the build out that you asked, would you prefer that build out to be in line or in an appendix?
[00:28:47] Elliot: In line. Absolutely in line.
[00:28:49] Paul Hoffman: Thanks. Just checking.
[00:28:49] Elliot: Yeah. Because it's a it's a pretty complicated concept. Right. Great. And I I it's the in line, I think, is a good idea.
[00:28:55] Paul Hoffman: Okay. Because that's one question that I have for the not today, but in general for the working group, which is, is there stuff that's in the body that would be better in an appendix? I generally think not. I have not only do I not like footnotes, I generally don't like appendices, but I recognize that I'm not a primary reader of this document. So as you folks are thinking about on the mailing list saying, could you add this? Can you do this or that? Do be thinking about what your preferences are, what would make the document most readable, inline or examples in the appendices. Right. Austin?
[00:29:39] Austin Wright: Hello, Austin Wright. Has anyone else had a comment on annotations before I change the topic? Okay.
[00:29:46] Paul Hoffman: Up there.
[00:29:50] Austin Wright: Value versus text, I mean, I I defined the term JSON document early on, and that may have been a mistake, but I was trying to relate things to the idea of web documents. I like the terms JSON text and JSON value, but JSON text, I think that's a good definition. It's just the whole document. It's, you know, what the JSON RFC uses as a whole document. The JSON RFC uses value as sort of a nested value. Like, you can have JSON values within values. And I think that's the definition we should be using when we say JSON value inside this document too. That also implies that there's a concrete serialization that everyone has to be interoperable with. You don't have to use that serialization inside your implementation, of course, but it's just saying that it's only going to be interoperable if there exists such a serialization. Is that fair? Okay. And then I have a second point, which I think is sort of a clarifying question towards the end of the slide deck regarding sort of the charter. I think it's important that we get the forward compatibility down, and that's gonna be very difficult to do because there's so many different mechanisms for extensibility that aren't quite there. Most notably, the mechanisms that we have for meta schemas and the dollar schema sign right now in vocabularies offers features like multiple inheritance and things like that, which are not available to general schema authors. And those are features that a lot of people are probably interested in, especially if we're trying to marshal and demarshal object oriented structs back to instances. So there might be a good case for trying to add this in as a feature to some extent or or adding in new features as long figuring out some mechanism of just making sure that we have the forward compatibility there so that if people write extensions in the future, it's not gonna paint us into a corner, so to speak, because it makes sense. Okay.
[00:32:31] Paul Hoffman: Welcome to the IETF. Yeah. Anyone in this room who's been here for more than a year has had to deal with exactly the same problem. We get to deal with it. We get to deal with it carefully, and we'll probably get it 90% right.
[00:32:46] Austin Wright: Yeah. It's not a new problem by any stretch of the imagination, but JSON Schema has had its share of that, like, for sure.
[00:32:53] Paul Hoffman: Carson?
[00:32:56] Carsten Bormann: Yeah. I have two observations. One is that many people mostly think about JSON schema as a recognition language. So you can recognize whether something matches the schema or not. Annotations turn it from a recognition language to a transformation language. It gets all the baggage a transformation language unless we probably restrict it in some way that probably nobody nobody in this room has an idea how to do it. Maybe we can develop that idea. It's not in the charter, but it could still be guiding our thinking. Going back one point, JSON value versus JSON text, we really have to look at the the content of the package. So if a process works on the JSON text, that process can look at the number of spaces you use for indentation, whether you have an additional zero, trailing zero in a decimal number, and so on. That's all in the JSON text. So if you write something that operates on the JSON text, you get all that complexity. And the nice thing about the JSON value abstraction is that it already incorporates the equivalence relationships that makes three JSON texts that only differ in the indentation or in trailing zeros the same. So it it's much easier to to write something because that abstraction has already has already been taken. And one one side comment on on what Austin just said, there is no point in restricting JSON value to be within something. There's the topmost, outermost JSON value is a JSON value. If you take that out, you just double the complexity for no gain. So I think it's not so important that a JSON value is in some other JSON value, but that it has those equivalences resolved.
[00:35:14] Lisa Dusseault: That I agree with all of that. And, yes, you highlighted something that I fully agree needs more work, which is that not just limited to annotations, but generally, we need to provide very good warnings about future extensions to JSON Schema or extensions in other groups to JSON Schema that go beyond what you can do with just the input you're looking at and without and and validating it or not. There are extensions out there, for example, that, hit databases to look up valid values, and that's out of our scope and and and has security considerations. So we probably wouldn't we probably want to, at the very least, warn people against doing that. Annotations in themselves don't do transformations. In fact, they might guide people out of the validation realm when they're doing transformations. For example, if you had most of the data coming in, had all your dates in the correct format, but occasionally you have one that's not in the correct format and you want to apply a transformation later in the pipeline after validation, you could write an annotation that that captured those on form incorrectly formatted dates, spit out a list of them, and now you know what you have to go and fix in a later part of the pipeline. But annotations by themselves aren't ever a transformation. They just might provide spit out data off to the side that could guide a transformation later. I think I think that is a is a useful tool for guiding people towards doing that outside of the validation step. Yeah.
[00:36:58] Austin Wright: Yeah. I think it's Austin, right, by the way. Annotations are technically a transformation, but it's not a JSON to JSON transformation where it's a JSON to infinite set transformation. And maybe we should have different words for that. There's, like, transducer, and there's there's a whole lot of language we could come up with.
[00:37:18] Lisa Dusseault: Technically correct. The best kind of correct. I think Henry's next on queue.
[00:37:22] Henry Andrews: Yep. I think so. Yes. Thank you. This is Henry Andrews. Yeah. So Lisa made some of the points that I was gonna make already about annotations are not a transformation system. I'll build on that. Again, coming back to the idea of the result info set, and there's some structure within that. I am finding that helpful because to for me, I would like to kind of pull the boundary of JSON schema in a lot so that we are we're defining what information needs to be provided as the real result of an evaluation, and we need to define some controls over that to let people, trade off performance versus this kind of functionality. You do not always need to track all of these things and have them available to return if you just want a Boolean yes or no validation, you know, acceptance rejection outcome. So we wanna we wanna make sure the implementations are free to do that kind of thing. But, yeah, pulling having focusing on what information must be made available and perhaps what additional information should or maybe made available, that and then if that's structured as we talk about that as a JSON value, then we can get away from the various serializations. What I have found and what we've learned through some experience over the over a couple of years is exactly what format you want to structure this information in varies depending on what your use case is. And, you know, we at one draft, I think we had either three or four different, formats specified in the draft, and that's probably getting a little a little out there. So I I I I would like to really focus on nailing down what the information is that we wanna have in the results info set. And then we can say, okay. Well, what do we need what formats do we need to be able to serialize this in for interoperability? Or, like, what JSON value structures? Maybe not even because then, you know, you can serialize that to JSON. So that's kind of where I wanna I wanna I would like to focus. And I think that also really helps define things like you have an info set. It does not it it it does not require you to literally annotate the instance so that you have a transformed instance. It does not cause transformation to happen. The annotations may in may impart semantics that a pipeline will use to do transformations then read up revalidation. I posted an extensive example of that to the mailing list a couple days ago, which those of you in Vienna probably have not seen because you're busy doing other things. But but it's there and shows it also you know, someone mentioned, like, whether annotations have been used. There's definitely some use of them. We, in OpenAPI, we we specify certain types of context sensitive validation in terms of annotations because that's a pipeline of you get the read only annotation, but JSON Schema doesn't know what a read is. It doesn't know what direction data is going in. It doesn't know about data movement, but OpenAPI knows about that. And I have one final thing. I was going to say oh, yeah. And the the the sorry, it's it's two it's 03:00 in the morning for me here. Okay. I said the thing. I'm at the transformations. Man, I think I lost it.
[00:41:04] Paul Hoffman: It might come back.
[00:41:06] Henry Andrews: It might come back. Hold on. One one last try. Context sensitive transformations. Nope. Gone. Okay. Sorry. No
[00:41:20] Paul Hoffman: problem. Thanks. Rowan?
[00:41:23] Rowan May: Hi. Rowan May. So first of all, I just wanna say that, like, the I'm really happy to have this work going on because, like, being able to reference JSON Schema before was kind of awkward. So I had two completely orthogonal points. So the first is that the the document, while it's, like, way, way, way cleaner, it has a lot of unmotivated shoulds. And, like, waiting like, usually, I that's kind of the thing I I check, like, near the end of a document. But there there are enough of them that it may be that may be something you wanna start doing on the next rev is to go through and, like and even if that means some of them go in a, like, implementer's appendix or something. The other thing is about regular expressions. It I I looked through the list, and I was like, like, it it would be nice if there was a little bit more solid set of of stuff in the in the list of in the regular expressions section, in my opinion. So happy to help with that part.
[00:42:37] Lisa Dusseault: Oh, thank you. These would both be excellent things to do better at.
[00:42:43] Paul Hoffman: Ben Go?
[00:42:44] Bengo: Hey. I like all the proposals. The notion of changing default to from an annotation to a keyword is seems extremely reasonable, but my spidey sense is that it'll break. There's so many libraries out there that do JSON Schema for a long time that it just seems like inevitably it'll break some assumption. There's a lot of metaprogramming and stuff that happens with JSON Schema, especially with OpenAPI. I think it's a good idea, but it makes me think that probably some of the, like, library authors out there and should be notified really early about that and that it might be, like, colloquially useful to have a name that's not default to refer to the annotation versus the keyword even as like a transitionary step. The main thing I guess the main thing is that probably the JSON Schema library authors out there that so many of those complicated use cases depend on probably will like an issue as early as possible that that's that advertises that that transition will happen.
[00:43:44] Lisa Dusseault: Absolutely. Yeah. We're plugged into the JSON Schema community. There's a a strong supportive community.
[00:43:51] Paul Hoffman: Actually, before you go, you didn't say your name at the mic. And since we are trying to create a community in here and you're just listed as Bingo
[00:43:58] Bengo: Sorry. Someone said my name right before I spoke, but but my name is Bingo. Thank you. Is that okay?
[00:44:03] Paul Hoffman: Just whichever. It's just single name Bengo is less helpful than so when someone reaches you out in the hall, like I say. So alright. Noted. Yeah. Austin.
[00:44:17] Austin Wright: Hello, Austin. Right? Yeah. With regard to the previous comment, yeah, there there is a number of distinct ways in which people use the default keyword, and we could break that off probably into, like, a default new keyword if you're trying to create a new value. What is a sensible default? And it doesn't even have to be valid. It might just have a bunch of placeholders that are invalid that you just have to fill in as a user. There's, like, missing values, which might say if this keyword or if the if this property is missing, it has the same meaning as being filled in with this value and so on and so forth. It might be useful to break out that default keyword into these things. I don't know if that's within the scope of the charter, but if that's causing interoperability issues, then maybe there's a good argument for that. With and then there there's a lot of implementation guidance with regards to, you know, BCP 14 shoulds. It just that's just because there's a lot of different implementations out there in the wild, and you need some shoulds from to to inform people that, you know, trying to distinguish 0.0 from zero. Some implementations do it, but if you try and do that, it's not going to be interoperable. You can do it. That's why it's a should. And there's probably a lot of text like that. And then and then excuse me. And then another important point, which I would like to point out, is that JSON Schema does not talk much about if two values are equal. There's really only two keywords where it talks about values being equal, and that's const and enum. And for those, we have to define some sort of function that equates two values as being identical or not. But for in general, like, all of the keywords, we're just they're just identifying a set of possible inputs and giving that a thumbs up or a thumbs down. And when we say that, you know, should 0.0 be the same as zero, what we're saying is there's no there there's not going to exist any keywords that say thumbs up for zero but thumbs down for 0.0. Now in theory, we could introduce a keyword that does that in the future. Maybe there's a sign maybe you're doing scientific notation and you want to do something with sig figs. You know, feel like that option should be open in the future. But just bear in mind, JSON Schema, it actually doesn't really dive into equality of values that much. But and this goes into text versus, like, text versus values, I think, where we want to talk about values being, you know, like, the concept of a value versus a text. I think we're talking about 0.0 should be different from zero, and then a value collises those together. But, again, that just doesn't come up very much. So I think we can treat that as just a value as a blob.
[00:47:35] Paul Hoffman: Henry again?
[00:47:39] Henry Andrews: Yes. This is Henry Andrews again. So I didn't remember what I was talking what I wanted to talk about, and, it is a little bit related to, what the the fellow was saying about default and implementations. So I want to point out that any implementation that does something with defaults, like writing them into the instance, is operating outside of the spec. So while, yes, we want to make sure that people understand what the change is, there's nothing in the spec that supports doing anything with default in an implementation at all. Nothing. Every every tool that does something with it made that up themselves. It may be totally logical, but it's it does not it cannot be tied to any requirement that's actually in the in the specification. At most, there's something in there that's like, you can you could do such a thing, and it's it's a could. It's not a it's not a, you know, it's not a may or should or or or must. Regarding shoulds and musts, there are a lot of places where we could use more of that. Some of that is because I didn't know what I was doing when I wrote parts of this spec. And now I know, and I look back, and we should put a lot more of those in. The thing that I wanted to mention, getting back to kind of the implementation community, there was talk about, like, well, have annotations been used? I mentioned we do refer to them in downstream specifications like open API. Because of some lag in tooling support, there hasn't been a whole lot of necessarily been a whole lot of avail of of opportunity to use them. What I did in that example with the transformation is I showed how there are keywords in a popular JavaScript implementation that gets more than 1,000,000,000 downloads a week. And an extension a set of extension keywords that get I I it was, like, 300,000,000 downloads a week or something like that. And some of those keywords, you cannot possibly implement in JSON Schema within the current parameters of what a keyword does because, for example, it modifies the instance while it's being validated. So, hopefully, you're not doing anything concurrently that attaches that that hits that because you're gonna get nondeterministic results. But what it does is it shows how annotations can be used to handle those cases as pipelines. And I think that's or annotations or, you know, result info sets. I think that's something that we should really be looking at, which is that people have tried to extend JSON schema in a lot of ways, in including default filling in, including transformations. And they may not realize that result info sets can let them do this without violating the constraints of JSON schema's proper evaluation, but that is really a really important thing that that that they enable. They enable a particular type of extensibility where there's a strict boundary of JSON schema goes this far, and then your other thing does this other piece. And that's different from the vocabulary, extensibility where we are saying, here's a keyword, and there needs to be a piece of code that says how you define whether this accepts or rejects, and you're gonna have to find some way to load that in your implementation and run it. So those are those are kind of two different types of of extensibility. And then there's format, which I wish would go away. So we'll just ignore that for now.
[00:51:06] Paul Hoffman: This is the default thing like security considerations. Thanks. Carson?
[00:51:15] Carsten Bormann: Yeah. One one comment pretty much supported by what Henry just said. I think it's really important that this working group becomes cognizant that it is working on a spectrum, one end of which is a union of all the mistakes any JSON Schema implementer ever has made, that's not a useful standard. Don't don't do that. And the other one is a situation where the specification cuts off parts of the community for no good reason by by just interpreting something in a way that is interpreted in a different way in in very popular libraries. And the the question really is one of normative intent. We have to shape the normative intent to be strong enough to avoid the union of every mistake ever made, but not strong enough to to actually cut out people that we'd rather continue to be part of the community.
[00:52:21] Lisa Dusseault: I think you're saying apply good judgment rather than solid rules, and we rely on you to help us with the good judgment.
[00:52:28] Carsten Bormann: I go beyond that. I would use the word taste.
[00:52:32] Lisa Dusseault: Yes. Cases rather than than absolute rules. And, if if the queue is empty and we have still a couple minutes, I wanted
[00:52:43] Paul Hoffman: to talk. Yeah.
[00:52:45] Lisa Dusseault: You five minutes good? Okay. I wanted to give a pitch for people who are doing schema work and examples in their specs, whether it's XML schema or CDDLCBOR or something else that has a validation language, you should, I think, take your examples and take them out of the spec and put them in a directory and reinclude them with the include keyword, which Carson, I think, put into the XML to RFC tool chain. And then you can write a simple script to validate all your examples every time you make a change to one of them or when you make a change to the schema that they're supposed to meet and, oh my god, the errors it saves. It the I've done this with the PDP archive spec as well as with the JSON schema spec itself. Again, this is so referential. All my JSON Schema examples are validated every time I do a PR or a merge. So I recommend it highly.
[00:53:52] Paul Hoffman: Andy, why don't you come up here?
[00:54:02] Andy Newton: I'm Andy Newton, the responsible AD for this working group. And first off, I wanna thank Paul for taking on the responsibility of chairing. It was not a small ask. I wanna thank the author team for for being diligent in their work and taking it very seriously as well as the rest of the participants here. I agree with Paul. It's a very, very well functioning working group so far. I don't that's not an invitation to
[00:54:31] Austin Wright: make it
[00:54:31] Andy Newton: dysfunctional. So but what I do wanna highlight is that this is you know, we're we're now a working group. There are people who are taking normative references to the output of this working group, and they're putting it in their docs, not just in the IETF, but in other standards development organizations. So with that, I'm highlighting the importance of meeting our milestone, which says May 2027. I am told that I can give you all extra cookies if we do it before then. So alright. Thank you.
[00:55:09] Paul Hoffman: So just to follow-up on that, you know, yes, we are really we're we're tied to the charter, which some of you find less of a tie than many of us do, and we're tied to the milestone. That milestone is an end date. If we, in fact, are working well, there's no reason to slow down at the end and then jump. For two reasons. One, as Andy just said, other people are relying on this, and some of them will rely on an RFC. The sooner we can hand them an RFC, the better without, you know, trying to get too far ahead. Go ahead. You can interrupt on that. Okay. But the other thing is is that as we've already seen in the last couple months on the mailing list, there are sometimes suggestions for, oh, I wish you could add this, which is outside of the charter, but that doesn't mean that that person didn't actually wish it. That could be in a later charter. So we don't get to recharter until we're done with this. So that's another motivation for us to finish sooner. Not to rush, but to finish sooner. Not to do the way some working groups go is, oh, we're way ahead. Let's just slow down. And then they always miss the deadline anyways. Let's keep on this because there is a lot of good interest here.
[00:56:33] Andy Newton: Yeah. That's actually what I was gonna say. The the the we have an opportunity to recharter. And so if there's you know, let's let's make our
[00:56:43] Paul Hoffman: After we're after we're done.
[00:56:44] Andy Newton: Let's make our milestone, and then we can have those conversations. Elliot, is there something
[00:56:49] Elliot: Yeah. Just a quick info question for Paul. Are you keeping track of the future stuff? No. It might be useful to have, like, a, you know, like, just
[00:56:58] Paul Hoffman: a I I rely on the people who asked
[00:57:00] Elliot: for it to do so. It might be nice to have, like, a consolidated
[00:57:05] Paul Hoffman: Yeah. We might we might do that. But yeah. Yeah. At this point, the the number of suggestions is is thankfully small. I mean, it's not zero. And, again, they seem well intentioned. But those people might actually want that done in a recharter. We'll see.
[00:57:20] Andy Newton: Yeah. And let's set some expectations here. Not everything may make it into a recharter. I don't know what the charter will look a recharter looks like at this and I don't want to have that discussion at this point. Right. The if we get into the point where we're gonna do a recharter, then we can start talking about scope and things like that, but we still have to meet our deadline.
[00:57:41] Paul Hoffman: Right. And the deadline is, again, significant not just because we made the deadline, but as Andy said, and other of you in the room have said, there are people relying on this who are not us. And we have an indirect, but I think real obligation to those folks as well. And I'm seeing a bunch of nodding heads. So good. Okay. Great. We are almost out of time. The queue is empty. Thank you very much. Please stay active on the list at sort of the level you are now, which is reading the document, coming up with some big picture questions, coming up with specific text, things like that, that's all great. And we'll figure out what's gonna go on next for the next meeting, but it seems like we have a lot of good momentum now. Thanks very much. Andy? So I have a question about
[00:59:10] Lisa Dusseault: Correct.