It is important to understand how the design of the XML will have an effect upon the delivery of live updates to the screen. In this blog entry the in memory database indexing as well as XML structure is summarised.

AltioLive achieves zero network latency data manipulation by maintaining a copy of data accessed by the client through a in memory database. This means that filters can be applied to the client data preventing the need to perform round trip server requests every time the user wishes to change the data viewed. Updates to the client database can be achieved through the use of data pools that push updates to the client.

AltioLive Client Side Database

AltioLive Client maintains a database of the XML data structures, which is indexed using AL_ID’s. This database is used to ensure efficient screen updates and to reduce the overall size of XML payloads sent and received by the AltioLive client.

AL_ID’s are defined using data keys. A data key must provide a mechanism to uniquely identify an XML element. When an update from the server datapool is received, the AL_ID of the XML element is looked up and the data contained within that element replaced.  Any controls connected to the modified data are refreshed to reflect the changes.

Each XML element is treated independently of parent and child elements. This means that data updates do not need to supply the whole XML block to refresh data. As long as the elements and attributes used for data keys are supplied for each parent element then the XML structure will be maintained.

Structuring XML for live update to the client

Achieving a balance between maintainability of the application and efficient screen updates requires the designer to consider the use of attribute and element based XML.

Traditional XML design recommends the use of element based XML structures. Historical weaknesses in DTD are probably the primary reason for this. While there is no reason why an AltioLive application cannot make use of XML that primarily uses elements, there are a number of reasons why attribute based structures are better for AltioLive applications;

• The number of required data keys is reduced
• Designer property settings are easier to read, you define the data source and the data field is a named attribute rather the the element <code>text()</code> reference.
• Reduced XML complexity
• Reduced size of the XML structures

The drawback of having shallow XML data structures that primarily use attributes is that changes to one attribute in the element cause all controls referencing the element to be refreshed, even if the attribute referenced by each control is different.

A general rule for structuring the XML is to identify data that will be refreshed regularly and put this into an element.

Example XML structure;

<static_element portfolio=”my portfolio” desc=”I won’t change often” owner=”anyone” attr1=”sfsfs” attr2=”jkjllklll”>

<dynamic_element stock_id=”alt” stock_value=”120.01″ desc=”I change frequently” />

</static_element>

Example data keys for the above example  

• static_element - concat(@portfolio,”-”, @owner)
• dynamic_element - concat(parent::*/@AL_ID, “-” , @stock_id)

Designing a service request that retrieves only the required data means that efficient dynamic screen updates can be achieved through an XML structure such as

<static_element portfolio=”my portfolio”  owner=”anyone” >

<dynamic_element stock_id=”alt” stock_value=”125.01″ />

</static_element>

In the above XML block the dynamic_element can be identified and controls referencing this elements data will be refreshed to reflect any changes.

The effect of time stamps

Time stamps play an important role of ensuring only the latest updates are reflected within the user interface. In the earlier examples no time stamps were used in the XML elements, this means that every time the XML is received from the server it will be processed and controls that have the element as a data source will be refreshed.

By adding a time stamp attribute and defining the time stamp in the service request it is possible to ensure only the data that changed is refreshed on the screen.

<static_element portfolio=”my portfolio”  owner=”anyone” timestamp=”1″>

<dynamic_element stock_id=”alt” stock_value=”125.01″ timestamp=”3″/>

</static_element>

In the above XML block incrementing the time stamp attribute of the dynamic_element block each time a change occurs ensures that only controls that have the dynamic_element as the data source are refreshed. No action will be taken on the static_element data unless the time stamp value increases.

A time stamp attribute can be a date time value, or a number. The important factor is that the value must increment to ensure screen refreshes take place. This also ensures that data received out of sequence is processed correctly by ensuring only the latest update in the time stamp sequence is reflected in the screen.

References:

http://www.w3.org/TR/REC-xml/

http://www.w3.org/TR/xmlschema-0/

http://www.ibm.com/developerworks/xml/library/x-tipsub.html

http://msdn.microsoft.com/en-us/library/ms345115.aspx

http://www.altio.com/download/documentation/Online_Help/data_routing2.htm

http://www.altio.com/download/documentation/Online_Help/what_are_datapools_.htm