Extension of schematized XML protocols

An application using one version of a schematized XML protocol communicates with another application using a different version of the schematized XML protocol. The different versions may correspond to different deployments or releases of the protocol. Each application generates messages to be sent using two data sets. A first data set is incorporated into the message using elements available in a standard XML protocol schema. A second data set is incorporated into the message using XML annotation elements. The receiving application processes the message using the schematized XML protocol to parse out the first data set. The receiving application further parses the message to identify the second data set that is carried by enhanced XML annotation elements. Extension or annotations are flexibly added to the XML protocol without requiring the client application to request—or the server application to respond to—a pre-negotiated number or type of annotations.

BACKGROUND

XML (eXtensible Markup Language) is a flexible, self-descriptive markup language that is designed to transport and store data. The XML language has no predefined tags, so the tags used in XML are defined by the author of an XML document. XML data is stored in plain text format, which makes it easy to create data that can be shared by different applications. XML data can be read by different-and even incompatible-applications, which provides a software- and hardware-independent means for carrying and storing data.

Some application use a schematized version of XML in which the building blocks and structure of an XML document are predefined by a schema. The XML schema may define, for example, the elements and attributes that can appear in a XML document, the data types for the elements and attributes, the use, number and order of child elements, and the like.

The XML schema may use predefined data types to describe allowable document content and to validate the data in an XML document. The XML schema can also provide secure data communication where a sender and receiver use the same schema and both parties use the same description of the XML content and, therefore, have a mutual understanding of the XML content.

However, if an application or protocol using the XML schema is revised, then the XML schema may also need to be revised to support changes in the application or protocol. This requires each application to keep close track of the XML schema version capability of other users to ensure that the data exchanged between users can be understood by the other party. If there are multiple active versions of the XML schema that are in use by various applications, then it becomes complex for the one application to identify the version in use on every other application and to preserve a mapping of the types of data to be sent to each other application.

SUMMARY

In the case of a client-server application that is following a pre-written XML protocol that uses a schema to format the XML, flexibility of sending and receiving data that is not core part of the schema can be achieved with minimal changes to XML schema. This allows the pre-written or schematized protocol, such as an XML protocol, to be extended to support version and deployment independence. Additionally, the client and server do not need to maintain a complex version-tracking system when an extended XML protocol is used by the applications to communicate. Additionally, they are not restricted to requesting only the extra data that they will understand or to return only the extra data that the other party can understand. A version-independent approach allows the server and client to extend the pre-written schematized XML data transfer protocol to support the most recent version of the protocol and related applications.

The schema that defines of any version of a protocol is extended by the insertion of an XML element named “Annotation.” The Annotation element represents extra data or other information that is different from what can be request using a standard request or what can be provided in a standard response in a pre-written protocol. The number and type of such Annotations is unlimited. A server returns the annotations or extra data only in response to Annotations specifically included in a request from a client. As a result, the server does not need to keep track of the current version of the protocol that is in use on the client.

In one embodiment, a client device extends a schematized XML protocol by identifying a first data set that is to be transmitted to a server application. The first data set can be identified using a standard XML protocol schema. The client application also identifies a second data set to be transmitted to the server application. The second data set cannot be defined in the standard XML protocol schema. The client application generates a message comprising the first data set using elements available in the standard XML protocol schema. The message also includes the second data set using XML annotation elements. The message is transmitted to the server application, which process the message and sends a return message. The return message includes a first response data set that is carried using the standard XML protocol schema. The return message also includes a second response data set that is carried using XML annotation elements. The enhanced XML annotation elements carry data that does not correspond to data support in the standard XML protocol schema elements.

