Scripting With XML

Returning to the initial goal of function shipping, what is ultimately necessary is a ubiquitous practice to describe and process data. The actual logic, encapsulated within components or objects, must be shippable; however, the runtime code itself need not be when the logic controllers are data driven. XML provides a ubiquitous way to process data that can be employed to govern system behavior.

Consider the fundamentals of digital asset management. These naturally involve a specialized set of CRUD (Create, Read, Update, Delete) operations that can be performed on assets, each which constitutes a specific behavior.

Table 16-4 shows a matrix that categorizes these CRUD operations.

Table 16-4 XMl Scripting; CRUD (Create, Read, Update, Delete) Operations

create			read			update		delete
import	Version	Checkin	Search	export	Checkout	replace	delete	purge

From an object-oriented perspective, many operations are specialization of others. For example, version is a specialization of import [create], wherein a new digital asset is created and the metadata and/or content of a previous rendition is carried forward. The check-in operation is a specialization of version, with the added step to release the lock--the digital asset is assumed to be checked-out, and thus, locked prior to check-in.

XML Persistent Interchange for Assets (PISA)

Artesia Technologies' XML Persistent Interchange Syntax for Assets (PISA) defines a data structure that is composed of N digital assets, where in actual practice, the upper bound of N can sometimes literally be in the hundreds of thousands. With an XML data stream that can measure gigabytes in size, the DOM cannot be sensibly employed--the memory required to so would be immense; hence, Artesia Technologies' DAM system, TEAMS, utilizes SAX instead, with the transaction level being per asset.

To aggregate the components of a digital asset expressed within a PISA file using SAX, the default document handler must be subclassed, coded specific to the PISA format. Because the CRUD operations enumerated above and the transaction level are per asset, a generic AssetProcessor class can be defined from which all operations on asset are derived; hence, all operations are by definition AssetProcessor(s). When an [XML] end tag for an asset is encountered, the document handler will have completed the construction of the in memory data structure representing that asset, and can subsequently initiate a call to the process method of an AssetProcessor for that asset.

Which AssetProcessor is applied varies based upon the actual type passed to the constructor of the document handler, usually governed by a specific callback intended to invoke an asset-level operation; thus, writing a single XML document handler, all asset operations can be made available as bulk operations in the digital asset management system. This approach is referred to as a design pattern. As it simplifies the design, implementation and maintenance of the XML processing, there being need for only a single data format [PISA] and document handler, enormous cost savings are realized within the software lifecycle.

Selection of AssetProcessor via a specific callback has a singular drawback, that being the processor type is fixed for the duration of the process. Often, however, it is desirable to queue processing on specific assets, each of which may have a distinct per asset operation. To process this queue as a single batch job, it is necessary for the XML file to be coded so that an event can be fired indicating a change of AssetProcessor. To realize this, Artesia Technologies designed an embedded scripting language that employs XML processing instructions to syntactically enumerate the control of system behaviors, such as which AssetProcessor is currently active.

Syntactic constraints on the internal data of a processing instruction, following its target, are minimal; therefore, data can be encapsulated in element attribute-like syntax as follows:

<?PITarget attr1='some value' attr2='another value'?>

Using SAX

As the SAX event for handling processing instructions conveniently dissects a processing instruction into its target [name] and its remaining data, parsing an element-attribute like syntax requires writing a minimalist document handler, as the processing instruction can thus be transliterated into an element and submitted to XML parsers, as follows:

<PITarget attr1='some value' attr2='another value'/>

The SAX event for handling start elements returns a list of attribute value indexable by attribute name; therefore, the processing instructions can be employed a scripting language that can easily be processed in a consistent manner, employing the XML parser as an application framework. Thus, by using XML, one can readily build a data driven, event based system capable of providing all services traditionally invoked by programmer level APIs.