Toru Marumoto write:
PaseReturnEntryInErrorResponse
== Abstract ==
Use the Atom Entry Document to express human readable descriptions
of failure conditions.
It's a nice idea, but unfortunately the requirements of RFC4287 make too
many fields compulsory that should be optional or possibly shouldn't be
included at all.
<title>Internal Server Error</title>
<summary>couldn't connect to the DB server.</summary>
<content type="html">[long winded explanation or trace log]</content>
<link type="text/html" rel="alternate" href="http://example.org/FooPu
blish/Docs/Errors/283.html"/>
This is cool if the server wants to produce nice comprehensive error
messages, but what if they just want to do something simple? They can't just
include an atom:title element, because RFC4287 requires either an
atom:content element or an alternate link, neither of which can really be
regarded as "simple".
<generator uri="http://www.example.com/FooPublisher";
version="1.0">Foo Publisher 1.0</generator>
<author><name>Foo Publisher</name></author>
I don't think atom:generator is valid as a child of atom:entry. You could
use atom:author as the sole representation of the generator, but that seems
like a bit of a hack. And you can't even leave out the author if you don't
like the idea since it's a required element according to RFC4287.
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
What purpose do these serve? Seems to me that they're also just there
because RFC4287 requires them to be.
Bottom line, there's way too much unnecessary cruft being forced into the
response because of RFC4287. If it was possible to ignore those
requirements, toss out a couple of elements, and make several others
optional, then maybe you'd have something. I very much doubt the WG would
approve that though.
Regards
James
