> However, I've been thinking about how to express XML data in python. > I was thinking about using lists to make a DOM like structure. There are > already DOM tools for python, but they use classes which I (and many of > the authors) think are too much overhead for a DOM tree. They've proposed > rewriting the module in C and as lists, too. If the current xml module is as slow as indicated in recent posts, we sure need a faster module, especially if loci uses the "everything is XML" data model. > The benefit is that individual node/tools/components/etc don't ever have > to worry about parsing XML and making up their own structures to hold > it. They always get these interfaces. This would be a big benefit. > Paos could also be modified to use a DOM->XML module rather than pickle > for storage (and even transport). Storage isn't a problem, but I think transport should definitely be in XML > Furthermore, it would make it simpler > (possible?) for non-python nodes to communicate in the system. Another big reason for doing transport in a standard format. > Additionally, we could move to a providing an interface over the network, > rather than transferring whole objects. DOM over CORBA, DOM over IP, etc. Like "fetch the exons from sequence M12345" and getting just the exons? Wouldn't this be much more complicated than just fetching a data object? Now we'll need a locid that not only can fetch and transport objects, but one that can understand their internal structure. Transport should just worry about getting the objects from one place to another, if you want something to chop up a data object, write an analysis locus that implements the feature, and returns the object to be transported: Local loci Remote loci ---------- ----------- I want to frob uid m12345 please send the exons gimme the exons from uid m12345 [exon extractor locus runs locally] here's the exons here's the frobbed sequence -- Humberto Ortiz Zuazaga Bioinformatics Specialist Institute of Neurobiology hortiz at neurobio.upr.clu.edu