OpenDocument - Adv Document Collab SC

Submitter's message Initial presentation document for todays presentation.
Please join the IRC as well http://webconf.soaphub.org/conf/room/odf

Meet you in about an hour,
Svante -- Mr. Svante Schubert Document Name : Presentation of Merge-enabled Change Tracking (MCT) Description The presentation to be given to the sub-committee explaining Merge-enabled Change Tracking (MCT) Download Latest Revision Public Download Link Submitter : Mr. Svante Schubert Group : OpenDocument - Advanced Document Collaboration SC Folder : Use Cases Date submitted : 2012-02-14 05:38:22

Following presentation by Svante today, participants in the call suggested the following activities: 1. Svante will update the presentation document because there appeared to be a number of errors in the examples and these need to be correct in order to be used as examples of how MCT works. 2. Svante will write up details of the path notation being used. This is not XPath/XPointer but is based on components in the ODF. 3. Patrick, Tristan and Thorsten will work on some examples, using the six Use Cases that were selected for detailed examination of ECT and GCT. Svante will provide some further documentation giving details of the operations to be used for these, then Patrick, Tristan and Thorsten will encode the tracked changes in MCT. Svante will also produce a 'correct' example for each. 4. We will have a further call to discuss in 2-3 weeks time. Meanwhile the TC is looking at requirements so our work is in parallel. 5. The objective is to have sufficient understanding so that we can review Svante's changes to the consensus report and update this as necessary with the findings of the SC. 6. Any other technical questions to the mailing list over the next few weeks. Robin   -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

On 14.02.2012 18:04, Robin LaFontaine wrote: Following presentation by Svante today, participants in the call suggested the following activities: 1. Svante will update the presentation document because there appeared to be a number of errors in the examples and these need to be correct in order to be used as examples of how MCT works. Another draft was just uploaded. 2. Svante will write up details of the path notation being used. This is not XPath/XPointer but is based on components in the ODF. As drafted in slide 6 the ODF XML tree will be mapped to a ODF component tree, where characters are the smallest components. After all root elements of components are identified the mapping from component paths to XPath to content.xml elements can be applied in praxis. The ODF Component reference is a simplification of XPath. Each number refers to the sibling number of a component in a hierarchy. For example, /1/2/3 refers to the first component in the document, its second child component and within the second child the third component. Only Tables will have an additional path which reflects the cell references notations widely used. 3. Patrick, Tristan and Thorsten will work on some examples, using the six Use Cases that were selected for detailed examination of ECT and GCT. Svante will provide some further documentation giving details of the operations to be used for these, then Patrick, Tristan and Thorsten will encode the tracked changes in MCT. Svante will also produce a 'correct' example for each. The basic idea is that the given operations (that will be serialized) would be specified. Not only the according XML change, which seems more some straight forward work, but more interesting as well general behavior, as if I split a paragraph, what are the properties of second new paragraph? Like the creation of the list, was only selecting a sequence of paragraphs and every paragraph will become a list item (slide 12). It does not matter if applications behave different, like the selection and deletion example (slide 13) shows. See notes for details. The idea for collaboration/change-tracking is to avoid unnecessary sending/serializing of information, that could be agreed on. Like what is an empty text/spreadsheet/etc. document?What are the basic style sets someone could refer to, as Heading 1 . We might still define custom sets as OOo 3.x, KOffice or MS Office 2010 flavor . The more we agree on defaults, the less we have to collab chit-chat over the wire and the more we have interoperability. 4. We will have a further call to discuss in 2-3 weeks time. Meanwhile the TC is looking at requirements so our work is in parallel. 5. The objective is to have sufficient understanding so that we can review Svante's changes to the consensus report and update this as necessary with the findings of the SC. 6. Any other technical questions to the mailing list over the next few weeks. I would enjoy feed-back. The feed-back of the presentation really already helped a lot! Thanks, Svante Robin   -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org

Hi Robin, On 14.02.2012 18:04, Robin LaFontaine wrote: Following presentation by Svante today, participants in the call suggested the following activities: ... 3. Patrick, Tristan and Thorsten will work on some examples, using the six Use Cases that were selected for detailed examination of ECT and GCT. Svante will provide some further documentation giving details of the operations to be used for these, then Patrick, Tristan and Thorsten will encode the tracked changes in MCT. Svante will also produce a 'correct' example for each. ... When mentioning six Use Cases, I believe you refer to those mentioned in the mail http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201107/msg00010.html I am asking as neither Wiki http://wiki.oasis-open.org/office/ChangeTrackingUseCases nor documents http://www.oasis-open.org/apps/org/workgroup/office-collab/documents.php explicitly referring to six use cases. Two questions: Wasn't there eight examples in the end? There are two documents labeled GCT-UC7.zip & GCT-UC8.zip? Is there a reason that our Wiki does not list UC6 the text frame example, nor maps to the 6 (or 8) UCs? Thanks, Svante

