Paul Everitt wrote:

Stefan Behnel wrote: BTW, anybody interested in having an lxml channel on Freenode? Or, is there already one?

There is one, it's called #lxml

...

I already implemented something called an XPathModel, subclassing ElementBase, that is basically a meta-model based on XPath. You write XPath expressions into the class body and they are transformed into attributes and access/modifier methods at class creation time. I also have an autoconstructor, that creates children at first attribute access. So, all you'd have to do for the above, is to make honkstyles a property and create the necessary children on access.

I'm going to read and re-read that a couple of times. :^)

Any chance I can get a look at what you did?

It's part of a project called 'slow' that will be on Berlios 'soon'. I just didn't have the time to upload the code yet.

I'm working with Berkeley DB XML (BDB XML) and Python on some stuff. Over the years, I've been interested in a pattern where I can do executable prototypes in a very productive way. Namely, I sit in a nice XML tool (like oXygen), whip up some mock XML, some mock XSLT, and iterate until I have what I like. I would like to then drop that into a "system" that pulls in data from a database, but keeps the productivity of the mockup stuff.

As such, I'd really be interested in not having a hard requirement on lxml, nor even extension functions, for the part that pulls in sample data. Instead, I'd like to simply have <model> or <db> in an XML file, with some dummy data underneath, and the <model> element is dynamically generated when evaluated in my system.

If this publishing pipeline requires lxml or extensions, I can't do the rapid prototyping with other tools.

I originally hoped to tackle this with custom resolvers. But those aren't available yet.

Next, I planned to have the input document generated from Python in the pipeline, vs. read statically from disk during prototyping. This, though, would mean that changing your mind about the input document contents would mean changing Python code. (Not too bad, but not very declarative either.) It would also mean grabbing all the nodes that might possibly be needed, instead of only getting the ones you traverse.

Finally, I hoped to have XSLT extension functions where you pass in the XQuery and get back node sets.

Along comes your element binding work, and gives me yet another way to look at it. :^)

At the end of the day, my central goal is to increase productivity by allowing XML studios to help. My second goal is to find clear, but extensible, ways to pull in foreign data on-demand.

See my other mail on a way how I think this could be done.

Stefan