Towards an Document Object Model (DOM) for Scribus
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Vox, Andreas
A Document Object Model serves more than one goal. Apart from storing the document’s data, it also supports scripting and serialization. It’s also the backbone for talking about compatibility, extensibility and testing. In this talk I’ll propose to use Relax NG for describing a new Scribus file format that also serves as DOM. With some tools, design patterns and Qt’s metaobject framework it will be possible to generate a DOM that maps 1:1 to the new file format and is accessible to scripts.
 Well, in fact, it's more like a road toward the document object model and the file format. And it's more or less like lightning talk, so it's very good chance I'll make good on the 15 minutes delay we already have. OK, let's start with the document object model. So it's three words. And document means it describes a document, not any menus or windows or processes or UV elements and stuff like that. But just a document and one thing you would expect. If you have an instance of a document object model and you've write it to a file, and when you load this file again to get a document object model, you should have a faithful copy of the original document. And of course, object means comes from object oriented. So you would expect some kind of trees or object, and every object has attributes and methods. And the important part, and that's where Scriber's legs right now, it's a model. It's not an implementation. So of course, we have classes, object oriented classes of Scriber's, which describe the document. But there's all kind of other stuff, how to do some things that event handling and what else. And that's not what we understand with a model. So the advantage of a model is when you have more than one implementation in theory. If you already have an implementation, it does not make sense anymore. You have to have a model which relates different implementations. OK. So a document object model has many users. So of course, first it's a guide to implementation. But then you can also use it for serialization, where it's writing to a file and loading from a file. So the most common nowadays is to just use XML and map objects to XML elements and attributes, object attributes to XML attributes or other elements. But you can also use it for scripting. So if you look at standards like SVG, they describe the document object, especially from how to tell how Javascript can access a document and change a document and work on it. So that's another important thing you need to do. It also helps with undo, because if you have an document object model, you can describe, OK, I have this action, and I've used the document object to describe the state before the action and after the action. And then the undo step is just to revert it. You can also do it with use it for testing. So if you have a document object model where you define some of the methods, you know what is expected. And then you can just test that. It just more or less gives a framework to talk about what is to test. Because if you have an implementation and you don't know what it's supposed to do, well, you can just observe and then say, OK, do I like it or not like it. But that's not really testing. And of course, another possibility would be to help with interoperability. So if you have different implementations of one document object model, you could have different applications which use the same document object model and hopefully can exchange data. OK, so the idea, what I would propose for Scribers is to use relaxNG to describe a document object model structure. RelaxNG is XML schema language. So the most common are relaxNG. The original was DTT, document type declarations. You might know about Bayer limitations and, of course, official XML schema language from W3C, which is a kind of complex and not that nice. DTTs themselves are not XML. But they are a part of XML standard, but how to describe XML. XML schema language is always XML, which is an advantage. But has the disadvantage that XML is not very readable. This example of relaxNG is the compact representation of relaxNG. The interesting thing about relaxNG is that they have two flavors, and they are equivalent. And you can convert this compact notation you see here in the example to a XML version you can use for tools and vice versa. So it's a one-to-one correspondence. And that's pretty nice. So oh, yeah. And here I just made up a possible grammar for Scriber. So you have to have a start element. So you just say start with document. Then the document is an element like Scriberstock. And Scriberstock is the process of a preference section, then the resource section, the style section, the content section, the structure section, layout section. And having said that, you go on with saying, OK, preference type thing looks like this. It's just a list of attributes. And here I used some real attributes we use right now in Scribers, which are probably going to change. For example, this name, unsullpages, it's a mixture of German and English. And we really want to get rid of that and have proper English names everywhere. OK, you can also see that if you have an attribute, then this is a name for the attribute. And you can give it a type, a data type. So this is an integer. You do know what it is. And it's possible to define several of these data types. And there are some predefined ones like integer and text. But you also could define your own points and whatever. OK, so advantages of Rolex and G. It's very readable. I hope you agree. And that allows it to discuss a dumb structure, because it's not fixed. That's just a mockup. And among what developers, we and maybe also interested users, we probably will do some fair discussion on how to fix the file format at the document object format of FOScribers to make it most usable. And so another example is it also provides a file format at the same time. So there have been ongoing complaints about existing file formats, because it was too complex. And of course, we also have to change the file format once in a while, because people like Louis are starting to rank with it. And so, yeah, and we will have a good correspondence between the implementation and the objects at runtime and the file format also. Next thing is because of the XNG, KS has another flavor, which is XML. It has good tool support for the XNG, for validation, and for other stuff. And last but not least, it's extensible. You can have annotations, two elements, which could tell how to use these elements or add documentation to it. You can separate your grammar with namespaces. So we could use it as a gene namespace, as well as our own scribes namespace, as well as CSS namespace, or whatever. And yeah, there are some interesting ways to use data type libraries, where you can define your own data types that you want to have. And we have some of those data types which are used in scribes, for example, for points or paths or colors. OK, so I'll just make an example of what an annotation in LexNG would look like. And the green part over there, which is an annotation, it looks very similar to the rest, but just in square brackets. And right now, I use the namesplace impl for implementation, and I made it up, OK, the class would be named scribestock. And the idea is that this annotation tells us, if we have elements scribestock in lower cases in the XML file, we are supposed to use the C++, scribestock in camel case, in the program. And our idea is to have a tool which translates the LexxNG to C++ code in a certain way. That does not exist yet. But there's some good reason to do it like this way. I'll go back sometime. If you look at this attribute, this is only the first three attributes. The scribest document has probably some dozens of attributes just for this. And altogether, the number of different attributes on different elements, I think, goes into the thousands. So now if you see that for every attribute to make it accessible, you have to write it to XML. You have to parse it from XML. You have to have methods to set and get the value. You have to make it available for scripting. You want to undo changes to it and stuff like that. And if you want to do it in consistent meta, but you have to do it like thousands of times, it's very error prone. So it would be nice to have a tool which just takes an annotated LexxNG file and creates a code which doesn't automatically in a consistent way. So that's one of the aims of it. OK. Now, and this is a conclusion. What are the steps ahead? So the first thing would be to define a LexxNG system like a mockup I just started to get it going. The second would be to implement a serialization in scribes. So we would add methods and scribes where the existing document implementation would write out XML, which would be validated against the LexxNG scheme we have. Once we have that, we can discuss the structure with developers in the community to tinker with it and make it better. So it evolves. So for scribes 1.6, we have a nice grid on the file format and an additional virtual-adaptive model. And also, I want to provide a tool which first had to go with Create C++ code from the scheme and by rotation with the LexxNG scheme to just use some ideas which are behind the server. Central base for LexxNG scheme which tells us our work on the college should be implemented. And the rest is all automatic. We don't have to be afraid that any parts keep in. From the end, once we have the tools, we can change the LexxNG and just regenerate the code and it will always stay the same. The file can be an other. OK, that was my phone. I think we have partners to that for that. Now, for your step number four, that looks very familiar because in the past I've done the same with XML schemas, XML, and access-sl-t to do the conversion. And one of the things when I was doing that, I was doing a bigger project I applied it to, I looked at not only when you make that conversion, you can create code to consume the file, put it in the format, you can create code to do stuff with the format, but you can also create a lot of unit tests to validate your assumptions about the format and handling of it. That's all that's interesting. I'd ask you about detail about it. So when they have encountered with this famous file format in the same plan, there are many, many options that are not well-optimized. So I wonder if in the last few years there's some method to map documentation for particular elements to get out of the project. So this is an application we have. I showed that's a general format of location. There is a special thing where you just use a number sign for comments, that's one thing. And if you have a element of sign, that's an abbreviation, something like a paradox or something, that's a document, just the documentation is a whole whole thing element. All right. Thank you, Carl. In that question, I mean, it would be nice if the people with strong interest in the script's format, I thought that you and the Italian guy who is doing the specification really deserves, maybe that they get involved. Yeah. I plan to have a discussion on the graph. So I would like to pose where we have a sample of the case. So I just wanted to say this is really great. And thanks for your great explanation on that, and it's the first time I actually got this. And also as an interest in first, I would like to answer some of your questions. Because it was mentioned, this was coming up very, very soon. I was wondering if there is something I could answer for the center of expectations. Well, I hope we can set up a discussion on ideas of our guide pretty soon, and also the first generation. And to have it complete, I think it would be for the next stable version. So it would be late 1.5 or 1.6. So the next stable version, 1.6, would be the start of the stable and the end of the forward. I would also like to say we tried to improve the pipeline for a long time. But it's kind of difficult for now, because it's always a moving target for one thing. And it's also very complicated to trade a file on, I think, but there are a lot of places on the code which you also have to change. And I really want to have this connection between the two things, the code, where you only have to trade it to one place. OK? Thank you very much for that. Thank you. Thank you. Thank you.
 Well, in fact, it's more like a road toward the document  object model and the file format.  And it's more or less like lightning talk, so it's  very good chance I'll make good on the 15 minutes delay we  already have.  OK, let's start with the document object model.  So it's three words.  And document means it describes a document, not any  menus or windows or processes or UV elements and stuff like  that.  But just a document and one thing you would expect.  If you have an instance of a document object model and  you've write it to a file, and when you load this file again  to get a document object model, you should have a faithful  copy of the original document.  And of course, object means comes from object oriented.  So you would expect some kind of trees or object, and every  object has attributes and methods.  And the important part, and that's where Scriber's legs  right now, it's a model.  It's not an implementation.  So of course, we have classes, object oriented  classes of Scriber's, which describe the document.  But there's all kind of other stuff, how to do some things  that event handling and what else.  And that's not what we understand with a model.  So the advantage of a model is when you have more than one  implementation in theory.  If you already have an implementation, it does not  make sense anymore.  You have to have a model which relates different  implementations.  OK.  So a document object model has many users.  So of course, first it's a guide to implementation.  But then you can also use it for serialization, where it's  writing to a file and loading from a file.  So the most common nowadays is to just use XML and map  objects to XML elements and attributes, object attributes  to XML attributes or other elements.  But you can also use it for scripting.  So if you look at standards like SVG, they describe the  document object, especially from how to tell how Javascript  can access a document and change a document and work on  it.  So that's another important thing you need to do.  It also helps with undo, because if you have an  document object model, you can describe, OK, I have this  action, and I've used the document object to describe  the state before the action and after the action.  And then the undo step is just to revert it.  You can also do it with use it for testing.  So if you have a document object model where you define  some of the methods, you know what is expected.  And then you can just test that.  It just more or less gives a framework to talk about what  is to test.  Because if you have an implementation and you don't  know what it's supposed to do, well, you can just observe  and then say, OK, do I like it or not like it.  But that's not really testing.  And of course, another possibility would be to help  with interoperability.  So if you have different implementations of one  document object model, you could have different  applications which use the same document object model and  hopefully can exchange data.  OK, so the idea, what I would propose for Scribers is to use  relaxNG to describe a document object model structure.  RelaxNG is XML schema language.  So the most common are relaxNG.  The original was DTT, document type declarations.  You might know about Bayer limitations and, of course,  official XML schema language from W3C, which is a kind of  complex and not that nice.  DTTs themselves are not XML.  But they are a part of XML standard, but how to describe  XML.  XML schema language is always XML, which is an advantage.  But has the disadvantage that XML is not very readable.  This example of relaxNG is the compact  representation of relaxNG.  The interesting thing about relaxNG is that they have two  flavors, and they are equivalent.  And you can convert this compact notation you see here in  the example to a XML version you can use for tools and  vice versa.  So it's a one-to-one correspondence.  And that's pretty nice.  So oh, yeah.  And here I just made up a possible grammar for Scriber.  So you have to have a start element.  So you just say start with document.  Then the document is an element like Scriberstock.  And Scriberstock is the process of a preference section,  then the resource section, the style section, the content  section, the structure section, layout section.  And having said that, you go on with saying, OK, preference  type thing looks like this.  It's just a list of attributes.  And here I used some real attributes we use right now  in Scribers, which are probably going to change.  For example, this name, unsullpages, it's a mixture  of German and English.  And we really want to get rid of that and have proper  English names everywhere.  OK, you can also see that if you have an attribute, then  this is a name for the attribute.  And you can give it a type, a data type.  So this is an integer.  You do know what it is.  And it's possible to define several of these data types.  And there are some predefined ones like integer and text.  But you also could define your own points and whatever.  OK, so advantages of Rolex and G. It's very readable.  I hope you agree.  And that allows it to discuss a dumb structure, because it's  not fixed.  That's just a mockup.  And among what developers, we and maybe also interested  users, we probably will do some fair discussion on how to  fix the file format at the document object format of  FOScribers to make it most usable.  And so another example is it also provides a file format  at the same time.  So there have been ongoing complaints about existing file  formats, because it was too complex.  And of course, we also have to change the file format once  in a while, because people like Louis are starting to rank with it.  And so, yeah, and we will have a good correspondence between  the implementation and the objects at runtime and  the file format also.  Next thing is because of the XNG, KS has another flavor,  which is XML.  It has good tool support for the XNG, for validation, and  for other stuff.  And last but not least, it's extensible.  You can have annotations, two elements, which could tell how  to use these elements or add documentation to it.  You can separate your grammar with namespaces.  So we could use it as a gene namespace, as well as our  own scribes namespace, as well as CSS namespace, or  whatever.  And yeah, there are some interesting ways to use  data type libraries, where you can define your own data types  that you want to have.  And we have some of those data types which are used in  scribes, for example, for points or paths or colors.  OK, so I'll just make an example of what an annotation  in LexNG would look like.  And the green part over there, which is an annotation, it  looks very similar to the rest, but just in square brackets.  And right now, I use the namesplace impl for  implementation, and I made it up, OK, the class would be  named scribestock.  And the idea is that this annotation tells us, if we  have elements scribestock in lower cases in the XML file,  we are supposed to use the C++, scribestock in camel  case, in the program.  And our idea is to have a tool which translates the  LexxNG to C++ code in a certain way.  That does not exist yet.  But there's some good reason to do it like this way.  I'll go back sometime.  If you look at this attribute, this is only the first  three attributes.  The scribest document has probably some dozens of  attributes just for this.  And altogether, the number of different attributes on  different elements, I think, goes into the thousands.  So now if you see that for every attribute to make it  accessible, you have to write it to XML.  You have to parse it from XML.  You have to have methods to set and get the value.  You have to make it available for scripting.  You want to undo changes to it and stuff like that.  And if you want to do it in consistent meta, but you have  to do it like thousands of times, it's very error prone.  So it would be nice to have a tool which just takes an  annotated LexxNG file and creates a code which doesn't  automatically in a consistent way.  So that's one of the aims of it.  OK.  Now, and this is a conclusion.  What are the steps ahead?  So the first thing would be to define a LexxNG system like  a mockup I just started to get it going.  The second would be to implement a serialization in  scribes.  So we would add methods and scribes where the existing  document implementation would write out XML, which would  be validated against the LexxNG scheme we have.  Once we have that, we can discuss the structure with  developers in the community to tinker with it and make it  better.  So it evolves.  So for scribes 1.6, we have a nice  grid on the file format and an additional  virtual-adaptive model.  And also, I want to provide a tool which first had to go  with Create C++ code from the scheme and by  rotation with the LexxNG scheme to just use some  ideas which are behind the server.  Central base for LexxNG scheme which tells us our  work on the college should be implemented.  And the rest is all automatic.  We don't have to be afraid that any parts keep in.  From the end, once we have the tools, we can change the  LexxNG and just regenerate the code and it will always  stay the same.  The file can be an other.  OK, that was my phone.  I think we have partners to that for that.  Now, for your step number four, that looks very  familiar because in the past I've done the same with  XML schemas, XML, and access-sl-t to do the conversion.  And one of the things when I was doing that, I was doing a  bigger project I applied it to, I looked at not only when  you make that conversion, you can create code to consume  the file, put it in the format, you can create code to do  stuff with the format, but you can also create a lot of  unit tests to validate your assumptions about the format  and handling of it.  That's all that's interesting.  I'd ask you about detail about it.  So when they have encountered with this famous file format  in the same plan, there are many, many options that are not  well-optimized.  So I wonder if in the last few years there's some method to  map documentation for particular elements to  get out of the project.  So this is an application we have.  I showed that's a general format of location.  There is a special thing where you just use a number sign  for comments, that's one thing.  And if you have a element of sign, that's an abbreviation,  something like a paradox or something, that's a  document, just the documentation is a  whole whole thing element.  All right.  Thank you, Carl.  In that question, I mean, it would be nice if the people  with strong interest in the script's format, I thought that  you and the Italian guy who is doing the  specification really deserves, maybe that they get involved.  Yeah.  I plan to have a discussion on the graph.  So I would like to pose where we have a  sample of the case.  So I just wanted to say this is really great.  And thanks for your great explanation on that,  and it's the first time I actually got this.  And also as an interest in first, I would like to  answer some of your questions.  Because it was mentioned, this was coming up very, very  soon.  I was wondering if there is something I could  answer for the center of expectations.  Well, I hope we can set up a discussion on ideas of  our guide pretty soon, and also the first  generation.  And to have it complete, I think it would be for the  next stable version.  So it would be late 1.5 or 1.6.  So the next stable version, 1.6, would be the  start of the stable and the end of the forward.  I would also like to say we tried to improve the  pipeline for a long time.  But it's kind of difficult for now, because it's always  a moving target for one thing.  And it's also very complicated to trade a file on,  I think, but there are a lot of places on the code  which you also have to change.  And I really want to have this connection between  the two things, the code, where you only have to  trade it to one place.  OK?  Thank you very much for that.  Thank you.  Thank you.  Thank you.
