ODF Toolkit/Minutes/2008 05

From Apache OpenOffice Wiki
Jump to: navigation, search


<Malte_> AGENDA:1 Status of the Teams1.1 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian1.2 UNO based Toolkit: Juergen Schmidt (jsc), Jirong1.3 AODL: Lars Behrmann (lb),liuyuhua1.4 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens, dyf2 Open discussions
jOpenDocument (n=blueos@AAmiens-151-1-105-167.w86-207.abo.wanadoo.fr) has joined #odftoolkit
<jOpenDocument> Hi
<Malte_> 1.1 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian
<liutao> Nothing from me. Ama is talking with somebody
<lijian> nothing new
<Malte_> 1.2 UNO based Toolkit: Juergen Schmidt (jsc), JirongSKIPPING1.3 AODL: Lars Behrmann (lb),liuyuhua
<lars> no news from me
<lars> btw. svante just arrived ;)
<Malte_> And now.... :)1.4 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens, dyf
<lars> .
<dyf> I'm still using and being familiar with new odfdom version,and thinking about how to migrate the form of odf4j to odfdom.
<dyf> .
<Malte_> Svante is trying to connect...
<lars> to what ;)
<jOpenDocument> ok so I'm back in 15minutes
|<-- jOpenDocument has left freenode (Client Quit)
Svante (n=sus@sd-socks-197.staroffice.de) has joined #odftoolkit
=-= Svante is now known as Svante_afk
=-= Svante_afk is now known as Svante
<Malte_> Svante - go go go !
<Svante> Morning - sorry traffic jam near Hamburg! :-)
<Svante> ODFDOM status update...
<Svante> I have started to work on the generation of the complete DOM Layer..
<Svante> But this will take a while..
<Svante> Next week I will be on vacation so there won't be an update on this
<Svante> And this week there were a lot of work on OOo 3.0 as well
<Svante> Bernd provided me with a patch for the OdfPackage and we will provide a patch after my vacation
<Svante> We noticed even that Styles from not implemented classes get lost (like Shape) as the default element is currently OdfDefaultElement, which is not inherited from a StyledElement.
amaOOo (n=amaOOo@sd-socks-197.staroffice.de) has joined #odftoolkit
<Svante> This will be fixed as soon we got all elements generated
<Svante> Is there any feedback / question regarding ODFDOM at this time?
<dyf> Svante: I'm still using and being familiar with new odfdom version.Now still not have a good idea.
<dyf> In the last week I'm thinking about how to migrate the form of odf4j to odfdom.Hope I can begin to do something next week.
jOpenDocu (n=blueos@AAmiens-151-1-21-72.w83-192.abo.wanadoo.fr) has joined #odftoolkit
<Svante> dyf: Just try and if you have any questions, ping one of us. Best on the odftoolkit list
<Svante> Perhaps we can put some more examples into the sources, which speeds up the usage..
<jOpenDocu> back
<Svante> of ODFDOM.
<Svante> Hi jOpenDocu
<jOpenDocu> Hi Svante
<dyf> ok
<Svante> dyf: My tip to get familiar is to use a simple JUnit test and debug with Netbeans to see what happens.. :-)
<dyf>  :)I'm doing this now.
<Svante> jOpenDocu: There will be a log published, so you can see what was written, but to summarize - I will be on vacation next week, but started with generation of all ODFDOM classes
<jOpenDocu> Svante: ok
<Svante> jOpenDoc: But the generation will sure take some time after my vacation as well. Nevertheless plan to give constantly feedback
<jOpenDocu> Svante: are you working on it alone?
<Svante> Nope
<Svante> But the transformation was done from Michael Brauer before and I have to work into the sources. The implementation (XSLT) part will be done by my part. The design is done in the team and with you (community)
<Svante> Lars Behrmann would like to reuse the transformation for other languages than Java as well. There might be done some refactoring..
vdaron (n=vdaron@ has joined #odftoolkit
<jOpenDocu> XSLT to Java???
<Svante> But the transformation is already quite powerful.
<Svante> Well actually using XSLT to generate ODF RelaxNG Schema to Java
<Svante> It is already in the sources, which can be downloaded...
<jOpenDocu> We did but focused on the model
<Svante> The idea is that we can regenerate the ODFDOM DOM Layer every time a new ODF version is delivered
<DieterLoeschky> bye!
|<-- DieterLoeschky has left freenode ("ChatZilla [Firefox]")
<Svante> bye Dieter
<Svante> I guess we have 2 minutes left in our usual time. Are there any questions left?
<Svante> As I was late, I sure can stay a little longer ;-)
<jOpenDocu> when do you plan the "full" model?
<Svante> 3-4 weeks from now
<jOpenDocu> ok
<Svante> Always keeping in mind, that there are functions that might be added later as well
<lars> bye
<Svante> But at least full in the term of a Java class for every XML element..
<jOpenDocu> what king of function do you mind?
<Svante> and a Java class attribute for every xml attribute
<Svante> Like adding a child to a parent
<Svante> Or the functionality I have described with my 0.6.1 announcement.. Second I am opening mailer..
<jOpenDocu> I thought you did it automaticaly
<Svante> Yes, this should being done automatically. :-)
<Svante> * Mandatory attributes should become part of the creation method.
<Svante> * Optional attributes should have default values from those used in
<Svante> OOo 2.4.
<Svante> These optional attributes need the defaults of 00o 2.4.x or later OOo 3.x
<Svante> The list is not complete yet - I believe
<jOpenDocu> I see
<Svante> Currently I am generating a list with the relation of styleable element to style:family
<jOpenDocu> seeing the xslt code, I wonder if it is the appropirate tool
<Svante>  :-)
<Svante> Well, if you have a better tool... ;-)
<jOpenDocu> Java!
<Svante> But I am quite familiar with XSLT and therefore it is easy for me..
<Svante> yes, that would be an option as well..
<Svante> Suggestions are most welcome..
<jOpenDocu> My problem is not to understand the XSLT
<Svante> That is the good think about 0.6.1 we still are able to change a lot of things
<Svante> But?
<jOpenDocu> but XSLT is far from what we could do in java
<Svante> my plan is to stick with XSLT first and if there are limits I will swap
<Svante> As Michael has started with XSLT it seems the fastest approach for me now
<vdaron> The other advantage of XSLT is that we could use parts of the same XSLT to generate C# code, right ?
<vdaron> or Python,...
<jOpenDocu> it will be a hell to add the default value and the "add to parent"
<Svante> vdaron: Yes, but we can be with Java similar flexible..
<Svante> jOpenDocu: Yes, but that's why I am doing it by myself :-)
<jOpenDocu> at the next schema update, how do you do?
<Svante> I suggest that we use always the latest schema..
<Svante> I quote myself from the last ODFDOM 0.6.1 announcment:
<Svante> * I suggest that for future versions of ODF, there won't be multiple
<Svante> DOM models nor multiple implementations of ODFDOM. ODFDOM should
<Svante> only work on the latest standardized ODF, but will annotate new
<Svante> ODF elements and attributes by their ODF version of appearance.
<Svante> Currently no such list exist and needs to be generated by
<Svante> comparing the RelaxNG schema of the different versions.
<jOpenDocu> is it on the wiki?
<Svante> I will move this to it, I thought so as well..
<Svante> Currenlty it is only in the mailing list
<jOpenDocu> ok
<jOpenDocu> I just wonder how "intelligent methods" could be added with XSLT
<jOpenDocu> and XSLT debuging is not what I could call "esay"
<jOpenDocu> easy
<odf-mib> Being the initial author of the XSLT code generation: I don't think it will be difficult to extend the XSLT based code generation to add default values or child elements
<Svante> The intelligent methods would be to get the information from the RelaxNG Schema. There are multiple parsing runs
<odf-mib> We are extracting these kind of information already from the schema for other purposes using XSLT
<Svante> jOpenDocu: If your refer of intelligent methods on the ODFDOM layer side, it will be in the Java source file template.
<jOpenDocu> ok but sometimes, "you" merged some classes like styles
<Svante> explain a little more..
<jOpenDocu> and such cases are not just "transformation"
<Svante> Can you give an example of this merge. I am not sure, if I understand completly what you are refering to.
<jOpenDocu> The best example is Style
<--| vdaron has left #odftoolkit
<jOpenDocu> there are a lot of Style subclasses, like AutoStyles
<Svante> You are right, we need to document, when there is a simple mapping and when we involve our own ideas to ease the life of the developer
<jOpenDocu> It could be difficult to add automaticaly inteligent code in class like: public class OdfTableStyle extends OdfStyle
<jOpenDocu> because XSLT is "just" about transform, not to "understand" java
<Svante> Yes, I agree with you. On the other hand we came quite far and I belive we should give it a try.
<Svante> Currently we use the try & error approach.
<Svante> The XSLT generates the Java classes directly into the source directory..
<Svante> If you do it, you will notice that they are even not in sync.. *coughcough* I did a little manual fixing short before the release... ;-)
<jOpenDocu> I have no doubdt that today it works, but how long did it take and how difficult is it to debug?
<Svante> Nevertheless give me a week after my vacation to work myself into it and I can give you more details...
<Svante> I believe you argue for a Java code generation solution, right?
<jOpenDocu> ok no problems
<Svante> I have no problem to switch from XSLT to Java if we should really run into that problems and/or you assist in creating a Java environment.. :-)
<jOpenDocu> what about replacing arrays by List in your generated classes?
<Svante> Sounds good to me at this moment. I will make myself a note.
<Svante> If any of you have feedback, let's sent it to the mailinglist or we create a wiki page to gather these ideas
<Svante> (any other suggestions are always welcome )
<jOpenDocu> I see a lot of things you cannot do in xslt too
<jOpenDocu> look at OdfListStyle
<jOpenDocu> String prefix = lse.getAttributeNS(OdfNamespace.STYLE.getUri(), "num-prefix");
<jOpenDocu> String suffix = lse.getAttributeNS(OdfNamespace.STYLE.getUri(), "num-suffix");
<jOpenDocu> String nformat = lse.getAttributeNS(OdfNamespace.STYLE.getUri(), "num-format");
<jOpenDocu> String bullet = lse.getAttributeNS(OdfNamespace.TEXT.getUri(), "bullet-char");
<jOpenDocu> how do we refactor OdfNamespace.STYLE.getUri() calls?
<Svante> Sorry, I miss the problem here..
|<-- lars has left freenode (Read error: 110 (Connection timed out))
<jOpenDocu> styleURI=OdfNamespace.STYLE.getUri();
<jOpenDocu> String nformat = lse.getAttributeNS(styleURI), "..."
<jOpenDocu> what eclipse call "refactor / extract local variable"
<Svante> Now I understand.
<Svante> Hmm.. I would still give it a try with XSLT.
<Svante> What about try it first with XSLT, as we have something there already, so there will be a full ODFDOM model available ASAP and then consider to switch if there are problems?
<Svante> I doubt that I can hold the similar deadline when I switch now to Java from XSLT.
<Svante> We can still port it later, but ODFDOM gets its full model earlier.
<Svante> Does this sound like a plan for you, jOpenDocu?
<jOpenDocu> yes
<Svante> BTW have you already subscribed our mailinglist?
<jOpenDocu> I will
<jOpenDocu> I'm very busy
<Svante> I have forwarded you the announcment of 0.6.1 with the items that will be moved to the wiki
<Svante> Just send an empty message to dev-subscribe@odftoolkit.openoffice.org.
|<-- odf-mib has left freenode ("ChatZilla 0.9.79 [Firefox]")
<Svante> jOpenDocu: No problem. I guess we are overtime anyway
<jOpenDocu> for jOpenDocument, we already have a working model that fot our needs, so we can wait for the complete generation of your classes
<Svante> I am very happy for your feedback!
<jOpenDocu> We planned to use your model for jOpenDocument 2.0
<Svante> BRILLIAN!
<Svante> It will push the quality of the model, when we have an advance application working on it!
<Svante> Looking forward to enhance our model that it satisfy your needs!
<jOpenDocu> if will need a lot of model changes/enhancement in you and our parts
<Svante> Of course
<Svante> But I am sure the hard work will be worth it
<jOpenDocu> sure
<Svante> Therefore once again thank you all for coming and especially you jOpenDocu!
<Svante> I am looking forward to come back to work recuperated from my Spain vacation ;-)
<jOpenDocu> I will keep you in touch by email
<Svante> Yes, please do. Not sure if I got mail on the countryside in Spain, but I will answer, whenever I am able to
<jOpenDocu> You had to go to San Francisco as I did :)
<Svante> Next time.. I have learned from you.. ;-)
<Svante> If there are not further questions.. I will just drop into my follow-up meeting.. :-)
<Svante> Starting in 30 seconds..
<Svante> All of you have a nice week-end! See you soon in two weeks.. but there will be a meeting next week (without me)
<Svante> byebye
<jOpenDocu> bye
<dyf> byebye