In another embodiment, a server application processes schematized XML protocol messages received from a client. The server receives a message from the client application and parses the message using the elements defined in a standard XML protocol schema. The server application identifies a first data set in the message that is carried by the standard XML protocol schema elements. The server application further parses the message to identify a second data set that is carried by enhanced XML annotation elements. The enhanced XML annotation elements carry data that does not correspond to data support in the standard XML protocol schema elements. The server application may generate a response to the received message. The response may include a first return data set that is carried in the response using the standard XML protocol schema elements. The response may further include a second return data set that is carried using XML annotation elements.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a client/server system implementing an extended schematized XML protocol. Server101and client102may communicate via a direct connection, such as by exchanging messages over network103. Messages exchanged between server101and client102may include, for example, requests from client102and corresponding responses from server101. Network103may be any wireline or wireless connection that is established directly or indirectly between server101and client102. For example, server101and client102may exchange internet protocol (IP) messages and/or data packets over a proprietary or local area network (LAN), across an Internet or public network, or via a WiFi (IEEE 802.11), WiMAX (IEEE 802.16), Bluetooth, or other wireless network.

Server101includes a processor104running one or more applications. Processor104may be a software-, firmware-, or hardware-based device. Memory105may be used to store data and computer program instructions, such as software and firmware used by processor104, and any other parameters needed by server101. Memory105may be any applicable storage device, such as a fixed or removable RAM, ROM, flash memory, or disc drive that is separate from or integral to processor104. In other embodiments, memory105may by a computer program product, computer-readable or machine-readable storage, DVD or CD. Processor104is coupled to memory105and to input/output (I/O) device106, which provides an interface to transmit and receive messages and data packets from network103.

As used herein, the term application means software or program code or steps that are used to perform one or more specific tasks. The application may operate on its own or may communicate with other applications using, for example, a schematized XML protocol. In one embodiment, a client application exchanges data with a separate server application to perform various tasks, such as synchronization, communication, data storage, etc.

Similarly, client102includes a processor107running one or more applications. Processor107may be a software-, firmware-, or hardware-based device. Memory108may be used to store data and computer program instructions, such as software and firmware used by processor107, and any other parameters needed by client102. Memory108may be any applicable storage device, such as a fixed or removable RAM, ROM, flash memory, or disc drive that is separate from or integral to processor107. Processor107is coupled to memory108and to I/O device109, which provides an interface to transmit and receive messages and data packets from network103.

Server101and client102both implement an application that uses a multi-version protocol, such as a communication, data-transfer, or synchronization protocol, that uses schematized XML to exchange data. As long as server101and client102use the same version of the application and protocol, then the format of the exchanged data, such as request and response messages, will be known to each application. However, if the formats of the request and response messages are modified in a new version of the multi-version protocol, then such request and response can only be used between clients and servers that know how to parse the data.

Using an extended schematized XML protocol, the server101and client102do not have maintain a mapping of the protocol version used by the other device. Instead, each device only requests the data that it can use and only sends the data that the other device requested. For example, every set of extra data that client102desires will be specified individually in a request sent by the client. Upon receiving the request, server101will send only the extra data sets that the client has requested and that server101understands or can identify. Server101ignores any extra requests that it does not understand or that it cannot return. Neither server101nor client102break, stall or otherwise fail if unknown data sets are requested or received. In this way, backward compatibility does not need to be maintained, nether device needs to know the currently active protocol version that is in use on the other device, and there is no requirement for controlling the order in which the protocol versions are deployed to server101or released to client102.

FIG. 2is a flow chart illustrating the exchange of messages between two applications according to one embodiment of the disclosed protocol. Server201implements a protocol version that implements data sets A, B, and C. Client202implements an earlier version of the protocol that implements data sets A and B only. Client202sends a request203requesting data sets A and B. Server201receives the client request203and identifies the request for data sets A and B only, even though data set C is also available on server201. However, server201ignores the “missing” request for data set C and collects just data sets A and B to be sent to client202in return message204.

The client request message203may be an XML-based message having the following format:

The server return message204may be an XML-based message having the following format:

Similar to client request message203, the root element <AnyStandardRequestOrResponse> includes the two child elements: <StandardSchema> and <Annotations>. The <StandardSchema> element includes child elements that correspond to the information requested by client202using standard elements for the protocol. The <Annotations> element includes child <Annotation> elements that contain information responsive to the Annotations requested by client202. Returned data sets A and B are identified using the <Name> element, and the <Value> element is used to identify the contents of each respective data set.

