 This is currently based on ITF technology, which is kind of legacy, which is kind of doing what it's supposed to do, but it's really quite future-proof. There's no standard, there's some ad hoc implementation of that, and a number of other clones of that implementation. But it would be really nice to have what's currently working with ITF to have that on ODEF, and even better to have that working on ODEF in a standardized way. There's a bit more background about CID, since we're kind of new here, so most of them probably hear about us first time, or if you were in a second time. It's a medium-sized company, as I say, it's about five years old, about 160 employees on multiple sites. Munich, Germany, and Hamburg, and Germany, and also Minsk and Estonia. Customers, mostly in Europe and also in the Middle East, for example, quite a number, about 165 customers from one group. Small products, those guys that produce billions of documents, stuff like PDF filters, electronic invoicing systems, etc. And about 2 million licenses sold worldwide, mostly so that the strongest presence is really in the financial issues, banking sector. So, when you look at what's happening for those more complex document production or synthesization systems, what do you need? So, well, usually you have some sort of letterhead that you want to modernize, that you want to, like, work with CI, you know, like this, you understand the main match thing, but you want to, probably, you want more complex, with more variables, more variation, more complex layouts. And you want to individualize that, so depending on the customer, I know you'll get some more colors and more text, or you want to add customer address, stuff like that. You also want to separate out, it's very much what those people do is very much like software engineering. So it's text processing, which is, if you're a large bag, a large insurance amounts to software engineering, so you're setting up a system, a very complex system of interacting pieces, and you really want to have that modular, so you want to have small independent pieces that can be used in other places, so you want to include stuff, so you want to master document, you want to plug in small pieces there. You also want to implement complex logic, so you want to, while you are processing this document and generating five million copies for your annual invoices or your annual statements, you want to customize that. So you want something comes out of your database, and something else comes out of your database, and you want to check, you want to start and then you will programmatically act on that and do preferred things. In this example, I don't know if this is visible, there's a wheelchair and this kind of crutch thing on one branch, and there's a balloon and a microphone on the other side. So depending on the customer, depending on the history of the customer, you want to do different things. You don't want to manually, it should be, you want to do a lot of programmatically and it should work like that henceforth. What is the function which is fulfilled by either a balloon or a microphone? The function? Yeah, so there's option B, and option B gives you either a balloon or a microphone. What's the option? Why would I want either of those? The balloon is like the toddler, you get the balloon and the microphone is like 15 years old. So you really want to tailor the document to the customer or to the recipient or to whatever other complex scenario that you might find. Whatever local rules, regulations that you have to fulfill. I don't know if this statement has to be on page one and this federal statement on page two of that or something like that. So depending on the input from the database, it wants to programmatically to the stock, so it's text programming to some extent. Yeah, and so of course where this all comes from, usually especially in the large scale, it comes from the database. So you want to generate content from the database. And while you say don't bore me, this is possible, yes it is. But for more complex scenarios, for example, if you want to generate tables, you can't do that because you can't generate higher level audio structures. Or if you want to, for complex reports, you want to generate lists of lists, depending on how much. So if there's, just imagine some co-operative that wants to have a mortgage. So suddenly you have not just one address and one name, but you have a list of that and different degrees and sometimes different legal systems. So you want to really generate or synthesize complex document content out of simple database input. Yeah, so this is what you want to do and this is what actually works in RTF, which is a system product. And the question now, what exactly is missing from RTF, and for that I'd like to, and I want to buzz leave. Okay, regarding RTF. This is easy, but we are missing almost everything of lists of reports. We are unable to use complex constructions to separate the blade with many smaller building blocks and to reuse them or modify. We are missing the ability to have complex conditions, for example, depending on... Maybe you can use the microphone. Not sure if it's loud enough in the back. Okay. We are missing the complex conditions in RTF. We want to compare, overfly some database with some other variables and depending on this, we want to customize our templates, our reports we generate. So we also, in case of quality, missing feature of usage complex formatting inside of the fields. For example, that conditional field we have, we have put only a text, a plain text inside. But how about complex formatting or even putting a table inside? That's still missing. And generation of complex objects like, say, torsion, tables, list of lists, and so on and so on. The classical examples can be here, for example, any report for bank list of transactions. We have one user and list of operations made. It is a long table, but hard to generate with existing ODT. What actually we implemented till this moment in our project called GS Merge? We decided not to invent heap of new fields like we had experienced with RTF, when we are missing something, we create a new field. Instead of this, we just decided to create just a couple of fields, not create, but user fields in the ODT. It is marking over block start and mark over block end. This is just a poorly praised market, and in between of them, there will be a field content. Visual appearance displayed below and more close to what can be placed in between these poorly marked brackets. One thing is that this stuff actually works in LibreOffice. You can do this text programming today in LibreOffice. Of course, it is kind of ad hoc, so it puts some semantics into actual documents, like free-form document content. So it is not very regular, but it actually works, which is cool. Actually, it is expected to show with Libre how it works, how it is intercepted, how these fields are processed. We have a technical problem here. It does not have GS mesh, and my laptop does not have HDMI. If somebody is interested in LibreOffice, you can ask me today or tomorrow, I can display how this stuff is really working. So, back to just slides here. Inside this field construction, we can place two different types of content. First of all, the starting with cache sign, followed by a script. In this place, we have a user can place a German script, processed by our products. Yes, we are more close to implementation of that crazy idea, the German script inside ODT. Or it was about HTML, but probably very close. And another variant, it is about content fields, which can be something not evaluated as a script, but placed somewhere in the output document. And to allow cache signs inside all our content fields, there is a special variant with a tick in front of it. And we define several primitive JavaScript functions from our backend. It is just a simple function text, which is just writing a text in blood function to include our file. And several specific functions for getting certain properties past the program. And a heap of iterations on database. Move to the next record, select record, reset our database point and so on. So, this is actually, will be enough to process any complex document, to implement any complex logic inside of templates. Because we do not need no longer implement like we have in RTF before. Complex if conditions, we do not need to implement wild loops. We do not need to create any of our custom formatting functions. Our customers can do it by themselves, just using poor JavaScript. Actually, for processing JavaScript is used Google V8 engine. It is for security reasons running as a sandbox. So, no direct file operations, no any general IO, no internet access, only just some JavaScript engine. Here must be a demo. And actually, what benefits we do receive with this idea? Actually, these topics are not very abstract, but mostly comparing to our previous approach with RTF, when we were using standard RTF fields. And we are trying to extend this list of fields with any new instructions. At first, we have more flexible support of documents. Theoretically, we are not limited just to JavaScript. Inside of the script field, it is easy to put any other script in a language. On the concept level, we were thinking about choosing between JavaScript and Google. But there is no critical reasons why to limit it to both of them. In any language, we just need to implement some basic functions and that's all. In this case, we are not limited just to classical weight we used in RTF, just putting fields inside fields to have a good result. And we can use in classes here any paper, dime or whatsoever. Because inside of this RTF template is running absolutely little general script. So the customers are feel free to use any type of ideas, how to proceed with the place, how to combine logic and representation. Probably some sub functions, probably in classes, in both cell. This way is very simple comparing to classical RTF. We use before because after some iterations of extending RTF fields, it is very hard to read what actually happens. It is hard to understand what actually doing this template. And it is became a kind of very specific and very limited language, which requires very specific knowledge to program it. This is not true if we just put snippets of common, well known to your customers' language. And of course we think that this approach can be very universal. Because theoretically this can be extended to use not just in auditory part, but even backported to RTF. Because we do not define exactly fields by themselves. We are not so syntactically, symmetrically specific. But we just define very basic two brackets. Opening the bullet bracket as a field and closing the bullet bracket. About the future of this person. So the proposal before, that is actually a working product. The nice feature is, as I said, it does not need any extensions to ODF. The drawback is that it is not actually ODF. It is a markup as if you would be going into a text document and marking something in red and then externally defining this red means something special. It would be better and more interoperable if there would be a way to express that in ODF, which there currently isn't. So one, this is just a rough idea. This is just a sketch of an idea that is not so different from a proposal that has been made a number of years ago about extending fields in the ODF to see, but maybe it's time now to pick up bits and pieces from that. So what this does, it's depth defining this bracket. So you have this beginning and end. Conceivably that will also be able to skip or to not be within the same level of the accidental hierarchy. But to have something that begins somewhere nested here and ends somewhere nested there. For example, if you want to include or exclude a large part of it actually. So if there would be an XML element of beginning and end, you wouldn't be able to skip in and out of the XML tree. So secondly, there's this field type, which gives a little bit more type safety to what's actually inside there, how to interpret that. Before the example had this markup with this hash mark and this escape hash mark. So that would be script content complex, for example. And then random content to be defined, like paragraph content. So one will probably set the limit somewhere there depending on the type, but probably in page-based markup one would include pages there as well. And for text markup, probably paragraph content is sufficient. From what I can tell. Yeah, well actually probably one would also be able to define styles. So that should be a bit more generic. Additionally, I guess it will pay to say that at least a number of statements in the script content like include, like text would be there. I would probably not mandate any language, at least if I open. But that's always, I mean this is not how the TC works. How the TC works is you have an idea, you make a proposal and then it gets made out over a certain time and then something, usually something better or at least something else comes out of it. Okay, so this is largely it. What do you think? I see a potential danger because this looks somehow like a rebuild of PHP, not on top of HTML, but on ODF, ODT actually. Yeah, that's actually quite to the point. And when you see the, and when you see what the people do there with this tax programming, it's rather similar. Yes, but so we have this unfortunate tradition in the office area that we have always this intermingling of application, logic, and data presentation. And I think we should continue in that direction. We have to find ways to declare it and then separate those issues. So for example here, let's call it processing. There's also something like selling database or something like that and also get data or get data entry. In my opinion, we should find ways to express it in a more declarative way. For example, in a separate file, maybe as part of the document, but not as part of the content, XML, have some algebraic expression which actually defines our data set, our period, maybe a hierarchical or relational. So what I hear is something like XSLT, so you can address statements and you can say what to do with that statement once you have selected that. And in your content XMLF marker, for example, this is the block to be used for that query and this is the block. The problem with that X query and XSLT is really not for the faint of heart to do. And what's happening here, ideally that's something that the, I mean for the simple cases that should be something that the secretary can do. But the fear is for the simple case, I think it's very fine. But then people are coming who are driving that simple, and it's the mechanisms to be intended to be used for simple things that drive me to the other most corners. Okay, I have one fundamental problem with that. And this is, I know I'm a computer scientist myself. And I also always try to make the world a better place. The problem is, it tends not to work out. So I don't know, I'm not doing this AI because they might build the robots that will take over the world. But it doesn't help because there's just one, it just needs one guy who's doing that and he did that. And so it always tends to fail. And if you look at PHP, I find PHP a wonderful example because PHP is immensely successful. If you look what people make out of PHP, it's awesome. And 80% of the internet of the sites run some PHP somewhere. And why not have that much of the world population do something wonderful with OOGF? Even if it's not fulfilling the high lesson of the computer scientist approach. It's not that people didn't try that. It's just separating that out at the very least that needs really, really excellent IDE support for you to integrate those two dissort parts. I find that rather imaginative. And this is the end of my buzzwords. It doesn't mean that it's not that you can only do one of the two. I mean you can do both. Josh, you had another question? Yes, I didn't put my finger up yet, but I have questions. Yeah, I think you were almost... Almost, yeah. Can you give me an example where you would need to have a field begin and field end instead of simply a surrounding element? Actually, Vasily asked me the same question yesterday and I was coming up with an example. So you had 24 hours already to think about this. He said, that's not very practical. Well, I think it is and we just have to let that... Let's go into that offline. It's possible that I'm not... Since I'm... I mean, Vasily has actually had to think and work with it and programme it and the demos and whatever. And so I'm terribly sorry but I'd love to show you a live demo of that. But unfortunately, there's some... Actual standards of the plugs. But yeah, let's go ahead and do that offline or in the TC even. So I think it's useful. I think it's... We might have several matching... We do some free includes and what comes out of that is valid XML. Well, if the begin and the end are on different levels of the XML, then what comes out of that query or out of that function should also be just an XML fragment and not actually a valid node set. But it should be text which should then be combined with the existing document and then be parsed. So that's quite complex to do. So you need to have a convincing argument why you want it. Okay, I take the sound. Okay. But that's a minor detail. I mean, if it's pointless, then it's pointless. It doesn't really invalidate the proposal and its entirety, I think. No, it's just one aspect. I mean, you could possibly then choose a different markup. So you could, well, perhaps have that as a real element, like really a nested element. I think it's more generic like that. And if it doesn't do any harm to be more generic, so if there's no cost to be more generic, then it's been more generic. If you tell me that it can't possibly work if it's re-pausing, for example, which is a good argument, I don't think that would work. Yeah. And I have a comment with regards to doing the standardization process. Since ODF 1.2, you can have any ODF 1.2 documents or ODF 1.2 extended options. So you can, right now, already pick a namespace and write all of this in that namespace. The problem is that you'll also then need to change all the editing applications you want to work with. Or write a plugin. Yes. Write three plugins, or four. So for this standard product, it was considered better to not do that. And the background, there was quite some how to put that, some confusion in the market. And if you don't really, you don't have the crystal ball to the future. And for that, you better play it safe and pick something that you can edit in every ODF processing application that's out there that supports fields. And you're done with it. And the mapping is trivial. I mean, programmatically, mapping one to the other, that's one to one mapping. You can always, if you use later things clear up, you can always change forces about losing anything. But I agree. Bring that into the TC, perhaps, that's what we're extending. Getting something to the TC can take a long time, right? So it might be a good idea, just like with the open formula. We started out with formulas in a specific namespace. It matured there in a number of implementations. And then it was adopted. And it was moved into the area. So it's probably best to just initially give that some vetting. So if this is complete nonsense, then you don't have to bother. If you can poke holes into that in five minutes, like you did with this nest thing, that's valuable as well. So then you can just set yourself up in a hassle, implement that, demo that, and then go back to the gloryboard. And then you do that and go from there, and then that gets the lesson. So there we are. Looked like six minutes all the time. Any further questions, comments, ideas? I don't know. Want to throw something at us? Great. Nothing. Cool. Thanks a lot for your attention. It's been great. See you around.