Towards_an_Document_Object_Model__DOM__for_Scribus_0_59.png Towards_an_Document_Object_Model__DOM__for_Scribus_60_755.png Towards_an_Document_Object_Model__DOM__for_Scribus_756_1307.png Towards_an_Document_Object_Model__DOM__for_Scribus_1308_1751.png Towards_an_Document_Object_Model__DOM__for_Scribus_1752_1835.png Towards_an_Document_Object_Model__DOM__for_Scribus_1836_1883.png Towards_an_Document_Object_Model__DOM__for_Scribus_1884_2339.png Towards_an_Document_Object_Model__DOM__for_Scribus_2340_2399.png Towards_an_Document_Object_Model__DOM__for_Scribus_2400_2543.png Towards_an_Document_Object_Model__DOM__for_Scribus_2544_5615.png Towards_an_Document_Object_Model__DOM__for_Scribus_5616_10103.png Towards_an_Document_Object_Model__DOM__for_Scribus_10104_11867.png Towards_an_Document_Object_Model__DOM__for_Scribus_11868_12107.png Towards_an_Document_Object_Model__DOM__for_Scribus_12108_12179.png Towards_an_Document_Object_Model__DOM__for_Scribus_12180_12935.png Towards_an_Document_Object_Model__DOM__for_Scribus_12936_14615.png Towards_an_Document_Object_Model__DOM__for_Scribus_14616_16331.png Towards_an_Document_Object_Model__DOM__for_Scribus_16332_24299.png Towards_an_Document_Object_Model__DOM__for_Scribus_24300_24339.png