| SyncML adopts a layered view of the software architecture for mobile data synchronization, as depicted in Figure 4-2. This layered view is similar to a layered network protocol like TCP/IP but at a different semantic level. The overall synchronization system consists of the following layers: Application Data Synchronization Transport Physical
Figure 4-2. The layered architecture of the synchronization framework and the position of the SyncML Synchronization Protocol within the overall software stacks of mobile devices and network servers. 
The application layer consists of the actual application, such as a calendar application, and associated synchronization logic, usually separated into a synchronization engine. There may be a single synchronization engine acting for many applications or one synchronization engine per application. At this layer, conceptually an application on a Client is communicating with an application on a Server. The communication and exchange of information actually occurs by crossing many vertical layers. At this layer, two synchronizing applications should focus on application semantics, such as what constitutes conflicting updates. There is an underlying layer of data below most applications. At the data layer the peers are not two applications but two datastores. A memory-resident file on a mobile Client could correspond with entries or rows in a Server database. The data layer identifies the kind of data being synchronized. Calendar applications may use vCalendar data, contact applications may use vCard [VCARD21] data, and health-care applications may use patient records. Note that the format of the synchronized data may be different from the native format of the data stored in the two datastores in this layer. In most cases the native data is translated into the standard format during synchronization. The synchronization layer constitutes the majority of SyncML specifications. This layer is concerned with the logical communication of changes to data items. The Synchronization Protocol determines the flow of the actual conversation between a Client and a Server during synchronization. The SyncML Representation Protocol DTD primarily determines the exact form of each communication. To effectively accomplish this, the synchronization layer also includes data-specific attributes, such as identification of datastores and identification of data items. Note that the synchronization layer is mostly concerned with the communication of changes and not their interpretation. The application layer determines what changes need to be communicated and the data layer determines the format of the data embedded in the communication. The transport layer consists of the network transport protocols that are used. This layer is concerned with the actual messages that are exchanged, in contrast with the logical packages specified by the synchronization layer above. The actual form of one or more physical messages corresponding to a logical package could be different depending on the transport being used. The headers, encoding, and other aspects of messages exchanged over HTTP are different than those exchanged over WSP and OBEX. The physical layer consists of the actual communication medium being used, which can range from wide-area wired networks to local area networks, cellular networks, or even Bluetooth networks. One transport layer protocol can operate over multiple physical networks. For example, HTTP can operate over wired and wireless networks, while OBEX can operate over Bluetooth or IrDA links. In summary, the various layers provide different levels of abstraction. Typically, an aspect of a higher layer can be realized by multiple entities in a lower layer. It is important to appreciate all the abstractions and software parts involved in end-to-end data synchronization to clearly understand the place and role of SyncML in data synchronization. The Meaning of Synchronizing Two Datastores What does it actually mean to synchronize two datastores? One possible answer is that after the process of synchronization, the two datastores are identical. This appears to be a limiting definition. For example, a mobile client device may store a limited subset of fields in a data item while the corresponding server data item stores all the fields. The mobile client device may also identify data items differently than a server. It may also be desirable for a mobile client only to store certain subsets of all data items in a server datastore. In addition to variations in the data items stored, synchronization has different meanings when different kinds of datastores are being synchronized. For example, adding a document or a data item to a datastore has different semantics than adding a transaction to a queue. To be practical, SyncML must allow the above flexibilities. SyncML depends on a notion of "equivalence" between data items in two datastores that are being synchronized. Datastore A is synchronized with datastore B if and only if for every data item in store A there is a corresponding equivalent (but not necessarily identical) data item in datastore B. SyncML does not define the specific definition of equivalence that is appropriate for two particular datastores but requires that a notion of equivalence exist. For example, a calendar record in a mobile device can be deemed equivalent to a calendar record in the server, even though the one in the mobile device does not have information related to conferencing facilities in the meeting room pertinent to the calendar entry. Note that if datastore A is deemed synchronized with datastore B, this does not imply that datastore B is synchronized with datastore A. In other words, synchronization does not have to be reflexive. This allows datastores on Client devices to be subsets of datastores on Server devices and still be synchronized using SyncML. Language of Synchronization: XML and MIME Usage SyncML is primarily about expressing operations on data and communicating such operations in a structured manner. Since the operations are on certain data items, the data items themselves need to be expressed and communicated in a structured, consistent manner. SyncML defines various operations corresponding to adding, replacing, and deleting data items in a datastore. Such operations are performed on calendar data, contact data, relational data, XML documents, and various other kinds of data. SyncML uses the XML syntax for expressing operations. It uses MIME data types to identify data formats. SyncML Messages are specified using well-formed XML. They do not need to be valid XML. This relaxation allows for terseness in SyncML Messages. SyncML makes heavy use of XML namespaces. Namespaces must be declared in the first element type that is used in a package from a particular namespace. SyncML also makes use of XML standard attributes such as "xml:lang". Any XML standard attribute can be used in a SyncML Message. The current SyncML DTD defines a namespace that is identified with a specific Uniform Resource Identifier (URI) and a specific Uniform Resource Name (URN).[9] [9] The URI for SyncML DTD version 1.0 is http://www.syncml.org/docs/syncml_represent_v10_20001207.dtd. The URN is //SYNCML//DTD SyncML 1.0//EN.
XML can be viewed as more verbose than alternate binary representations. This is often cited as a reason why XML (and SyncML) may not be suitable for low-bandwidth wireless networks. In most cases, SyncML uses shortened element type and attribute names, providing minor reductions in verbosity. Additionally, SyncML messages can be encoded in efficient tokenized binary formats such as WBXML. The use of the binary format is external to the specification and should be transparent to any SyncML application. The combination of shortened element type names and binary format makes SyncML competitive for usage over low-bandwidth networks. Clearly, the main advantage of XML is its international widespread acceptance for document markup. It allows for both human readability and machine processability. It allows one to capture document structure as well as content. This is extremely useful for data synchronization, where not just capturing content, but capturing structure semantics is essential. The overall benefits of using XML far outweigh the performance concerns. SyncML leverages the MIME industry standard for specifying content types. Different data types in SyncML are expected to be registered MIME types such that a SyncML processor can determine how to process encapsulated data. SyncML messages themselves are registered MIME types. Clear text SyncML messages are registered as "application/vnd.syncml+xml", while binary encoded messages are registered as "application/vnd.syncml+wbxml". For transport-level protocols such as HTTP that support MIME content types, the MIME types for SyncML messages must be used. | 