<DieterLoeschky> Hi!
<DieterLoeschky> Svante is going to facilitate the chat today
<Svante> AGENDA:
<Svante> 1 Status of the Teams
<Svante> 1.1 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens, dyf
<Svante> 1.2 AODL: Lars Behrmann (lb),liuyuhua
<Svante> 1.3 UNO based Toolkit: Juergen Schmidt (jsc), Jirong
<Svante> 1.4 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian
<Svante> 2 Open discussions
larsb_ (n=chatzill@nat/sun/x-c5a7ec1d71463a28) has joined #odftoolkit
odf-mib (n=chatzill@nat/sun/x-c17f09d45d0a3bd6) has joined #odftoolkit
<Svante> Let's start this is our agenda
<Svante> 1 Status of the Teams
<Svante> 1.1 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens, dyf
<Svante> That's my area, therefore I will continue.. ;-)
<Svante> Yesterday we uploaded a new version of ODFDOM
<Svante> With a couple of bugfixes and some enhancements
<Svante> I sent a detailed list to the newsgroup odftoolkit ..
<Svante> about the changes
<Svante> And as well give some insights about the possible upcoming changes
<Svante> Are there any questions regarding the new version 0.6.1?
<dyf> I just got the new version,but still not have a look.
<Svante> Good trick to upload it such close to the meeting, wasn't it? ;-)
<Svante> The truth is that we had some issue we were looking for before releasing the next version...
<Svante> But now you got something for the week-end.. :-)
<Svante> Any other questions?
<Svante> 1.2 AODL: Lars Behrmann (lb),liuyuhua
<larsb_> Wrote a little app to display all all elements and their attributes like they are defined by the spec to see which elements and attributes have to be generated for ODFDOM and maybe the also the ODFDOM implementation for AODL.
<larsb_> .
<Svante> Anything else?
<larsb_> . <-
<Svante> 1.3 UNO based Toolkit: Juergen Schmidt (jsc), Jirong
<larsb_> no ;)
<jsc> well, i don't see that i will continue to work on an UNO based toolkit at the moment. The only thing that of course make sense is to prepare a working prototype showing that UNO can be used to design an intuitive and easy to use API. Even with Java only but the opportunity to use it from other languages as well. Anyway not comparable with the office API where we did some mistakes and the...
<jsc> ...current available UNO mechanisms weren't in place at the design time.
<jsc> If we then can agree that it make sense to combine all efforts on one implementation that can be used from different programming languages, then and only then it make sense from my point of view to investigate deeper in an UNO based toolkit.
<jsc> Otherwise i would focus on odfdom and make this API as easy and intuitive as possible. We need more adoption of ODF in other applications, especially in web applications and on small devices and probably Java is a good choice to address this without UNO. I am not sure ... we will see
bei (i=rfc821@e177100107.adsl.alicedsl.de) has joined #odftoolkit
* jsc waiting that you have read it ...
<bei> Hi there!
<Svante> I am looking forward for a prototype using UNO in ODFDOM so we can have a base for our discussions to use UNO or neglect it in ODFDOM..
<jsc> i agree that it will make further decisons easier ....
<Svante> Any further comments - without doing the discussion now?
<Svante> The discussion might take place in the end of the IRC meeting ;-)
<bei> The main problem I see for an UNO approach is that UNO sometimes redoes things that java has instead of mapping it to the corresponding java thing in the java binding.
<Svante> We should postpone this to the end, bei..
<bei> ok
<Svante> I continue..
<Svante> 1.4 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian
<amaOOo> Resync of CWS swrefactor with m13 is done, a lot of conflicts (hopefully) solved
<amaOOo> (DEV300m13 contains e.g. pages01, notes3, changefileheader)
<amaOOo> Build after resync just started
<Svante> Anything else?
<lijian> I have compiled new code changes and provided dlls to zhulihua
<Svante> All right, than we might start with the discussions..
<Svante> 2 Open discussions
<Svante> There was already a comment from <bei>
<Svante> "The main problem I see for an UNO approach is that UNO sometimes redoes things that java has instead of mapping it to the corresponding java thing in the java binding."
<Svante> JSC, you migth want to comment this..
<jsc> well not everything is perfect ... No i am just joking ...
<jsc> We can still think about UNO improvements if necessary
<bei> Question is if with the new things introduced in java6 a better mapping might be possible
<jsc> ... that have to analyzed in detail then
<jsc> ... new Java UNO language binding
<bei> I would for example like to stick to that w3c defined DOM as org.w3c.dom classes and not use some com.sun.star.dom thing instead if that would be possible
<jsc> i don't know yet but that are details
<jsc> anyway let us discuss it later
<Svante> You might start a list of these details, bei and hand it to JSC (or publish it)
<Svante> I guess enhancement requests are always appreciated
<bei> ok
<Svante> We still have 10 minutes...
<Svante> Anything else that somebody wants to discuss?
<jsc> no not om me
<bei> I have just seen that java6 defines some methods to redefine a class after it has been loaded and was wandering if this would be something that could be use to enhance the java<->Uno language binding
* jsc mmh my keyboard eat charaters
<Svante> Sounds interesting, bei. This will surely need to be analyzed in detail by the UNO group. BTW you might want to add a usage scenario together with the feature.
<jsc> bei: i don' know yet but i see some difficulties
<bei> I know this might be just a weired idea.
<Svante> Than I suggest, you just put it on your enhancement list for now.. ;-)
<jsc> anything else for today?
<Svante> We are close to the end... 2minutes left...
<Svante> Nothing? Than thank you for coming...
<jsc> ok, thanks and bye
<Svante> Till next week with a public reviewed ODFDOM 0.6.1 ;-)
<Svante> bye everybody!
<amaOOo> Bye bye!
<bei> bye
<dyf>  :)byebye
<--| amaOOo has left #odftoolkit
<Klemens> bye
<--| Klemens has left #odftoolkit
<fme> Bye all.


