I'm a little confused. Why the third abstraction from csv -> XML -> uc and not just csv -> uc?

I imagine it's to potentially make future imports of other "types" easier (write to one interface) but it kind of creates just as much work doesn't it (at least for the person that's going to have to import the data and covert each set of data (csv etc) to the uc xml spec == 2 conversions instead of one)?

i'm biased towards csv because that's what i'm going to use to import () and outside of it, i'm not sure how many different import methods actually are used in practice? If there aren't many other methods, that extra abstraction to xml might be wasted? csv is supported by php so it's a straight shot if someone builds out csv -> uc importer. And i could see people using it a lot and fairly easily. But maybe not

xml is valid i'm sure, i just haven't gone down the path yet so wondering why all the emphasis is being placed on it or what benefits it brings by using it? Maybe your importer magically insulates the coding of the actual cck fields and such that would have to be changed for every individual use of an import script.

if i had a second to breathe, i'd have finished an uc csv import script (not a module) by now but unfortunately i don't. .

imho, a standardized and documented import is THE thing that uc needs right now above all else. Otherwise store conversions can't take place. That means "most" uc implementations are "probably" going to be brand new store implementations or ideas. Or that others have written their own private import scripts to complete their stores.

thanks