 Good afternoon. Welcome to the third talk in this session. It's very nice to see so many familiar and friendly faces here. I'm standing in the corner because the cable is short, not because I'm scared of the audience. I would have preferred to stand over there, but it's a bit tricky. If you don't mind, I'll stay here. The building you see in this picture is actually the Ministry of the Interior. The two sharp peaks, that's the Ministry of the Interior in the Netherlands. That's where I've been working since last October. I'm a civil servant now. You might know me from previously visiting the Plugfest where I was trying to plug WebODF. I'm not the main developer of WebODF anymore. This project is continuing at COLAB Systems in Germany. But I'd like to plug it anyway, as I always try to do at any Liberal Office conference. I tried to run it here, but the Wi-Fi was a bit slow to load my document in the actual WebODF, so I'm using Liberal Office to do this presentation. The future of WebODF. Small slip of the tongue. Yeah, I'd like to start at the start. What's the point of WebODF? Why do we even have it? Well, it's to enable real choice for the computer user. That's the most important thing. We need standards so we can have multiple implementations that support an independent standard, and that gives the user choice to choose between different applications, such as Liberal Office and Liberal Office, or maybe Microsoft Office or WebODF, any other implementation. Right now, in 2015, we have a situation where what you do mostly on your computer, at least that's what I'm seeing, is that you're sending emails, reading, writing, you're reading web pages, you're also writing web pages or posting on social media, and you're reading and writing office documents. And two out of three have good standards. The last one, Office Documents, also has a good standard, but it's still mostly a market where there's only really one big company offering the software. So we haven't really achieved the situation where there's a lot of user choice. And I think whatever we talk about for the future of WebODF, we should keep in the back of our minds that we have to aim for better user choice when we try to improve this standard. ODF is developed at Oasis. That's a standard body, just like W3C and ISO, and it has some other very cool standards. One of the most new ones is Legal XML. Where different governments are trying to standardize an XML format to put their laws in. So then we can have the same XML format for different countries and different laws to more easily compare them and also to allow people to investigate the information in these laws in a more systematic way. But here we're talking about ODF. And I have been working for the government since October, but since this September, they are allowing me to work two days a week on the ODF standard. So the Dutch government has seen, yes, ODF is very important. It's important for a digital future, and we are going to pay somebody to actually join the TC and work on it. So I'm very happy with that. And I'm really looking forward to working very hard on the standard and everything that surrounds it. How do we make the standard in the TC? Well, I guess for many people you're not really familiar with how it works. You may be familiar with how Legal Office development works. And the standard is not so different. We have an issue database where we find problems in the spec or ideas for improvements and we label them and say in this version of ODF we want to change that. In that version of ODF we want to change that. Or we write down, we see an issue here. Maybe at some point we should think of a solution for that. We do this in bi-weekly phone conferences and we have a public mailing list where anybody of you here can mail and send us comments. If you really want to be dedicated you can also join the ODF TC. Everybody is free to join. Private persons are very welcome and in the ODF TC we have a couple of private persons joining and doing on-work. One of the co-chairs of the ODF TC does this purely from this private choice. One of the improvements we're going to make in the TC is version control. I'll speak a bit about that later. And we sometimes build prototypes to demonstrate that new ideas for the specification are good. And when we make a release we sync it to ISO so that the OASIS standard of ODF also becomes an ISO standard. And this last June finally the ODF 1.2 specification has become also an ISO standard. Here's a brief history. We'll talk about the future, but this is our history of ODF in 2005. We had the first 1.0 release after four years of work which started in 2001. Then in 2007 we had the 1.1 which was slightly larger and then in 1.2 we made a big leap again after the sort of bug fix release at 1.1 where we had very cool features like RDF metadata which is what Svante was talking about. We finalized the specification for the formulas and spreadsheets and we had a couple of more nice improvements. So what are we working on for the next version which will be 1.3? It will be mainly bug fixes. There are 200 open issues which we are working through at the moment which we want to fix before we make a release and we have a change tracking subcommittee to improve the change tracking and this was the talk which was Svante just giving. And one of the other things we're doing is we're moving extensions which are invented in liberal office into the standard slowly. But the specification is just the stars. If you have a specification then you can start writing software and when you have software it still doesn't mean that people are actually going to use it. You need local communities to help spread the software, spread the word and help people making the change to this different software and understanding what the specification is all about. This is also part of education. What's also important is having a strict policy for adoption. What we see for example in the Netherlands is you have a policy of adoption but you don't have strict rules is that adoption goes very slowly. You need to have good migration guides here at this conference. There will be plenty of talks about how to do migration and this is one of the things that I like about the liberal office conference is not just about the software. It's also very much about how to talk to the users, how to get the users to use the software and be happy with it. Now, of course you also need documentation. You need people who are willing to invest money and make a business model around ODF and eventually at the DC we'd like to get some feedback and put them in a bug database. So this talk, the future about ODF. I have here some ideas for what we can do to improve ODF and I'll go through them in this talk. At the end I would like to have a very scientific measurement of how popular these ideas are by letting you clap for everyone to say if you like it or not. So pay attention and at the end we're going to go through them and see how much you like them. If anybody has any suggestions at the end and that's time, I'm also very open to it. If there's no more time, please come to me after the talk or during the next few days. So last week we had the ODF plug fest and that's all about testing ODF and for me that's the most important thing we need to do right now. We have quite a few implementations. We have a spec with many features. So what we need to do now is make sure that all these implementations see the spec in the same way. This is a picture from the first ODF plug fest in 2009 and this is a picture of the last plug fest last week. So, yeah, did something change? Well, a bit. Yes, Andreas is in the second picture, exactly. Yeah, it's not here. If you're very quick, maybe you can find the amount of overlap between the people in the two plug fest. Yeah, Korg? Yeah, I'm not sure where I am. Let's see, I'll check. This is Korg? Yeah, Korg. This is Frante here. I had to stand at the back, I don't know why. I'm in corner now, here I'm standing in the back. I'm not a very important person, I guess. Well, here this is Flis. She is from the UK government. She gave a very good talk about how the UK government is doing adoption. I think they're doing it quite well. It's early days, so I don't know what it will look like in a year from now, but this is very nice. And the guy in the red shirt at the front, that's Michi Linnas, and he's the driving force behind all the area of plug fests. Yeah, we had 11 plug fests so far. If you look at this list, you see that all of them have been in Europe. I think it's time for a change. So if anybody knows a nice location outside of Europe, I will, yes. I already didn't see it. You already didn't see it, yeah. Might be nice. Brazil, yeah, I like the suggestion very much. Brazil, India, those are two very good suggestions, yes. Okay, yeah, so what do we actually do at the plug fests? We used to do a lot of manual testing, but what we have done now is we used all the other tests. What are those? Basically, it's more than a thousand tests right now, but we're creating still many more, and we automatically evaluate them. And we get reports like this image here. This is an output for Caligra of the World Unliable Office, and what you can see is do they write back phallad.odf? Do they pass? Do they keep the style? If you look at the Hello World written there, it's supposed to have a weekly line through it, and only Caligra actually shows it correctly, but both Caligra and Libo Office, no, actually also only Caligra loads the same as it correctly. So this is, it's a bug in Libo Office, unfortunately, so we try to then put this information to the implementers. Now, at this plug fest, we did many of these tests. We had prepared in advance, and at the plug fest itself, we sit down and look at the results of each of these tests and see if it's really a bug, or maybe there was a problem with the test. And actually, we also found some tests which we had some problems, so we fixed those. I expect within the next few weeks to publish a report on what we found during the last plug fest. Yeah, I think this is the most important thing we can do right now to improve early effort adoption, so what does work to do? The plug fest is once or twice a year, but it would be much better if you could do the testing all year round via a website. So we're going to build a website now where you can supply tests, where the tests will be automatically run on the different implementations, and we'll keep an up-to-date score of all the implementations, how good they are. For that, we have some open positions, in the sense open voluntary positions. It's very fine. Well, yes. After a few months, you realize, I'm not getting paid to help you. What's going on? Yeah, so if anybody's good at writing a front-end for a website or back-end, or if you want to be an office shop operator, that means that you keep an instance of people's office, for example, running and make it accessible from a testing server. That's also very useful. Or just write tests or comment on tests. Yeah, so I have an example of the latest test results. Now we have added colors, so you can more quickly see what's going on. At the top of the page, we have now some percentages of how good every implementation is. I have to add here that, for example, Google Docs get very bad points in this one, but it's because it's a quite specific set of tests. So we haven't covered all the specifications yet. We have covered maybe 10% at this moment. So Google Docs might be very good in other areas of ODF. Yeah, we also have Microsoft Office 2016 in there. So it's basically just a very big file. And what we did at the PlugFest is divide into groups and go through these tests and make a big report. Okay, yeah, so that was one idea, testing important. The second one is profiles. As Santa just mentioned, there are 600 different elements in ODF. There are 1300 different attributes. Nobody implements all of that. And that's not going to happen in the next years, that there will be implementation which implements all of it, I think. So maybe it's an idea, right? I'm not saying this is something we're planning to do, it's just an idea. Maybe we should write profiles with subsets of ODF. And then an implementation can say, yes, I have the full text implementation. Or I can say, I'm just marked down compatible. So quite limited set of things I can do. Or I am perfect for annotating open data. And then we combine the link data, RDF features, with the text features. Just an idea. Another idea. In ODF 1.2, we specified what formulas should look like. Before that, it was implementation specific. That's of course unmentainable, right? You need to, if you want a spreadsheet which is still working in the future, you need to specify actually what the formulas mean. This happened in ODF 1.2. Now, an idea could be to also do that for a scripting language. Right now, there are many points in ODF where you can tie scripts, but we don't specify what programming language it is. So maybe we should standardize that. Another idea. Next idea, change tracking. Well, we're going to improve change tracking. And this idea is about the minimal thing we can do to improve it. Actually, the ODF spec says, one problem in change tracking right now is that change tracking in tables, in texts, is not supported very well. If you remove a row or column in a text, that's not supported. That's not change tracked. And that's because this snippet of text is written in the spec. It says, the table changes element is usable within the following element of a spreadsheet. Why only in a spreadsheet? Actually, I don't know why it's limited to that. So if you remove this line, then the specification suddenly says that you can do change tracking on tables and presentations and in texts too. So this would be the minimal adaptation going to 1.3 to make that change tracking better. The other alternative is to go full change tracking and do what Santa just presented. Real-time change tracking and collaborative editing. There are already some implementations who support this, namely WebODF, OAC documents, MS Office Online, support sets, AB Word supports, collaborative editing. But these are all doing it in an incompatible way. This has not been standardized. So maybe we should put more effort into standardizing it. We have a subcommittee for it. But to really make it happen, we need to kick up the efforts in there. Upgrade, downgrade instructions. If we want to give users a lot of choice, we need to have a lot of different implementations. But it might be difficult for an implementation to support only F1.0, 1.1, 1.2, 1.3. That's four different versions. That's a lot of work. So maybe we should specify very clearly how to downgrade from 1.2 to 1.1 or upgrade from 1.1 to 1.2 because it's not entirely obvious how to do that. So if we specify that clearly or maybe even make software available to do it, that would be a good way to spend our time. Another idea, publishing ODF on the web. Yeah, right now, if you want to send somebody an ODF file, you can worry that do they have ODF software or not. Not everybody, if you have an iPhone, I don't think it has ODF, the reading capability by default. What you can do with that is send people a PDF. But what if you want to publish a document online? If you put an ODT online, many people might not be able to open it. They may have a plugin in their browser to open it. Maybe they download the file and open it in the labor office. So what people often do is, you can change it to a PDF, but putting PDFs on websites is not always the best solution. So what we could also do is convert the ODF to HTML. Now, we have already implementations which have a save as HTML option. But those are not always optimal. Maybe we should standardize how you should convert it to HTML. Yet again, it's just an idea. I'll go even further, but this is another sneaky web ODF plug. Maybe we should just save it in ODF as HTML with embedded the ODF file and in there also the editor with the JavaScript. It's technically possible and your iPhone will be able to handle it actually. But it's a slightly crazy idea. Your document will then be like 5MB extra if you do this. If you do the last one. If you add a full editor. 5MB extra and then you have a full editor. Why not? Self-extracting. Yeah, self-extracting. It will have a button, save ODF from the HTML file. Or you can edit it and then it will have a button, save back to ODF or save back as HTML with ODF with editor. It's technically possible, but it's a slightly crazy idea. Slightly, yeah. If you try to figure out how to hold this week, maybe we can have a prototype. Yeah, I'm going to skip this one. Oh yeah, wait. How many people are actually developers of LibreOffice here? Can I see your hands? Who writes the code? Yeah, okay. Are you proud of your editor? It's a great question, yes. Of a product, yeah. You're proud of the ODF writer, of LibreOffice writer. Okay? So why is the readme not an ODF file in the documentation? That's a markdown file. That's strange. If you're surprised of your text editor, why don't you use it? Just save ODF files for the documentation. In the code. So I'm normally not developing a writer, but writer is not a developing program. No, no, I don't mean the code. I mean, the readme files in the code. The files called readme and there's just plain text files. That's such, I think that's a bit sad to be honest. You can generate ODF API documentation and that's the work I think it's done. I'm not talking about the comments in the code. It's not working that way. I thought this would be a controversial suggestion. But still, I think if you're proud of your software, you should also have the readme be an ODF file. And of course that's a problem, right? And I see, I wrote it down, if you save it in the office, the file changes in places every time, which are not necessarily what you just edited. And that's something which you can improve. So maybe we should make saving the files more Git friendly. For the ODF TC, we are going to, I'm doing this, I wrote some code to clean up ODF files so that they work well together with Git. So we're going to put our specification into version. There is an environment variable which does some of the stuff with VM product. I was told it's not conformable to spec anymore because I was told when I was looking into that how to compare really the files on text spaces, I'm not able to generate correct spec, ODF files with those unique numbers with changing all of the tags. So when I'm debugging this stuff, I just generate wrong stuff just to really debug the result. I think we should, we can sit down later to look at the details of this. And then we need slides like this. We talked about normalization of XML, normalization of ODF, which I'm not going to bore everybody here with. There are quite some things you need to do to do this correctly, yes? One request that I have from people who are, I think, more happy sitting in a terminal and you can log back and etc. is they would love to see change-track in ODF, some kind of nice conversion between that and a series of git mitts. Now this will probably be a script, but again, it's something that maybe ODF considered into the standard to make it easy to go from this particular format into, again, a different sort of set of gifs. So just something for you to think about. Yeah, yeah. Well, that could be an approach as well. So, yeah, the approach I come forward here with is to normalize it, to remove some points which normally can differ between documents. For example, the last one, which units are we using? If I'm collaborating with somebody who has a different setup, then the units are swapping around every time. But the end result should hopefully be something like this, where you can have a nice diff, which is what developers are used to and so they can easily read what actually changed. And what you can see here is the reason why this diff works is because the elements are sorted alphabetically. That's just one small thing. Okay, here's another controversial topic. If you read the HTML spec, there is a very large chapter in there which deals with loading wrong files. If your file is not a valid HTML, they have a whole list of what you can do to fix it. Maybe we should standardize that so that if I'm reading an invalid ref file, I can still read it. This is a very long text and it's crazy difficult to implement it. But I thought I should put this idea here as well. Why not? For HTML, you have specifically tricked. I think it was tricked and transitioned or something like that. So there is a difference which kind of you have in the HTML file if you really want to apply all those. Okay, HTML might be wrong, but ignore that. Just show something. Yes, so the thing is you have HTML and XHTML. And XHTML is more strict. But that's rarely used. Most people still use normal HTML and then you have crazy amount of rules. What happens if the tag is not closed? What happens if you're using a misspelling of an element name? What happens if you don't escape a smaller than sign? It's all written down explicitly and it's written down from experience of all the browser implementations. So basically you have a list of bugs and instead of fixing the bugs, you write them in the spec. So yeah, I wonder how much you'll close this one. Okay, this was an audience suggestion. I got earlier. Theme support. It's an ODF. You can read an ODF file and then your application changes. That's crazy idea. I'm not sure I understand. You mean the previous one? Theme support. No, yes. This is a screenshot from somebody with a very nice theme set up which is irrelevant for the content of the liberal office window. Sorry for the confusion. What I'm talking about here is the title and heading here which is you open a document then you click on a nice style preset and this gives you a nice style document. This is a picture from the master of a liberal office which has this feature and it's currently implemented simply by applying a default style to the document. It is, should we also have maybe a couple of style profiles in a document or should we pack out exactly how this should work? Maybe we should have colors which we give names and named color. Could be an improvement at this time. Yes? Shastri Marx usually he has such themes as set of styles also in a corporate environment that are part of the corporate design and what we are going to do if this changes, if we say well now this is old style we will implement or we will go for that new style for the new streaming in our documents if everything is embedded then we have really a mess maybe it's something different here I don't know yet. Yeah, well I get your point. So one thing you would definitely need to do is you need to make agreements on what the names of the styles are what is the name for a heading 1 what is the name for a heading 2 that's the first step and that's currently not in the standard what is in the standard is that we have a special file styles XML which you can swap out with a different style but theming support encompasses more than even is in this in the spec now I'm not going into details here but it's just one of the ideas, right? Yeah, so those are all of the ideas now it's time for the applause meter Yeah, let's calibrate it 5 seconds of silence this is being recorded I'll look at the recording later 5 seconds of maximum applause so the first one testing and certification that's reasonable profiles so the profiles means quick recap, the profiles means that your implementation can say I have I support only mark down similar features in text editing I support only spreadsheets may I say that currently it's very easy to be an audience of the mentor you might even say all the to be biteray, you can have to read and write a venant document but it's not meant that you can edit it so you can be biteray loaded and flash it back and then your venant audience application so it might be a little absurd like you can say you have a certain only have OXML interoperable feature set you have a feature set that you can always turn around or everything that is currently supported is change tracking that is also a feature of the application so like you have a certain level of quality but on the other hand you want to have something like a viewer on the lead a viewer is completely chasing you and you do this there is probably something that wasn't really in profile that year it was ok I can edit I actually turned on something like that but something like I can show with stuff would be something bad so one profile could be I can freely display everything that could be one thing or I can freely display everything if they have the right full back images because the ODS spec allows you to have a very complex object but then put a PNG file as well as a full back so you could say I do all the layouts 100% correctly and I do all the full back images that would already be quite a bit of work to make that so that would be one thing so again the interesting thing on profiles to me is that profiles are like feature sets and feature sets require that they have to define what a feature is I can't we all say we only have the definition of XML but we don't have like it's ok it's mentioned there or then you can edit table sets so this might require also the testing simplification like you have a feature set so just to help us you can tell I guess that profiles is also going to show this for you feature set so let's ok measurement ok scripting do we want standardized scripting language kind of macros so right now you can put any language I will do a short explanation again for every topic before we do so yes the real time change tracking which allows you to collaborate real time with other people on the documents should we standardize that that's clear more than the maximum so an implementation might have only support for 1.0 or maybe only 1.2 so maybe we should help make tools to upgrade and downgrade the documents for you sorry no no no sorry so a applause for this feature now the slightly crazy idea of using html as a container format for ODF ok that will seem to be a lot of work instead of a lot we have a lot of work yeah ok so the next one normalization of ODF so we can actually talk for it and let developers also use ODF we do like html does and make a long specification about how to handle envelope opportunities ok this has been an awareness response actually yeah well yeah it's clear that it's not very popular maybe we should also send an email to W3C what do we think of html ok the last one theme support I think somewhere in the middle now if you have any other suggestions I'm here until Friday we have the public comment mailing list and of course we have the possibility, the exciting possibility for you to become a member of this exclusive club which is the area of technical committee and there's a huge pile of nice ODF stickers yes your laptop wants it thank you