A fundamental direction of efforts to address the limitations of current Web data structuring technology has been attempts to integrate aspects of object technology with the basic infrastructure of the Web. A previous report, Towards a Web Object Model [Man98], identified the relationship of parts of the Web to parts of an object model, described some Web standards related to those object model parts, and suggested an overall approach for combining these standards to produce "objects" in the Web. This report describes a number of new Web technologies currently being developed that further the integration of Web and object technology. In particular, this report:
If the Web is to be used as the basis of complex enterprise applications, it must provide generic capabilities similar to those provided by the OMA (although these may need to be adapted to the more open, flexible nature of the Web). This involves addressing the provision of higher level services (such as enhanced query and transaction support) and their composition in the Web. However, the basic data structuring capabilities provided by the Web must also be addressed, since the ability to define and apply powerful generic services in the Web, and the ability to generally use the Web to support complex applications, depends crucially on the ability of the Web's underlying data structuring facilities to support these complex applications and services.
The basic data structure of the Web consists of hyperlinked HTML documents, accessed via the HTTP protocol. It is generally recognized that HTML is too simple a data structure to support complex applications [Bos97], e.g.:
There is much other ongoing work within both the Web and database communities on data structure developments to address Web-related enhancements. Work on similar issues is ongoing within the Object Management Group as well. This work has contributed valuable ideas, and the various proposals illustrate similar basic concepts (generally, movement toward some form of object model). If the Internet is to develop to support advanced application requirements, there is a need for both richer individual data structuring mechanisms, and a unifying overall framework which supports heterogeneous representations and extensibility and provides metalevel concepts for describing and integrating them.
A more complete integration of object technologies into the Web provided by a Web object model would provide the basis of both powerful capabilities for integrating all kinds of data and information, and a wide variety of enhanced services, within a distributed architecture that is both widely-available, and easy-to-use and extend.
[Man98] noted that progress toward a Web object model requires:
The report also identified, as key component technologies to support these requirements:
In addition to using these emerging Web technologies, the report also proposed taking advantage of other existing aspects of the Web, e.g.:
In addition, this report does not claim to be totally comprehensive. The specific technologies cited are not necessarily the only technologies in these areas under development; instead, they are cited as examples or illustrations of the types of technologies being developed. New technologies appear quite frequently.
Finally, a number of the sections refer to ongoing activities of the World Wide Web Consortium (W3C). The reader should be aware that in many cases the specifications and capabilities described are works in progress. As a result, some of the details described in this report, as well as the source references, may no longer be completely accurate (or accessible due to changed URLs) by the time this report is read. The latest information on these activities can always be obtained through the main W3C Web page <http://www.w3.org/>.
Object (state) Class object +---------------+ +-------------+ | class pointer |------------->| Class data | +---------------+ +-------------+ | variable 1 | | method 1 | | variable 2 | | method 2 | | ... | | ... | | variable n | | method m | +---------------+ +-------------+C++ implementations use similar structures. The state is a collection of programming language variables, which (usually) are not visible to anything but the methods (this is referred to as encapsulation). A typical object model has a tight coupling between the methods and state. All the structures (class objects, internal representation of methods and state, etc.) are determined by the programming language implementation, and are created together as necessary. The class (in particular, the methods it defines) defines the way the state should (and will) be interpreted within the system, and hence is a form of metadata for the state. As a result, the link between an object and its class is essentially a metadata link.
Extending this idea to the Web environment, the idea is that Web pages (or parts thereof) can be considered as state, and objects can be constructed by enhancing that state with additional metadata that allows the state to be considered as objects in some object model. In particular, we want to enhance Web pages (or parts of them) with metadata consisting of programs that act as object methods with respect to the "state" represented by the Web page (or part thereof). The resulting structure would, at a minimum, conceptually be something like:
+----------+ +---------->| method 1 | +-------+ | +----------+ | Web |--+ ... | page |--+ +-------+ | +----------+ +---------->| method n | +----------+There are already a number of mechanisms used in the Web to integrate code (behavior) with Web pages, so the construction mechanism may be either simple or complex.
Constructing these object model structures requires a number of "pieces" of technology. [Man98] identified the following pieces:
These assumptions (or rather, the lack of them) means that the state can have a very general form, given the generality of XML. For example, the state of an object need not be all in one unit (or file), since XML allows a document to refer to external entities that can contain either XML or data in some arbitrary representation. In addition to referencing other data using entities, XML documents, like HTML pages, can also use hyperlinks to other documents or Web resources, and these could be considered as part of the state defined by the document, depending on the semantics that the software that interprets the object attaches to this linked material. At the same time, the state of an object could be defined as being a subset of an XML document, i.e., a given XML document could represent the state of multiple objects. This is so because an XML document represents a tree of separately-marked elements. A given element could be interpreted as being a separate object, with its type and associated methods identified by the element tag. Some of these techniques are discussed in Sections 3.2 and 3.3. (Introductory material on XML may be found in [Man98], or in a number of recent texts, e.g., [Har98, Hol98, Lig97, Meg98, StL98].)
Proposals have also been made to represent programming language constructs directly in HTML and XML (i.e., define elements/tags which represent programming language statements for control flow, function calls, etc.) as yet another representation of Web page behavior. Several such approaches are discussed in Section 3.4. These approaches effectively define another scripting notation, where the special tags are interpreted by their own interpreter to generate the specified behavior.
[Man98] noted that programs, as descriptions of behavior, could be considered a form of metadata, and hence could be described using either embedded or separate RDF resources. For example, an RDF resource associated with a given Web page could contain OBJECT elements (or some corresponding XML constructs) that identify the programs that act as the page's methods. Alternatively, the RDF resource might refer to programs defined as Web resources using some mechanism other than the OBJECT element, and also include a reference (possibly as an OBJECT element) to a "loader" mechanism capable of accessing those programs and providing them to the client on request. RDF resources contain explicit references to the Web pages for which they define metadata. However, they do not require that the Web pages themselves be aware of the existence of this metadata, and hence do not require that the pages be created with (or modified to contain) references to the metadata. Thus, using an RDF-based approach would allow Web pages to be associated with object methods without the pages themselves having to contain references to the methods.
However, while methods can be considered a form of metadata, and hence could in principle involve RDF, there are a number of alternative (and generally more straightforward) mechanisms that are also available.
Possibly the most straightforward approach to associating methods with a Web page is to embed either the method itself, or a pointer to it, in the page. Scripts are often implemented as directly embedded methods, using the HTML SCRIPT element to contain the script. Applets are usually implemented by embedding a pointer to the file containing the applet in the page, using the HTML APPLET or OBJECT tag. Scripts can be implemented using pointers to external files as well. In particular, SCRIPT elements can be used to associate collections of scripts with a page, thus forming something akin to an object class. Separately linked style sheets also provide a way of associating sets of behaviors with HTML documents.
These mechanisms for associating methods with HTML pages involve the use of special tags, e.g., OBJECT and SCRIPT, along with built-in mechanisms for processing them. XML per se does not define such standard tags. However, XML defines a number of mechanisms that can be used to define elements that contain scripts or other method representations, or pointers to them. These methods could then be processed (interpreted) by separate interpreters (much as Web browsers refer HTML SCRIPT and OBJECT elements to specific interpreters). In addition, W3C's Extensible Style Language (XSL) <http://www.w3.org/TR/WD-xsl> represents work toward a way of associating formatting behavior with XML documents. Additional XML-related technology is also being developed to support other ways of associating behavior with XML pages. These XML-based technologies are discussed in Section 3.2.
Current HTML mechanisms for associating methods with Web pages deal not only with associating methods with pages as a whole, but also with associating methods with specific parts of Web pages. For example, a given script can be associated with a particular HTML element to provide behavior for that specific element (e.g., to define what happens when the user clicks on it). The same script could also be associated with multiple elements. Stylesheets also provide mechanisms for associating styles with specific HTML elements (or possibly all elements satisfying specific criteria). Mechanisms for associating methods with XML pages must provide corresponding capabilities. This is particularly important in the context of XML, since each XML element type (tag) potentially represents distinct semantics, and hence may need to be associated with behavior specific to those semantics.
Another form of method/state relationship is the way the methods gain access to the state (for reading or updating it). The form of this access is a particularly important consideration in building objects from XML documents, which may have a complex structure, as opposed to the simple "flat" state typically found in programming language objects.
The most straightforward approach for providing this access would be to simply provide each method with access to the character string making up the XML state. However, this would require that the method effectively parse the state in order to find the particular part of the XML document it needed to work on. [Man98] identified the W3C's Document Object Model (DOM) as a means by which methods could conveniently access the (XML-based) state. The DOM provides a generic object-oriented API for XML documents, permitting methods to access individual elements (and other components) of the XML without having to parse the document. The use of an explicit DOM interface to the object state representation also provides another advantage, namely an additional degree of generality in choosing the state representation. This is because, if methods access the state through the DOM interface, any representation (not just XML) could conceivably be used in building an object, provided that a DOM (or DOM-based) interface could be defined for it.
The DOM itself defines only a generic API to an XML document (e.g., it presents the document as a collection of objects of types such as Document, Element, and so on). It does not provide for the construction of application-specific interfaces based on the interpretation an application may assign to specific element names (e.g., the DOM does not provide a specialized interface for an AUTHOR object even though the document's outer element tag may be AUTHOR, and those are the intended semantics of the document). Instead, additional processing must be applied to the XML to provide such interfaces, possibly as specializations of the DOM-defined interfaces. Examples of technology to define such interfaces are described in Sections 3.1 and 3.3.
In some cases, providing a method with access to state needs to be done in what might be considered multiple steps. For example, Java applets associated with a Web page have no native way to access the page directly. Netscape's LiveConnect technology, discussed in Section 3.1, provides such a mechanism.
The approaches discussed above are more-or-less "Web-native" ways to associate behavior with Web pages. A conceptually different approach is that used in providing object interfaces to non-object data (such as relational databases) in distributed object systems using object "wrappers" or "shells". In this approach, ordinary objects in some object-oriented implementation technology are created, which use Web data as their state (e.g., they might retrieve data from the Web when they need access to state information). These approaches are not discussed further here, but are discussed in, e.g., [App97, OH98].
Generally, it is possible to define objects in many different object models using the same basic internal components (e.g., methods and state). The W3C DOM specifications illustrate how an XML document can be represented as objects in CORBA IDL, ECMAScript, and Java. Section 3.1 illustrates how XML can be used to construct objects in both Java and JavaScript (despite the similarity of the names, these are two distinct object models) using some specific interface support technologies.
The NCITS Object Model Features Matrix [Man97] identifies many different object models, with widely differing characteristics and ways of defining object interfaces. Different object models could also be used for objects in the Web. The details of the structures to be supported in a Web object model depend on the details of the object model we choose to define. For example, many object models are class-based, such as the C++ and Java object models. Choosing a class-based model for the Web would require defining separate class objects to define the various classes. Other object models, such as JavaScript, are prototype-based, and do not require a class object (each object essentially defines itself).
In typical distributed object systems, such as CORBA, interface definitions are sometimes used by stub generators to generate code for accessing objects, and hence the interface definitions themselves may not be needed at run time in processing method invocations. However, in other situations (such as dynamic invocation) it may be necessary to access the interface definitions at run time. As a result, the interface definitions are saved in some form of Interface Repository so they can be accessed when needed. This requires that an explicit representation for interface definitions be considered. In the context of the Web, a straightforward approach would be to represent object interface definitions in XML. A number of Web technologies described in Section 3 use XML to define interfaces. The XML element types (tag names) used in these XML representations are based on the particular object model chosen.
An important supporting technology in the definition of interfaces for objects in the Web (and in expanded applications for XML in general) would be improvements in the ability to define data type information for XML. XML Document Type Definitions (DTDs) are sometimes characterized as being like database schemas, or object class definitions; i.e., as defining the characteristics of a collection of instances (individual XML documents). However, this is only true to a limited extent. David Megginson, in a recent email message to the xml-dev email list, has noted that XML DTDs actually "bundle" several roles (inherited from SGML DTDs):
A number of proposals have been made for alternative schema and data type facilities for XML, including:
Both these approaches to "pulling objects together" are illustrated by the technologies discussed in Section 3. In some cases, XML-encoded information, possibly together with other object "pieces", is translated into objects interpretable by an existing object interpreter (e.g., into Java or JavaScript objects). In other cases, a separate interpreter or other piece of software is used to interpret the XML and other object "pieces" as objects (e.g., the Scriptlets runtime engine discussed in Section 3.1.4.2).
Other, more general, architectural issues must also be addressed. For example, if the Web is to be used as a generalized information repository (whether objects are used or not), the issue of updating needs to be addressed. The DOM provides a general interface (at least potentially) for updating XML documents on the client side. However, better mechanisms are needed for conveying these updates to the server, and implementing them there. This includes protocol-level work such as WebDAV (Web Distributed Authoring and Versioning) <http://www.ietf.org/internet-drafts/draft-ietf-webdav-protocol-08.txt>, work on improved security mechanisms, and work on higher-level mechanisms for synchronizing concurrent updates. Such work includes work on versioning, simple locking (which is covered in the WebDAV work), and higher-level database-like transaction mechanisms (the WebDAV work uses XML to represent both method input and output information in its protocol). Additional work is also required on improved Web messaging protocols. A number of mergers of Web and object technologies, such as the WebBroker technology discussed in Section 3.5.1, use the existing HTTP protocol for object-oriented messaging. However, work such as HTTP-NG <http://www.w3.org/Protocols/HTTP-NG/> aims at improvements in the Web's support for "purer" object-oriented messaging (e.g., the use of a binary, rather than a text-based, format). Addressing these and other issues, such as support for improved caching schemes, will make the Web an even better vehicle than it is now for efficiently implementing objects.
However, creating objects from Web resources involves reconciling two organizational philosophies that appear somewhat distinct. On the one hand, the conventional idea in object-oriented programming is that the behavior defined for an object is "mandatory"; an essential component in defining the semantics of an abstract data type. Having only data, even using semantically-meaningful attribute names as in XML, could allow the data to be used inappropriately, in a way that is not consistent with the actual intended type semantics (which are defined by the operations).
On the other hand, the SGML philosophy (from which XML and much of the Web derives) is that the essential semantics are wrapped up in the data alone (in particular, in the element names). In this philosophy, there are a number of good reasons for not binding operations too tightly to the data (if at all). For example, labeling elements instead of explicitly binding them to code avoids locking information into one program, or even one purpose [DeR97]. This is particularly important in the case of a representation (like XML) with possibly-rich semantics, which may be moving between organizations. For example, a Purchase Order represented in XML, and transferred between two businesses, will probably not be processed by the same programs at each end. Instead, the XML would be linked to distinct (company-specific) processing. So, according to this approach, it is enough to tag the document as being a PURCHASE-ORDER, and rely on a separate mechanism to associate a PURCHASE-ORDER with the appropriate application(s). The use of MIME types in the Internet illustrates the value of this general approach, since it allows the use of different programs on the same data, while also providing information (the MIME type) that helps see to it that only programs capable of processing the data are actually used. The use of XML element names provides a similar form of indirectness in associating behavior with data, but at the granularity of individual elements. This same concept is also very much along the lines of the thinking behind the use of a relational database as a generalized information repository which can then be used by multiple applications. The need for care in how tightly behavior is associated with data also shows up in object analysis and design.
In general, it is desirable to support flexibility in how tightly behavior is associated with data, since in some cases a tightly-coupled object-oriented programming style will be appropriate, while in other cases a looser coupling will be appropriate. For example, in some cases it might be appropriate to agree on a definition of each element type, and possibly even to include a pointer to a machine-accessible version of that definition as metadata (e.g., an ontology), but not to require the use of a specific piece of code to process it. On the other hand, in some cases it may be desirable to provide standard pieces of code to process particular elements (e.g., to implement industry-standard semantics where process interoperability is involved, or industry-standard algorithms for certain kinds of processing exist). In addition, it is desirable to support the ability to change the decision as to how tightly behavior is associated with data, to accommodate changes in requirements or other circumstances.
These requirements for flexibility particularly exist in the Web, given its dynamic and heterogeneous nature. At the same time, however, Web technologies provide the necessary infrastructure to support these requirements. For example, the Web infrastructure supports remote access to code, which makes tightly coupling data with "standard" code more feasible. Moreover, XML and related technologies described in Section 3.2 illustrate that a range of mechanisms exist for supporting both loose and tight coupling of data and behavior. Interface implementation mechanisms such as Object Request Brokers provide another mechanism for flexibly associating data and behavior. A Web object model must support these flexibility requirements, and take maximum advantage of the Web's capabilities in doing so.
The above comments have primarily concerned flexibility in the Web at the object construction level. Flexibility is also required at the model level. An object model for objects in the Web itself needs to be flexible, in the sense of providing support for interoperability among the wide range of data and processing resources on the Web, much as a global data model provides this type of support in a heterogeneous distributed database system [SL90]. Section 3.1 describes some existing forms of interoperability between different object models in the Web. The idea of a global object model for the Web is discussed further in Section 4.2.
This section also discusses some technologies that go beyond straight HTML. Specifically, Section 3.2.3 describes some techniques which explicitly make use of XML, or XML-like extended tags, together with scripting, for creating components (objects), in several object models, which can be embedded in Web pages.
DHTML defines objects that represent both an HTML document (and its contents), and also the browser environment, e.g., the browser and the browser window. A script is associated with the document using an HTML SCRIPT element. The SCRIPT element may either directly contain executable code in a specified scripting language, or associate external script libraries with the document by referencing an external file. Other elements on the page can then include specifications of particular events, e.g., onClick to indicate a user selecting the element, together with the script-defined function to be invoked when that event occurs with respect to that element. An important capability of DHTML (and the reason it is called "Dynamic") is that scripts can dynamically change what is seen by the user. Whenever a script manipulates and changes an attribute of an element or modifies the contents, the document is redisplayed with the new information. The exact DHTML facilities provided currently differ among browser implementations, which is the basic reason for the W3C DOM standards activity.
The JavaScript scripting language supported by Netscape and Microsoft (as JScript) provides the usual means for scripting in DHTML (although Microsoft Internet Explorer also supports VBScript). Some simple examples of JavaScript are distributed throughout this report (see the cited texts for more detailed examples). A particularly interesting aspect of JavaScript is its extremely flexible object model (described in the following section). For example, unlike conventional object-oriented programming languages, JavaScript functions and properties can be dynamically added to any object, and predefined behavior can be overridden. An eval method is also available that can evaluate a passed-in string as a script, and return the result.
DHTML (at least in principle) allows elements to be dynamically added to a document, either by creating a new element in memory and associating it with the document, or by directly modifying the underlying HTML contents. DHTML exposes all information about the document, including unrecognized elements and attributes. This feature can be used in some cases to create user-defined behavior based on custom elements and attributes. E.g., by adding unrecognized attributes (attributes not defined in HTML) to existing elements, the elements can be provided with additional behavior (thus providing a way to simulate subclassing of an element). In addition, user-defined elements can be added, and behavior attached to them. (The ability to do this depends on the specific browser involved, and also on the way current HTML browsers generally ignore unrecognized elements and attributes).
The HTML OBJECT element allows controls and applets to be included in a page that extend the available behavior. For example, objects can be defined to embed graphics or even other documents directly into the document.
Motivations cited for the use of scripting languages versus more conventional programming languages (in some cases, including Java) include:
For example, a Web browser (client) provides an ECMAScript host environment for client-side computation which includes objects that represent windows, menus, pop-ups, dialog boxes, anchors, frames, history, cookies, and input/output (these objects are defined by DHTML's Document Object Model, and the DOM being specified by the W3C). Further, the host environment (DHTML in this case) provides a means to attach scripting code to events such as change of focus, page and image loading, selection, form submission, and mouse actions. Scripting code appears within the HTML, and the displayed page is a combination of user interface elements and fixed and computed text and images. The scripting code is reactive to user interactions and there is no need for a main program. A Web server would provide a different ECMAScript host environment for server-side computation which includes objects representing requests, clients, and files, and mechanisms to lock and share data. By using browser-side and server-side scripting together it is possible to distribute computation between the client and server while providing a customized user interface for a Web-based application. Each Web browser and server that supports ECMAScript supplies its own host environment, completing the ECMAScript execution environment.
ECMAScript is object-based: basic language and host facilities are provided by objects, and an ECMAScript program is a cluster of communicating objects. An ECMAScript object is an unordered collection of properties. Properties are containers that hold other objects, primitive values, or functions. A function stored in the property of an object is called a method. A property can also have 0 or more attributes which determine how the property can be used--for example, when the ReadOnly attribute for a property is set to true, any attempt by executed ECMAScript code to change the value of the property has no effect. A type in ECMAScript is a set of data values. A primitive value is a member of one of the following built-in types: Undefined, Null, Boolean, Number, and String; an object is a member of the remaining built-in type Object.
ECMAScript defines a collection of built-in objects which completes the definition of ECMAScript entities. These built-in objects include the Global, Object, Function, Array, String, Boolean, Number, Math, and Date objects. ECMAScript also defines a set of built-in operators which are not, strictly speaking, functions or methods, including various unary operators, mathematical operators, bitwise operators, relational operators, assignment operators, and so on.
ECMAScript syntax intentionally resembles Java syntax, but is relaxed to enable it to serve as an easy-to-use scripting language. For example, a variable is not required to have its type declared, nor are types associated with properties; the values stored in properties can change type at runtime.
ECMAScript does not provide classes such as those in C++, Smalltalk, or Java, but rather, supports constructors which create objects by executing code that allocates storage for the objects and initializes all or part of them by assigning initial values to their properties. All functions including constructors are objects, but not all objects are constructors. Each constructor has a Prototype property which is used to implement prototype-based inheritance and shared properties. Objects are created by using constructors in new expressions, for example, new String("A String") creates a new string object. Invoking a constructor without using new has consequences that depend on the constructor. For example, String("A String") produces a primitive string, not an object. Storage management is handled by a garbage collector.
ECMAScript supports prototype-based inheritance. Every constructor has an associated prototype, and every object created by that constructor has an implicit reference to the prototype associated with that constructor. A prototype may have a non-null implicit reference to its prototype, and so on; this is called the prototype chain. When a reference is made to a property in an object, the reference is to the property of that name in the first object in the prototype chain that contains a property of that name. In other words, first the object mentioned directly is examined for the property; if that object contains the named property, that is the property to which the reference refers; if that object does not contain the named property, the prototype for that object is examined next; and so on. All objects that do not directly contain a particular property that their prototype contains share that property and its value.
Unlike class-based object languages, properties can be added to objects on the fly simply by assigning values to them. That is, constructors are not required to name or assign values to all or any of the object's properties.
There is a unique global object which is created before control enters any execution context. Initially the global object has the following properties:
ECMAScript's flexibility, as well as the fact that it is a "native" (to Web browsers) way of specifying behavior, allows it to play the role of an integrating technology in associating behavior with Web pages. This will be illustrated in several of the subsequent sections.
One "direction" of using LiveConnect allows Java applets to be accessed from JavaScript. For example, if JavaScript needs to perform a complex computation, it may be easier to write this as a "hidden" applet called from JavaScript than as a native JavaScript function. JavaScript can access applets via the document.applets array, which is an array of objects representing each applet in the document, and is defined as part of DHTML's Document Object Model. (The W3C's DOM (HTML) Document object has a corresponding applets collection). If the applet is named, it can also be referred to by name, i.e., document.<appletName>. Any public method of the applet can be called by JavaScript. In the following example (from [Hal98]), the applet Acoustics supports a way of computing sound propagation through water, and a Web page is being created that requires that computation. The applet would be included in the page using:
<APPLET CODE="Acoustics" WIDTH=10 HEIGHT=10 NAME="acoustics"> </APPLET>A JavaScript function calling the public getSignalExcess method of the acoustics applet would then be defined as:
function signalExcess(...) {
return(document.acoustics.getSignalExcess(...));
}
The JavaScript signalExcess function could then be used wherever
needed to compute the required values (in effect, the applet call is wrapped
by the JavaScript function). In this case, the applet is referred to by
the name document.acoustics.
The other "direction" of using LiveConnect allows applets to access JavaScript. This allows the use of Java syntax to access all JavaScript objects, read and set all available properties, and call any legal method. To use this approach, Netscape's JSObject class must be obtained and imported into the Java applet. This class supports a static method getWindow that allows the applet to obtain a reference to the window that contains it (as an object of type JSObject), as in:
JSObject Window = JSObject.getWindow(this);The Window object's getMember method can then be used to read properties of the main window, and via the values of these properties, other parts of the window (JavaScript objects) can be accessed.
The ability to access page contents as data (i.e., an API to the page) is clearly a necessity in adding behavior to pages. LiveConnect provides this capability for HTML and Java, and some such capability is also required for XML. The most straightforward means of providing this would be for XML-supporting browsers to directly support DOM interfaces in a range of programming languages (including Java).
The following example <http://www.sigs.com/publications/objm/9711/vanderveer.code.html> defines a non-persistent client-side JSB that displays a configurable scrolling message in a browser's status bar. The JSB_PROPERTY and JSB_METHOD elements define the properties and methods, respectively, exposed at the component's interface. To use the AWT 1.1 event model, the additional elements JSB_EVENT and JSB_LISTENER would be used. If a method has parameters, each parameter is specified using a JSB_PARAMETER element inside the corresponding JSB_METHOD element. The JSB_CONSTRUCTOR element contains the JavaScript code (omitted here) for each defined method, and a constructor function (the last function defined) for the JavaScript component. The constructor code of a JSB is similar to the code that would be run to construct a user-defined object in JavaScript. Once the component is instantiated, it's scroll(), stop(), and reset() methods will be exposed for invocation from other components.
<JSB>
<JSB_DESCRIPTOR NAME="netscape.peas.ScrollingBanner"
DISPLAYNAME="Scrolling Banner"
ENV="client"
CLASS=""
CUSTOMIZER=""
SHORTDESCRIPTION="JavaScript Scrolling Banner">
<JSB_PROPERTY NAME="msg"
DISPLAYNAME="Message" PROPTYPE="JS" TYPE="string"
READMETHOD="" WRITEMETHOD=""
SHORTDESCRIPTION="Text message to scroll in status bar">
<JSB_PROPERTY NAME="speed"
DISPLAYNAME="Scroll Speed"
PROPTYPE="JS" TYPE="number" VALUESET="0:200"
READMETHOD="" WRITEMETHOD=""
SHORTDESCRIPTION="Scrolling speed">
<JSB_PROPERTY NAME="position"
DISPLAYNAME="Start Position"
PROPTYPE="JS" TYPE=""
READMETHOD="" WRITEMETHOD=""
SHORTDESCRIPTION="Starting position of message">
<JSB_METHOD NAME="scroll" TYPE="void"> </JSB_METHOD>
<JSB_METHOD NAME="stop" TYPE="void"> </JSB_METHOD>
<JSB_METHOD NAME="reset" TYPE="void"> </JSB_METHOD>
<JSB_CONSTRUCTOR>
function scroll(){ //snip script }
function stop(){ //snip script }
function reset() { //snip script }
function netscape_peas_ScrollingBanner(params){ //snip script }
</JSB_CONSTRUCTOR>
</JSB>
Tools that read JSBs, like Netscape's Visual JavaScript, use the JSB file
as the basis for automatically-generated JavaScript code, essentially translating
the JSB into conventional JavaScript which can be interpreted by the browser.
Since the result of a JSB is actually JavaScript, the JSB can be linked
with other components on the page (or, using LiveConnect, with applets).
JSBs can run on both Netscape Navigator or Microsoft Internet Explorer
clients, and on Netscape's Enterprise Server (the JSB definition provides
control over whether the bean can run on the client, the server, or both).
If a JSB has no support files, it can be used in a single .jsb file. However, JSBs can be made up of more than one file, including JavaScript code or external Java .class files. In this case, all the files can be packaged into a Jar file, for distribution as a unit.
[Nic98] notes that Visual JavaScript allows CORBA objects to be used in much the same way as JavaBeans and JSBs, through the use of JSBs. To do this, a file containing the IDL definitions for the CORBA objects is loaded into the Visual JavaScript tool. During this process, each IDL interface definition in the file is converted to a JSB, which serves as a wrapper or proxy for the (potentially remote) CORBA object. IDL attributes are converted into JSB properties. Other properties are also added by Visual JavaScript, e.g., an ObjectURL property, which allows the user to specify a URL which identifies the actual location of the CORBA object. At runtime, the CORBA object is found using the value of this property. IDL operations are converted to JavaScript method declarations (with data types converted to Java data types). Again, these methods serve as wrappers for the methods of the CORBA object. At runtime, the component will be connected to an actual CORBA object on the server. The JavaScript program references this object through a property called corbaObject.
Another technology for defining interfaces between JavaScript and CORBA objects is the CORBA Component Scripting response (orbos/97-11-27) from Netscape, Oracle, Visigenic, Sun, and Genesis to the CORBA Scripting Language RFP. This response proposes JavaScript (ECMAScript) as a CORBA scripting language, and is based on the use of LiveConnect technology. The approach involves constructing a JavaScript reflection of CORBA objects, which allows the CORBA object to be manipulated as if it were a JavaScript object. Property access and function calls in JavaScript are translated to accessors and method calls on the corresponding CORBA object. To construct the reflection, the CORBA IDL interface is mapped to a JavaScript object which serves as a prototype. Instances of that interface are represented by a JavaScript object whose prototype is the interface object. Attributes are mapped to properties of the JavaScript object. Methods are mapped to (JavaScript) function-valued properties of the JavaScript object. Invoking these functions from JavaScript causes the appropriate interface method to be invoked through the CORBA Dynamic Invocation Interface.
The response defines a complete language mapping from IDL to JavaScript. This closely parallels the LiveConnect language mapping from Java to JavaScript, which already permits JavaScript to act as an implementation language for JavaBeans and Java objects. No reverse JavaScript to IDL mapping is needed. JavaScript objects, because of runtime typing, can masquerade as objects implementing arbitrary IDL interfaces. This is implemented by using CORBA's Dynamic Skeleton interface to handle CORBA operations with JavaScript function calls or property references. Circumventing CORBA's type system in this way means that some errors will not be detected until runtime. If the JavaScript object does not have the necessary properties to implement an invocation on the interface, the CORBA::NO_IMPLEMENT exception is raised.
A scriptlet is defined by a file with a .sct extension, which contains script code and XML markup (using a specialized tag set). An example (from [Esp98a] is:
<SCRIPTLET>
<REGISTRATION
Description = "Factorial"
ProgID = "Factorial.Scriptlet"
Version = "1.00"
ClassID = { ***UUID for the class*** } >
</REGISTRATION>
<IMPLEMENTS ID="Automation" TYPE="Automation">
<METHOD name="Calculate">
<PARAMETER name="num"/>
</METHOD>
</IMPLEMENTS>
<SCRIPT language="JScript">
function Calculate(num) {
if(num<2)
return 1;
return num*Calculate(num-1);
}
</SCRIPT>
</SCRIPTLET>
The <IMPLEMENTS> element can also define component properties
as well as methods, using a <PROPERTY> tag. A property can
be defined either by specifying its name, as in
<PROPERTY name="Text"/>or by explicitly specifying GET and PUT methods (which refer to functions written in the scripting language), as in
<PROPERTY name="Text"> <GET internalname="DoGetText"/> <PUT internalname="DoPutText"/> </PROPERTY>Explicitly specifying GET and PUT methods allows for custom read and write functions, and also allows the definition of read-only and write-only properties (by only specifying a GET and PUT method, respectively).
The <REGISTRATION> tag defines the information needed to identify the COM object defined by the scriptlet. The CLSID is used instead of the file name to identify the component (e.g., in referring to it from other files). The association between the component and the file name is stored in the Windows Registry during the registration process.
Part of the implementation of scriptlets is a DLL called scrobj.dll. This is a runtime engine that interprets and executes the XML code of the scriptlet. It also acts as a broker between clients and the scriptlets. A module in the DLL provides a default implementation for the standard COM server interfaces IUnknown, IClassFactory, and IDispatch. The DLL also handles registration and dynamic instantiation.
An application uses the object's ProgID to identify the object. The ProgID is matched to a Registry entry that stores the path both to scrobj.dll and the .sct file that defines the component. Each time the client calls one of the component's exposed methods, scrobj.dll loads the proper script from the linked .sct file. A scriptlet can be inserted in an HTML page by referencing it like an ActiveX control, and invoking its methods from JavaScript.
IE5.0 also defines a mechanism called DHTML Behaviors which allows scriptlets to be associated as behaviors with specific document elements using CSS stylesheets (see Section 3.2.2.2). Scriptlets used to implement DHTML behaviors do not require registration to be used within Web pages (they are downloaded as needed). By adding a behavior handler (by specifying <IMPLEMENTS TYPE="Behavior">), such scriptlets can also expose custom events to the page, access the containing page's DHTML (DOM) objects, and receive event notifications.
Multiple scripting languages can be used for a single scriptlet's methods (a separate <SCRIPT> element is required for each language); the runtime module calls the appropriate script language interpreters as necessary.
Advantages cited for scriptlets are:
With the appropriate interpreters, this same general approach could also be used to directly construct objects in other object models, such as CORBA IDL (Section 3.1.3.1 also noted how what are effectively JSB or JavaScript "wrapper" objects could also be used to support CORBA objects). A further generalization of this approach could also support objects implemented using more general XML structures than the relatively simple ones allowed in JSBs and Scriptlets.
There are two general types of entities:
<!ENTITY xml "Extensible Markup Language">Given this definition, a reference to it of the form &xml; can be included anywhere in attribute values or mixed content. When it is processed, the reference will be expanded to the full text "Extensible Markup Language".
Here, our interest is primarily in general external entities. For example, the following entity declaration (from [Meg98]) defines an external entity containing the text of a document:
<!ENTITY chapter1 PUBLIC "-//megginson//TEXT Chapter 1//EN" "chap01.xml">This example illustrates the two ways XML provides for associating the entity name chapter1 with the physical objects that store the entity text: public identifiers and system identifiers. A system identifier in XML is a URI which may be used to retrieve the entity. A public identifier is a logical name (formally defined in ISO 8879, the SGML standard), and is intended to be resolved by looking it up in a catalog to find a corresponding URI. The SGML/Open consortium has defined standard syntax for catalogs to be used in this translation from public identifiers to system identifiers. An informal proposal for XCatalogs <http://www.ccil.org/~cowan/XML/XCatalog.html>, a corresponding specification for use with XML, has been discussed on the xml-dev email list. In the example above, the entity declaration specifies both a public identifier -//megginson//TEXT Chapter 1//EN and a system identifier chap01.xml (when a system identifier is specified by itself, it is preceded by the keyword SYSTEM; when both a system identifier and a public identifier are specified, the public identifier comes first, preceded by PUBLIC, and the system identifier follows, not preceded by SYSTEM).
The entities defined above are examples of parsed entities. The XML processor will attempt to parse the contents of the entity at the point where the entity reference appears in the document text. XML also provides a means to declare general unparsed (non-XML) entities, by specifying the entity as NDATA, and referencing a separate NOTATION declaration, as in the following example from [Bry97]:
<!ENTITY fig1 SYSTEM "fig1.eps" NDATA postscript >
where postscript is defined by:
<!NOTATION postscript SYSTEM "eps.bat" >
The NOTATION declaration is used to assign a unique name to the notation, language, or format of the external entity (postscript in this example).
In this case, the system identifier eps.bat is intended to identify a file to be activated to process the non-XML data (this invocation, and the return to the XML parser, happens in a system-defined way). [DeR97], in discussing the use of this convention in SGML, notes that many creators of DTDs believe that the external identifier in a NOTATION declaration should point to a program that can interpret the notation. Many software products for processing SGML support this by calling the specified program when an entity in the given NOTATION is to be presented. However, in principle, the intention is that the pointer should identify a specification of the notation (e.g., its documentation). [DeR97] notes: "There is a sense in which any program that (perfectly) implements a processor for some notation can be thought of as a "definition" for that notation, but that is quite a broad sense, and not in harmony with the examples SGML gives." A convention for providing both pieces of information is to specify a public identifier that points to the specification, and a system identifier that points to a local processor for it. In the Web, the need for this distinction is partially blurred, since providing a complete URL for the system identifier potentially allows the resource to be accessible from anywhere in the Web, hence making the system identifier more portable. However, the use of a public identifier would support the use of alternative sources for the same processor, as well as handle the problem of the processor changing its location (other mechanisms, such as URNs, would also solve this problem).
The general mechanism provided by XML external entities and notations can potentially be used in a number of ways in supporting object construction in the Web, since GIF, Java, JavaScript, etc. are all potentially examples of "notations" that could be used in XML documents. For example, a GIF image could be included by defining a notation and entity such as:
<!NOTATION GIF89a PUBLIC "-//CompuServe//NOTATION Graphics Interchange Format 89a//EN"> [...] <!ENTITY fig3 SYSTEM "figure3.gif" NDATA GIF89a >The same approach could be used to define an entity using any other binary notation (including a user-defined notation).
It is important to note that there is a difference between external entities that are declared in a document, and separate documents that may be referenced from that same document (using, e.g., XML's linking facilities), even though both may be identified by URLs. Unlike separate documents, external entities are intended to be parts of the document in which they are referenced, and a validating XML parser will process these entities in determining whether the document has a valid structure. This difference can be significant when delivering XML documents containing external entities to clients which use non-validating XML parsers. A non-validating parser is not required to process external entities (which are declared in the DTD), and hence the client may miss some of the document's content if the client's parser does not process them. A number of suggestions have been made for dealing with this problem, including:
An important use of notations in the context of constructing objects would be the incorporation of scripts into XML documents. One approach to doing this would be to define each script as an external entity having a NOTATION of whatever its scripting language was, e.g., JavaScript, as in:
<!NOTATION JavaScript PUBLIC "+//IDN netscape.com//NOTATION Java Script//EN" >This NOTATION definition associates the local name JavaScript to the formal specification identified by the public identifier. As noted above, a SYSTEM identifier could also specify a processing engine (interpreter) to process the script data.
Another approach to doing this, which more closely resembles the way scripts are contained in current HTML documents, was described in a posting to the xml-dev email list by W. Eliot Kimber, using the following example:
<?XML version="1.0"?> <!DOCTYPE MyDoc [ <!NOTATION JavaScript PUBLIC "+//IDN netscape.com//NOTATION Java Script//EN" > <!-- Script element contains JavaScript code: --> <!ELEMENT Script (#PCDATA)> <!ATTLIST Script notation NOTATION (JavaScript) JavaScript> ... ]> <MyDoc> <Script>This is a JavaScript script</Script> </MyDoc>This approach uses script elements rather than entities. Again, the NOTATION definition associates the local name JavaScript to the formal specification identified by the public identifier. A Script element is then defined to contain the actual scripts. An attribute notation is defined for this element to hold the name of the notation which identifies the specific scripting language used (JavaScript is the only possible value specified in this case). Script elements can then be included in the document to hold whatever scripts are needed (in the example, JavaScript is also defined as the default notation, so that it does not explicitly appear in the example Script element).
By analogy with the way many SGML processors deal with notations, the idea is that when the document is processed, the XML processing application sees that the Script elements are defined as having the JavaScript notation, and knows that the named notation governs the interpretation of these elements. The processor would look up the notation information, extract its external identifier, use it to find the processing program for that notation (a dll, plug in, JavaBean, or other executable; the script interpreter in this case), and pass the element to it. The notation processor would then do its processing, returning whatever the interface between the XML processor and the notation processor requires or allows.
Kimber notes that this approach is essentially what is done in Web browsers to process objects with different MIME types. The only difference is that notation types are not pre-defined or necessarily registered anywhere, but are instead defined in XML documents. A similar approach could be used to associate individual (object) methods with specific elements, provided system identifiers could be specified to point to the programs implementing the methods, and the interfaces between the XML processor and the methods were appropriately defined.
Taking full advantage of this approach in creating objects in the Web would require some additional support. For example, XML processors would have to be implemented so as to support this capability. In addition, XML does not currently require that a notation declaration actually reference a processor. While this is a convention in many SGML applications, it is not required there either. Standard syntax is required to associate an external processor with a specific element. This could be done either by expanding the semantics of notations, or by alternative syntax to explicitly deal with this requirement. This would allow arbitrary processing to be associated with various elements, rather than simply hardwiring support for specific notations into the XML processor (along the lines of HTML browsers' support for GIF). One model for this would be to use XML syntax to express the sort of information used in HTML browsers to assign plug ins or helper applications to specific MIME types. Ideally, this information would be considered a form of metadata, rather than as part of the document content itself.
Another requirement is for well-defined interfaces between element processors and XML processors, and between element processors and the elements passed them. These could be defined along the lines of plug in interfaces, possibly using a DOM-based approach for the element interfaces. In addition, it would be desirable for the XML processor (browser) to cache processing programs, rather than always following a URI specified in the metadata. The processor would only retrieve the processor for the specified element if it did not find a local processor for the element.
XSL is based on concepts similar to those defined in the ISO standard Document Style Semantics and Specification Language (DSSSL) [ISO96] used in formatting SGML documents. Following DSSSL, in XSL the conceptual model of formatting an XML document is that of transforming an input tree structure into an output tree structure. The input tree structure is, roughly speaking, the hierarchical element structure of the XML document produced by parsing (in DSSSL this structure is called a grove, which stands for Graphical Representation Of property ValuEs; the DOM defines a similar element structure, and the WD defines a similar conceptual model). Hence, roughly speaking, each node represents an element in the input document, and its properties.
As defined in the WD, the stylesheet defines the formatting of a document through a set of template rules (DSSSL and the submission call them construction rules), which specify how the input tree (element) structure of the document is to be converted to a result tree. XSL can be used for both generalized document transformation, and for formatting. When XSL is used purely for structural transformation, the result tree consists of the same types of nodes as were contained in the original tree. However, these may be filtered and reordered, and additional structure may be added. When XSL is used for formatting, the rules are used to specify a transformation from the input tree to a result tree of special formatting objects (DSSSL and the submission call them flow objects; the WD includes both flow objects and some additional kinds of formatting objects). A formatting object has a class, which represents a kind of formatting task, together with a set of named characteristics, which further specify the formatting to be performed. The XSL WD includes definitions of a standard set of formatting object classes (a subset of those defined by DSSSL), instances of which are used to construct the formatting object tree. These formatting objects are expressed using a formatting vocabulary of special XML tags defined in the WD. In other words, formatting is performed by transforming the original XML structure into another XML structure which uses tags that have predefined formatting semantics. Once the formatting object tree is created, the final formatted output (e.g., the display in a Web browser) is produced by processing the tree of formatting objects, and performing the specified formatting tasks (a task performed, e.g., by a Web browser's "rendering engine"). A conforming XSL processor is required to understand the formatting vocabulary and semantics defined in the WD, and implement those formatting semantics.
A template rule contains a pattern, which identifies specific elements in the source document to which specific formatting is to be applied, and a template, which defines a resulting subtree in the result tree. These rules somewhat resemble the situation-action rules used in rule-based expert systems. The stylesheet processor recursively processes source elements to produce a complete result tree. An example of a simple XSL stylesheet (from the WD) is:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" xmlns:fo="http://www.w3.org/TR/WD-xsl/FO" result-ns="fo"> <xsl:template match="/"> <fo:page-sequence font-family="serif"> <xsl:process-children/> </fo:page-sequence> </xsl:template> <xsl:template match="para"> <fo:block font-size="10pt" space-before="12pt"> <xsl:process-children/> </fo:block> </xsl:template> </xsl:stylesheet>XSL uses XML namespaces <http://www.w3.org/TR/WD-xml-names> to distinguish elements that are instructions to the XSL processor (prefix xsl:) from elements that specify literal result tree structure (prefix fo:). An XML stylesheet contains an xsl:stylesheet document element. This element contains xsl:template elements that specify template rules. The above stylesheet constructs a result tree for a sequence of para elements. The result-ns="fo" attribute indicates that a tree using formatting objects is being constructed. The rule for the root node specifies the use of a page sequence formatted with any font using serifs. The para elements become block formatting objects which are set in 10 point type with a 12 point space before each block (see the WD for further description of the details of stylesheet specification).
The original submission allowed XSL stylesheets to support scripting using ECMAScript. It is likely that some such capability will ultimately be supported in later versions of the WD as well. Stylesheet scripting is supported by some current Web browsers, and DSSSL provides somewhat similar capabilities using a dialect of the Scheme programming language. A future level of the DOM is intended to define a stylesheet object model, and define functionality for manipulating the style information associated with a document, which would make the stylesheet accessible to a scripting language. These scripts could serve a number of different purposes. For example, within a template (an action, using the terminology of the submission), an eval statement containing an ECMAScript expression could be used to compute generated text (e.g., section numbers) during stylesheet processing. In addition, scripts (and other behavioral elements such as <OBJECT> elements) could be specified that are to be inserted into the document, for execution by the browser at run time.
XSL also intends to support an extensibility mechanism. The WD does not provide any details about this mechanism, but the original submission indicated that this mechanism could, e.g., allow the specification of new flow object classes and their characteristics, by defining:
<?xml:stylesheet href="mystyle.xsl" type="text/xsl"?>
where the type specifies a stylesheet language (xsl, css), and href is a system identifier such as a file name or URL. Multiple processing instructions can be used to associate multiple stylesheets with a given document in this approach. However, alternative linking mechanisms are also possible, so this mechanism may not be the one ultimately adopted by the W3C. For example, as discussed in [Man98], it would also be possible to use the various PICS/RDF mechanisms, defined for associating ratings and other metadata with Web content, to link stylesheets with documents.
The general model of XSL stylesheet processing is that an XML page is combined with additional associated information (style information in this case) by a specific processor (a "rendering engine" in this case) that uses the additional information to do something with the XML (in this case, producing a display), where this "something" can involve adding behavior. Consideration has frequently been given to generalizing this model to handle additional types of processing. Two ways of generalizing this model can be thought of as either (a) generalizing the "rendering" itself (the process that is applied), or (b) generalizing what the "rendering" produces. These types of generalization are discussed in the next two sections.
<xsl>
<rule>
<root/>
<HTML>
<HEAD>
<SCRIPT LANGUAGE="JSCRIPT"><![CDATA{
function hiLite(e) {
if (e.style.backgroundColor != 'yellow')
e.style.backgroundColor = 'yellow';
else e.style.backgroundColor = 'white';
} ]]></SCRIPT>
</HEAD>
<BODY>
<children/>
</BODY>
</HTML>
</rule>
<rule>
<target-element type="item"/>
<DIV id='=tagName + formatNumber(childNumber(this),"1")'
background-color="yellow"
onClick='="hiLite("+ tagName + formatNumber(childNumber(this),"1")+")"'>
<children/>
</DIV>
</rule>
</xsl>
This effectively defines a mechanism for associating behavior with XML
pages (and specific elements in pages) by using the stylesheet as a repository
of object behavior, and dynamically associating it with specific parts
of the pages during stylesheet processing. The stylesheet acts as a form
of object "class", since the same stylesheet can be associated with multiple
pages. This approach involves the use of HTML as an intermediate output
format, and so is not "pure XML", but the generation of intermediate HTML
may be a common scenario in commercial Web browsers for some time.
Behavior to be included as part of the output document content could also be implemented using languages other than ECMAScript, and techniques other than scripting. For example, such behavior could also be specified by defining stylesheet rules that cause links to, e.g., Java objects (corresponding to HTML <OBJECT> elements), scriptlets, etc. to be included in the output page. Use of these techniques in "pure XML" requires an XML-native target representation for scripts or other behavioral components (e.g., the use of external entities with appropriate NOTATION specifications, as described in Section 3.2.1), together with appropriate processors for XML containing those behavioral components.
A recent Netscape submission to W3C takes this general approach further by specifying the concept of Action Sheets <http://www.w3.org/TR/NOTE-AS>. The submission notes that many current Web pages look more like full-fledged software programs than declarative specifications of document structure, due to the fact that an increasing fraction of the content of these pages consists of blocks of script, most of which run in response to user events. Action sheets attempt to provide a mechanism for consolidating the script-encoded behavior of document elements in a reusable package, separate from the structural definition of a document. The concept is particularly useful for XML since, as noted above, while HTML currently contains a SCRIPT element, and HTML elements may contain attributes that specify event handlers (onClick, onMouseOver, etc.), XML currently mandates no specific way of integrating an external scripting language. In the same way that external stylesheet rules can associate presentation properties with specific XML elements, external action sheet rules can associate arbitrary event handlers with specific XML elements or classes of elements.
An action sheet contains a set of productions (rules) somewhat similar in form to XSL template (formatting) rules. Simplifying somewhat, a rule contains a selector (pattern) which defines the document elements to which the rule applies, and an action, which specifies the script to be run for a given action (e.g., event such as onClick). Action sheets would be associated with XML documents in the same way as stylesheets.
While action sheets are conceptually similar to stylesheets, there are also important differences:
Due to the similarity between stylesheets and action sheets, there is some question as to when authors would use stylesheets and when they would use action sheets. This question will be investigated within the W3C groups working on stylesheet capabilities.
Microsoft has also defined a related technology in Internet Explorer 5.0 called DHTML Behaviors <http://www.microsoft.com/sitebuilder/magazine/ie5behave.asp>. This allows a scriptlet (see Section 3.1.4.2) to be associated with a particular document element using a Cascading Stylesheets (CSS) stylesheet, to provide default behavior for that element. Microsoft has indicated that this technology is being submitted to the W3C. This technology could be extended for use with XSL as well as CSS, since the W3C has indicated an intent to coordinate CSS and XSL properties and objects, with the goal of defining a common underlying formatting model.
For this purpose, the XSL would define the overall transformation between the input XML and the result objects, while the combination of the XML and the result object classes would contain the information to be used in the construction (the state and behavior). The construction mechanism could be entirely declarative, using XSL construction rules, or the construction could be augmented by behavioral specifications in the form of scripts and/or result object methods to perform additional construction activities. "Rendering" in this case could be simply the instantiation of the result objects themselves, together with the provision of an API so they could be accessed at run time. A browser could serve as the "host" for these result objects, and provide access to them via either DOM-based or application-specific object interfaces. Alternatively, specialized "rendering engines", referenced by the result objects (and made available to the browser, e.g., as plug-ins) could be invoked to do further processing on the result objects.
This approach is not unrealistic, since one possible form for an XSL processor would consist of a core which implements the tree transformations, together with a number of specialized backend processors for rendering the XSL-defined flow object classes to various media (e.g., one backend for rendering flow objects to a display, another for rendering flow objects to printers, etc.). All that would be required would be for such a processor to provide a way to augment the "flow object classes" it recognized, and the specialized backend processors it called to "render" them.
A step along these lines is a W3C submission from Hewlett-Packard describing Spice <http://www.w3.org/pub/WWW/TR/NOTE-spice>. Spice is a combination of ideas from DSSSL, CSS, and JavaScript. Spice is an extended version of ECMAScript, designed to make it simple to apply style and behavior to XML documents (it can also be applied to HTML). Spice supports cascading style rules using the same syntax as CSS. These rules name the flow object class to be used to format each element. However, Spice supports not only the predefined set of CSS flow objects, but also downloadable sets of extended flow objects which can be written in Spice itself, or in Java or ActiveX. These flow objects can exploit the full capabilities of the Document Object Model in processing the document content. To further control behavior, event handlers can be written to script flow objects. This allows the document to be dynamically altered after it has been loaded. (Spice differs from XSL primarily in using CSS syntax for style rules and properties.) The W3C Spice submission indicates that HP is developing a Spice compiler as a plug-in.
Further along these lines, discussion on the xml-dev email list has mentioned the idea of a general mechanism for declaring which flow objects a given stylesheet is using, and where to acquire a "rendering engine" (processor) for those objects. Specific industry groups or vendors could then define specialized sets of flow objects, and rendering engines for them, which could be used as the basis for complex applications. In this approach, for example:
These technologies represent another point on the spectrum of techniques for associating behavior with the elements in XML documents, based on element semantics. The simple end is for a separate application to use the XML document as input, and to perform appropriate actions based on the element tags. What might be thought of as a "mid point" in the spectrum is the W3C Document Object Model, which involves the generation of a collection of objects of generic types, with generic behaviors, based on the contents of an XML document. What we are discussing here (and what was discussed in Section 3.2.2.3) are techniques for creating, from an XML document, one or more objects whose types are based on the specific element types contained in the XML document. This can be thought of as specializing the DOM to produce application-specific objects (as discussed in [Man98]). However, creating these specialized objects need not necessarily involve actually generating the DOM objects first, and creating the application-specific objects from them. Instead, the specialized objects could be created directly based on the XML elements.
These ideas can be illustrated by the example of an XML document which represents a poem. The collection of DOM objects representing this document would have roughly the following structure:
document |-> Element |-> Element |-> Element | |-> Element | |-> Element |-> Element | |-> Element |-> Element |-> Element |-> Element |-> ElementThe Element entries are generic DOM objects, all of which have the same behavior (although they would each have distinct state, in particular, it would be possible to determine the distinct element type (the tag) of each element.
What we would like to have instead is an object structure where the object types are based on the specific element types in the XML document, and where the resulting objects contain type-specific behavior corresponding to those element types. In this case, the resulting structure might be:
poem |-> |-> front |-> title | |-> author | |-> revision-history |-> item | |-> body |-> stanza |-> stanza |-> stanza |-> stanzawhere poem, front, body, title, author, revision-history, and stanza are classes with type-specific behavior. Note that, in this case, the type-specific (poem) structure is in (roughly) one-to-one correspondence with the original XML element structure above. However, in general this need not be the case.
The section heading refers to "object serialization" because these techniques can be considered as ways to use XML as a representation for serialized objects (and object serialization is sometimes cited as one of the motivations for these techniques). In the case of OOXML, the analogy with "object serialization" is very straightforward: the XML constitutes the direct representation of the object, including elements that contain the object's state, and other elements that contain the object's methods. A method interpreter interprets the method code, which refers to the elements containing state when access to state is necessary.
In the case of MONDO and Coins, the XML acts as a sort of serialized representation for information that allows programming language objects to be constructed from it, using an XML parser together with one or more other components (e.g., a "builder", or "constructor" of some kind). However, "object serialization" is just one way of viewing these latter approaches. They can also be considered as alternative implementations of the generalized "rendering" process discussed in the Section 3.2.2.3, in that they start with a document as a "web" of connected state and code, and build objects based on that information. This is also a form of "compilation", in that the process does not interpret the XML as objects directly, but rather builds objects in a different form that are then interpreted by a separate interpreter (whatever can interpret the resulting objects, e.g., the Java Virtual Machine, or the native hardware).