 Otherwise, I have to try again. Yes. Okay. Okay. So, I tried somehow to get both. Do you see only the slideshow? I just start. Okay. Today's my anniversary. I started exactly 21 years ago on the 15th of October as Hamburg. So, freebies for a free beer for everyone. As well, I'm the maintainer. Are you still working? Do you hear me? Hello, hello. Yeah, I can hear you. Just so we can hear you. All right. Sorry. So, the maintainer of the audio toolkit, I'm talking tomorrow. So, there's no real maintainer, but there's something from there sometime. And recently, because I rejoined the AudioFTC, I became the editor two months ago after spanning six weeks to fixing AudioF103 and tooling on this and starting the GitHub. And I did this with Michael Stahl, who is also co-editor. And even more recently, I became a co-chair of the TC chair. So, it's time to celebrate. And let's talk about the reason of the AudioFTC. The TC is a technical committee. And it's maintaining the specification, which is the blueprint for Audio application. So, it was invented that there's an interoperability between Audio application. Like, if you have a certain size of paper in your printer, you can buy it from every vendor. And it fits in all printers, like DNA4 paper. It's quite similar. That's the whole reason of the standard of an ecosystem and independence and like a legal blocks, right? They're comfortable. And to talk about why we need Git, and when I say GitHub, it can be GitLab as well. The GitHub is just for the AudioFTC. The usual thing, the usual process from this committee is that we meet every week and we discuss JIRA issues. That's also the tool of choice. And when there's a solution, we paste it in and in the end, the editor takes the JIRA solution, put it into the certification document. That's a simplified work process now. And so what about GitHub issues? Well, they came later. And my choices and my ideas that we put the talk about AudioFTC, the features, semantics, people are interesting in enhancing AudioFTC. They're still based on JIRA. And when it's coming up editorial changes, how we make this differentiated spec, how we can make something better, it's on GitHub. So we have a separation of concerns here. So why version control? So I always thought it's a good idea to, if we have a blueprint of software, it's the same reason when we work on software. You want to have all your deliverables on a single plate like the source code. And basically there's ODT, which is also transformed to PDF and HTML. And the grammar, the rex and g grammar. And you see this bold rex and g HTML is something new. You know, maybe you know the request for changes. And they're also in HTML. And similar, I created some... I can't see it now if you can see it. I don't paste them now. But it's just an HTML page or the RNG in HTML. And now they are linked together. So when you search something, then you can jump through the document. And also, I used some fragment identifier here to have some line highlighting it. So if anybody's invited to enhance this tooling, I would love that you click on the line and then jump to that line. You change the fragment identifier. Learning just jumps. So, and back to it, aside of that, we need of course the tooling. And after years, so nine years ago, ODF Monitor released and where all this transformation, the Excel transformation of ODT to HTML, that was, yeah, it was not broken, but it was not adopted. It was once my task at the web office, I started at some mic stems. And the same Excel digital transformation, Microsoft was so kind to update in the LibreOffice, it's the export filter to XHTML, which should be changed to HTML because nobody's using XHTML. And the other thing is about extra default values. Because once there were default values in the grammar, they were removed because the silly parsers just inserted them in every XML and blow up the XML. So instead they were taken out of this schema and into the specification. And there they were highlighted with styles and it could be extracted. And, for instance, the OD toolkit used these default values to generate source code. And I realized when I rejoined that this was totally completely forgotten and broken and updated it. And it's not made into the intervals because they are conditional default values and so it's not ready and it was never. So, but it's going to be, we're working. So, and last but not least, we, of course, we need to enable reviews, like for a principle, is the text in the GREC really the same way overtaken the ODT and was the fix in the ODT correct. And because these are binaries, Michael and I came up with the idea that we used in LibreOffice the configuration to pretty print the XML. And we're also on Zippit there. And we might in the future do some automatic tests and slide before you change something, we do a pre-commit hook, meaning an automatic test that, for instance, the extracted default values are still the same and not any regression. So, and last but not least, the automated OASIS release process. So, what is this? I come to the next slide, please. Oh, first of all, sorry, this is the structure. When you go for it, we use the simple major standard director layout, meaning there's a source with main and test. The main contains all the deliverables and the test is all which is not even delivered like the tools and tests. And the docs, this is a GitHub feature. It's been directly mapped to a page, a GitHub page, where, for instance, people can check the HTML output before it's being integrated, which is pretty cool and useful. So, what's the automatic process? So, from a high level, there's a system called OASIS, or the TC, received from OASIS from time to time, new ODD templates about look and feel, and sometimes they need to deliver a zip bundle of the release. And the problem is, I have faced it many times and spent really days on this, just to change dates within and they always release IDs and URLs and some names. And this is very, very cumbersome, yes, and many other things as well. And usually, all software developers would put a variable in this and will exchange the variable during the continuous integration of the automatic release, okay? That's exactly what we should do here as well, and we haven't done yet. And that's the solution to put some place of this thing and every time, constantly bundle a zip with every change that could be delivered to OASIS, yes. So, currently, it's pretty time-consuming. So, what is the long-term goal? There's some, I coined it, it's going to adjust specifications. So, it's like a vision like the mountain in the end and the horizon, it's when the specification is a blueprint, right? Then it makes sense that the blueprint software harmonized. Like, if the software, but currently software has been updated, usually not weekly, maybe labor office, I'm not sure, is it now a quarter or half a year, but it's much faster than the nine years of the last ODF on a two-speed specification. And they need to be in harmonized. Like, usually you should first implement the updated blueprint and then generate parts of it from the specification. And so, this is a time gap. It's a common problem, and I stated the solution. We need to have more automation, more generation. Like, when there is, like, default rate, they have to be extracted. And also, these human readable specifications need to be generated from some basic data, yes. And also, test document maybe, piece of test, should be at spec level. And Regina started with test documents because Microsoft asked for it to have ODT test documents or the ODF documents one or three, and it makes sense to collect them at one place and know every application after we implement them and re-manage those as well. And to give an example, take a look at these. This is a common order on a two-table table. You see there are three chapters, like paragraphs. There's first all the parents of this table, and then the next is the attribution of the children. This is a very easy way of generating things. It's been generated and should be generated because you don't want to maintain this manually. So, another thing is about ODF adoption, right? I know it's hard to put it here, but with every ODF release, ODF applications have to be updated. And, well, honestly, a spec and application can be, and that's not happening at the moment, can be split into features. Currently, these features or these changes are bundled by G-Ray issues at the end of the spec. When you look at one or three at the agenda appendix, there are some G-Ray issues, but that's not the optimal way you have to look. The G-Ray issues have to read them. That's not the automation. So, what can we do better? Of course we can. So, imagine there's a new feature, like, oh, we have a page orientation, which seems to be very simple, and every table and paragraph is an existing feature. You can change the landscape, the orientation. You can use landscape or portrait of the page, meaning it's horizontal and vertical. So, from a software developer's view, you say, oh, that's simple. We have this paragraph or table object, and we have a Boolean attribute that's either landscape or portrait. That's easy fix, yes? But how does it look in the XML? So, we have the user feature, the semantic definition of an orientation that can be changed on a paragraph, and we have this XML syntax. And, okay, this is one of the, I show you now, this is one of the most complex things. It's hard to see here, but at the bottom, there's a table, sorry, there's a paragraph here, and it's referencing up in yellow to the paragraph style, which is a page style in orange, and that's a content XML, moving to a different XML, and then going to the page layout, which is, well, it's a little bit difficult, and especially if you want to have, like, oh, automatic generate this feature, like what happens if in the runtime model I change the layout on the paragraph, then this XML has to be automated, altered, okay? Depending on true or false, yes, in all cases. And that is what I'm going to work in the next year and the other two kids. So this is going to be tomorrow, and just written here the paragraph styles, the style to master page, and so on, okay? So it's a little cumbersome, and so there's a certain gap, and to have it in a specification, it's like to define this, and the source code is simply, and I did myself a little bit once, you have to manually write it down, you have to glue it together, and it's, you have to, I've written it now for Java, and when somebody comes in, I want to have a T-sharp on C++, I have to write it again, and that's stupid. I think you have to do it in a decadent way and generate source code from it, and I'm going to try this. So my personal wish list is here. I want to have enhancement of the ODF spec review in generation to toss and talk about it, so it's continuous integration, continuous deployment. We want to have a machine readable ODF info set, and first of all, we are missing semantics. So I had joined the ODFTC in summer when I rejoined when the question came up, what does it mean when the cell, a table cell, is empty? What does it mean for the XML? So I was, yeah, it sounds boring, but to me it was very interesting because that's exactly what I need. I need a semantic view that every user can understand, or an ODF user, and then I have to, and I need for this some semantic dictionary, maybe Regina started with it already, and like we all know a paragraph of these things, and from this we can talk on to the ODF semantic changes because it's funny, but test-a, because funny, because in all rich text editors, ODF application, you can insert a table, insert a row, insert column, but it's not defined that you can do this. You expect it as a user, but in my point of view, it's unspecified, that we specify unspecified, whatever. It's unspecified. That's not been there. So if we have to do this, we could have a performance test so we can compare things like Post-This-Map and have things like HTML does. Asset. Okay, and that's the last slide. It's just, if you didn't understand that, at the beginning of the year, Titi talks about my 20 years, the past and the future, and you see the next million document for much to embrace all this and more, but it would spark this. That's all. Are there any questions? But I think I'm running out of time anyway. Yeah, thank you very much, though. Maybe if you do have questions, you can write something on Telegram and people can ask you those on the site. Just call me, ping me, yeah, directly. Thank you very much. Thanks. Again, as I mentioned, Sarah's talk will