[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [odf-adoption] Interop camp example
Hello Erwin, all, how many people do you think would attend this event? best, Charles. donald_harbison@us.ibm.com a écrit : > > Erwin, > > I like your outline below., I recommend we propose this for > discussion/review/modification to the conference organizers for > consideration under the September 18th 'Project' day programme. That > way it removes any confusion/conflict with the mainstream conference. > > Comments? > > Regards, > > Don Harbison > Program Director, IBM ODF Initiative > Business & Technical Strategy > IBM Software Group > tel:1-978-399-7018 > Mobile: +1-978-761-0116 > email: donald_harbison@us.ibm.com > > > > > From: Erwin Tenhumberg <Erwin.Tenhumberg@Sun.COM> > To: robert_weir@us.ibm.com > Cc: odf-adoption@lists.oasis-open.org > Date: 06/26/2007 04:42 AM > Subject: Re: [odf-adoption] Interop camp example > > > ------------------------------------------------------------------------ > > > > Hi Rob, > > Thanks a lot for your input and your ideas! > > I'd like to step back for a second and think about the larger agenda > of the event first. Here is what I could imagine: > > > 1) Keynote by an ODF adopter about what they expect regarding > interoperability / conformance (30 minutes) > > 2) Potentially a second 30 minute keynote by another ODF adopter > (30 minutes) > > 3) 10 minute presentations by the different ODF implementors who > came to the event about how much of ODF they implemented, > how they did it and what major problems they ran into > (about 1 hour and 30 minutes) > > 4) Lunch (1 hour) > > 5) Workshop / discussion / brainstorming / life testing of the > issues mentioned during the first presentations (3 hours) > > 6) A session for anybody interested in implementing ODF and > wants to learn from the experts how to do it, e.g. it could > be a panel where the newbies ask the experts. (1 hour) > > > Focusing on word processing might make sense because it might be > the area where we can achieve a critical mass most easily. > However, we could also first just ask the different companies and > projects who will come and then decide if we want to add other > aspects as well. For example, if Google and KOffice send > spreadsheet guys, we could add spreadsheets to the agenda. > > > Max Odendahl from Odendahl SEPT-Solutions who created Mobile > Office from Symbian already expressed interest in coming to the > event. I haven't heard back from Softmaker, yet. > > > I guess topics 1) to 5) would be useful for any vendor interested > in implementing ODF, but I think we should encourage them to > be remain in a "listening only" / consuming mode for the first > parts in order not to distract the interop discussions. Then in > session 6) all the newbies would get a chance to ask all the > questions they collected during the day. Invitations could be > sent to CMS, DMS, SOA, etc. vendors. > > > Anyway, in the end the key players for ths workshop are the > experts specifying ODF and implementing ODF. Thus, it might > make sense to move this discussion to the main line TC or > at least to include the main line TC. > > I myself like to attend the event and am willing to help with the > setup, but I probably would not be a key player at the event myself. > > > All the best, > Erwin > > > > robert_weir@us.ibm.com wrote: > > > > A few words to explain what I was proposing for an interoperability > camp. > > > > I was thinking we could concentrate on word processor format > > interoperability, since we're more likely to get a critical mass of > > participants if we focus. The idea would be to get those who knew the > > internals of their word process and came with the source code and the > > ability to prototype changes during the camp. So we want the coders. > > > > In advance of the camp, we would send out PDF files illustrating some > > sample documents. In advance of the camp, each vendor would attempt to > > replicate that document to the best of their application's abilities. > > They would then save the document in ODF format. > > > > An example document might be to replicate the first page of this PDF: > > > https://www.socialsecurity.be/foreign/en/employer_limosa/infos/documents/pdf/act_mb_28122006.pdf > > > > > > > This is an example of Belgian statute format, where the text is > given in > > parallel translation. To get the proper alignment would require > > probably the use of tables with hidden borders. There are also some > > challenging aspects of getting the numbered lists and list levels > correct . > > > > When we send out the PDF we would also provide some annotations to > > explain some finer points of the document that might otherwise be > > overlooked, like the use of em-dahes and en-dashes in the page header. > > > > Depending on the complexity, we might have 5 or so documents that we do > > in this way, each one emphasizing different practical issues concerning > > interoperability. > > > > We would collect the ODF's from each vendor in advance of the camp, and > > distribute them to everyone at the camp, or a few days in advance. So > > if we have 5 vendors, then everyone would have 5 different ODF versions > > of each document. > > > > And what do we do at the camp? Say we have 5 vendors and 5 target > > documents. That gives each vendor 20 documents to try loading, giving > > 100 different interoperability tests we can perform. How do we handle > > this? One way would be to set aside an hour for each document and have > > each vendor take a turn first explaining any issues they had in > creating > > the document originally, and then they could load each other vendor's > > version of that document, and the group could note what new > problems, if > > any, show up. If each vendor can be projecting their application on > the > > screen while doing this, we can all look and observe together, and do > > this efficiently. > > > > We would then want to reserve some time for coding, and some time at > the > > end for vendors to demonstrate any fixes, and some time to discuss next > > steps. > > > > As you can see, this is going to be time consuming. So maybe we would > > only be able to do 2-3 test documents? > > > > -Rob > > ___________________________ > > > > Rob Weir > > Software Architect > > Workplace, Portal and Collaboration Software > > IBM Software Group > > > > email: robert_weir@us.ibm.com > > phone: 1-978-399-7122 > > blog: http://www.robweir.com/blog/ > > -- Charles-H. Schulz, Associé / Associate Ars Aperta.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]