| Users perform a variety of operations on data items. SyncML provides a set of verbs, or commands, to express different operations that are performed on data. The following discussion summarizes the various different operations, and their respective nuances and implications. Modifying Data Perhaps one of the most common operations that users perform is to modify a data item in a datastore. SyncML expresses this using the Replace element. Different modifications have different semantics. Some modifications are only changes in fields within a data item, for example, changing the time field in a calendar data item. Some modifications may entail changing only certain meta-attributes of a data item, such as marking an email message from "unread" to "read." Adding Data The creation of new data entries is also a common operation. SyncML expresses this as the Add element. The Add operation is complicated because of the data identifier issue. SyncML allows Client devices and Servers to use different data identifiers. For example, new data items are added in a Server datastore. The Server only informs the Client that a set of items have been added and sends those items to the Client. As part of synchronization, the Client not only adds those items in the local datastore but also generates local unique identifiers for those items. The Client then communicates those identifiers to the Server using a Map command. Deleting Data In addition to adding or modifying data items, users may wish to delete data items from a datastore. The Delete operation has various possible semantics. The obvious kind of delete is when a user intends to delete a record from a datastore. This kind of delete is called a hard delete. During synchronization, the recipient of a hard delete operation, such as a Server, will actually delete the item from the corresponding Server datastore. There is another notion of delete called the soft delete. The soft delete is inspired by the requirement that memory-constrained mobile devices may run out of space to store data and would like to be able to free up storage space by discarding certain data items, keeping only the most pertinent items. When a Server receives a soft delete operation, it does not delete the data item from its datastore; instead it will not send this item to the client again. Another type of delete is the archive delete. Sometimes mobile Clients would like to delete a data item but want a Server to archive a copy of the data item. For example, an insurance worker may want to delete claims processing data from his mobile device for a claim that has just been completed, while wanting the Server datastore to archive the claim data. Refreshing Data It is not uncommon for a mobile device to have its data lost or corrupted by power failure, rough use, or other failures. It is desirable for mobile devices to be able to obtain the latest data from a Server. This can be thought of as a data refresh operation. The refresh operation is not required under normal circumstances, but SyncML recognizes the need for a practical protocol to support refresh semantics and supports it. To initiate a Refresh From Server operation, the Client sends an Alert element to the Server with a "Refresh From Server" value. It is important to understand the distinction between refresh and slow synchronization. Slow synchronization entails transmission of all Client data items in a datastore to the Server, a comparison with all Server data items in the corresponding datastore, and resulting changes sent back to the Client. At the end of slow synchronization, the Client has a synchronized datastore, just as in ordinary synchronization. In contrast, the refresh operation only involves one-way data flow from the Server to the Client, obliterating the Client datastore with items from the Server datastore. At the end, the Client has a copy of the Server datastore. Symmetrically, SyncML also supports refreshing a Server datastore with values from a Client datastore. Searching for Data Mobile devices may require the ability to search for patterns within a data element or for particular elements within a datastore. SyncML has a Search command that enables the search of a datastore, with the resulting data returned in a Results command. A combination of the Get command with target address filtering, as discussed above, may also have the desired effect of a search operation. The Get operation can also be used to fetch complete datastores, such as device information. It is possible that the Put operation can be used instead of the Add or Replace operations, but the prevalent use of the Put operation entails replacing entire datastores, such as device information. Grouped Operations on Data All the typical user operations such as adding, replacing, and deleting data are individual operations on one or more data items. During synchronization, however, a datastore on a Client is synchronized with a datastore on a Server as a whole. It makes sense therefore to be able to group operations on a datastore within a container operation. The notion of a container simplifies a number of things. For example, authentication and access control could be performed at a datastore level for each container operation but not for individual operations inside. In an actual Server implementation, grouped operations in a container can be batched and scheduled efficiently. In addition, sometimes a group of operations have collective semantics in addition to individual operations inside. The Sync container operation in SyncML allows multiple unit operations such as Add, Replace, and Delete to be grouped together in the context of one datastore. Aside from the grouping, and possible efficiencies derived from the grouping as indicated above, the Sync container has no additional semantics. The individual operations within a Sync container can be performed in any order. One or more operations within the Sync container can fail and not affect the status of the Sync. However, the Sync container can fail for other reasons, such as overall authentication failure with the datastore or inablility to communicate with the datastore. Another possible container operation in SyncML is Atomic. Individual operations included within the Atomic container must all be successfully performed, or none at all will be. This container is useful when applications require transactional behavior. This container requires that the set of individual operations be performed but does not require them to be performed in the order specified. The Sequence container requires the individual operations that it contains to be performed in the order specified. This type of ordering is useful for applications that require workflow-like semantics. The Sequence container does not explicitly require that all operations be performed. The Sequence and the Atomic containers can be nested within each other to enforce strict ordering as well as transactional behavior. | 