Data set C was not requested in message203ofFIG. 2and, therefore, was not returned in message204. However, had data set C been included in message204, client202would ignore it and any other Annotations that it did not request or recognize.

FIG. 3is a flow chart illustrating the exchange of messages between two applications according to one embodiment of the disclosed protocol. Server301implements a protocol version that implements data sets A, B, and C. Client302implements a different version of the protocol, which implements data sets A, B and D. Client302sends a request303requesting data sets A, B and D. Server301receives the client request303and identifies the request for data sets A and B, but ignores the request for data set D since it is not supported by the protocol version deployed on server301. Additionally, server301ignores the lack of a request for data set C and collects just data sets A and B to be sent to client302in return message304.

The client request message303may be an XML-based message having the following format:

The server return message304may be an XML-based message having the following format, which is similar to message204.

No Annotation is returned in message304for data set C because it was not requested. No Annotation is returned in message304for data set D because it is not available on the server301.

When a client does not send any Annotation in a message, such as in the case of a client running a default or basic protocol, the server will not send any Annotation data and, therefore, the client will not break or stall due to unknown or unexpected data.

When a server does not support any Annotation data, such as in the case of a server running a default or basic protocol, the inclusion of Annotation data in the XML request do not cause the server to break or stall. This case may occur, for example, before a server upgrade to implement the logic to understand and return D is deployed, but a new client version has been released that knows how to use and parse D. For example, in the example above where server only supports data sets A, B, and C, a request including the following do not break the server:

Likewise, the following response from the server does not break the client even if the client only requested data sets A, B, C:

<Annotations><Annotation><Name>A</Name><Value>Value of A</Value></Annotation><Annotation><Name>B</Name><Value>Value of B</Value></Annotation><Annotation><Name>C</Name><Value>Value of C</Value></Annotation><Annotation><Name>D</Name><Value>Value of D</Value></Annotation></Annotations>

However, this response, which includes D, do not occur in normal operation since the client did not request data set D.

When the client and server follow these design principles, the clients and servers would be resilient to not break each other or otherwise be negatively impacted by a request or response that includes an unknown data set no matter what deployment and/or release pattern was used to update the clients and servers.

FIG. 4is a block diagram of a client/server system implementing an extended schematized XML protocol. The system ofFIG. 4implements various versions of synchronization protocols to provide a synchronization service between server401and client402. This service enables client402, which may be a mobile application for example, to access mail, calendar, contacts and tasks data from server401.

Server401may want to return a particular data set to client402that is not part of the standard synchronization protocol. Client402expects data in a certain format that is specific to the version of the synchronization protocol that it is implementing. If that particular data is returned to all clients, then client402may not know how to parse and use the data, and hence client402will break or stall. Various versions of the client may be interested in and understand various sets of extra mail, calendar, contacts and task data. However, it would be is complex and unsustainable to maintain a mapping of each clients' versioning at the server side so that the data returned the clients' is specific to a particular synchronization protocol version.

Any version of the synchronization protocol can be extended with the insertion of an XML element “Annotation” as described herein. The Annotation element represents any “extra data,” which is data that is extra or other than what can be requested in a standard synchronization request or can be returned in a standard synchronization response.

The number of such Annotations and type of such Annotations is boundless. The synchronization server401returns Annotations with the extra data only in response to clients402that have specifically asked for that data by using Annotations in a request message. The synchronization protocol implements this solution to pass data in a field that only clients that have negotiated and asked for the data will receive the data.

FIG. 4also illustrates messages exchanged between the synchronization server401and the client402. The server401implements the synchronization protocol, which uses schematized XML to send request from clients and responses from the server. Since there is no provision in the synchronization protocol to send or request any extra data that is not supported in the protocol, the XML implementation disclosed herein extends the synchronization protocol to enable it to pass extra data between client402and server401using Annotations and name/value pairs. A generic example of such message flow would be:

