API thoughts...

[David Durand]

At 2:52 PM -0500 3/4/97, Peter Newcomb wrote:
>> From: dgd at cs.bu.edu (David Durand)
>>
>>     I see two main approaches to creating the data access methods:
1 specific node types for each construct
2 generic node types, with special methods to test type and values.

>>    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.

Your description of the tradeoffs confuses me. It seems that a set of
specific classes corresponding to node types is the _easy_ solution for a
programmer. You need a little dynamic typing in the content of elements,
but you can let virtual methods do most of the work for you. With generic
elements you need to test explicitly for everything.

I can see that the "one-type" model may make some kinds of transformation
engine (mainly ones that use the grove model already) and low level
operations like serialization easier, but actually it seems that most
applications _need_ to do something different for an attribute than an
element, most of the time.

The practical reason to have one type currently is just time on the wire
for applets (if there are going to _be_ XML applets). One thing to thing
about is what interface would be easier for an applet author to deal with.

I can see applets that do custom rendering based on the markup of a subtree
of the document, and can get their input pre-parsed (even validated by a
DTD, if they want to cut some error code out). What interface makes
implementing such an applet easiest?

  Anyhow, I don't yet have a very clear sense that the generic node
approach offers much more than a trimmed class tree. Am I missing something?

  -- David

_________________________________________
David Durand              dgd at cs.bu.edu  \  david at dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________



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