xml-dev - Re: YAXPAPI and DOM

["Mark L. Fussell" <fussellm@alumni.caltech.edu>]

I am a bit confused by the recent statements about the "complexity of 
DOM" and the proposed simpler alternatives for an object model.  The DOM 
model seems as simple and direct as all the proposed alternatives.  I 
could see suggesting changes (I have myself) but it would seem these 
should be relative to the DOM as it is or have some significantly new 
features.  The core DOM 'content' information classes [with the read part 
of their interfaces[*1] ] are:

    public interface Node {
      public int /*NodeType*/ getNodeType();
      public Node     getParentNode();
      public NodeList getChildren();
    }

    public interface Element extends Node {
      public String   getTagName();
      public NodeList getAttributes();
    }

    public interface Attribute extends Node {
      public String   getName();
      public NodeList getValue();
      public boolean  isSpecified();
    };

    public interface Text extends Node {
      public String  getData();
      public boolean isIgnorableWhitespace();
    };

I can't see how you could get much simpler in the number of classes and 
the concept for each class[*2].  

So if we have the Grove model and the DOM, of what value is another 
similar, less-standard standard object model?  

--------

I can see a different problem though: it may be that no model will be 
useful to standardize for the actual interfaces.  Each application will 
want slightly different object models that have very small changes that 
are very significant to it.  Two examples I have in the above are both 
from the same type of problem: restricted Typing.  In the above 
interfaces I would much rather have NodeList->List [the JDK 1.2 interface 
for a general indexed collection] because I have many more 
implementations and functionality to use for manipulating lists than I do 
for NodeList [I could wrapper and delegate all the functionality but that 
is much more effort and less maintainable for no real benefit].  Likewise 
I would rather have Attribute's value be an Object or a String than a 
NodeList.  These minor changes make the DOM interfaces themselves 
impossible to use: I can have interfaces just like them but they will 
have to be my own version.  

   I suspect this may always be the case.  I have helped build many large 
and small information system models and none of them committed to using 
exactly somebody else's code for the DomainModel[*3].  Having control 
over the model of the information your application works with is crucial 
to both good design and good/maintainable implementations.  This isn't to 
say you can't use someone else's designs: that works excellently (e.g. 
Design Patterns and Analysis Patterns).  You can even start with someone 
else's code but you will almost certainly need to modify that model ever 
so slightly (or majorly) at some point.

    An approach that works better than defining an exact ObjectModel 
(i.e. exact Types) to implement is to think from outside the Model: to 
the client and supplier points of views.  From the outside people only 
care about limited interfaces and protocols that a DomainModel must 
support to work with them.  This is how Swing's TreeModel works (as long 
as you support the TreeModel interface you are worthy) and other 'M's in 
the MVC pattern.  This is also how Java Beans work, but with a runtime 
signature-binding approach.  In all these cases, the client/supplier 
requirements come first and you can decide if you want to work with them 
by suitably designing and implementing your DomainModel.

So I suspect all of the following are true: 
   (1) The DOM interfaces will be exactly suitable to some 
       applications
   (2) There are many applications that the DOM interfaces 
       (as exact code) will not be suitable 
   (3) The DOM model is a good design model and template for 
       a good number of these applications
   (4) It would be good to suggest possible modifications to the 
       DOM to either make it better or as possible alternatives 
       for people in situation (2)
   (5) There are many good reasons to start defining the possible 
       clients and services that (Document) DomainModels may want 
       to use. [*4]
   (6) There is no reason to have a similar model to the DOM 
       and make it a semi-standard
   (7) Frequently (2) will turn to using (3), (4), and (5) to make a 
       suitable model, so these will be very valuable.

So it would seem good to focus on all of (1)-(5) in the above but not on 
(6) except as it helps to understand the others[*5].

--Mark
mark.fussell@chimu.com


[1] I made a couple minor stylistic/convention changes (e.g 'is' for 
booleans) to these interfaces.

[2] I coded a skeleton implementation (able to construct, inspect, and 
print objects) of the level-1 DOM model (i.e. including the DocumentType 
classes) in a part of an evening and offered to provide it as source in a 
previous email.

[3] Except, for a while, when the model can be extended without changing 
the source (a Smalltalk/ENVY feature).

[4] As an example of (5) in DOM, the DOM interfaces are generally Java 
Bean compatible.  This is very useful in Java: the MONDO DOM 
ObjectBuilder had exactly one line of code to specify how to take a 
recipe for a (for example) ModelGroup and build a ModelGroup object:
        addBeanFactoryFor_toBuilder(ModelGroupClass.class,builder);

[5] In the above I am not referring to an event oriented API, but will 
respond to that in a different email.



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