Using this mechanism, server401and client402can implement any version of the synchronization protocol and can easily pass extra data to each other without regard of the synchronization protocol version deployed on either application. The number of such Annotations instances in an XML message is unlimited, and the existence of an Annotations block in the XML messages is optional. The synchronization protocol schema is extended to allow the Annotations to pass through the validation system. However, since format of the request and response is modified, such request and response is useful only for clients that know how to parse it.

If multiple versions of the client synchronization protocol are interested in receiving different sets of data, then it becomes a complex problem for server401to identify each client402and to preserve a mapping of client versions to desired sets of Annotations that server401sends to client402. For this reason, the server401does not rely on logic that is based on knowing the client's synchronization protocol version to select the necessary extra data to be sent. Instead, server401sends only the data that the client requests. For every set of extra data (or Annotation) that is of interest to client402, the client individually specifies what data it wants. Once server401sees the request, it sends only those sets of extra data that client402has requested.

Further, server401ignores any extra Annotation request that it does not understand or that it cannot return. Also, the client402does not break if extra Annotations are sent by server401. In this way, there is no need to maintain backward compatibility among protocol versions, and there is no need to follow a particular order between a server deployment and client release.

Using this mechanism, server401and client402can implement any version of the synchronization protocol and can easily pass extra data to each other without regard of the synchronization version deployed on either application. The number of such Annotations instances in an XML message is unlimited. The existence of an annotations block in the XML messages is optional. The synchronization schema is extended to allow the Annotations to pass through the validation system. However, since format of the request and response is modified, such request and response is sent to clients that know how to parse it.

If multiple versions of the client synchronization protocol are interested in receiving different sets of data, then it becomes a complex problem for server401to identify each client402and to preserve a mapping of client versions to desired sets of Annotations that server401sends to client402. For this reason, the server401does not rely on logic that is based on knowing the client's synchronization protocol version to select the necessary extra data to be sent. Instead, server401sends only the data that the client requests. For every set of extra data (or Annotation) that is of interest to client402, the client individually specifies what data it wants. Once server401sees the request, it sends only those sets of extra data that client402has requested.

Further, server401ignores any extra Annotation request that it does not understand or that it cannot return. Also, the client402does not break if extra Annotations are sent by server401. In this way, there is no need to maintain backward compatibility among protocol versions, and there is no need to follow a particular order between a server deployment and client release.

