[PEAK] XML Configuration and Serialization

[Phillip J. Eby]

At 04:40 PM 6/1/04 +0200, Ulrich Eck wrote:
> > 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 ?

The result is whatever you're willing to program.  :)  However, I 
anticipate having some kind of wrapper that makes converting <foo 
bar="baz"> into a 'Foo(bar="baz")' component relatively trivial, at least 
if all the attributes are strings.


>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 ?

I'm really only thinking de-serialization at the moment.  This is more like 
ZConfig, but in XML instead of Apache-style configuration format.  And, 
instead of using a static schema that's interpreted, the schema is 
dynamically defined via configuration and Python code.


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

Arbitrary ones.  This is just a configuration mechanism to allow 
registration of handlers for different element types, as a 
broadening/generalization of how DOMlets get made from XML.  You should be 
able to use this to create components from any existing XML vocabulary such 
as XUL, XForms, RDF, or whatever strikes your fancy.

Of course, you still have to write the components themselves, and any 
handling/glue code they need to do what you want.  This just lets you write 
up an .ini file to specify who does what, and you can even combine in one 
document many separately-written vocabularies from however many XML namespaces.


>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?

Yes, just like DOMlets can.