It is becoming increasingly popular to utilise electronic documents encoded with a markup language, such as Standard Generalized Markup Language (SGML) or eXtensible Markup Language (XML), for exchanging information among devices and services. Whilst the following discussion is largely described with reference to XML, it will be apparent to a person skilled in the art that the principles of the invention are not restricted thereto and may be equally practised on documents encoded using other markup languages.
XML provides a way to serialize structured information. XML schemas provide a means for defining the structure, content and semantics of XML documents. Schemas are used to specify valid elements that may occur in a document and the order in which such elements may occur. Schemas may also constrain certain aspects of the elements.
Each networked device or service that is to interchange XML documents is equipped with a parser conforming to a particular schema. On receipt of an XML document, the device executes the parser on the document to determine whether the received document is valid for the particular schema that the device is using. Using a validating parser in this manner requires memory, processing power and time. Some documents have an associated version number that indicates the schema to which the document conforms, thus reducing or obviating the need for validation.
XML does not provide an effective solution for handling incompatibilities that arise between different schema versions. Such incompatibilities generally occur as a result of enhancing functionality of devices and services over time. This is the problem of future-proofing, which seeks to ensure that XML documents utilising different schemas may be handled in an appropriate manner. There are a number of approaches presently used that attempt to address this problem.
The first, and arguably the simplest, approach adds new information to an existing schema of an XML document, as the need arises. In this way, a device is designed to use a parser that ignores all unknown elements and attributes in a received document by assuming these new elements and attributes have been added for new functionality on new devices. This solution fails to cater for any modification of existing elements and attributes, and is thus somewhat limiting. Examples of such modifications include renaming elements and attributes or moving existing elements and attributes within the document structure. These types of modifications typically arise when a schema is updated to provide new functionality. Thus, this first approach is unable to validate a document that has modified or new elements or attributes.
The first approach described above can be enhanced by adding a new schema to an original schema to produce an extended schema. Most elements in an extended schema do not require amendment and remain the same. Reorganized elements and new elements constitute new elements in the new, extended schema. Thus, devices equipped with a parser based on the original schema still successfully parse a document encompassing the extended schema, although the document might not validate against the old schema. New devices equipped with a parser conforming to the new schema ignore old information contained in the document and parse the new information successfully. Unfortunately, extending an existing schema in this manner increases the size and complexity of the document. Further, a new problem of maintaining duplicate information within the document has been created. It is preferable not to deal with the maintenance of duplicate information.
A further approach is to treat different versions of a schema as separate schemas. Rather than merging an existing schema and new schema together in the manner described above, this further approach utilises a translation function to enable a schema to be translated from the new schema version to the existing schema version and from the existing schema version to the new schema version. This translation function allows devices equipped with parsers conforming to different schemas to interchange documents successfully. The translation functionality can occur in either one or both of the devices that are interchanging a document, or as a separate service on a connected network.
The translation function disadvantageously requires details of how to translate between various versions of a given schema. This conversion is generally created manually by one of the schema designers. More recently, conversions have been generated in a semi-automatic manner by a schema mapping method that determines a way to map the same information from one schema to a different schema.
Schema mapping is used to provide a first attempt at mapping information between two given schemas. This first attempt at mapping is then manually updated, usually by a schema designer, to correct any errors caused by the schema mapping method. Some schema mapping methods produce a scoring value that can be used to provide an approximate indication of the success of a mapping. There is presently no single automatic schema mapping method that perfectly maps one arbitrary schema to another. Such a translation function can be implemented by utilising an Extensible Stylesheet Language Transformation (XSLT) transformation file.
The translation function is implemented in the device containing the translation functionality. As indicated above, this device can be one of the devices interchanging a document or can be a separate service on a connected network. Over time, the translation function consumes increasing amounts of memory on the device providing the translation, as the translation function needs to maintain translations between every combination of schema versions.
Although creating a new translation file is a time consuming and somewhat expensive process, translation has been considered a good solution, since the translation between two given schema versions is a precise mapping that has been verified by the schema designers. However, the translation approach requires constant availability of the mapping service, and eventually the mapping service may be used in every transaction, causing network and device bandwidth, latency and dependency problems.
XML is generally considered to be an exact structured format for storing information. Validating parsers are given a schema and reject any document that does not conform exactly to the schema. Validating parsers are not generally used in embedded devices, as validating is a processing and memory consuming overhead. Embedded devices typically have limited memory and processing power. Such embedded devices include printers, personal digital assistants (PDAs) and mobile phones. Further, in many instances there is no prescribed action if a document fails the schema validation. However, schema validation is useful when a person is using an XML editor and generating an XML document. The validation provides feedback to incorrect use of the XML structure by the user.
To reduce the rigidness of parsing an XML document, an application designer can use a parser, such as a Simple Application Program Interface for XML (SAX)-like parser, in a non-validating mode to allow for a loose form of parsing. The designer can design the application to process SAX events on specific XML elements, ignoring the relationship of these elements to other elements within the XML document. Although this approach seems prone to error, the document schema can be designed so that there is a unique tag name containing the relevant information. This means loose parsing is also somewhat robust to changes in the schema, because the schema structure can be changed and the parser still finds the XML tag and associated data. However, this approach does not work when a new version of the schema renames an element or attribute, or if there is more than one element of the same name in the document. This approach is equivalent to searching for a tag and ignoring structure, and thus does not use the full facilities of the XML technology. Consequently, structure or relationship information is not used.
Another form of loose parsing is the ubiquitous World Wide Web (“web”) browser. Although HyperText Markup Language (HTML) does not necessarily conform to the strict rules of XML, HTML is very similar to the XML format. XML is concerned with describing data and what constitutes the data. In contrast, HTML is also concerned with displaying display and how data looks.
Web browsers have been designed to make a poor, but workable, “best-effort” attempt to display something from a given web page. A web browser is capable of displaying plain text containing no HTML tags whatsoever. HTML tags can be misspelt or important tags forgotten and the browser still provides something on the display. Generally, an HTML parser ignores any tag that the parser does not recognize and attempts to display any information contained within those tags. This leads the web browser defaulting to display the text nodes if no other formatting information is found. The web browser may also accept HTML tags, even when such tags have been placed in an incorrect part of the HTML document. This “best-effort” approach to process an HTML document is considered to be a desirable feature of web browsers and has reduced the amount of frustration with browsing poorly written web pages, or even pages designed to work better with a particular type of browser rather than another. When browsing web pages, it seems that showing something is better than showing nothing.
XML is becoming a common format for storing and interchanging information on the Internet. Unfortunately, the designers of schemas for information stored and interchanged on the Internet generally use different structures for storing the same data. For example, a first employee database stores the first name of an employee in a field entitled “FirstName” in one schema, while in another company the schema stores the first name of an employee in a field entitled “first”. This lack of consistency makes interchanging information between companies very difficult.
An embedded device that is to operate in an environment where the document schema is constantly being evolved, new profiles are being generated and these profiles' schemas are also being evolved, can have a difficult time finding a document that the embedded device can understand sufficiently well to operate on. The constant need to update translation services to map new versions of the schema and profiles to older versions can be expensive and delay product releases due to the time taken to generate and test the translation files.
Thus, a need exists to provide a manner for “future-proofing” documents encoded using a markup language to enable documents conformant to different schemas to be handled in an appropriate manner when interchanged among networked devices and services.