- From: David Megginson <ak117@freenet.carleton.ca>
- Date: Mon, 4 May 1998 14:46:38 -0400
- To: www-dom@w3.org
Vidur Apparao writes: > A couple of responses: > 1) The purpose of a standardized DOM is to have a common and > consistent way to access and modify XML documents. This allows a > developer to create scripts or programs that operate on arbitrary > documents, irrespective of their specific tag set. In the same way > that XML might not be the most compact way to represent data (one > can, for example, think of a slightly more efficient representation > for the record you have below), the DOM might not be the most > optimal way to operate on it. > > 2) The DOM specifies a set of *interfaces* to modify a > document. The implementor of the document engine is expected to > provide implementations of these interfaces on demand. This does > not mean, however, that the internal representation of a document > must immediately contain concrete implementations of the DOM > interfaces. In some cases, the DOM interfaces may be implemented by > objects that already exist in the internal representation. In other > cases, objects may need to be constructed on-the-fly specifically > for the DOM. You are absolutely correct -- there is no reason not to provide a DOM interface on top of some other object structure, and in fact, I expect that such an approach will be quite common (though a read-write interface could be surprisingly tricky to implement, depending on how closely the XML view and the internal storage are aligned). I think that the last sentence of your first point is very important, however: it is one thing to expose a DOM view of an object structure so that general scripting tools can work with it; it is quite another to do primary processing (say, rendering a large PGML graphic) through a DOM interface. All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com http://home.sprynet.com/sprynet/dmeggins/
Received on Monday, 4 May 1998 14:47:39 UTC