<?xml version="1.0" encoding="iso-8859-1"?>
<rdf:RDF xmlns="http://purl.org/rss/1.0/"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:content="http://purl.org/rss/1.0/modules/content/">

<channel rdf:about="http://base-art.net/Articles/22/">
<description>&lt;p&gt;Via DailyPython URL!&lt;/p&gt;
&lt;pre class="literal-block"&gt;
Gre7g Luterman: XMLObject_ [XMLObject is a Python module that simplifies the
handling of XML streams by converting the data into objects.]
&lt;/pre&gt;
&lt;p&gt;That's kind of fun and reminds me the story about Python ALSA wrappers. People do things in their corner. And the final lambda user get lost in the jungle of XXX softwares doing about the same work.&lt;/p&gt;
&lt;p&gt;And in this case, especially using &lt;strong&gt;the same name&lt;/strong&gt; for each project. So we have about three different XMLObject projects:&lt;/p&gt;
&lt;ul class="simple"&gt;
&lt;li&gt;&lt;a class="reference" href="http://zope.org/Wikis/zope-xml/XMLObject"&gt;Zope XMLObject&lt;/a&gt; .. for Zope,&lt;/li&gt;
&lt;li&gt;&lt;a class="reference" href="http://xmlobject.base-art.net"&gt;Base-Art XMLObject&lt;/a&gt;,&lt;/li&gt;
&lt;li&gt;Last but not least &lt;a class="reference" href="http://xmlobject.sf.net"&gt;Gre7g XMLObject&lt;/a&gt; ..&lt;/li&gt;
&lt;li&gt;Not to mention an XmlObject in Java :)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Are you confused ? Well i probably shouldn't have named my stuff like the Zoped one, i'm guilty here. Finally one more or one left, no difference.&lt;/p&gt;
&lt;p&gt;-- Reserve your XMLObject jungle map to your favorite receller :)&lt;/p&gt;
</description>
<link>http://base-art.net/Articles/22/</link>
<title>Comments on article "Don't you have your XMLObject yet ? oh sweet heart :("</title>



<items>
<rdf:seq>

<rdf:li rdf:resource="http://base-art.net/Comments/52/"/>

<rdf:li rdf:resource="http://base-art.net/Comments/46/"/>

<rdf:li rdf:resource="http://base-art.net/Comments/41/"/>

<rdf:li rdf:resource="http://base-art.net/Comments/40/"/>

<rdf:li rdf:resource="http://base-art.net/Comments/39/"/>

<rdf:li rdf:resource="http://base-art.net/Comments/37/"/>

<rdf:li rdf:resource="http://base-art.net/Comments/36/"/>

</rdf:seq>
</items>


</channel>


<item rdf:about="http://base-art.net/Comments/52/">
<dc:date>2004-11-12T23:57:01.000004+01:00</dc:date>
<title>Tobias Brox on Don't you have your XMLObject yet ? oh sweet heart :(</title>
<link>http://base-art.net/Comments/52/</link>
<author>Tobias Brox</author>
<description>
I think making some bridge between SQLObject and XMLObject may be a good idea.&amp;nbsp; I haven't looked into SQLObject, but I assume both holds typed information.&amp;nbsp; 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.&lt;br/&gt;&lt;br/&gt;One of the good things with XMLObject is the abstraction and transparency.&amp;nbsp; 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.&amp;nbsp; We don't have to worry at all about the protocol - the XML part of it is handled completely by XMLObject.&amp;nbsp; 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.&lt;br/&gt;&lt;br/&gt;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.&amp;nbsp; Unfortunately, many of our unit tests were asserting the protocol language to be XML so I had to turn off that feature again ;-)
</description>
</item>

<item rdf:about="http://base-art.net/Comments/46/">
<dc:date>2004-11-02T19:13:53.000001+01:00</dc:date>
<title>ianb on Don't you have your XMLObject yet ? oh sweet heart :(</title>
<link>http://base-art.net/Comments/46/</link>
<author>ianb</author>
<description>
&lt;p&gt;I think that the name &lt;tt class="literal"&gt;&lt;span class="pre"&gt;gnosis.xml.objectify&lt;/span&gt;&lt;/tt&gt; 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 &lt;tt class="literal"&gt;&lt;span class="pre"&gt;gnosis.xml.objectify&lt;/span&gt;&lt;/tt&gt; you have to understand &lt;tt class="literal"&gt;&lt;span class="pre"&gt;gnosis.xml&lt;/span&gt;&lt;/tt&gt; and &lt;tt class="literal"&gt;&lt;span class="pre"&gt;gnosis&lt;/span&gt;&lt;/tt&gt;.&lt;/p&gt;
&lt;p&gt;At least, this is my impression from the various packages out there that put several libraries under one umbrella project.&lt;/p&gt;

</description>
</item>

<item rdf:about="http://base-art.net/Comments/41/">
<dc:date>2004-10-31T12:24:11.000006+01:00</dc:date>
<title>phil on Don't you have your XMLObject yet ? oh sweet heart :(</title>
<link>http://base-art.net/Comments/41/</link>
<author>phil</author>
<description>
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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 :)&lt;/p&gt;

</description>
</item>

<item rdf:about="http://base-art.net/Comments/40/">
<dc:date>2004-10-31T04:27:15.000006+01:00</dc:date>
<title>DavidMertz on Don't you have your XMLObject yet ? oh sweet heart :(</title>
<link>http://base-art.net/Comments/40/</link>
<author>DavidMertz</author>
<description>
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.&amp;nbsp; 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.&lt;br/&gt;&lt;br/&gt;Uche Ogbuji has done something similarly sensible with his 4Suite stuff (ft.*).&lt;br/&gt;&lt;br/&gt;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.&amp;nbsp; And it still is near the best in speed and memory-friendliness.&amp;nbsp; Plus there's the fact mine came first!&lt;br/&gt;&lt;br/&gt;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).&amp;nbsp; &lt;br/&gt;&lt;br/&gt;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.&lt;br/&gt;&lt;br/&gt;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.
</description>
</item>

<item rdf:about="http://base-art.net/Comments/39/">
<dc:date>2004-10-30T18:26:05.000005+01:00</dc:date>
<title>phil on Don't you have your XMLObject yet ? oh sweet heart :(</title>
<link>http://base-art.net/Comments/39/</link>
<author>phil</author>
<description>
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 :)
</description>
</item>

<item rdf:about="http://base-art.net/Comments/37/">
<dc:date>2004-10-30T13:06:49.000005+01:00</dc:date>
<title>Jkx on Don't you have your XMLObject yet ? oh sweet heart :(</title>
<link>http://base-art.net/Comments/37/</link>
<author>Jkx</author>
<description>
Ouch this CSS is space oriented ? grrr
</description>
</item>

<item rdf:about="http://base-art.net/Comments/36/">
<dc:date>2004-10-30T13:06:14.000005+01:00</dc:date>
<title>Jkx on Don't you have your XMLObject yet ? oh sweet heart :(</title>
<link>http://base-art.net/Comments/36/</link>
<author>Jkx</author>
<description>
&lt;p&gt;That 's why, we should use a package naming a la java. I mean&lt;/p&gt;
&lt;pre class="literal-block"&gt;
from base-art.XMLObject import XMLObject
&lt;/pre&gt;
&lt;p&gt;By this way, we can avoid this kind of troubles..&lt;/p&gt;

</description>
</item>


</rdf:RDF>