>>>>>>>>>
That doesn't seem sufficient to me=2E 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=2E)
The model I'm working with right now does include a mapping of name
to class, but it's not direct (e=2Eg=2E can be many to one) and is aware
of namespaces=2E It can be statically configured (e=2Eg=2E an XML element
containing mappings -- embedded, or in a separate document) as well
as algorithmically configured (i=2Ee=2E a factory class)=2E
<<<<<<<<<<<<<
Its completely insufficient=2E But it is a base level at which things will=20
work=2E The package name can be ingnored as classes dont have to be in a=20
package=2E (bad idea - but allowed) or a default could be used=2E
The model I have working uses XML config files to specfiy the binding and=20
allows the specification of more powerful delegation structures than simply=
=20
inheriting from the w3c=2Enode=2E
I guess my point really comes back to having a variety of interfaces on the=
=20
domBuilder that allow for as much or as little binding configuration as=20
required=2E I think we need to pick up the XObjects discussion on the=20
domBuilder interfaces=2E If this sounds like a good idea I'll sift through=20=
the=20
contributions of interfaces / part interfaces and present those as a=20
starting point?
graham=2E
gdm@dpsl=2Eco=2Euk