Web designers use markup languages to create and modify web sites. A document object model (DOM) is created by a viewer when accessing an extensible markup language (XML) based file. It is often desirable to manipulate the DOM.
One way to manipulate a DOM is to use scripting. However, many web designers do not have the programming skills required for DOM manipulation via scripting. Thus, programmers are needed to create the scripts for the designer. Programmers can be costly, plus it can take a long time to develop stable, fast code. Thus, it is desirable to have a system or method of manipulating a DOM that a designer with minimal programming knowledge may operate, and which could also aid even an experienced programmer to rapidly develop a web application.
One way of assisting designers and developers is to have pre-canned scripts for the most commonly required functionality. However, script is difficult to auto-generate. Supporting the insertion of pre-canned scripts via an integrated development environment (IDE) is both complicated and limiting. For example, the Microsoft (TM) Visual Studio IDE can create auto-generated code for its Microsoft Foundation Classes (MFC) (which abstract the programmer from the core Win32 API's), making it easier and quicker to program Windows applications. However, limits must be imposed on the user. User-modification of the auto-generated code is discouraged, because it makes it difficult to regenerate the code from the project file, or to automatically modify the pre-generated code as a result of new user-defined parameters to the abstractions. Auto-generated script cannot easily be customized afterwards, unless the IDE absolves itself of all responsibility should the designer make modifications.
Software exists that allows one to map input XML markup to output markup, automatically generating extensible stylesheet language transformation XSLT (the most commonly used XML markup language for transforming XML markup to a different form of markup). However, script is difficult to data-map.
Script relies on full DOM support. Scripts are only as powerful as the DOM methods that the viewer supports. Although it is desirable to have all viewers support the entire spectrum of DOM methods, they currently do not. Thus one must write script that only uses the API's supported by all viewers, in order to ensure that the script works on all viewers (i.e., one must program towards the lowest common denominator).
Script is complex. Abstracting the DOM methods using dSVG markup has allowed for the creation of a more direct linkage between the syntax and the intent of the author. Take the example of a designer creating a new element dynamically in the DOM. The designer wishes to create a circle at a particular location in the DOM tree. To do it in script is quite complicated, requiring over a hundred lines of code. One must first use getElementById( ) to find the target element, and then either the parent or sibling element. One then uses createElement( ) to create the circle. If inserting beneath a parent, parent.appendchild( ) is used. If inserting before a sibling, sibling.insertBefore( ) is used. If inserting after a sibling sibling.nextSibling.insertBefore( ) is used, unless there is no nextSibling, in which case sibling.parentNode.appendChild( ) is used. The author may wish to insert it as, say, the fourth sibling from the top or bottom, requiring a loop to be written which counts the siblings and accounts for the fact that maybe there are not that many siblings. Or the author may wish the new element to be the parent of existing elements, which requires removal of those elements and appending them as the children of the new one. Then finally setAttribute( )is used to set its identifier (ID) so that you can refer to it later.
Script is slower than native code. Scripts are interpreted, and thus provide slower performance than what would be possible with a natively-implemented markup language. Just having a script interpreter is a lot of overhead for a small device.
Script must use DOM interfaces. Scripts can only manipulate the DOM via the DOM methods, which are abstractions on top of the real object model used by the viewer. Natively-implemented markup could access the real object model directly, which may improve performance even more.
Script requires more data to transfer. Scripts greatly add to the amount of data needed to be transferred. This is a problem especially for small devices.
Finally, scripts are only as powerful as the DOM API's that the viewer supports. Currently, not all viewers support the entire spectrum of DOM API's.
The Synchronized Multimedia Integration Language (SMIL) has a <set> element that allows one to set the attributes of an element within the current document to a specific, known value. However, this <set> element does not actually call the DOM's setAttribute( ) method. Thus it does not fire a mutation event (informing any listener function that the attribute has changed). Also, the <set> element does not actually result in changes to the “core DOM”, which represents the document, but rather it results in changes to the “animated DOM”, which stores animated values for each attribute which may be animated. Furthermore, there is no way to monitor changes to the animated DOM. Also, the <set> element cannot affect other elements in other documents, and cannot be easily linked to events and cannot reference attributes in other elements. So, while SMIL can result in visual animation, it cannot be used for full DOM manipulation. Only script can do that by accessing the DOM methods.