Replies inline. On 20/02/2012 13:29, Svante Schubert wrote: Hi Robin, On 14.02.2012 18:04, Robin LaFontaine wrote: Following presentation by Svante today, participants in the call suggested the following activities: ... 3. Patrick, Tristan and Thorsten will work on some examples, using the six Use Cases that were selected for detailed examination of ECT and GCT. Svante will provide some further documentation giving details of the operations to be used for these, then Patrick, Tristan and Thorsten will encode the tracked changes in MCT. Svante will also produce a 'correct' example for each. ... When mentioning six Use Cases, I believe you refer to those mentioned in the mail http://www.oasis-open.org/apps/org/workgroup/office-collab/email/archives/201107/msg00010.html Yes I am asking as neither Wiki http://wiki.oasis-open.org/office/ChangeTrackingUseCases nor documents http://www.oasis-open.org/apps/org/workgroup/office-collab/documents.php explicitly referring to six use cases. Two questions: Wasn't there eight examples in the end? There are two documents labeled GCT-UC7.zip & GCT-UC8.zip? Yes - UC7 see email 2011-07-25 Possible UC7 for consideration... See also document GCT-UC7.zip - UC8 see email 2011-07-25 Possible UC8 test case. See also document GCT-UC8.zip Is there a reason that our Wiki does not list UC6 the text frame example, nor maps to the 6 (or 8) UCs? No reason, it is a wiki so please do update to include these. The page was set up before these UCs were selected/proposed and lists all the original use cases which were developed to demonstrate GCT, plus J.1 and J.2 which were suggested but have not been actioned. As H.1 Formula and Number Modification Example is in scope for MCT you may wish to consider that one also to show how MCT handles a spreadsheet example. Robin Thanks, Svante -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

On 21.02.2012 12:25, Robin LaFontaine wrote: ... Is there a reason that our Wiki does not list UC6 the text frame example, nor maps to the 6 (or 8) UCs? No reason, it is a wiki so please do update to include these. The page was set up before these UCs were selected/proposed and lists all the original use cases which were developed to demonstrate GCT, plus J.1 and J.2 which were suggested but have not been actioned. As H.1 Formula and Number Modification Example is in scope for MCT you may wish to consider that one also to show how MCT handles a spreadsheet example. I am missing the details for the example H.1. Unfortunately there is neither a reference to test document and/or mail(s), nor a reference to the GCT example, completing this scenario. May suggest that I will work out the examples for MCT, providing operations for Patrick, Tristan and Thorsten to solve their scenarios, having a solution made for myself. While you (or some other helping hand) bring the Wiki up-to-date in terms of references so we all can rely on the same detailed requirements? Thanks in advance, Svante

The reference is there, perhaps not clearly enough, see second para in the wiki: Each use case is defined in terms of a 'before change' and 'after change' ODF document which you can find in a zip under 'Use Cases' folder in http://www.oasis-open.org/apps/org/workgroup/office-collab/documents.php The solutions for the Generic proposal are also in the same folder. Those for the Extended proposal are in the 'Standards' folder within the proposal itself. I just downloaded the zip - everything is there, except for J.1 and J.2 which have not been done. Robin On 21/02/2012 13:24, Svante Schubert wrote: On 21.02.2012 12:25, Robin LaFontaine wrote: ... Is there a reason that our Wiki does not list UC6 the text frame example, nor maps to the 6 (or 8) UCs? No reason, it is a wiki so please do update to include these. The page was set up before these UCs were selected/proposed and lists all the original use cases which were developed to demonstrate GCT, plus J.1 and J.2 which were suggested but have not been actioned. As H.1 Formula and Number Modification Example is in scope for MCT you may wish to consider that one also to show how MCT handles a spreadsheet example. I am missing the details for the example H.1. Unfortunately there is neither a reference to test document and/or mail(s), nor a reference to the GCT example, completing this scenario. May suggest that I will work out the examples for MCT, providing operations for Patrick, Tristan and Thorsten to solve their scenarios, having a solution made for myself. While you (or some other helping hand) bring the Wiki up-to-date in terms of references so we all can rely on the same detailed requirements? Thanks in advance, Svante -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK

