 Good morning, my name is Regina Hensel. I'm going to talk to you about my work in the ODFTC. First, a little bit about the specification. ODF is a specification for file formats for office documents. The version 1.2 has been published as ISO standard in June 2015. The subcommittee 34 and there in the work group 6 is responsible for it. This subcommittee has a scope, document descriptions and processing languages. It deals in Office Open, XML and EPUB as well. Although the standard is under the responsibility of ISO, actual development and maintenance is done by OASIS. OASIS is a nonprofit consortium with membership of over 600 organizations and individuals. The participants work in currently 64 technical committees. And one of them is a project OASIS Open Document Format for Office Applications. A short open document. Now I show you a little bit about the TC itself. The chart shows the current number of participants of the TC. We have in yellow regular members. They get voting rights by attendance in meetings. The table shows the members which were actually active last year. Despite the small number you see the diversity of the members and their widespread field of experience. From a point of organization we have companies here and here. Associations and document foundations. We have government departments. That's the last one, I have no more. And we have individuals. From a point of office application you will notice a calligram. That's here. We have LibreOffice. And we have Microsoft Office in this TC. What has this TC to do? The first part is maintenance. The specification has about 1,300 pages. Such large documents always has typos or broken references and such errors. Some semantic is reflected to styles. Source of additional errors. Furthermore special care is needed in using normative keywords. And keeping schema and post text matched. The next items address content problems. Which come into view by comparing programs. For example all implementations use angle in radian but degree is specified. This case is easily solved. We will adapt the specification. More difficult are cases where the implementations are different. We might solve it by introducing new elements and attributes. Or by making one behavior standard for F1.3. What requires changes in other applications. There exist rules for voting. But of course we try to find consensual solutions. Let us have a look at the tools. We use common tools like mailing list, meetings and bug tracker. The public mailing list gives non-members. This means to report bugs or request features or give other input to the TC. The member mailing list is used for discussions and attachments. And agendas and meeting notes are routinely posted there. Both lists have a public archive. Radia meetings are held by telephone. Currently the TC meets on Monday. Starting at 17 UTC for one hour. That is 6 o'clock in the evening for members in Germany. 9 o'clock for members in California. OASIS provides G-RISU tracker. Unfortunately it is global settings like formatting features and attachments. We work around it shortcoming by using mailing list attachments or Wiki. And uploading documents to the repository. So let us look how we work. All starts with an issue. Currently nearly 300 issues with target ODF 1.3 are unresolved. The chairs select a group of issues for the next meeting. And early announcement of the agenda gives the members time to prepare. Only few issues can be immediately handled finally. Example given obvious typos or off topic requests. In most cases short is customs revealed open problems. Which leads to some homework for the members. After one or sometimes more turns the members agree on the basic solutions. That is here we therefore here the circle. One member gets the issue assigned and scripts a solution. That means changing the schema and the text. In a final run the team votes on this proposal and then the issue is solved. But that is not the end of the work. All the changes have to be incorporated in a draft for the next version of the specification. Currently the TC has a backlog of nearly 100 resolve but not included issues. And there exists no complete working draft. Help is appreciated. Of course the TC also consider new features. Such come in from several sources. So all the FTC itself has a subcommittee to work on collaboration in document editing including change tracking. For details please frog ass. As I already mentioned a few elements and attributes were added to solve differences between existing implementations. Sometimes TC gets a feature request via office comment list. If it is indeed a request for file format and seems useful then the TC will track it in an issue. The TC does not automatically work on it but will wait until someone is actually going to implement it. Most features come in from implementers. They first put a new element or attribute in a private namespace and test it. ODF provides an extended mode that can be used for that purpose. Implement or TC member will write down the needed changes for text and schema. It is put in an issue then and the TC works on it. That way new file format elements have at least one realization. But developers tend to badly document the extension and so makes it unnecessary difficult for other applications to implement it. There is no automatism that the proposal will be carried over exactly. But implementers might need to change their application when they are going to support ODF 1.3. I have noticed some problems in regard to file format in LibreOffice. Other projects may not have such problems so please do not rush to generalize them. Validity should not be a problem because the check is simple. We have heard about Validate data. However, it is annoying that developers sometimes neglect that aspect. Differences between applications are serious for the standard. If they are not errors in one application but are caused by a weak specification, then that means trouble for the TC. It is important that the TC becomes early aware of such problems. There exists a public mailing list, open document users, which had been created for that purpose but it is not used. Nevertheless, the communication channel does not really matter. As long as developers consult with the TC in case the specification is not clear enough. The last group is a bit tricky because they touch the attitude of developers. One aim of my talk is to raise awareness of file format and encourage developers to a fruitful collaboration with the members of the ODF TC. I have been a member in the ODF TC for almost five years now. You might wonder why I work as it is volunteer. I am interested in mark-up languages and I use StarOffice and its successors for 20 years now. More important, I like that ODF is an open standard. Everyone can participate in the development of the standard. The process is anti-transparent and decisions follow democratic procedures. That was my talk. I have skipped a lot of details because of the time frame. Thank you for listening to me. Do you have questions? In other words, if I made open office, it validates exactly the concept that you are there. What do you use to come up with the... You can use a validator to test the document, but the problem with open office and deep office is that code is in part over 20 years old. There exist features which have been transformed to the propriety XML format of openoffice.org but are not transferred to ODF. There are a lot of features which need to be transferred to ODF 1.3 before all cases can validate against the schema. At the moment, there is no timeline. The problem is that we would need some people more to do the work. As I already mentioned, we have 300 unsolved and 100 solved but we need at least an editor who incorporates the already solved one. When the work is good, we can solve four issues in a week and then you can count yourself how long it needs until we have worked on all the existing issues. There are still some open in deep office where there is not even an issue to. There is no timeframe yet. You can accept other questions informally, right? Yes, okay. Yeah, okay. Goodbye. I forgot, there is a presentation by FOSTA, you can download it and it has a lot of information in the notes including links and so on.