{"history":[],"article":{"id":"f8650127-7190-4d14-9fda-64e74619cc50","title":"SyncML","slug":"syncml","content":":::summary\n:::\n\n# \n**SyncML**, or Synchronization Markup Language, was originally developed as a [platform-independent](https://bliptext.com/articles/platform-independent) standard for [information synchronization](https://bliptext.com/articles/data-synchronization).\nEstablished by the [SyncML Initiative](https://bliptext.com/articles/the-syncml-initiative), this project has evolved to become a key component in [data synchronization](https://bliptext.com/articles/data-synchronization) and device management.\nThe project is currently referred to as [Open Mobile Alliance](https://bliptext.com/articles/open-mobile-alliance) Data Synchronization and Device Management.\nThe purpose of [SyncML](https://bliptext.com/articles/the-syncml-initiative) is to offer an [open standard](https://bliptext.com/articles/open-standard) as a replacement for existing [data synchronization](https://bliptext.com/articles/data-synchronization) solutions; which have mostly been somewhat [vendor](https://bliptext.com/articles/vendor), [application](https://bliptext.com/articles/application-software), or [operating system](https://bliptext.com/articles/operating-system) specific.\nSyncML 1.0 [specification](https://bliptext.com/articles/specification-technical-standard) was released on December 17, 2000, and 1.1 on February 26, 2002.\nA **SyncML** message is a well-formed [XML](https://bliptext.com/articles/xml) document that adheres to the [document type definition (DTD)](https://bliptext.com/articles/document-type-definition), but which does not require validation.\n\n# Internals\nSyncML works by exchanging [commands](https://bliptext.com/articles/command-line-interface), which can be requests and responses.\nAs an example:\nCommands (, , , etc.) are grouped into messages.\nEach message and each of its commands has an identifier, so that the pair (MsgID, CmdID) uniquely determines a command.\nResponses like commands include the pair identifying the command they are responding to.\nBefore commands, messages contain a header specifying various data regarding the [transaction](https://bliptext.com/articles/database-transaction).\nAn example message containing the command for begin a refresh synchronization, like in the previous example, is:\n8000\n\n\n\n1\n\nEvents\n4242\n\n\n\n\n\nThe response from the [computer](https://bliptext.com/articles/computer) could be an [XML](https://bliptext.com/articles/xml) document like (comments added for the sake of explanation):\n\n\n\n1\n1\n0\nSyncHdr\nPC Suite\n\n\n2\n1\n1\nAlert\nEvents\n\n\n\n\nThe transaction then proceeds with a message from the mobile containing the command, and so on.\nThis example is a refresh where the mobile sends all its data to the computer and nothing in the other way around.\nDifferent codes in the initial command can be used to initiate other kinds of synchronizations.\nFor example, in a \"[two-way](https://bliptext.com/articles/two-way-communication) sync\", only the changes from the last [synchronization](https://bliptext.com/articles/synchronization) are sent to the [computer](https://bliptext.com/articles/computer), which does the same.\nThe and tags are used to keep track of a possible loss of sync.\nrepresents the time of the last operation of synchronization, as measured by each device.\nFor example, a [mobile](https://bliptext.com/articles/mobile-phone) may use progressive numbers (, , , ...) to represent time, while the computer uses strings like \" \".\nis the current time in the same representation.\nThis latter data is stored and then compared with in the next synchronization.\nAny difference indicates a loss of sync.\nAppropriate actions involving sending all data can be then taken to put the devices back in sync.\nAnchors are only used to detect a loss of sync; they do not indicate which data is to be sent.\nApart from the loss-of-synchronization situation, in a normal (non-refresh) synchronization, each device sends a [log](https://bliptext.com/articles/logbook) of changes since the last synchronization.\n\n# SyncML client connectors and plugins\n\n# SyncML servers\n1SAN = Server Alert Notification.\nThis SyncML Push technology is based on definitions by the [Open Mobile Alliance](https://bliptext.com/articles/open-mobile-alliance) and extends the existing SyncML protocol specification by offering a method of server initiated synchronization.\n\n# SyncML hosted services","current_revision":null,"created_by":"kACnuQmH5k9Nr5VNVEpVeg7XpvUmMctD","created_at":"2025-01-25T19:27:53.226Z","updated_at":"2025-01-25T19:27:53.226Z","search_vector":"'syncml':1","search_content":" \n \n\n# \n**SyncML**, or Synchronization Markup Language, was originally developed as a [platform-independent](https://bliptext.com/articles/platform-independent) standard for [information synchronization](https://bliptext.com/articles/data-synchronization).\nEstablished by the [SyncML Initiative](https://bliptext.com/articles/the-syncml-initiative), this project has evolved to become a key component in [data synchronization](https://bliptext.com/articles/data-synchronization) and device management.\nThe project is currently referred to as [Open Mobile Alliance](https://bliptext.com/articles/open-mobile-alliance) Data Synchronization and Device Management.\nThe purpose of [SyncML](https://bliptext.com/articles/the-syncml-initiative) is to offer an [open standard](https://bliptext.com/articles/open-standard) as a replacement for existing [data synchronization](https://bliptext.com/articles/data-synchronization) solutions; which have mostly been somewhat [vendor](https://bliptext.com/articles/vendor), [application](https://bliptext.com/articles/application-software), or [operating system](https://bliptext.com/articles/operating-system) specific.\nSyncML 1.0 [specification](https://bliptext.com/articles/specification-technical-standard) was released on December 17, 2000, and 1.1 on February 26, 2002.\nA **SyncML** message is a well-formed [XML](https://bliptext.com/articles/xml) document that adheres to the [document type definition (DTD)](https://bliptext.com/articles/document-type-definition), but which does not require validation.\n\n# Internals\nSyncML works by exchanging [commands](https://bliptext.com/articles/command-line-interface), which can be requests and responses.\nAs an example:\nCommands (, , , etc.) are grouped into messages.\nEach message and each of its commands has an identifier, so that the pair (MsgID, CmdID) uniquely determines a command.\nResponses like commands include the pair identifying the command they are responding to.\nBefore commands, messages contain a header specifying various data regarding the [transaction](https://bliptext.com/articles/database-transaction).\nAn example message containing the command for begin a refresh synchronization, like in the previous example, is:\n 8000 \n \n \n \n 1 \n \n Events \n 42 42 \n \n \n \n \n \nThe response from the [computer](https://bliptext.com/articles/computer) could be an [XML](https://bliptext.com/articles/xml) document like (comments added for the sake of explanation):\n \n \n \n 1 \n 1 \n 0 \n SyncHdr \n PC Suite \n \n \n 2 \n 1 \n 1 \n Alert \n Events \n \n \n \n \nThe transaction then proceeds with a message from the mobile containing the command, and so on.\nThis example is a refresh where the mobile sends all its data to the computer and nothing in the other way around.\nDifferent codes in the initial command can be used to initiate other kinds of synchronizations.\nFor example, in a \"[two-way](https://bliptext.com/articles/two-way-communication) sync\", only the changes from the last [synchronization](https://bliptext.com/articles/synchronization) are sent to the [computer](https://bliptext.com/articles/computer), which does the same.\nThe and tags are used to keep track of a possible loss of sync.\nrepresents the time of the last operation of synchronization, as measured by each device.\nFor example, a [mobile](https://bliptext.com/articles/mobile-phone) may use progressive numbers (, , , ...) to represent time, while the computer uses strings like \" \".\nis the current time in the same representation.\nThis latter data is stored and then compared with in the next synchronization.\nAny difference indicates a loss of sync.\nAppropriate actions involving sending all data can be then taken to put the devices back in sync.\nAnchors are only used to detect a loss of sync; they do not indicate which data is to be sent.\nApart from the loss-of-synchronization situation, in a normal (non-refresh) synchronization, each device sends a [log](https://bliptext.com/articles/logbook) of changes since the last synchronization.\n\n# SyncML client connectors and plugins\n\n# SyncML servers\n1SAN = Server Alert Notification.\nThis SyncML Push technology is based on definitions by the [Open Mobile Alliance](https://bliptext.com/articles/open-mobile-alliance) and extends the existing SyncML protocol specification by offering a method of server initiated synchronization.\n\n# SyncML hosted services","revisionCount":0},"hasMore":false,"nextCursor":null}

History