In the example illustrated inFIG. 4, synchronization protocol version X is deployed on server401. Protocol version X supports standard contact data First Name (FN), Last Name (LN), and Address (AD) and extra contact data Birthday (BD) and Work Address (WA), which may have been added in version X, but is not available in all versions of the synchronization protocol. Client402is using synchronization protocol version Y, which may have been released before or after version X was deployed. Version Y also supports standard contact data First Name (FN), Last Name (LN), and Address (AD) and extra contact data Birthday (BD. In addition, instead of supporting extra contact data Work Address (WA), version Y supports extra data set Spouse Name (SN).

Using message403, client402requests synchronization data from server401. In particular, client402requests updated standard contact data and extra data Birthday and Spouse Name. Using Annotations in the XML protocol, client synchronization request message403may include the following elements:

Synchronization protocol version X deployed on server401does not understand the data Spouse Name, so server401ignores that request. However, server401does understand the data Birthday, so it returns that extra data set. In addition, server401does not care, and therefore ignores, the lack of a request for the Work Address extra data in message403.

Server401generates synchronization response message404, which may include the following elements:

Server401does not send the Work Address data because it was not requested by the client402. If server401did send an Annotation with the Work Address data, client402would ignore the unrequested Work Address data.

Although the example ofFIG. 4is directed to a synchronization protocol for purposes of illustration, it will be understood that the extensions to the XML protocol as described herein would apply to any schematized XML protocol and not intended to be limited to synchronization, which serves merely as an example application type.

Although the terms “Annotations”/“Annotation” are used as the XML elements that allow for the exchange of extra data in a highly schematized XML protocol, it will be understood that any other name or term can be used as for the extra-data element, as long as the name or term is not already designated in the XML protocol for another element. “Annotations” is just an example that is selected to indicate “extra data.” Any other term, such as “ExtraData,” “Extension,” or “ExtendedData,” for example, may be used instead of “Annotations” since the actual name of the “extra data” element is not important.

Additionally, although the terms “server” and “client” are used in the example embodiments above, it will be understood that the extended schematized XML protocol disclosed herein can be used for communications between any two applications. As used in the description herein, the term “client” refers broadly to an application that is generating a request to another application. The term “server” as used herein refers broadly to an application that receives the request and that prepares a response based upon that request. It will be understood that in practice a server may request information from a client using a XML protocol and that extra data may be requested by the server and provided by the client using an extended XML protocol with Annotations.

The XML protocol extension Annotations are not limited to use in a request/response transaction between applications. The XML protocol extension Annotations may also be used to exchange or carry other information, status or parameters between the applications. Moreover, the XML protocol extension Annotations do not have to be used in a two-transaction. XML Annotations may be used to carry data from one application to another in a message that may or may not be acknowledged by the receiving application. For example, a protocol release used on a first application may include standard XML elements that allow the first application to indicate to other applications that it is in an “on” state or is active. The protocol release on the first application may also allow for extra information, such as an estimated battery life. The first application may periodically send a registration or other message to a second application that identifies an active status using the standard XML protocol and that includes battery life data using XML Annotations. The receiving second application may understand and process the battery life data identified using XML Annotations, or it may ignore the battery life data if that features is not included in the protocol deployed on the second application. In either case, the second application does not need to specifically acknowledge the status or battery life data, but may instead merely acknowledge receipt of the message.

FIG. 5is a flowchart illustrating a method for an application, such as a client application, to request extra data from another application, such as a server application, in a schematized XML protocol. In step501, the requesting application identifies desired data that it wants to obtain from the other application and that can be identified using a standard XML protocol schema. In step502, the requesting application also identifies additional data that it desires to obtain from the other application, but that cannot be identified using the definitions in the standard XML schema. The requesting application generates a request for the desired data in step503. The request for the desired data uses the elements available for the XML protocol in the standards schema.

In step504, the requesting application adds requests for additional data to the data request using XML Annotation elements. The request is then transmitted to the other application in step505, and a response is received in step506. The requesting application then analyzes the response in step507and identifies requested data that has been carried using the standard XML protocol schema. In step508, the requesting application identifies additional requested data that has been carried in the response using Annotation elements. If the response includes further extra data, then the requesting application ignores this data in step509if it has not been requested.

It will be understood that steps501-509of the process illustrated inFIG. 5may be executed simultaneously and/or sequentially. It will be further understood that each step may be performed in any order and may be performed once or repetitiously.

FIG. 6is a flowchart illustrating a method for an application, such as a server application, to respond to a request for extra data from another application, such as a client application, in a schematized XML protocol. In step601, the application receives a data request from the requesting application. In step602, the application parses the data request using the elements defined in the standard XML protocol schema to identify what data has been requested by the requesting application. The application generates a response to the request message. The response includes the data that was requested using the elements in the standard XML protocol schema.

In step604, the application further parses the request to identify any additional data that was requested using enhanced XML Annotation elements. The additional requested data is added to the response message in step605using XML Annotation elements, such as Name and Value elements. In step606, the application ignores any extra data requests that are included in the XML Annotations if the extra data is not understood or not supported by the protocol version that is deployed on the application. Finally, in step607, the response with the data identified using either standard XML elements or XML Annotations is sent to the requesting application.

It will be understood that steps601-607of the process illustrated in ofFIG. 6may be executed simultaneously and/or sequentially. It will be further understood that each step may be performed in any order and may be performed once or repetitiously.

Note that many of the functions described herein may be implemented in hardware, software, and/or firmware, and/or any combination thereof. When implemented in software, code segments perform the necessary tasks or steps. The program or code segments can be stored in a processor readable medium. The processor readable medium may include any medium that can store or transfer information. Examples of such a processor readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable ROM (EROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, etc. The code segments may be downloaded via computer networks such as the Internet, an intranet, etc.