[PEAK] XML Configuration and Serialization

[Ulrich Eck]

> Unlike ZConfig, however, we won't use a separate schema.  Instead, we'll 
> use PEAK's existing configuration system.  I figure it'll look something 
> like this:
> 
> [XML Elements for http://peak.telecommunity.com/example_namespace]
> foo = "somepackage.someclass"
> bar = "somepackage.anotherclass"
> * = "somepackage.function_that_raises_an_error"
> 
> So, this simple schema allows 'foo' and 'bar' elements at its top 
> level.  As with DOMlets, configuration lookup takes place relative to the 
> containing XML element, so this means that 'foo' and 'bar' could define 
> their own "XML Elements for <namespace>" that defined other elements 
> available inside a foo or bar element.

looks good, i have written some DataManager that use the 
same idea (map element-name -> <metamodel>.<class/feature-name> 
directly. this would reduce the needed work for the parser to
just writing the elements that handle the data + config - nice.

is the result a tree of model.Elements or binding.Components ?

if you plan to process streams, there need to exist serialization and
deserialization (that would mean, component/element-trees could be
saved to a string/file as well) or do you plan do it like this:
xmlin -> IDOMletNode(object-from-xml).render -> xmlout ?

do you plan to be able to process arbitary xml-data/streams,
or only ones that match a curtain scheme ?

to implement context-dependent behaviour (e.g. handle
element/attribute-nodes differently because they have a 
different meaning in this context),
i provide configuration within the parent component
for the namespaces used by these nodes that alter the "handler"
and therefore what happens .. right?

[snip details]

> These changes may have some impact on custom DOMlets, although I'll try to 
> keep it to a minimum by ensuring that created DOMlets end up with the same 
> attributes as before, even though different classes will be doing the work 
> of setting them up.

/me has only worked out a few domlets for prototyping .. i don't care
rewriting there in favour to e.g. the generator-based interface we
discussed.

cheers Ulrich