Base-Art

Gre7g Luterman: XMLObject_ [XMLObject is a Python module that simplifies the
handling of XML streams by converting the data into objects.]

#.   Jkx on Sat Oct 30 13:06:14 2004

That 's why, we should use a package naming a la java. I mean

from base-art.XMLObject import XMLObject

By this way, we can avoid this kind of troubles..

#.   Jkx on Sat Oct 30 13:06:49 2004

Ouch this CSS is space oriented ? grrr

#.   phil on Sat Oct 30 18:26:05 2004

Yeah this CSS is space oriented :) Anyway i thought about renamming XMLObject also .. but it would be a pain in the ass, really. Your solution is interesting and lazy-people-friendly :)

#.   DavidMertz on Sun Oct 31 04:27:15 2004

Aside from finding it a bit annoying how many new XML binding tools pop up for Python (seemingly every day), I think I merit tooting my own horn in pointing out that 'gnosis.xml.objectify' uses a very sensible package naming scheme.  Other tools in the Gnosis Utilities have other descriptive package paths, but it's all under 'gnosis.*'... which I presume no one else will bother using.

Uche Ogbuji has done something similarly sensible with his 4Suite stuff (ft.*).

In terms of the tool itself, I continue to believe that gnosis.xml.objectify does things in the most "Pythonic" fashion of all the binding tools.  And it still is near the best in speed and memory-friendliness.  Plus there's the fact mine came first!

This just seems like an area where the Python community is harmed by an endless proliferation of "not invented here" solutions, each new one adding nothing useful (and generally taking away much of what's useful in the earlier ones). 

Fred Lundh has done a lot of work on ElementTree; while I'm still a little vainly concerned that he did that, rather than just enhance gnosis.xml.objectify (which could well be done to add the things ElementTree does that gnosis.xml.objectify does not), ElementTree is quite high quality.

Most of the other bindings that roll out are just flash-in-the-pan partial solutions to the same problem, with nothing except slightly novel (and less intuitive) usage syntax to recommend them.

#.   phil on Sun Oct 31 12:24:11 2004

I haven't looked at gnosis utilities deeply. And i don't really care how much ElementTree is inpired from it. Many people believe it's the One Candidate for integration in the Standard Library. And there are probably good reasons for that.

May i place a word about the XML/Python wrapper i wrote. Its design is highly inspired from SQLObject, and there are good reasons for that. In future, if XMLObject gets mature enough, i'd like to make some kind of bridge between SQLObject and XMLObject. Thus it would allow transparent data storage in XML or/and in classic RDBMS supported by SQLObject ... I'm probably wrong this way but anyway i'd like to see what happens :)

#.   ianb on Tue Nov 2 19:13:53 2004

I think that the name gnosis.xml.objectify actually works against the project. People are usually reluctant to use libraries that are part of a single person's (or company's) larger library; there's greater dependency issues, there's funny conventions, and just a feeling that the library subsumes the application. This might not be the case -- but the name alone indicates that. Each name is meaningful, like a specialization of the name above it, and there's the implication that to understand gnosis.xml.objectify you have to understand gnosis.xml and gnosis.

At least, this is my impression from the various packages out there that put several libraries under one umbrella project.

#.   Tobias Brox on Fri Nov 12 23:57:01 2004

I think making some bridge between SQLObject and XMLObject may be a good idea.  I haven't looked into SQLObject, but I assume both holds typed information.  It's a pity we didn't peek into SQLObject when starting our project - I'm far from happy with our current framework for shuffling database information too and from XML.

One of the good things with XMLObject is the abstraction and transparency.  As for us, we use XMLObject to ferry information between two servers we've written over a common framework - but it's a requirement that we should be able to speak with third party software using XML.  We don't have to worry at all about the protocol - the XML part of it is handled completely by XMLObject.  For all we would know, the objects could be hand written on papyrus rolls and sent by a bicycle courier service between the servers - it's cleanly and completely detached from our work.

For internal communication between our own servers written in the same framework, it doesn't really matter what protocol is used - XML is pretty inefficient, so some few days ago I wrote some few lines of code, turning all communication to using the pickle protocol instead. Thanks to the transparency, it's a very easy thing to do.  Unfortunately, many of our unit tests were asserting the protocol language to be XML so I had to turn off that feature again ;-)