As Robin stated before the H.1 spreadsheet example is explained verbose via 'before change' and 'after change' ODF documents, which you can find in the following zip http://www.oasis-open.org/apps/org/workgroup/office-collab/download.php/40800/use-cases.zip The interesting change occurs within the content.xml: State A - before: <table:table-row table:style-name= ro1 >     <table:table-cell office:value-type= float office:value= 2010 >         <text:p>2010</text:p>     </table:table-cell>     <table:table-cell office:value-type= float office:value= 10000 >         <text:p> 10000 </text:p>     </table:table-cell>     <table:table-cell table:formula= of:=0.15*[.B4] office:value-type= float office:value= 1500 >         <text:p> 1500 </text:p>     </table:table-cell> </table:table-row> State B - after: <table:table-row table:style-name= ro1 >     <table:table-cell office:value-type= float office:value= 2010 >         <text:p>2010</text:p>     </table:table-cell>     <table:table-cell office:value-type= float office:value= 11000 >         <text:p> 11000 </text:p>     </table:table-cell>     <table:table-cell table:formula= of:=0.2*[.B4] office:value-type= float office:value= 2200 >         <text:p> 2200 </text:p>     </table:table-cell> </table:table-row> On the first glance it seems the document has changed at five different places. At a closer look - with some ODF back-ground - only two changes are identified, because the following ODF relations create dependencies of changes: The cell's @office:value attribute (see [1] ) is always reflected by the cell's paragraph content.  Changing a cell's formula (@table:formula attribute, see [2] ) changes as well the cell's @office:value - if existent - and the cell's paragraph content Changing a cell's content (text of child paragraph), which is referenced by another cell's formula results in general in a change of the @office:value and the paragraph text of the cell with the formula. By the above dependencies the XML changes are mapped into basically two state changes, which can be mapped to two operations to be serialized using Merge-Enabled Change Tracking (MCT): The change of cell value [.B4] The change of the formula of cell [.C4] and the resulting cell value & paragraph text change Two comments on the operations to be created: Tables are extraordinary ODF components. Tables are like two dimensional data arrays within the document tree. A world for its own. They got an own reference scheme (see [3] [4] ) that should be reused by operations. The at the beginning listed dependent changes due to ODF relations are like a set of operations being executed as a transition. Therefore a <transaction> element was added to MCT to represent the atomic change. Instead to use two operations of delete and addition of the similar text sequence, the replace function has been added. A properties of a component is in general named as the local name of the XML attribute (if unambiguous) Properties of components are exchanged in total versus the text content of paragraphs, as properties will never be merged. The component before the cell reference in the path /1/[.B4] have to be a table. If there is an URI or sheet locater in the reference, it have to be resolved to the table, otherwise OT will not work. Changes from A to B (over A'): Only for demonstrating the changes, not required for change-tracking to undo the changes: <changes>     <transaction>         <replace s= /1/[.B4]/@value value= 11000 />         <replace s= /1/[.B4]/1/2 >1</replace>         <replace s= /1/[.C4]/@value value= 1650 />         <replace s= /1/[.C4]/1 s= /1/[.C4]/3 >165</replace>     </transaction>     <transaction>         <replace s= /1/[.C4]/@formula value= of:=0.2*[.B4] />         <replace s= /1/[.C4]/@value value= 2200 />         <replace s= /1/[.C4]/1 e= /1/[.C4]/3 >220</replace>     </transaction> </changes> State A' - intermediate: The intermediate after the first transaction is assumed to be <table:table-row table:style-name= ro1 >     <table:table-cell office:value-type= float office:value= 2010 >         <text:p>2010</text:p>     </table:table-cell>     <table:table-cell office:value-type= float office:value= 11000 >         <text:p> 11000 </text:p>     </table:table-cell>     <table:table-cell table:formula= of:=0.15*[.B4] office:value-type= float office:value= 1650 >         <text:p> 1650 </text:p>     </table:table-cell> </table:table-row> Changes from B to A (over A'): The following are the operations necessary to undo the changes to be serialized in the undo.xml file: <changes>     <transaction>         <replace s= /1/[.C4]/@formula value= of:=0.15*[.B4] />         <replace s= /1/[.C4]/@value value= 1650 />         <replace s= /1/[.C4]/1 s= /1/[.C4]/3 >165</replace>     </transaction>     <transaction>         <replace s= /1/[.B4]/@value value= 10000 />         <replace s= /1/[.B4]/1/2 >0</replace>         <replace s= /1/[.C4]/@value value= 1500 />         <replace s= /1/[.C4]/1 e= /1/[.C4]/3 >150</replace>     </transaction> </changes> If we could assume that the ODF application is able to interpret formula and is aware how to map an @office:value to a paragraph text, again a lot of boilerplate could be removed: Redo.xml: The redo.xml file is only for demonstration purpose and would only be saved using the history feature saving the document to the original state A and still able to go to the future state B. <changes>     <replace s= /1/[.B4]/@value value= 11000 />     <replace s= /1/[.C4]/@formula value= of:=0.2*[.B4] /> </changes> Finally the MCT solution for change-tracking this example would be the file below: Undo.xml: <changes>     <replace s= /1/[.C4]/@formula value= of:=0.15*[.B4] />     <replace s= /1/[.B4]/@value value= 10000 /> </changes> In the end only the essential operations would remain. - Svante [1] http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-office_value [2] http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-table_formula [3] http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html#Reference [4] http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html#References