<Malte_> AGENDA:1 Status of the Teams1.1 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens, dyf1.2 AODL: Lars Behrmann (lb),liuyuhua1.3 UNO based Toolkit: Juergen Schmidt (jsc), Jirong1.4 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian2 Open discussions
<Malte_> 1.1 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens, dyf
<Svante> Let me start..
<Svante> We have found some issue with constructors...
xiuzhi (n=Administ@ has joined #odftoolkit
<Svante> And looking forward to upload a new version
<Svante> Still fixing and refactoring package layer
odf-mib (n=chatzill@nat/sun/x-8fbae7770c5c049e) has joined #odftoolkit
<Svante> Most likely next week a new version
<Svante> will be available
<Malte_> What about some repository access? ;)
<Svante> Good question ;-)
<Svante> We are working on this one too..
<Svante> Even on features like nightly builds.. :-)
<Svante> Any further questions?
<dyf> nothing from me.
<Svante> Me and Bernd will work on the package layer
<Svante> And will upload an update next week
<Malte_> 1.2 AODL: Lars Behrmann (lb),liuyuhua
<larsb_> Analyzed possible steps for refactoring AODL to implement the ODFDOM architecture. If AODL will implement this archtitecture, I think we should do it, we will also move to .NET 2.0. At least I worked on cleanup the exitsting NUnit tests.
<liuyuhua> nothing from me
<larsb_> .
<Malte_> 1.3 UNO based Toolkit: Juergen Schmidt (jsc), Jirong
<larsb_> skip?
<Malte_> Yes... :)
<xiuzhi> yes
<Malte_> 1.4 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian
<amaOOo> Status swrefactoring:
<amaOOo> I've changed our CWS in a way that our modularization rework has been retained
<amaOOo> even I disabled the feature "multiple layout" for this CWS
<amaOOo> I'm planning to resync this CWS next week.
<lijian> I have checked out these code changes
<amaOOo> lijian: Could you provide libraries with my last changes to Zhu Lihua?
<amaOOo> He could help me to find bugs caused by my rework.
<lijian> amaOOo:OK. No problem.:-P
<amaOOo> lijian: Fine, thanks!
<lijian> amaOOo:You are welcome!
<Malte_> 2 Open discussions


