 So, hello there, my name is Michel, I work for CD, and I wanted to give a presentation on the next version, the upcoming version, of course, what I'm thinking, what is the status of that. So, but first, look at history. So, what do we have here? So, back in 2001, in 2002, SignWriting Systems wanted to create a document format that allows for iterable editable office documents to be interchanged. So, they donated the OpenOffice.org to the OASIS standard organization, and there a technical committee was formed, the TC. So, try this one, okay, fantastic. Go to the other guy, thank you, outside. Okay, that's as well? Yes, thank you. So, then the OpenOffice technical committee worked for a couple of years, and in 2005 it released the first version of OASIS. As an OASIS method, and this was then submitted to ISO, to the subcommittee 34, which then released it as an international standard, 26300, about a year later. And then, in the meanwhile of the OASIS, the committee was working on the next version, which was just a minor revision with a few new features, which came out in 2007. And for some reason, the ISO process there took a bit longer, I'm not sure why, that was then released as an amendment to 26300 in 2012. And even before that, OASIS finished the work on OASIS 1.2. And this was the very substantial revision of the specification document. It was completely restructured, it was split into three parts, and one of the parts was even completely new, it was the own formula language for spreadsheet formulas. Yeah, so this was then also transferred to ISO and released in 2015. And you will notice there is a dash 1 now in the number of the standard, and that's because one of the three parts of the OASIS specification became its own ISO standard. So now you have the chance to pay ISO 3 times the money to read the specification. But actually, I think this specification is even available for free from ISO as we have. So now, once we have history out of the way, what happens in that? So first, I should say, at the beginning of the OASIS 1.3 process, I was not participating myself. So this is all a bit vague and incomplete, and technically very basalt. And then also, I guess I should say that everyone in this presentation is just my personal opinion, in no way an official position of the technical committee or OASIS or anybody really. So the work on OASIS 1.3 started sometime in 2011 or 2012. At the time, the committee was also busy with other issues, such as creating a random document for the existing OASIS 1.1 version. In the beginning, it was decided that a big focus for version 1.3 should be change tracking, because the change tracking in OASIS 1.3 was considered a bit inadequate, like in features. And so the staff committee was formed to handle the change tracking. And then three different proposals that had very different approaches were discussed in this vice committee. I think currently, there isn't much work going on there, that's probably correct if I'm wrong. Yeah, but there's nothing so far as being actually implemented in the large office to meet. And also during the early years, there was quite some foundation, people meeting, people joining the committee. And so I personally joined 2013, but unfortunately some experienced people were meeting, so yeah, that caused a bit of disruption. And then in the year 2015, the committee asked itself a bit of hard questions about what actually the OASIS 1.3 should be, or should not be, or what is in store. So the situation was a bit confusing, because the committee uses a JIRA issue tracker to handle, track all of the work items, everything that needs to be done, has a JIRA issue, and just several hundred issues that all had a target assigned to them of audiophonography, which seemed too much to handle. And previously, the issue was that before that time the committee was very reluctant to close issues without doing anything. So a lot of these issues were of questionable quality in the first place. And another thing that I think we got around to is to focus not so much on dreaming up new features from scratch, but instead, look at what implementations such as JIRA Office were already doing, had already implemented, and just standardized the existing practice. And then we started for more than a year to just go through all these hundreds of issues and assign the proper target to them. So what is an issue was about an obvious defect. Then we kept the target at the 1.3. If it was a new feature that came with an actual implementation, usually the implementation was a bigger office, but I think there were a couple of other applications. Yeah, we also take it forward with 1.3. But if it's a new feature, it's a good idea, but no one has already implemented it yet. Then we just say we assign it only a later target, which is not definitely any specific audiophonversion. So essentially it has a very long priority, and we will only look at it when we run out of payout priority issues. Or of course if somebody actually implements it, we can of course give a different target at that point. And then there were some issues that were just never going to happen because, for example, there might be an impedance mismatch between what has been proposed and what already exists in one aspect. Of course, back-up compatibility is also something very important for us. Or maybe the issue was just very, very vague and not asking for anything specific. So I think we had one proposal that was titled 3, and then the spreadsheet, which I'm not sure what exactly that means. Could we please be more specific than that? So we closed those issues then. And of course if you have hundreds of issues, then you will have lots of loopy heads. So some of these were proposed four times or something. We closed all the loopy heads across. And once we are there, so this is a bit of an overview about the result of this factory arching. So we closed around 140 issues, all right. And then there were about 130 left that eventually ended up in only one thing in the graph. Then another 110 or so, we initially accepted 4.0.3, but eventually we moved them to the next 4.0.3 version. So then we are planning to put these in 4.0.4. And then there are about 40 that we have put on the only data target. So these are the low priority issues. And then once we were finished with this factory arching, we... TC basically was working on the issues that have the 1.3 target, writing, so basically discussing the issue in the conference halls and refining the proposal in the issue until consensus was reached that the proposal was of high enough quality that it can go into the specification. Yeah, and we continued with this for a couple of years until in June of last year we decided that quite a lot of time has passed since only 4.0.2, and we really want to release something relatively soon. So we had a feature release at that time. And every new feature that did not yet have an accepted proposal would go into the next version that is 1.4. And yeah, what has happened since the feature release is that basically the editors have taken the resolutions of the issues that have been accepted and inserted them, edited them into the draft specification. And the rest of the committee was then reviewing these draft documents and pointing out any issues. And of course new issues were also found during that time. Like when you use something you noticed that it's just here to the title there, whatever, and so this also took some time. And yeah, so what are all these issues that actually made it into 1.3. So firstly, there were 26 new features that those are actual new example elements and attributes that enable you to represent something in the document that was not possible to represent before. Then there are about a dozen that have the time improvement that was a bit vague. Some of them are sort of minor features where it was not necessary to add a new element. We could enable some additional functionality by changing the pros of the specification. And some of them were various miscellaneous things. The vast majority of the issues about 90 were just fixes for bugs in the specification. Maybe there was a title, or maybe something was contradicting itself, or maybe something was unclear or whatever. And then there was one or two tasks, which is to whom I tend to track back. Something we serve at a certain point in the process. So where are we now? We are basically very close to the end. So two weeks ago the committee approved the committee specification draft 1. And the next steps then are that the draft is going to be submitted for a public review. And this has about two weeks of lead time. And then the public review itself will be 30 days. I believe it should start on Friday, if I can talk correctly. And then the general public is invited to send any comments they have on the draft to the comment list that are made in this. And then it depends on what comments are received during the public review. The committee has to acknowledge all of these comments and probably revise the specification. And either the revision will contain only editorial changes, like fixing typos or whatever, or there will be material changes to the specification required. And in the latter case, an additional public review of the revised draft is necessary in the last 15 days. And once we are at the point when no more material changes are required, the committee can vote to make the draft a committee specification. And at that point, if successful, it will be handed over to the OASIS at large. And it will become a candidate OASIS standard. And then another period of review follows. This one lasts for 60 days. And at the end of it, there will be a vote to confirm it as an official OASIS standard. So I'm not sure how long this is going to take in practice, but yeah, I guess the earliest I would expect is all to finish at the end of the year. Oh, and of course, I should already also mention this committee I've been talking about because I'm curious that actually who is doing the work. And I am on this slide, I'm listing only the people who are currently voting members in the committee. Because if I would list everybody who had anything to do with only the fund with me, you would not be able to read anything on the slide. So first we have Patrick DeRusso, who is the chair of the committee and also one of the editors of this draft. And Regina Henshel, who is representing the document foundation in the committee and who is really amazingly resourceful and spends a lot of time tracking down the detailed questions and figuring out what should be done in which he has written a lot of the actual proposals that are going to go into the audience committee. Then I'm also on the committee and we have Andreas Bötel, who is working on Numeric, which is a practice application, and we have... I'm sorry, I've written Rich, who are from Microsoft, and then we have Francis Cave, who is the second editor for the project. He is being paid by the problem project. Francis Cave is not a voting member, he contrasts with all the other people on the slide. So what is Cozum? This was already mentioned in the previous presentations and just a quick reminder that it came about last year when somebody came to the conclusion that just waiting for volunteers to edit the specification is going to take too much time and it's going to delay the release of ODE F1.3 yet further. So this Cozum project was created at a non-profit organization in the UK. Initially it was funded by the document foundation by Microsoft, and later on other organizations jumped the bot to provide additional funding and at least they also take donations. And basically they are funding the ODE F editor, so Patrick and Francis Cave to create these job documents. So so much for the ODE F1.4 and as I already said there are plans on the way for the following version of the ODE F1.4. We already have more than 100 issues in Q1 with the target ODE F next. And there is also a page in the Libre Office that contains ODE F extensions that are already implemented in Libre Office. And most of these already have a geo-injection but there are a few that do not and those will also need to be so somebody needs to create those geo-injections for them. And in addition to that we are using during the Libre Office unit test we are using a customized schema that contains all the known extensions that our ODE F export can write. And we have found that there are also a few additional ones in there that are neither half a euro issue and what is this, nor are they listed in the wiki. So if you look at this schema file there are lots to do, lots of comments in there so that is also more additional work to do. And it's even possible that there are in more ODE F extensions written by Libre Office that don't even have a real test for them which is really concerning in practice but it needs to stop. So I wish to know your idea so any questions? Yes Frank? Some users in Taiwan that were asking me about now we have ODE 1.3 released and obviously we start to implement that instead we say about the compatibility issue with Libre of current version it can open new ODE 1.3 file format without a problem and now do we have any proofs or proofs that we can tell users that it is no more inter-probability or compatibility issues? So the question is basically can a current Libre Office version open ODE 1.3? Right, because now we have no one wants to end it yet but we also cannot find any pure ODE 1.1 editor now so I cannot prove anything like okay you see ODE 1.2 file but open by pure ODE 1.1 editor without a problem even some of the company can understand so some users starting to ask me So basically we are preparing for that because what we currently do is we write by default unless you change the configuration we write ODE 1.2 extended which means that all the new elements are going to go into an extra name space the other name space and when we are going to write ODE 1.3 these elements and attributes will move to the standard name space instead of LX but our import should already be able to read both these elements and attributes in the LX name space and in the standard name space so of course I am not sure if that is true for one hundred percent of all of these extended elements and attributes but that is the general idea I hope we are very close to one hundred percent I have a question I have a question about presentation, page number so as far as I know that in ODE 1.2 the page number is limited to the integer starting from 1 so I wonder if this is and so is there any any guide for the implementation size that for example if it is not a new attribute but it is not a new attribute I am not sure the question is about the page number attribute it needs to be limited to the positive integers but in ODE 1.3 we have extended the range so that 0 is also possible now and in that case I am not exactly sure but what I hope is going on is that if you use ODE 1.3 extended sorry 1.2 extended then we may write the 0 into the attribute and the input can make the 0 and if you choose ODE 1.3 then we may write the 0 into the attribute and choose ODE 1.2 strict then we would not write the 0 into the attribute and yeah I guess we would write the 1 or something the closest equivalent I guess and so at input we can handle the little value so it is a relatively minor chain practice I have of course the problem would be interoperability with some other application that would not understand the 0 yeah I guess that is not something we can solve on our own I guess but I guess for those cases if you are concerned about that we have the ODE 1.3 strict version so I guess this is the best video I can practice so I believe I am talking to you bye