OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: API thoughts...

[ Lists Home | Date Index | Thread Index ]
  • From: Peter Newcomb <peter@techno.com>
  • To: dgd@cs.bu.edu
  • Date: Tue, 4 Mar 1997 14:52:27 -0500

> Date: Tue, 4 Mar 1997 12:44:09 -0500
> From: dgd@cs.bu.edu (David Durand)
> 
>     I see two main approaches to creating the data access methods:
> 
>     1. to create a bunch of particular objects Element, Attribute, etc. and
> allow looking at them directly. This does make for a rather fat interface,
> and a lot of objects. In some contexts this is good (low object coupling),
> in others, bad (currently applets pay a high price for using many classes,
> and this will take at least a year to improve).
> 
>     2. Create a general node object that can represent an element or
> attribute or entity, etc, and use a general protocol to explicity test and
> act on node types, and to traverse. This is essentially the grove model, as
> I understand it.  The disadvantage is that it's not very concrete, and so
> it's harder to understand. You also lose the ability to use type-based
> dispatching if your programming style favors it -- you have to test the
> generic nodes yourself.
> 
>    Either of these models is good, but we need to examine the tradeoffs
> much more carefully and explicitly.

I think that it is important to define the data access API in such a
way as to facilitate the use of either or both models: If (1) is
implemented as a bunch of classes for element, attribute, etc., but
each of those is derived from a general node class as described in
(2), then the best of both worlds is available, since applications (or
language implementations) that cannot handle the overhead of (1) can
use just the generic node interface, and applications that can take
advantage of strong typing are not restricted to (2).  Also, since the
two schemes would be interoperable at the generic node level,
different modules of the same application can use either model without
regard for what model other modules use.

-peter

--
Peter Newcomb                           TechnoTeacher, Inc.
233 Spruce Avenue                       P.O. Box 23795
Rochester, NY 14611-4041 USA            Rochester, New York 14692-3795 USA
+1 716 464 8696 (home)                  +1 716 464 8696 (direct)
+1 716 755 8698 (cell)                  +1 716 271 0796 (main)
+1 716 529 4304 (fax)                   +1 716 271 0129 (fax)
peter@petes-house.rochester.ny.us       peter@techno.com
http://www.petes-house.rochester.ny.us  http://www.techno.com

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS