We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

News from the ODF Toolkit

00:00

Formal Metadata

Title
News from the ODF Toolkit
Subtitle
Quick overview: Intro, use cases & updates from the past months and likely future!
Title of Series
Number of Parts
542
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
14
15
43
87
Thumbnail
26:29
146
Thumbnail
18:05
199
207
Thumbnail
22:17
264
278
Thumbnail
30:52
293
Thumbnail
15:53
341
Thumbnail
31:01
354
359
410
Web 2.0Office suiteCore dumpValidity (statistics)Library (computing)Computer fileRun time (program lifecycle phase)LaptopStandard deviationLecture/Conference
ImplementationStandard deviationMeta elementInfinityODF <Format>Content (media)DigitizingUsabilityDigital signalSource codeCivil engineeringElectronic signatureAttribute grammarElement (mathematics)CodeData modelDefault (computer science)Constructor (object-oriented programming)MathematicsTable (information)Computer-generated imageryArchitectureView (database)Probability density functionWeb pageRevision controlSearch engine (computing)WebsiteOpen setEndliche ModelltheorieView (database)Well-formed formulaCodeProjective planeSpecial unitary groupStaff (military)Query languageMetadataInsertion lossPattern languageTable (information)Source codeMultilaterationType theoryComputer fileValidity (statistics)Wrapper (data mining)Electronic signatureUsabilityElement (mathematics)Digital divideFile formatLevel (video gaming)ImplementationSearch engine (computing)Web browserRun time (program lifecycle phase)Macro (computer science)MereologyDefault (computer science)Latent heatInternetworkingAttribute grammarMedical imagingConstructor (object-oriented programming)NumberMathematicsNetwork topologySocial classWordEncryptionWeb pageComputer animationLecture/Conference
Program flowchart
Transcript: English(auto-generated)
I guess I start already because otherwise it gets boring. Hi, everyone. I'm Svante Schubert. I started in 1999 with StarOffice in Hamburg and never worked on LibreOffice core StarOffice
earlier, but always from the beginning, although I applied at C++, other Java-based web top, we called it, a web office, right? And we had two in some. The second one was where the golden master came in 2011. It was canceled, everything. And this library I'm talking about, the ODF toolkit, was the core of this web office and
later on a fork from OpenExchange for another web office. So I worked once at the ODF standard, which is the file format, the shot frozen runtime that you dump and send to others. And the reason of the standard is to be interoperable with other things like Microsoft Office.
Microsoft is also participating in the OASIS ODF TC. Okay. So far, not bringing your own laptop because everything goes faster this way. Anyway, it doesn't matter. So by the way, we are three from seven members in the OASIS TC.
We are three from the Document Foundation, Regina Henschel. It's very active. And Michael Stahl from Atropia. Many thanks for Atropia for joining that. And Michael is also the co-maintainer of this ODF toolkit. And yes, I bring out that, please.
Okay. So yes, yes, okay. Anyway. So the ODF toolkit is basically Java-based. And it has two main core de-levels. This is the ODF DOM.
And the other thing is the validator. And yes, I know, but gosh, here we go. Sorry for the inconvenience. It's over there.
Gosh.
Ah, here's something. Okay. Sorry. Okay. The one thing is the core, the ODF DOM. And the online validator is the wrapper around it. And you know it. It's hosted by ODF. And it's used for validating this ODF file format. And ODF DOM, you hear it by the name.
It's not only an ODF implementation, but also in DOM. And you might know this from the browsers. And that's the browser standard, the HTML standard, demands that at the runtime, the browser is accessible by the DOM API. And that is the way that JavaScript not only runs in Firefox or in Internet Explorer, but that is this macros are inter-bubble in all browsers.
And ODF doesn't have such runtime API. You have either LibreOffice macro or Microsoft Office macro, and they do not work to each other. This is a real downtime. I don't say that we need a DOM, but there's no DOM access at LibreOffice. But it would be nice to have a feature API, a high-level API.
And the reason is that we have a standard, a blueprint, the OSTC given standard. And then we have this implementation where ODF is one of them and it's hosted by ODF. And just in a nutshell, what is the standard defining? The standard blueprint is defining the zip. If you have an ODT document, you can exchange the suffix, and then suddenly you have a zip.
And there's different parts in the specification parts, number one introduction, number four formula that's not implemented here. But the zip itself is defined in the package, like the encryption signature, and also this meta-inf manifest, which is a content table, and you find, well, signature XML as well.
And the whole XML part is one of them. And the reason now, the high-level goal is to close the gap between the standard, the blueprint, and the representation, like want to get away from paper because you don't want to get, oh, here, developer, here's another 500 pages of specification I'll start.
But the idea is to generate as much as possible, like documentation and most of the core, by this. And yes, ease by this development. And how it's been done? Because we are generating from the XML, look, there are a lot of elements of the XML, but the manifest is, like I said, the content table. Signature is also the manifest XML, and all of this is taken away,
abstracted from the developers. So we generate the DOM tree and type DOM tree, like for each element and attribute, we have a class and an element gives you methods to what's inserted, and the default values are extracted from the spec.
So soonish is like you should have a constructor from all the mandatory words of a subtree, something like this. But there's also some gap in the, let's say, digital gap in the spec. Like there's some formulas in the floating text saying, oh, when attribute A is active, then the attribute B, sorry,
if it's B is present, then A become active, or there's a certain value for B. And these conditions, I would love to read out and generate from it the source code, because I don't want to type it myself with thousands of attributes. Another thing that's not there, because it's a lot of things, the puzzle pieces,
I would call them feature. And this should be the feature API. Everybody expect there is an image and there's a table, and this is like even if you don't know anything about ODF, you will find another file from HTML markdown, and you have a certain assumption that if there's a table, you can insert a column.
And this insert column function, yes, this change API request, that has a certain pattern of XML change. And this might and should be defined in spec to generate even this API from it. So in the end, it's something like this, where you have a semantic layer, and this is currently not generateable, an XML layer and a package layer.
And the idea is that you might exchange the semantic layer with even other file formats. Like there's also a table where you can do markdown from a table, insert column and markdown this way. So let me run through it a bit. Of course, there's just a model and not a view. This is for Libra Vassoni,
and because as well that the spec is not very strict on the view. And the highlights is we've done recently a release for ODF102 still. We refactored a lot this code generation, and also did a release after 20 years and took over the multi-schema value data, which is for loading and understanding the grammar, because we have something called real XMG,
which is simpler like XSD grammar, and from this we traverse and are able to generate as much. There's one, three upcoming release. Nowish. I thought I could do a reset with Michael for Faustin, but it was some bugs. And 1.4 later.
Why 1.4 later? Let's see the ODF2C update. This was the last release, 1.2 with Sun, that Sun was stopping staff this year. And it took a while till we made the next release for Oasis. And now we are closing on ODF. There's a link. You can click on it and see the query of the 66 issues
which are already in. And there are 23 candidates where people can validate from this thing, take something from it. OK. So there's another thing. I did a project on a metadata search engine where the text of the metadata is extracted from ODF.
And I realized that there's something missing in ODF or just for discussion after something. It's like we don't have this ODF model in the middle, like this feature model. And then we say, OK, now I tell you how do I do the export? Like how should a table look like in Markdown? And you can do like cherry picking
of features you like to have in your own format, like Markdown or HTML. And I realized that the whole design, like we came from XML. And later we realized we need this feature level to abstract from this distinct XML details that this is missing. So here are some sources left.
And I really, really love to discuss on some kind of this later by TB or something. Thanks a lot. See you next year.