On Tue, 2012-02-21 at 15:28 -0700, Svante Schubert wrote: > The interesting change occurs within the content.xml: > > State A - before: > <table:table-row table:style-name="ro1"> > <table:table-cell office:value-type="float" office:value="2010"> > <text:p>2010</text:p> > </table:table-cell> > <table:table-cell office:value-type="float" office:value="10000"> > <text:p>10000</text:p> > </table:table-cell> > <table:table-cell table:formula="of:=0.15*[.B4]" > office:value-type="float" office:value="1500"> > <text:p>1500</text:p> > </table:table-cell> > </table:table-row> > > > State B - after: > <table:table-row table:style-name="ro1"> > <table:table-cell office:value-type="float" office:value="2010"> > <text:p>2010</text:p> > </table:table-cell> > <table:table-cell office:value-type="float" office:value="11000"> > <text:p>11000</text:p> > </table:table-cell> > <table:table-cell table:formula="of:=0.2*[.B4]" > office:value-type="float" office:value="2200"> > <text:p>2200</text:p> > </table:table-cell> > </table:table-row> > > On the first glance it seems the document has changed at five > different places. At a closer look - with some ODF back-ground - only > two changes are identified, because the following ODF relations create > dependencies of changes: > The cell's @office:value attribute (see [1]) is always > reflected by the cell's paragraph content. I would disagree with this formulation. The cell's paragraph content can be deduced from the office:value attribute (assuming one knows the applicable style, but not vice-versa). > Changing a cell's formula (@table:formula attribute, see [2]) > changes as well the cell's @office:value - if existent - and > the cell's paragraph content > Changing a cell's content (text of child paragraph), which is > referenced by another cell's formula results in general in a > change of the @office:value and the paragraph text of the cell > with the formula. > > By the above dependencies the XML changes are mapped into basically > two state changes, which can be mapped to two operations to be > serialized using Merge-Enabled Change Tracking (MCT): > > > 1. The change of cell value [.B4] > 2. The change of the formula of cell [.C4] and the resulting cell > value & paragraph text change Unfortunately this only suffices as long as the office:value change is a deterministic consequence of a formula change. Simple recalculation of a document could change values without any accompanying formula changes (think of random number generation or other volatile functions such as date, time,....) Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta Attachment: signature.asc Description: This is a digitally signed message part

On 22.02.2012 01:36, Andreas J. Guelzow wrote: > On Tue, 2012-02-21 at 15:28 -0700, Svante Schubert wrote: >> The interesting change occurs within the content.xml: >> >> State A - before: >> <table:table-row table:style-name="ro1"> >> <table:table-cell office:value-type="float" office:value="2010"> >> <text:p>2010</text:p> >> </table:table-cell> >> <table:table-cell office:value-type="float" office:value="10000"> >> <text:p>10000</text:p> >> </table:table-cell> >> <table:table-cell table:formula="of:=0.15*[.B4]" >> office:value-type="float" office:value="1500"> >> <text:p>1500</text:p> >> </table:table-cell> >> </table:table-row> >> >> >> State B - after: >> <table:table-row table:style-name="ro1"> >> <table:table-cell office:value-type="float" office:value="2010"> >> <text:p>2010</text:p> >> </table:table-cell> >> <table:table-cell office:value-type="float" office:value="11000"> >> <text:p>11000</text:p> >> </table:table-cell> >> <table:table-cell table:formula="of:=0.2*[.B4]" >> office:value-type="float" office:value="2200"> >> <text:p>2200</text:p> >> </table:table-cell> >> </table:table-row> >> >> On the first glance it seems the document has changed at five >> different places. At a closer look - with some ODF back-ground - only >> two changes are identified, because the following ODF relations create >> dependencies of changes: >> The cell's @office:value attribute (see [1]) is always >> reflected by the cell's paragraph content. > I would disagree with this formulation. The cell's paragraph content can > be deduced from the office:value attribute (assuming one knows the > applicable style, but not vice-versa). Fully agree. This is what I meant to say. The paragraph value is deduced from the office:value. >> Changing a cell's formula (@table:formula attribute, see [2]) >> changes as well the cell's @office:value - if existent - and >> the cell's paragraph content >> Changing a cell's content (text of child paragraph), which is >> referenced by another cell's formula results in general in a >> change of the @office:value and the paragraph text of the cell >> with the formula. >> >> By the above dependencies the XML changes are mapped into basically >> two state changes, which can be mapped to two operations to be >> serialized using Merge-Enabled Change Tracking (MCT): >> >> >> 1. The change of cell value [.B4] >> 2. The change of the formula of cell [.C4] and the resulting cell >> value & paragraph text change > Unfortunately this only suffices as long as the office:value change is a > deterministic consequence of a formula change. Simple recalculation of a > document could change values without any accompanying formula changes > (think of random number generation or other volatile functions such as > date, time,....) You are right. Not only the change of a formula, but as well the recalculation will trigger the described changes. In addition due to random functions it will never be sufficient to have an operation indicating the recalculation of formula, but the results are important. PS: If you have a complex scenario in the back of your mind, just draft at and I will try to solve it. The technique will evolve by usage. Thanks for your feed-back, Andreas! Svante

