[00:00.000 --> 00:15.800]  This entire talk is inspired by a single remark by a former co-worker of mine who just casually
[00:15.800 --> 00:21.080]  dropped the line that Yama was so simple that nobody could ever attain mastership in
[00:21.080 --> 00:22.080]  it.
[00:22.080 --> 00:26.560]  So, a question towards the audience, also slight audience participation, sorry, who would
[00:26.560 --> 00:30.000]  tend to agree?
[00:30.000 --> 00:33.680]  That is almost nobody.
[00:33.680 --> 00:37.480]  That's a shame because you would be in good company.
[00:37.480 --> 00:45.280]  This is in the goat's section of every spec of Yama, there it is.
[00:45.280 --> 00:54.120]  So let's get a bit into detail and the very cool Yama exists to provide printable text
[00:54.120 --> 00:57.680]  presentation of structured data.
[00:57.680 --> 01:03.080]  In that regard, it is a rival to things like JSON, XML and other formats, it's been around
[01:03.080 --> 01:08.880]  for quite a while, we're almost looking into 20 years of Yama now.
[01:08.880 --> 01:17.200]  It is somewhat interwoven with JSON since version 1.2, actually all of JSON is also
[01:17.200 --> 01:19.800]  valid Yama.
[01:19.800 --> 01:27.720]  That is, they're just introducing an interesting relation because now since I think 2018, JSON
[01:27.720 --> 01:35.640]  is a strict subset of JavaScript, thus there's an intersection of Yama and JavaScript now
[01:35.640 --> 01:40.240]  that is precisely JSON.
[01:40.240 --> 01:46.200]  Let's not get into the argument if that's good or not.
[01:46.200 --> 01:55.240]  If you write a lot of Yama, all of the examples, well, most of the examples, most of the real
[01:55.240 --> 02:01.160]  life specimens of Yama, they will let you believe that there are no real types in Yama.
[02:01.160 --> 02:08.440]  Actually the opposite is true, Yama is heavily typed, almost everything in the Yama document
[02:08.440 --> 02:09.440]  has a type.
[02:09.440 --> 02:17.520]  Here's a selection, they're nothing surprising, all the times you see here, they are also
[02:17.520 --> 02:22.440]  present in JSON and that's also inspiring an interesting question.
[02:22.440 --> 02:30.920]  Let's say you have a Yama document, could you just change the syntax to JSON and have
[02:30.920 --> 02:33.320]  a valid presentation?
[02:33.320 --> 02:34.800]  What that work?
[02:34.800 --> 02:38.960]  Oh, you're too good.
[02:38.960 --> 02:44.880]  I attracted the wrong audience because, yeah, no, that doesn't work.
[02:44.880 --> 02:48.840]  It falls apart with the map type.
[02:48.840 --> 02:52.320]  The map type in Yama is really, really wide.
[02:52.320 --> 02:58.680]  It does allow for such things as composite keys to its entries.
[02:58.680 --> 03:03.400]  If you're really interested, they're introduced by, what's the token?
[03:03.400 --> 03:10.360]  Should mark space, so that's a thing.
[03:10.360 --> 03:18.640]  There are not so basic types, O-map is an audit map, the regular mapping is not audit,
[03:18.640 --> 03:25.400]  set is somewhat, yeah, special, there's not a complete list, by the way, there's a way
[03:25.400 --> 03:29.920]  to have Yama inside Yama, that's nice.
[03:29.920 --> 03:35.480]  And there's a type specifically for binary data.
[03:35.480 --> 03:42.880]  This one is really, really useful, provided it actually works.
[03:42.880 --> 03:46.160]  Try it.
[03:46.160 --> 03:53.720]  The problem really is in JSON, XML, also in Yama is you can't have certain bite marks.
[03:53.720 --> 04:00.560]  So the first 16, I believe, character points, they are off-limits, they are controlled signals,
[04:00.560 --> 04:03.840]  they can't be part of the stream.
[04:03.840 --> 04:10.280]  With this type, you can just base 64 everything, and once your Yama is being passed, that is
[04:10.280 --> 04:16.520]  being expanded into the raw binary, pretty neat, eh?
[04:16.520 --> 04:30.600]  First example, this is not minimally Yama, but it does help to illustrate a few points.
[04:30.600 --> 04:36.680]  I suppose a lot of you got a lot to do with, say, OpenShift, Kubernetes and the like.
[04:36.680 --> 04:40.320]  You've seen three hyphens a lot, haven't you?
[04:40.320 --> 04:41.320]  Okay.
[04:41.320 --> 04:44.320]  Who knows what that does?
[04:44.320 --> 04:52.880]  Not quite, no, no, it's not the beginning of the document.
[04:52.880 --> 04:57.160]  What this is is a document separator.
[04:57.160 --> 05:03.000]  So what you see here is it's not actually a Yama document, it's a Yama stream.
[05:03.000 --> 05:10.560]  Yama is meant to be streamed, possibly, don't do that unless you have a solid message framing
[05:10.560 --> 05:16.800]  because truncated Yama tends to be earlier than Yama, so I think twice before you do
[05:16.800 --> 05:17.800]  that.
[05:17.800 --> 05:25.960]  The thing is, most of the tools that you have with Yama will assume there's only one document
[05:25.960 --> 05:26.960]  ever.
[05:26.960 --> 05:32.280]  You need to do some convincing to get all the documents out of the stream.
[05:32.280 --> 05:40.880]  By the way, do you know what happens if you omit those three hyphens?
[05:40.880 --> 05:42.880]  You do.
[05:42.880 --> 05:49.280]  Okay, pretty much everything you see here, if it's omitting, it's implied.
[05:49.280 --> 05:53.720]  Also, great, eh?
[05:53.720 --> 05:58.840]  Say for the version number, there's also a bit of a homework for you, there's a chance
[05:58.840 --> 06:05.640]  this is going to break your tools because they do not understand version 1.2.
[06:05.640 --> 06:10.160]  The majority of the tools are still stuck at 1.1.
[06:10.160 --> 06:17.040]  Yeah, let's get into the time for it.
[06:17.040 --> 06:20.160]  This is something you see quite common, what do we have here?
[06:20.160 --> 06:28.800]  It's a mapping with a single entry, which shares the key variables, inside is another
[06:28.800 --> 06:34.080]  mapping for the key app version, we've got something in it.
[06:34.080 --> 06:37.960]  Now there's no indication to what dantotype that is.
[06:37.960 --> 06:39.960]  It's an integer, right?
[06:39.960 --> 06:40.960]  Agree?
[06:40.960 --> 06:43.240]  It depends on your schema.
[06:43.240 --> 06:47.640]  It depends on your schema.
[06:47.640 --> 06:56.760]  We're not quite there yet, but this is for most pure Yama, so this is an integer, we
[06:56.760 --> 07:01.400]  agree, for the time being.
[07:01.400 --> 07:04.160]  This is a float, right?
[07:04.160 --> 07:10.000]  This is a string, and this is still a string.
[07:10.000 --> 07:12.680]  You may have noticed I omitted a few things.
[07:12.680 --> 07:13.680]  What's three-point?
[07:13.680 --> 07:17.680]  It depends on your schema.
[07:17.680 --> 07:18.680]  No?
[07:18.680 --> 07:21.680]  Yes, it does.
[07:21.680 --> 07:29.680]  It says, the regular expression for float says three-point is float.
[07:29.680 --> 07:33.680]  What is point one then?
[07:33.680 --> 07:36.120]  It's also float.
[07:36.120 --> 07:41.720]  So if you want to make sure this is really always a string, you may be tempted to do
[07:41.720 --> 07:47.880]  something like this, I quoted things, our thing, also in Yama, big surprise, so you
[07:47.880 --> 07:56.440]  quoted also, so the professional may do something like this.
[07:56.440 --> 08:02.120]  This is a tag, the two exclamation marks means it's a global tag.
[08:02.120 --> 08:08.080]  So there's global meaning, oh, I'm running out of time.
[08:08.080 --> 08:10.960]  It's a string, have my word for it.
[08:10.960 --> 08:16.280]  The true professional who lost the plot may do something like this.
[08:16.280 --> 08:24.080]  These marks are identified by URNs, and also there's a namespace mechanism in Yama.
[08:24.080 --> 08:30.760]  There's a part where you go, yay, namespaces.
[08:30.760 --> 08:35.920]  So advanced features, this is something you do not commonly see.
[08:35.920 --> 08:43.120]  Most users of Yama are probably unaware this exists, but you have some tools to reduce
[08:43.120 --> 08:46.960]  duplication redundancy within your structures.
[08:46.960 --> 08:54.160]  One is anchors, they're basically marker, and one are alliances that do invoke those
[08:54.160 --> 08:55.160]  anchors.
[08:55.160 --> 09:06.040]  Pretty nifty, also these do give way for an attack known as one billion laughs.
[09:06.040 --> 09:17.280]  So it's basically you can set an anchor to an array or list of alliances who themselves
[09:17.280 --> 09:20.680]  contain a lot of anchors.
[09:20.680 --> 09:26.920]  So this allows for a very complex presentation of a very complex data structure that quickly
[09:26.920 --> 09:31.360]  expands plenty of votes.
[09:31.360 --> 09:41.880]  So if you happen to consume Yama from untrusted sources, this is something you should know.
[09:41.880 --> 09:45.680]  Magical operator, this is another really nifty tool.
[09:45.680 --> 09:57.240]  It's only valid in 1.1 of Yama, it got immediately deprecated in 1.2, and also it's a data type.
[09:57.240 --> 10:05.840]  It's there to basically merge mappings into all the mappings, great stuff.
[10:05.840 --> 10:09.600]  So test from the trenches, these are examples that really happened.
[10:09.600 --> 10:17.680]  Do you see, I should explain this, this is part of a GitLab setup, as a script, this
[10:17.680 --> 10:23.960]  is expected to be a sequence of strings to be executed on the shell.
[10:23.960 --> 10:25.960]  That's not what it is.
[10:25.960 --> 10:27.960]  What is the answer?
[10:27.960 --> 10:28.960]  No?
[10:28.960 --> 10:40.680]  Oh, very good, yes, that's not a string, it's a mapping.
[10:40.680 --> 10:46.440]  Because of the single pass design of Yama, the algorithm is very, very greedy.
[10:46.440 --> 10:53.840]  So it sees that colon there and says, oh great, this is a mapping, and completely ignores
[10:53.840 --> 10:57.200]  the quotations.
[10:57.200 --> 10:59.640]  So how do you fix this?
[10:59.640 --> 11:10.960]  There's one for ways, yes, I think the third one is my favorite, the fourth is really unsafe
[11:10.960 --> 11:17.160]  because once again, raw binary data, perhaps I don't know that.
[11:17.160 --> 11:23.040]  This is another favorite, again, GitLab CI, we have a mapping.
[11:23.040 --> 11:27.440]  We try to set some variables for GitLab to expand.
[11:27.440 --> 11:33.080]  What is the content of bar?
[11:33.080 --> 11:37.600]  I must remind you, mappings don't have order, oh, who knows?
[11:37.600 --> 11:41.560]  I thought the answer was for us.
[11:41.560 --> 11:46.520]  Oh, no, it's going to be empty, it's going to be empty.
[11:46.520 --> 11:53.280]  Another thing is, the mapping doesn't have an order, the Yama implementation in GitLab
[11:53.280 --> 11:59.440]  has other ideas, so it takes the mapping and applies an order on it, so bar goes top because
[11:59.440 --> 12:02.880]  lexicographic order.
[12:02.880 --> 12:10.320]  And then there's a single round of interpolations, and foo at that point is empty as a variable.
[12:10.320 --> 12:12.200]  So how do you fix that?
[12:12.200 --> 12:31.080]  Either way out is you rename your variables, or this, thank you, thank you.
[12:31.080 --> 12:37.240]  This never happened to me, but it's been too good to pass.
[12:37.240 --> 12:38.480]  What do we have here?
[12:38.480 --> 12:40.080]  What does languages contain?
[12:40.080 --> 12:50.640]  It's a sequence of, we will need to drink.
[12:50.640 --> 12:58.920]  It's one string and one Boolean, because no, which we're supposed to present Norwegian
[12:58.920 --> 13:08.320]  here, is accepted as a Boolean, so you need to tag that or quote it, however you wish.
[13:08.320 --> 13:17.240]  So my observations, because of the edge cases of the hidden complexity, there's a huge disparity
[13:17.240 --> 13:24.040]  in features that various tools actually support, they also show different behavior.
[13:24.040 --> 13:28.080]  It's one hot mess, I can't put it in other words.
[13:28.080 --> 13:36.800]  Also, if you're writing Yama, it is admittedly really a pleasure, it's easy to type, but
[13:36.800 --> 13:39.520]  you can never let your guard down.
[13:39.520 --> 13:45.800]  Yama would try to do a lot of lag work for you, being very accommodating, and sometimes
[13:45.800 --> 13:52.000]  the worst way possible.
[13:52.000 --> 13:57.800]  Some proposals on that, because the versions of Yama really do different behavior.
[13:57.800 --> 14:05.080]  You should start to tag your streams, accordingly, you should see that the tools you use for
[14:05.080 --> 14:10.240]  consuming Yama are properly configured, things like language-specific extensions.
[14:10.240 --> 14:18.520]  So part of the Yama streams could be evaluated in the process, read, executed, and that's
[14:18.520 --> 14:21.840]  a bit scary.
[14:21.840 --> 14:28.480]  As most of, yes, right, as most of Yama is relatively simple, the complexity is mostly
[14:28.480 --> 14:34.000]  because it's deeply nested and you can't properly edit it.
[14:34.000 --> 14:41.680]  But Yama may be a solution, it's a strict subset of Yama with a lot of the ambiguity
[14:41.680 --> 14:49.600]  removed, way safer, way easier, tooling support is so-so.
[14:49.600 --> 14:56.760]  So I teased a question with this talk, the question could be, Yama is exactly then the
[14:56.760 --> 15:03.400]  answer if all you wanted was Jason with comments.
[15:03.400 --> 15:06.920]  Some other niceties as well, but that's pretty much it.
[15:06.920 --> 15:15.200]  So this concludes my talk, thank you very much, you've been terrific.
[15:15.200 --> 15:16.720]  Is there any questions?
[15:16.720 --> 15:18.720]  Please repeat the questions.
[15:18.720 --> 15:20.720]  We've got four seconds.
[15:20.720 --> 15:25.720]  Is Jason any better?
[15:25.720 --> 15:31.680]  There you have it.
[15:31.680 --> 15:33.680]  It depends on what your use case is really.
[15:33.680 --> 15:35.240]  Repeat the question please.
[15:35.240 --> 15:42.520]  Oh yes, the question was Jason any better.
[15:42.520 --> 16:02.720]  So yes, thank you very much again.