 Hello, my name is Michael Stahl and I want to give you a quick status update about the current ODF situation for this year's LibreOffice conference. And I work for a company called Alotropia Software. We do lots of consulting related to LibreOffice. And so, first a quick overview about the history of ODF. And in the beginning, in the year 2002, Sun Microsystems wanted to have an open standard for office documents. So they went to this standard organization, OASIS, and the technical committee was created for this purpose to develop the open document format for this applications. And in 2005, the first version of the standard was finished. It became an OASIS standard. And this OASIS standard 1.0 was then taken to a different organization, ISO. And in this subcommittee number 34 there, it was turned into an international standard. And then a couple of years later, there was a new OASIS standard 1.1. And in 2011, there was version 1.2 was finished. And this one contains a lot of new features and substantial changes. And now, just earlier this year, in June, we managed to finish, and OASIS has published the OASIS standard for ODF version 1.3. And so generally speaking, all of these versions are backwards compatible, which is nice. So given that we have a new version now, finally, after 10 years it's finished. I think it's time to celebrate a bit. And so what about this technical committee who is actually in that committee and who is doing the work? So first we have Alfred from Microsoft and Andreas who is an individual and is also the maintainer of the Economeric spreadsheet application. Then we have Francis, who is one of our editors and myself. I am also technically an editor now. And then we have Patrick, who is probably the longest running member of this committee. He is one of the chairs and also an editor. And then we have Regina, who is representing the document foundation. And she is doing quite a lot of very excellent work there. And then we have Rich from Microsoft and also Svante, who is an individual member and is also now co-chair and editor. And I should like to point out that this entire talk is just basically my personal opinion and I do in no way speak for the committee or for OASIS or for anybody else. So since we have finished ODF 1.3 now, what are we currently working on? We actually started to discuss the proposals that should go into version 1.4, the next version of ODF about three years ago already, which I was surprised to learn recently. So currently the committee is still very busy working on all of these proposals. And also earlier this year we have discussed and accepted a new charter for the TC. Because we noticed that the previously current version of the charter made ambitious predictions about what should happen in the year 2005. So it was a little bit outdated. And the most important item I think in the new charter is that we want to move to a bit of a more agile process and not have another 10-year delay between versions. So as part of that we want to deliver a committee specification draft once a year. And hopefully this should provide a bit of an incentive to speed things up a bit. And what have we done already for the next version of ODF? So we are tracking all of the proposals that should go into ODF in the OASIS JIRA. And we have resolved already somewhere between 35 and 40 issues there. And there were several new features that have been accepted. There are more than a dozen improvement issues, which in some cases are some sort of clarification of the specification and in other cases maybe even a small feature. And the largest chunk of the accepted issues have been defects in the specification that have been fixed. And what is still left to do? We have about again 35 issues that are targeted at ODF 1.4, which have not been resolved yet. And then there are an additional more than 100 issues that have been targeted at ODF next, which means they are basically ready to be discussed by the committee. And in addition to that, there are maybe 50 that have ODF later, which means they will only be discussed if there's nothing more important. But of course, since I mentioned we want to be a bit more agile, it doesn't mean if an issue has the target ODF 1.4, that it's guaranteed to get into ODF 1.4. There probably will be a time-based cut-off at some point, but I don't know yet when that will be. And in addition to these issues that are already tracked in JIRA, we have in the office many features that have already been implemented as ODF extensions for which there is not yet an OASIS JIRA issue. These features are tracked in the Wiki on this ODF extensions page. And in addition to that, we have found while running all of the unit tests that are in the LibreOffice code base that there are additional extension namespace elements and attributes being exported. And these are tracked in a schema file that is in the LibreOffice sketch repository, because without that the unit test would fail because it tries to validate every exported ODF document against the schema. And some of these are still missing both in the OASIS JIRA and on the Wiki. And it's possible that there are even more features already implemented for which there exists no unit test. Of course, it's hard to find these features. And now we come to the question of how is the development of the ODF standard being funded? And this was a bit of a problem during the ODF 1.3 process because it turned out that all of the large corporations that have funded this in previous decades were no longer interested. And so Regina came up with this idea that we should distribute the funding so that we aren't dependent on a single large corporation anymore. And this is now set up as a cause in the community of ODF standard maintainers and it's run via some nonprofit corporation in the UK that's managed by Simon Phipps. And there was seed funding provided for this by the Document Foundation and then several corporate sponsors also pitched in like Microsoft and Colabora and CIB. And what's being funded there is the ODF editors, so Francis and Patrick are being funded to actually create the standard documents and schemas out of all of the proposals that are in all of these JIRA issues. And now also, Svante is being funded to implement the ODF 1.3 support in the ODF toolkit project which is these days also hosted at DDF. And what has been achieved so far with this funding is that the 1.3 standard is actually finished now. And what we hope to be able to get funded soon or I'm not sure if it's actually funded yet, we want to automate the editorial release process a bit so that there isn't as much manual work involved. So we want to have some tooling to automate things. Which brings us to the next topic, the editing workflow for the next version of ODF. And as I said, we have all of these proposals in the OSS JIRA. So how are we going to get them into the specification documents? Nowadays, since about a year ago, we have a GitHub repository which contains all of the deliverables of the specification. So the ODT documents and also the various generated files like PDFs and so on. And it also contains the tooling that processes these deliverables and converts them and whatnot. So there are things like converting the ODT file to HTML or extracting default values out of the specification text because for technical reasons they cannot be in the schema. And we are already using this GitHub repository for a bit of a pull request workflow to enable reviews. But while it's useful, it's not as useful as it would be for a software development project because there is no tool that can merge ODT documents. So it's not possible to use branches for that. And yeah, there are currently a lot of manual steps involved when editing the documents. So things like version numbers have to be adjusted and links to previous versions have to be set in multiple different locations. And there are four different parts, which means four ODT documents that all have to basically show the same information for the spoiler plate. And it's all very time intensive and error prone to maintain all of that manually. So we are currently planning how to automate the workflow a bit there so that we can have some tooling to do the boring parts of the work. And we also want to have a bit of continuous integration there that can create all of the different output formats. For example, the ODT is converted into PDF and HTML and this is currently done manually by just starting writer and going through the menus. So yeah, this would be nice to have. One question which held up the ODF 1.3 process quite a lot at the end was how we convert the ODT specifications into HTML files that look nice in all of the browsers. And because the previous versions of ODF were all also available as HTML and of course this is very useful. So in writer there are basically two different export filters. The first one is the Save as HTML. So it's available in the Save as menu item and this one is implemented in C++ and we found that it can only export the math formulas as images which are not at all accessible. So this is clearly not ideal. And then there were some issues with the table borders and also problems with nested numbering. So somehow the numbering turned out different in different places and this was particularly bad because you can have references to some numbered paragraphs somewhere but it's bad if these numbers don't match then. And then there were also some cross-references that were not exported as hyperlinks that you can click on. So yeah, some issues there and unfortunately nobody had time to investigate how to fix those problems. So the second option to export from writer is the export to XHTML so that is under the export item in the menu and this one is implemented in XSLT and at first it appeared that it would be just basically unusably slow with the implementation of XSLT that is used by default in LibreOffice in particular in Part 3 where there were thousands of headings and there was some algorithm in the XSLT that was quadratic iterating all of those headings but we were able to fix that and then the speedup was so tremendous that it only took about half an hour to export Part 3 and we found that if we install the Saxon XSLT2 transformer extension which is basically providing a different implementation of XSLT we get an enormous speedup and the export can be done in about 3 minutes which is now practical and then Sante fortunately and thankfully had a lot of spare time available last year to fix a lot of small problems with the quality of the generated HTML so it looks really nicely now and in order to make all of this bug fixing easier we decided to put a copy of the LibreOffice XSLT filter into the ODFTC gitter repository so that we don't have to wait for a new release of LibreOffice if there are any problems that we need to fix we have just recently synced the two copies of the XSLT filter again and there is just one patch remaining in the ODFTC fork of it which is that it adds some huge JavaScript blob called MathJax because one serious problem that we had is that the Google browser that has like most of the browser market I forgot what it's called Internet Explorer or something like that it cannot display the 20 years old MathML properly and that's what this JavaScript blob then fixes it somehow converts the MathML that's in the document to something that the Google browser can display and now for something slightly different what was going on in recent years in the LibreOffice project with relation to ODFTC so firstly the document foundation put out a tender to implement ODF 1.3 conformance in LibreOffice and this was awarded to CRB and it was all implemented and is shipping in the 7.0 release and since this release, ODF 1.3 extended is the default file format of LibreOffice so then there was a second tender which was about adding features that are new in ODF 1.3 but which had not been implemented in LibreOffice so this was the ODF 1.3 Delta tender and this one was also awarded to CRB and these features, most of which were in chart are now shipping in the LibreOffice 7.2 release and then there is a third tender which is currently underway about implementing automated ODF filter regression testing so the idea there was that we have this server somewhere which has about 100.000 documents on it and it's loading all of these documents and exporting them to a couple different file formats and the goal here is to compare the ODF documents that have been produced by the current development version of LibreOffice against the documents that have been produced by the previous version from the previous day, for example so that if there are any unexpected changes there we would know about them and this has been awarded to Collabora and they are currently working on it so now to the final topic of this presentation you want to add a new feature to LibreOffice that requires some sort of ODF extension so how do you go about doing that? so firstly you can add the implementation with elements and attributes in an extension namespace the prefix for this namespace is LOX and this is all described in the wiki and then you should add a unit test for the new feature and probably this unit test is going to fail because the testing framework runs the ODF validator on the exported files and it's going to complain about your new extension elements so you have to add them to the schema file which is in the git repository in this directory here and usually this is quite easy if you just want to add another attribute somewhere if it's a more complicated case you can always ask me and then once your new feature is in the master branch you can add it in the wiki to the page that lists all of the ODF extensions and during this whole process you can ping Regina or Svante or me and we can give you hints on what to do or what not to do it would also be quite useful to have a demo document for the feature because very often new features are also kind of obscure and it's not that obvious where to find them in the user interface and so on so that would be useful to have and then you have several options you could, if you like, write a proposal yourself to get the new feature into the ODF specification and there is a public mailing list called office comment and it just requires subscription but anybody can do that and send ideas to this list or alternatively you can ping the three of us and discuss the feature with you and write a proposal then and we can get it on the agenda of the TC and hopefully discuss it rather quickly and based on the feedback that we get from this discussion in the TC we can give you some quick feedback if there are some changes required sometimes people object to certain aspects of a new feature and want to do it differently or find that there is some obscure way to use an existing feature to do the same thing or things like that but in any case we will get back to you with the result of the discussion and hopefully get the new feature into the next committee specification draft and then ideally if there are any changes required you would have some time to adapt the implementation before the next release happens and it goes out to the users so the goal here is that we want to have a quicker feedback cycle for implementers of new features so that we don't have a situation that we had in the past where we have to ask people what they did 5 or 10 years ago which they likely have forgotten the details of so that was all from me and thanks for listening