Well, I'd claim "best" is a judgement that should be specific
to some application domain. If the application is "element
oriented" (as many can be) this separation may be irrelevant.
> For this purpose [1st stage] it
> suffices to declare a relation between java packages and xml
> namespaces and to use introspection to map from element name
> to class. One would have standard java packages appropriate
> for and associated with standard elements.
Of course with this sort of solution you prevent many-to-one
mappings. Those can be convenient to work with. If one must
take well formed XML and emit an HTML vocabulary, the ability
to have one class handle all of HTML's empty-element printing
syntax (e.g. <BR> or <BR /> but never <BR/>) is a time saver,
certainly at the "encoding" level and possibly higher up too.
Many other solutions for this exist. For now, I'm assuming
a factory method createElement(uri,tag) that can have many
implementations, including the one james sketched above.
> The second (items 3 - 5 in the original note) is more complex.
Also, I'd claim, highly specific to the application structure.
I'd certainly agree that in the general case, XML will be
getting connected to some pre-existing application data which
calls for complex model transformations to become XML. And
that a good XML applications framework must enable that!
However, I'd define the goals of an XML Object Framework to
be focussed a bit more closely on what Peter called "Element
Oriented Computing" ... where, I think, the assumption can
be made that least some elements are the natural focus of
an application.
- Dave