 OK. Can everybody see the slides now without irritating hip hop? Yes. All right. Yes, I can see it. Awesome. Good. Let's get this going, then. Welcome, everyone, and hopefully kicked. Yeah. Excellent. That seems to work. Yay. That's great. Somebody's going to be aggressively kicking, because I think that guy will keep coming back. So now let you get the hang of it. So let's get this going quickly before it comes back. ODF. Everybody knows what ODF is, Open Document Format, State of the Union, Quick Recap on. Thank you, man. Good. Back to the slides. Where are they? Here. ODF. And how did we get there? And where are we going? Quick introduction, who I am. My name is Thorsten Behrens. I'm working for CIB since 2015, built the liberal office team there. I'm actually one of those naughty people who were founding TDF liberal office. And I'm also on the TDF board. I've been working with liberal office and the predecessor open office as an engineer since 2001. And as a person, I'm a hacker computer scientist. I've been fighting for open source. Ah, what a relief. I think this is going to be the theme of this talk. So at the very least we can say it was an entertaining session, maybe not because of me. So very quick work through history of ODF. How did we get here? And what are we doing? The deep past. It all started with a number of great things with Sun Microsystems. Rest in Peace was a great company. The inaugural TC meeting there was some inside Sun. There was already contacts through ASIS for other standards. So just people were just using that inaugural to see meeting pretty fast track in 2002. So let me continue. So why do people do that? Well, actually back in the day before Sun, a study version said that XML is cool and they wanted to get rid of the binary file format. So they were pushing towards a native XML file format. And so that's where it all flew from. Then it was run relatively quickly, ODF 1.0 in 2005, 1.1. 2007. So basically someone joins quite regularly and they start sharing a video of. Yes. Sorry, can people still hear me and see my slides? Yes, we can hear you. Things are kind of fine now. Oh, I just please tell me somebody's not going to spawn up. Okay. Let me just continue. So right. And people please poke me because I can't see both slides and the room at the same time. Something goes wrong. Yeah, let me know. So just speak up and poke me. I will just continue meanwhile. You'll figure out what to do. So what you see is there was relatively quick progress in the first five years. And then it slowed down with ODF 1.2 ratified in 2011 and advanced to ISO standard in 2015. And after that, well, you can guess it correlates with the sale of selling of some microsystems and the fork. So what still happened was the chat hurting of 1.1.2 that was mostly helped with by IBM. And then there was lots of activity, but mostly inside areas like change tracking. There was advanced document collaboration subcommittee, which had three competing drafts done in succession. Some of them a great deal of time went into that. It's actually currently dormant. Nothing is going on here. So we're going to go back to the main stage. 2015-2016 work shifted back to the main TC, working on so-called ODF Next, which is now officially ODF 1.3. But back then there was no clear targets, really no funding, no focus. And so 2015, there was this thinking, where I'll be going? Where is this heading? There were a number of few hundreds of issues that were targeted 1.3. There was this problem. People didn't want to close issues or shift them. And the focus then shifted to standardizing pretty much existing practice. So rather not have this Star Trek future, everything is wonderful, you can render everything, every document in this world from every source, but rather what is actually implemented in software with this provably working and catching up with those implementations out there in the field. There was some great triage. Stole that from Michael Stahl 2015-2016, but more than a year when actually some focus went back into the standardization, something that was obviously broken already in one of the two earlier. Let's fix that for the next version, feature with an implementation. So it's implemented in, I don't know, Microsoft Office or LibreOffice or OpenOffice or AbbeyWord. Great, let's take it as well. Great idea, but no funding, no one implementing it. Okay, let's call it later. And everything else, Star Trek Future, great plans of grant intellects. Okay, let's close it and come back when you've got funding and have it implemented. And also closing by that, by reviewing pretty much every issue, closing a metric ton of duplicates. Yes, but after that, what the hell are we doing now? So the problem was obviously no more big players, no more easy way to get people spending time on something that is very, very boring, which is some TC work, which is lots of admin overhead, lots of rat type, lots of process, very little hacking. So how to resolve that conundrum? Well, obviously we can try with community that was the partial success with, for example, Regina Henschel, one of the core contributors to the ODF 1.3 standard and doing it all as a volunteer. And so there was like a number of names in the TC, Horst van den Erver and Andreas from I think University of Waterloo were doing that on spare time or partially spare time, but as I said, it's rather boring work. So what TDF came up with, initial idea again from Regina was to put some money there and hoping that would help fixing that, making progress. So the TDF was in 2018 getting some funds approved and trusting those funds with public software CIC and UK Charitable Company, Charitable or Community Interest Corporation actually. So it's a non-profit entity chartered to attract funding for continuing the ODF TC work and the editing. And it was successful. So the COSM project attracted funding from Microsoft CIB and Collabora and was matching that with funding from TDF. So in the end, we got two editors and a bit of development work for the ODF toolkit funded to get 1.3 implemented, edited, heard it through the standardization process with the initial goals of 1.3 actual review work starting April 2019 committee draft later in 2019 and finished standard by end of 2019, which as you might have seen did not quite work out like that. So the current status is right now the initial funds have all been spent we're kind of waiting for 1.3 to happen which has been almost done since pretty much the beginning of this year. It's just taking an inordinate amount of time to fix tiny little editing mistakes and then you have a multi-weeks delay because then you need to re-trigger this standards approving process and getting the OASIS machine to grind and get a new version out and putting it up for voting. So that's not much actual work going on just lots of busy work and spinning of wheels. So the hope is to have it finally done or finally approved and ratified as an OASIS standard by the end of this year. So it's one year delay mostly due to editorial errors and process errors and I will get to that in a moment. So TDF has approved follow-up funding for ODF 1.4 and improvements in the editorial workflow which are obviously necessary. So that's 10K new budget also again for matching funding so again the call goes out to companies, corporations, also perhaps governments who are using and benefiting from ODF to perhaps ship in a little bit of money TDF then happily matches that. Right, and the editorial workflow so it's essentially lots of manual work very error-prone nobody did that in 10 years so even people who did that in the past knowledge has been a bit rusty tools have changed it's all kind of creaky and leaky so the modern way to attract that is like have some continuous integration workflow there and I think that's achievable. Beyond that, beyond chipping and funds and getting your funds matched by TDF what else can you do to help ODF? So well of course work on the standard so if you're a TDF member you can join the ODFTC and work there otherwise that's quite some price tag to that but if you're a member TDF happily gets you there so of course that needs a bit of time I think the minimum is probably an hour or two per week to be able to read the mails and attend the calls but likely more of course you can also propose features do bug fixes and do QA work on LibreOffice and other ODF processing applications in OASIS itself join other TC's or OASIS projects do lobbying work tell your local MP or lobby inside your company that ODF is a great standard and of course you can donate to TDF which helps funding projects like COSM and also helps towards paying the OASIS fees the membership fees a bit a bit more details what's happening so well updated timeline as I said committee draft was out committee draft one was out in September 2019 so there's some kind of waterfall diagram and standard committee so you first draft something and then you think as a committee well it's done then you call the committee draft which then goes through some public review where you can have other people point out the obvious mistakes then you can get yourself upgraded to committee specification and the committee specification which has the stamp of approval then the TC says well we're done which then goes out for another public review and a public vote by all TC members and then finally becomes an OASIS standard so yeah so we get stuck pretty much at the very beginning of that process there were issues found omissions problems in the production cycle several attempts to fix that there was an initial vote for committees back in 2019 but then more errors were found and so we have a committee spec O2 about ready to vote on now so yeah about one year late and the hope is if nothing else goes wrong that we get it OASIS standard end of this year what is missing for that should okay so if there's any questions just fire away otherwise I will just keep talking right end of the year so the next step after this yes this out is state of use so everybody out there or if it's something that's an ODIF toolkit would be great to get your signed statement of use that you have implements and are very happy with ODIF 13 and of those products between three of them to advance to the next step in the standardization process you can also do marketing around ODIF the adoption TC as we open this ODIF project to tell you tell you MP tell your government to lobby around open data and open government go for initiatives around open standards just to state that here standard is publicly accessible so no nothing hidden no NDA you need to sign it's like unencumbered you can implement the standard you don't have to pay patent royalties and the actual process of standardization is open travel it's a smoke toilet room and only special people are admitted so everyone can join really given the time I made a quick walkthrough the development projects related to ODIF that happened there in the past also largely done by TEP but not exclusively ODIF validation which was one of the very first steps to get something that perhaps in the end in next year 2021 with the editorial workflow we will become a culmination that is from code to standard to written approved standard ideally there should be no losses so when when you start hacking on something and you change the file format in the office that should ultimately end up in a change or in an update or at least in a proposal to change the standard and not accidentally get lost because nobody realized so what's in place now is a way to have every unit test that writes ODIF files have the ODIF and ODIF validation to run over that and the same is true for a weekly crash testing run that essentially loads and saves possible documents we can get access to in all the back trackers of a number of projects so with that it's not impossible but it's kind of unlikely at least if you adhere to processes and write unit tests for your changes that we detect when you change when you modify the way liberal office writes ODIF so if you notice that unit test breaks you have to change the schema changes to the schema will get flagged at the latest when a release happens and then we can write a proposal to the ODIFTC for a change and those get tracked in JIRA so at least it's not lost there and then hopefully it gets written into the next standard and also the fact that we want to automate the spec writing so ideally when you do a change that affects the ODIF format you change the schema and you give us a little bit perhaps in the commit message a little bit of prose that describes what you're doing there that then the ODIFTC editors can use to convert that into something that can put into the standard doesn't have to be standardies just a lay person description of what this is doing is enough to get this started another number of things like improved layer support there was from the German prototype fund some support for the ODIF toolkit library there was from the German federal computer security they funded open PGP support for ODIF it's also part of ODIF103 the necessary amendments and the last one was ODIF103 converting all the extension namespace that had accumulated over some oldest one was more than 13, 14 years old still during open office times convert all those let's extend ODIF and at some stage we will roll it into the standard features roll this back into the main or ODIF namespace, XML namespace which was quite a bit of work but that's happened that's included in ODIF70 with necessary back quotes to the older maintained version so that at least we can read that you write ODIF toolkit interesting story there initially at the Apache foundation and TDIF has inherited that from Apache and it's now maintained in the document foundation GitHub repository and we're also TDIF is also contributing and helping and it's an essential part of ODIF and also the editorial workflow and the validation it includes the ODIF validator we're using to make sure we detect any changes bit of marketing blurb like best stand alone for ODIF plus some very very nice tools that is a prototype fund sponsored for decomposing a document into changes and operations what's up next ODIF next which is possibly ODIF 1.4 perhaps ODIF 2.0 at some stage so not necessarily all of those ODIF next issues going to be 1.4 quite a bit more to file from the wiki page that has the ODIF liberal office ODIF extensions all of that needs to be rolled into the schema I mentioned that gets used by the unit test validation and perhaps more from the D past that we have not detected yet and finally the editorial workflows that some something that has to happen next year as well right now the TC already has a repository on github it's already as much as possible working from there for producing the standard so when you need to change the standard ideally you just submit a pull request what's missing is a completely fully entered and automated pipeline to get the schema that's planned for next year yes and perhaps we can track other OASIS projects to follow us there to adopt that as well and then perhaps contribute to the automation effort there and keep that going it's it's not unheard of I mean for web standards it's pretty standard to do it like that meanwhile it's just for this relatively heavy weight standard writing that is at OASIS and that ISO in particular it's kind of trailblazing here so how is that it's working well and attracting others to follow that great so that's the end of the 30 minutes I'm glad no further interruptions from funny videos thanks for your attention thanks to my employer for having me spend time on great things like LibreOffice and ODEF and if there's any questions I don't know if we have a few minutes left I have one question should how about deprecations of existing properties or elements anything concrete you have in mind just general workflow what would we do is the same like you would add new things to ODEF or for example what I have in mind is like gradients maybe there are some properties that aren't needed for example anymore or I don't think we should include them so for many things in ODEF are not mandated so the wording of the standard is quite often not verbatim but the essence is optional so there's very few things that are required so you don't need to be able to correctly display every single element and attribute in the standard because the rendering is not standardized so as long as you're not crashing by reading such a file you're free to ignore it whether this is good user experience whether this is making your friends when somebody loads a file from 10 years ago and something is missing that's a different question so as such it's I think it's probably unless you have a concrete proposal where something is absolutely required by the standard and it's a burden to keep that maintained on our side and support it I don't think it's a problem worth fixing because we can simply decide at some stage to deprecate something on our implementation side and say well here is some loaded in 64 and then save it as 0 and save it as 1.3 and you're going to be fine and in five years we're not going to support this attribute anymore just to answer the question yes so I think it's not a question for ODF it's a question for let's say liberal office product I mean if there is an idea if we should deprecate some some standardized features I mean we did something similar for the I believe for the way that writers are storing tables like nested tables so that's the sub table versus I think joining rows and columns and there was a change I believe in ODF 1.2 where it was just a different table model introduced so there's a history of actually throwing something out of the standard but adding new features and then henceforth using that from the software another example would be the lists for which there were two different presentations in ODF 1.1 and one of them was deprecated in ODF 1.2 because they just both allowed to do the same thing which is kind of pointless and the second one was only implemented by K-Office version 1 did we clean that up? that mess up I think we did yeah it might even be possible that we have an issue to actually make up so it's definitely deprecated I'm sure of that for other questions or perhaps suggestions great things we should do in ODF land just in case something comes up I'm on ISE and telegram and there's some email address on the first slide so just feel free to poke me and with that I'd say we'll close this session six minutes late thanks so much again and enjoy the conference, take care bye