Back to XObjects was XLink - where a

Graham Moore graham.moore at
Thu Nov 12 11:18:14 GMT 1998

 - Dave wrote


That doesn't seem sufficient to me.  What's the package name?  What
about classes that should represent multiple element types?  What about
the different semantics associated with different namespaces?  Suppose
you want the element and class names to be different, perhaps because
you and your users work with different natural languages?  (And I'll
confess to having deferred the homework to finding out exactly how
XML names and Java names differ!  I'd expect them not to be the same.)

The model I'm working with right now does include a mapping of name
to class, but it's not direct (e.g. can be many to one) and is aware
of namespaces.  It can be statically configured (e.g. an XML element
containing mappings -- embedded, or in a separate document) as well
as algorithmically configured (i.e. a factory class).


Its completely insufficient. But it is a base level at which things will 
work. The package name can be ingnored as classes dont have to be in a 
package. (bad idea - but allowed) or a default could be used.

The model I have working uses XML config files to specfiy the binding and 
allows the specification of more powerful delegation structures than simply 
inheriting from the w3c.node.

I guess my point really comes back to having a variety of interfaces on the 
domBuilder that allow for as much or as little binding configuration as 
required. I think we need to pick up the XObjects discussion on the 
domBuilder interfaces. If this sounds like a good idea I'll sift through the 
contributions of interfaces / part interfaces and present those as a 
starting point?


gdm at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list