<Malte_> AGENDA:1 Status of the Teams1.1 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens1.2 AODL: Lars Behrmann (lb),liuyuhua1.3 UNO based Toolkit: Juergen Schmidt (jsc), Jirong1.4 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian2 Open discussions
<Malte_> 1.1 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens
<Malte_> Skipping, nobody here...
<Malte_> 1.2 AODL: Lars Behrmann (lb),liuyuhua
<dyf> I had submitted the code to Bernd.
<larsb_> Wait for dyf?
<Malte_> Sorry dyf
<larsb_> Or go on?
<Malte_> Didn't have you on that item...
<dyf> Yes,;)
<larsb_> I've optimized the AODL package handling and the NUnit tests.
<larsb_> .
<Malte_> 1.3 UNO based Toolkit: Juergen Schmidt (jsc), JirongSkipping....1.4 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian
<amaOOo> If we don't find a solution for controls and drawing groups we will disable multiple layout functionality
<amaOOo> and integrate our CWS because of its general progress in modularization and code quality
<amaOOo> Later on (in another CWS) we will find a solution and then enable the functionality again.
<lijian> nothing new
<liutao> Nothing from me.
<liutao> amaOOo: +1
<Malte_> OK, seems we are already done :)
<Malte_> Please: Arrive in time for the next meeting!
<Malte_> Open discussions now...
<dyf> Svante and Bernd are all not here?
Svante (n=sus@sd-socks-197.staroffice.de) has joined #odftoolkit
=-= Svante is now known as Svante_afk
=-= Svante_afk is now known as Svante
<Malte_> Svante - late, but I know you are traveling ;)
<Svante> Morning, sorry TrafficJam in Dublin
<larsb_> good morning svante ;) wrong time in dublin ;)
<Malte_> Anything you want to say about ODFDOM?
<Svante> I am happy its open sourced now
<Svante> Have there been certain questions already
<Svante>  ?
<DieterLoeschky> Yes, great job delivered in time!
<larsb_> Any first feedback from your presentation ?
<dyf> I had a look at the ODFDOM's source code,It's cool!
<Svante> Good feedback adn thx dyf
<dyf>  :)What can I do for this project?
<Svante> Whatever you can :-)
<larsb_> Great, I think we can talk about it next tuesday :)
<Svante> I will start a task list / 2do list (possibly issuetrackerlist) next week
<Svante> Giving suggestions where to go in the next steps..
<dyf> OK,will odf4j moved to ODFDOM?
<Svante> But dyf, you can check theAPI closely for consistendy
<Svante> yes, odf4j fucntionality wil be merged into ODFDOM
<dyf> ok, Now should I begin working for the mergement?
<Svante> dyf you might give suggestions on the list, what funtionality you want to get moved first from ODF4j to ODFDOM
<dyf> The list had be publiced?
<Svante> I mean the maling list ;-)
<dyf> Oh, No problem.
<Svante> We have not evolved the processes to work smoothly with multiple external developers on ODFDOM
<larsb_> Next to move convience functionality from odf4j to ODFDOM we should also start generating more classes resp. elements ..
<Svante> But we will com up with suggestions very soon
<Svante> Yes, larsb that's my impression too
<dyf> I see.
<Svante> I suggest everyone takes a look what he can do, and what he thinks need to be done...
<Svante> Of course we stumbled over seeral things, that still need work, like the automatic style handling
<larsb_> +1
<Svante> dyf: I would suggest we discuss further progres on the mailing list, as on Monday is public holiday in Germany, don't expect a feedback before Tuesday :-)
<dyf>  :)OK.
<Svante> Any further questions on ODFDOM?
<dyf> nothing else now. we'll discuss it in the mailing list.
<Svante> Otherwise I would leave 5min earlier as the next talk is starting here on the XTech
<Svante> k
<Svante> Thanks for your help offering, dyf. Looking forward to work together
<dyf>  :)Me too.
<DieterLoeschky> Svante: good luck for your XTech talk and have a good trip back
<Svante> ok, guys. I will move on. Malte will you take over.. Thx Dieter!
<Svante> cya
=-= Svante is now known as Svanteafk
<Malte_> Take over what? ;)
<Malte_> I think we are done now...
<Malte_> Bye all :)



Personal tools