What is the value of XML in e-commerce?

It is very common today to see XML-based technologies employed, for various purposes, in e-commerce. It’s popularity is increasing due to the advantages XML offers over other traditional database technologies.

One of the main reasons for increasing XML adoption consists of the fact that XML is more future-proof – data stored in XML does not necessarily depend on a specific application to enable users to make use of it. If a company stores it’s data in a SQL database, for example, retrieving the data a few years from now might not be a simple task – the format supported by SQL database applications might change, or the particular SQL application used by the company might not be available anymore due to bankruptcy or other reasons. This is an unlikely scenario, but nevertheless possible; XML avoids these potential issues because it’s data is stored as text, which can be searched; therefore, a simple text editor can be used to retrieve data from an XML document, or edit it.

Additionally, there are many XML processors available, which are relatively easy to adapt for a particular XML type of document. This is a direct result of XML being extensible by definition.

Another benefit resulting from XML’s textual nature is that corrupt data is likely to be more salvageable than a database file; a few corrupt bytes will not render the XML file useless – most of the data can still be accessed – this is likely to be an important issue for companies.

XML is also being increasingly used for communications between applications, services and web-servers, via the XML-RPC ( Remote Procedure Call ) protocol.

Parsing XML using SAX

SAX, the Simple API for XML, is another take on parsing XML files. But, as opposed to the DOM approach, a SAX parser will not re-construct the entire document tree in memory, but instead operates in an event-driven manner. The SAX API allows clients to register callback functions for the items they are interested in ( which can be text nodes, element nodes, processing instructions or comments ). When the SAX parser will encounter these items, an event will be triggered and the callback function ( if any are registered ) will be called, allowing the client application to take action. Another event will be triggered when an end of any of those XML features is encountered, and eventual functions called.

Another difference between SAX and DOM is that there is no standard for SAX, and therefore the API is not guaranteed to be the same for all parsers. In practice, differences between various implementations are quite significant, requiring users to familiarize themselves with the particular flavor of SAX which the parser employs.

For example, a SAX parser is described by Microsoft’s ISAXXMLReader (http://msdn.microsoft.com/en-us/library/aa924174.aspx ); callback functions can be set using the ISAXContentHandler::startElement method. But fortunately other implementations outside COM ugliness are available for C++; one of the most popular choices is Xerces (http://xerces.apache.org/index.html ), by Apache. It can be used like this:

void foobar_sax_handler::startElement(const XMLCh* const name,

                           AttributeList& attributes)

{

    char* m_name = XMLString::transcode(name);

    cout << "Element encountered: "<< m_name << endl;

    XMLString::release(&m_name);

}

This assumes that we have defined a class named foobar_sax_handler, which inherits from HandlerBase and has a startElement method. We can set this class to handle XML events with the setDocumentHandler method of the SaxParser class. Our customized parser can then be invoked using the parse( xml_file ) method of the SaxParser class, where xml_file represents the name of an XML file.

When the parse method is called, the startElement method will be called for each element, printing it’s name. Of course, inside this method we can perform more specific actions, for example only printing or modifying certain elements.

SAX bindings are also available for other languages as well, for example the jssaxparser ( http://code.google.com/p/jssaxparser/ ) is for JavaScript; a SAX parser is also available for Java ( javax.xml.parsers.SAXParser ). The API varies slightly between all these implementations, but the same principles apply; if one is familiar with using SAX with one programming language, switching to a different one will be relatively easy.

The Document Object Model

The DOM is an interface which provides a way of accessing and modifying structured documents, such as XML, XHTM and SVG. The DOM is usually accessed via it’s public API, in a platform- and operating system-independent manner.

The DOM has a troubled history, due to the fact that the early browsers market was very competitive, which reflected negatively on the willingness of the companies producing them to cooperate, develop and implement standards. W3C later managed to get companies such as Netscape and Microsoft to collaborate and develop a standard for a scripting language ( ECMAScript ), and a DOM afterwards, in late 1998.

The concept of a DOM is used by browsers, which expose an API to enable JavaScript code to access and modify the DOM. For example, the following code will find an element which has the ‘foo’ id and make it’s background colour green:

document.getElementById('foo').backgroundColor="green";

This example illustrates a few important concepts about the DOM – instead of being a monolithic specification, it is divided into several separate documents, each describing a specific area. For Level 2 DOM, it comprises a ‘Core’ ( http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/ ), and the other recommendations extend on it. For example, the Level 2 HTML DOM extends some components which are part of the ‘Core’ specification, specializing them according to the needs of HTML. The HTML DOM ‘HTMLDocument’ interface, for example ( http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-26809268 ) was derived from the core ‘Document’ interface, and similarly the HTMLElement interface was derived from the core ‘Element’ interface.

Such extensions of the ‘Core’ DOM allow for a wider range of application, and therefore more uses. The aforementioned HTML DOM allows for HTM-specific manipulation – for example, hiding an element with a certain ID. The DOM Level 2 Style specification allows scripts to dynamically access and update the content of stylesheets, therefore affecting how the document looks.

SVG Images

Scalable Vector Graphics ( SVG ) relies on text for describing an image. It also supports the inclusion of raster data, however the mainstay of SVG is textual description of graphic data. For example, the following SVG document contains a red circle with a black outline:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<svg

   xmlns:dc="http://purl.org/dc/elements/1.1/"

   xmlns:cc="http://creativecommons.org/ns#"

   xmlns:svg="http://www.w3.org/2000/svg"

   xmlns="http://www.w3.org/2000/svg"

   version="1.1"

   width="100"

   height="100"

   id="svg2">

  <g

     transform="translate(0,-952.36218)"

     id="layer1">

    <path

       d="m 90,50 a 40,40 0 1 1 -80,0 40,40 0 1 1 80,0 z"

       transform="translate(0,952.36218)"

       id="path2987"

       style="fill:#ff0000;

              fill-rule:evenodd;

              stroke:#000000;

              stroke-width:1px;

              stroke-linecap:butt;

              stroke-linejoin:miter;

              stroke-opacity:1"

    />

  </g>

</svg>

As it is obvious from the document above, SVG is an application of XML – valid SVG documents are also validate as XML. It also showcases how graphical data is stored inside the SVG file – as XML elements, with graphical properties described via attributes. The circle is represented by the path element – the ‘d‘ element is actually short for ‘Path Data’, and describes it’s shape. ( http://www.w3.org/TR/SVG11/paths.html#PathData ). Other properties of the circle, such as it’s fill colour and stroke width/colour are described via attributes, as visible in the above example.

The SVG specification has multiple profiles; for example, the SVG Mobile Recommendation ( http://www.w3.org/TR/SVGMobile/ ) defines the SVG Tiny and SVG Basic mobile profiles. SVG Tiny is targeted at highly restricted mobile devices, while SVG Basic is meant to be suitable for higher level mobile devices.

One of the major issues concerning SVG is a reduced browser adoption rate. Although the most recent versions of all major browsers have at least some level of support for SVG images, some older, but still widely-used versions do not support SVG; Internet Explorer fully supports the SVG Basic specification only since version 9, released on March 14^th 2011.