<revisions> (Revisions)
This element represents the root node of a list of revisions made in this shared workbook. This root node shows up at the beginning of every log file that contains specific revisions made to the workbook.
When multiple users are sharing, and editing, a workbook at the same time, there may be conflicting changes. The spreadsheet application should have logic to resolve such conflicts, and the file format should only contain enough information so that the spreadsheet application can restore the workbook to the correct state after conflict resolution. Revisions can also be tracked by the spreadsheet application for review by the user at a later time (as opposed to only dealing with conflicts on a save event.) Some edits to workbooks will be made as a result of this conflict resolution. So, there will be cases where a revision is effectively undone by another user, and as a result that undoing is itself a revision that adds or changes data in the file. These types of operations are tracked by the ua and ra attributes of many different elements.
Step 1:
User 1 inserts Column A. So the XML in the revision log would look like this:
<revisions xmlns="…" xmlns:r="…"> <rrc rId="1" sId="1" ref="A1:A1048576" action="insertCol"/> </revisions>
Step 2:
User 2 synchronizes the file to pick up that change, but then activates the Track Changes feature, and rejects that change. This effectively performs an undo on User 1's insertion. This is denoted in the file with the ua attribute meaning that this change happened as the result of an undo. The XML for the revision log would look like this:
<revisions xmlns="…" xmlns:r="…"> <rrc rId="2" ua="1" sId="1" ref="A1:A1048576" action="deleteCol"/> <rcft rId="1" ua="1" sheetId="1"/> </revisions>
Step 3:
User 1 types "foo" in A1, and saves the file. A conflict resolution dialog is shown since User 2's version of the file removed the inserted Column A. User 1 chooses to accept their own changes. This undoes the change that User 2 made. So, in effect, it performed an undo on a previous undo operation. This is denoted in the file format by the ra attribute meaning that a the change occurred because a previous undo was undone. So the resulting XML for the newest log file looks like this:
<revisions xmlns="…" xmlns:r="…"> <rrc rId="3" ua="1" ra="1" sId="1" ref="A1:A1048576" action="insertCol"/> <rcft rId="2" ua="1" sheetId="1"/> <rcc rId="4" sId="1"> <nc r="A1" t="inlineStr"> <is> <t>foo</t> </is> </nc> </rcc> <rcft rId="2" sheetId="1"/> </revisions>
Parent Elements |
|---|
Root element of SpreadsheetML Shared Workbook Revision Log part |
Child Elements |
Subclause |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The following XML Schema fragment defines the contents of this element:
<complexType name="CT_Revisions">
<choice maxOccurs="unbounded">
<element name="rrc" type="CT_RevisionRowColumn" minOccurs="0" maxOccurs="unbounded"/>
<element name="rm" type="CT_RevisionMove" minOccurs="0" maxOccurs="unbounded"/>
<element name="rcv" type="CT_RevisionCustomView" minOccurs="0" maxOccurs="unbounded"/>
<element name="rsnm" type="CT_RevisionSheetRename" minOccurs="0" maxOccurs="unbounded"/>
<element name="ris" type="CT_RevisionInsertSheet" minOccurs="0" maxOccurs="unbounded"/>
<element name="rcc" type="CT_RevisionCellChange" minOccurs="0" maxOccurs="unbounded"/>
<element name="rfmt" type="CT_RevisionFormatting" minOccurs="0" maxOccurs="unbounded"/>
<element name="raf" type="CT_RevisionAutoFormatting" minOccurs="0" maxOccurs="unbounded"/>
<element name="rdn" type="CT_RevisionDefinedName" minOccurs="0" maxOccurs="unbounded"/>
<element name="rcmt" type="CT_RevisionComment" minOccurs="0" maxOccurs="unbounded"/>
<element name="rqt" type="CT_RevisionQueryTableField" minOccurs="0" maxOccurs="unbounded"/>
<element name="rcft" type="CT_RevisionConflict" minOccurs="0" maxOccurs="unbounded"/>
</choice>
</complexType>