W3C home > Mailing lists > Public > www-dom@w3.org > April to June 1998

Re: xxxML on top of, embedded in XML

From: Vidur Apparao <vidur@netscape.com>
Date: Mon, 04 May 1998 11:21:10 -0700
Message-ID: <354E0716.68B4B49D@netscape.com>
To: www-dom@w3.org
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.

--Vidur 


David Megginson wrote:
> More generally, though, imagine a document consisting of, say, 50
> million records like these (normally, the structure should be a little
> more robust):
> 
>   <contact>
>     <name>David Megginson</name>
>     <email>dmeggins@microstar.com</email>
>     <nationality>Canadian</nationality>
>     <date-of-birth>
>       <year>1964</year>
>       <month>November</month>
>       <day>18</day>
>     </date-of-birth>
>     <education>Ph.D. (University of Toronto)</education>
>   </contact>
> 
> It is fairly efficient to put these straight into a customised Contact
> object:
> 
>   public class Contact {
>     public String name;
>     public String email;
>     public int nationality; // assuming constants defined somewhere
>     public int birth-year;
>     public int birth-month;
>     public int birth-day;
>     public String education;
>   }
> 
> Building a DOM as an intermediate step would make little sense, since
> you would generate a painfully large number of nodes for each record
> (instead of just one Contact object with a couple of strings).
> 
> 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:21:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:45 GMT