I guess I start already because otherwise it gets boring.
Hi everyone.
I'm Svante Schubert.
I started 99 with StarFist in Hamburg and never worked on LibreOffice core StarFist
earlier.
But always from the beginning, although I applied a C++, other Java-based Vaptop, we
called it a web office, right?
And we had two and some.
The second one was when the Golden Master came in 2011, it was cancelled, everything.
And this library, I'm talking about the ODF toolkit, was the core of this web office and
later on a fork from Open Exchange 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 ODFTC.
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 OASISTC.
We are three from the Document Foundation, Regina Henshel, who is very active, and Micha
Stahl from Atropia.
Many thanks for Atropia for joining that.
And Michael is also the co-maintenor of this ODF toolkit.
And yes, sorry, Dennis, bring my laptop, please.
Okay, so, yes, yes, yes, yes, okay, anyway.
So the ODF toolkit is basically a Java-based, and it has two main core deliverables.
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, or it's over there, sorry.
Hi, here's something, okay, sorry, okay.
The one thing is the core, the ODF DOM, and the online validator is the wrapper around
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, demand that at the runtime, the browser is accessed by the DOM API, and that
is the way that JavaScript not only runs in Firefox or Internet Explorer, but that is
this macros are interbubble in all browsers.
And ODF doesn't have such runtime API.
You have either a LibreOffice macro or Microsoft Office macro, and they do not work to each
other.
This is a downtime.
I don't say that we need a DOM, but there's no DOM access in 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 OSSTC 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 will have an ODT document, you can exchange the suffix, and then you suddenly
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
will find signature XML as well, and the whole XML part is one of them.
And the reason now, the high-level goal is to have a, to close the gap between the standard,
the blueprint, and the limitation, like want to get away from paper because you don't want
to get, oh, here, developer, here's another 500 pages of the specification or start.
But the idea is to generate as much as possible 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 a set
of content table signatures, also the manifest XML, and all of these is taken away, abstracted
from the developers.
So we generate the DOM tree, and type DOM tree, like for each element, 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 burned soonish is like you should have a constructor from
all the mandatory ways of the 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 is 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's 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 the spec, generate even this API from it, right, so in the end it's something
like this, we have a semantic layer, and this is currently not generatable, and 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 Libre Vasone, and because as well that the spec is not very strict on the view, and
the highlights is, we've done recently a release vote of one or two still, we've 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 X and G, which is simpler like XSD, grammar, and from this
we traverse and are able to generate as much.
As in one, three upcoming release, nowish, I thought I could release it with Michael
for Foster, but it was some bugs, and one at four later, why one at four later, that's
the ODFTC update, really, you see, this was the last release, one or two with Son, that
was really, Son 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 then 23 credit dates, where people can validate
from, take something from it.
Okay, so there's another thing, I did a project on a major data search engine, where the text
in major been extracted from ODF, and I realized that there's something missing in ODF, I 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, okay, now I tell you, how do I do the export,
how should a table look like in Markdown, and you can do cherry picking of features
you like to have in your own format, like Markdown or HTML, and I realized that the
whole design, we came from XML, and later we realized, we need this feature level to
abstract from this thing to XML details, that this is missing.
So here's 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.