Svante, Quick question on volatile elements: On 02/21/2012 07:46 PM, Svante Schubert wrote: <snip> By the above dependencies the XML changes are mapped into basically two state changes, which can be mapped to two operations to be serialized using Merge-Enabled Change Tracking (MCT): 1. The change of cell value [.B4] 2. The change of the formula of cell [.C4] and the resulting cell value& paragraph text change Unfortunately this only suffices as long as the office:value change is a deterministic consequence of a formula change. Simple recalculation of a document could change values without any accompanying formula changes (think of random number generation or other volatile functions such as date, time,....) You are right. Not only the change of a formula, but as well the recalculation will trigger the described changes. In addition due to random functions it will never be sufficient to have an operation indicating the recalculation of formula, but the results are important. Question: Wouldn't the question of recalculation be covered in part by Part 2, section 3.5 When recalculation occurs? That is change tracking would be constrained by the definitions for formulas therein? Yes? Hope you are having a great day! Patrick -- Patrick Durusau patrick@durusau.net Chair, V1 - US TAG to JTC 1/SC 34 Convener, JTC 1/SC 34/WG 3 (Topic Maps) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) OASIS Technical Advisory Board (TAB) - member Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau

This is by way of an update on where we are at the moment, see notes below. The TC is setting up a Select Committee to recommend the way ahead, so there seems no point doing further work at the moment in the SC. Of course if there are further questions about MCT then these can be discussed, and I am sure the Select Committee will have questions to ask. On 14/02/2012 17:04, Robin LaFontaine wrote: Following presentation by Svante today, participants in the call suggested the following activities: 1. Svante will update the presentation document because there appeared to be a number of errors in the examples and these need to be correct in order to be used as examples of how MCT works. Completed. It is important to note that collaboration operations are from old version of a document to new and change tracking instructions are the other way round, because the final document is the one that is represented. 2. Svante will write up details of the path notation being used. This is not XPath/XPointer but is based on components in the ODF. Not done but we have Svante's solution for several of the use cases, this has been uploaded to the documents repository. 3. Patrick, Tristan and Thorsten will work on some examples, using the six Use Cases that were selected for detailed examination of ECT and GCT. Svante will provide some further documentation giving details of the operations to be used for these, then Patrick, Tristan and Thorsten will encode the tracked changes in MCT. Svante will also produce a 'correct' example for each. This has not been done and I have not been pressing for this because we have Svante's solutions. However this means no-one else has tried to get an MCT solution so there has been very little peer review of MCT. Patrick and Thorsten will look at it more closely as members of the Select Committee. 4. We will have a further call to discuss in 2-3 weeks time. Meanwhile the TC is looking at requirements so our work is in parallel. Not done because TC has now agreed to set up a small group, the Select Committee, to look at the best way forward for ODF change tracking. 5. The objective is to have sufficient understanding so that we can review Svante's changes to the consensus report and update this as necessary with the findings of the SC. See 4 above - we are not working on updating the report. 6. Any other technical questions to the mailing list over the next few weeks. Very few questions. The one from Svante on formula example was more to do with the ODF format and what changes need to be recorded rather than how MCT does it (a very valid question of course, but not clarifying MCT). As we do not have a document describing the path notation it is probably difficult to ask more questions. Robin   -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK --------------------------------------------------------------------- To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd Experts in information change T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK