On 8/9/07, whit <[EMAIL PROTECTED]> wrote: > +1 (to elementree and to the use of lxml in plugins) > > I would encourage introducing no new dependencies outside of what can be > isolated inside a plugin (dunno if john's changes fall into that category) > and disable any related tests if the dependency is unavailable. Special > dependency code also should not hide the fallback implementation from tests; > a conditional import rendered the standard sparql xmlwriter and it's > brokeness hidden from those with Ft installed for a quite awhile on trunk.
FYI: The brokeness of the 'standard' sparql xmlwriter had all to do with the poor capability of native Python SAX writing - which couldn't even handle namespaces properly! I was also unable to use RDFLib's XMLWriter for that purpose as well - for reasons similar to John's. I have been working with an updated version of a harness for the (new) W3C DAWG tests for SPARQL but have not checked it in (and probably won't) mostly because it required additional XML processing I was simply unable to perform with 'native' Python: comparing SPARQL results against expected test results, for instance. In addition, I also needed Ft.Lib.Uri to do 'proper' RFC-compliant resolution of URIs (for which the 'native' capabilities of urllib/urllib2 are broken in many regards). URI resolution is a *major* component of SPARQL. I'm not so familiar with ElementTree or lxml (mostly because I've been spoiled by 4Suite for so long). A seperate question: a dependence on ElementTree bumps the overall dependency to Py2.5, is that where we want to be? If so, I would be curious to find out what aspects of XML processing can be done with lxml and which of those are crucial to RDF processing. _______________________________________________ Dev mailing list Dev@rdflib.net http://rdflib.net/mailman/listinfo/dev
