My one problem with both of those is that neither generates what I consider to be "good" schemas. I assume this is intentional, since the tastypie code cites the "REST worst practices" blog entry, which mentions:

It’s really tempting to have each resource have a different representation (i.e. schema if using XML), but I think that’s a bad idea — it makes consumption code really hard.

But that's fallacious thinking. I'd suggest that it's roughly analgous to saying that typing variables is bad because it makes handling variables hard. Yes, it's "easier" to have dynamic typing silently converting for you; but it's dangerous.

Having well-typed REST resources makes sense, as they represent objects. REpresentational State Transfer. There's a tendency in every python REST framework I've looked at so far on this list to treat XML as serialization rather than state transfer.

The thing is, good toolchains for dealing with REST XML (an example I'd use would be scalaxb generating case classes from XSDs) empower programmers to use APIs in a less error-prone way. That, coupled with good practices like correctly content-typing the objects (ie, sending an address with something like application/vnd.sitename.appname.objectType+xml) means a firm definition for content types. It also allows a much more robust use; for example, an object can contain links (often in 0..n lists) which reference by content-type.

What's interesting is, the "worst practices" article cited by tastypie docs actually sort of follows a similar philosophy for links; it's a good practice to link to actual resources rather than something opaque like a list of IDs, but it's better to do so with a content-type so the client can know what it is requesting before it asks. (It's a bad practice, in fact, to assume a client can handle every type; strong content-typing avoids that)

Real xs:schema schemas for tastypie resources would be a fabulous improvement in my book. (It's actually something I'm probably going to work in in the next couple months; amazingly, someone already did some generator code; I'm hoping to just port that so that I can replace the tastypie schema generator with one that generates real XSDs.)

There are other reasons to use real XSDs; for example, some people might want to manipulate them with a tool like oXygen, an amazingly robust tool for generating/manipulating schemas; but it doesn't understand the random "xml soup" currently generated by tastypie. There are also constructs that, in w3c terms, have really interesting and potentially graceful interactions with Django's model handling; ie, party tricks with <xs:extension> come to mind. It's hard to express something like <xs:extension> in xml soup. My only other real issue is I'd like to be able to stipulate what is an element and what is an attribute; xml-soup generators tend to want to make everything elements, but that's sort of silly. Elements shouldn't used for something like a name. To go with the simplest example:

<Widget>
  <name>Cheddar Cheese Widget</name>
</Widget>

is bad, compared to

<Widget name="Cheddar Cheese Widget" />

<xs:attribute> is good for... well, attributes. <xs:element> is good for collections (whether 1..n or 0..n or 0..x, etc). Partially this is because elements themselves can (and should where appropriate) have attributes. It's funny, because the REST worst practices blog entry (which I largely think is smartly written) mentions "Resource != Model". Entirely true, and it may well make sense to include elements that are actually (in Django terms) models.

For example:

<System href="http://example.com/system/45" status="running">
  <Tasks>
    <Task status="running" startTime="2012-05-12 12:12:12"
      type="application/vnd.sitename.automata.task+xml"
      href="http://example.com/task/80085" percentComplete="45" />
  </Tasks>
</System>

This is a simple representation of a system and some sort of automated task associated with it.

Anyhoo, I'm getting awfully long-winded here, but, suffice it to say, I'd like to see a REST-XML framework that did real rest schemas, instead of a tag-soup xml serialization.