Well I share the concern because while developing amplee I ran into
issues like that. My conclusion was to apply HTTP error handling where I
could and where it made sense and leave the rest to the application
developer using amplee.
For instance return one of the 4xx error code when I meeting
On Mon, 27 Nov 2006 08:39:41 +0100, Sylvain Hellegouarch [EMAIL PROTECTED]
wrote:
Mind you considering that RFC 4287 is very clear on what makes an Atom
entry a valid one I imagine APP servers which don't have the necessary
context will decide to reject the request altogether.
Am I the
* Asbjørn Ulsberg [EMAIL PROTECTED] [2006-11-27 20:55]:
Am I the only one pondering and worrying about what the
different server implementations will respond to invalid client
requests (as, for example, an invalid Atom document)? How can
the client implementors be interoperable and compatible
I personally just think it's way too early for us to really be able to
say much about it. So far the APP implementations that have actually
been deployed seem to work rather consistently in that I can get a
single client (e.g. Abdera) to work with each with very little effort
and only minor
-1. The current spec is fine as is. It currently does not say anything
about whether or not the post entry MUST be valid although that is,
indeed the spirit of the spec. The spec does not say that servers MUST
reject entries that are not valid. Servers are free to accept or reject
entries as
James M Snell wrote:
-1. The current spec is fine as is. It currently does not say anything
about whether or not the post entry MUST be valid although that is,
indeed the spirit of the spec. The spec does not say that servers MUST
reject entries that are not valid. Servers are free to
On Wed, 22 Nov 2006 23:50:14 +0100, Sylvain Hellegouarch [EMAIL PROTECTED]
wrote:
[...] how would people feel about stating in the draft that the server
MAY (SHOULD?) reject an Atom entry which would be invalid as per
RFC 4287 ?
+1 to MAY, -1 to SHOULD.
I think at least a MAY would give
Hi folks,
Quick question regarding the atom:author element in a member resource.
Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author (which could be considered as not valid but that's not
the question here), now say that my app server does not have any
] On Behalf Of Sylvain
Hellegouarch
Sent: Wednesday, November 22, 2006 19:11
To: atom-protocol; atom-syntax
Subject: Author element best practice
Hi folks,
Quick question regarding the atom:author element in a member resource.
Say I POST an atom:entry to a collection URI, this entry does not have
* Sylvain Hellegouarch [EMAIL PROTECTED] [2006-11-22 12:25]:
do you think it'd be better to put an empty atom:name or to put
a dummy value such as 'anonymous' or 'n/a'?
Ugh. Dummy values are nasty, perverse and evil. Someone *will*
eventually suffer miserably if you pollute your data like
On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote:
Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author
If I were implementing the server, in this scenario I'd reject the
post with an error message. It's hard for me to see a scenario where
the
Tim Bray wrote:
On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote:
Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author
If I were implementing the server, in this scenario I'd reject the post
with an error message. It's hard for me to see a
Sylvain Hellegouarch wrote:
Tim Bray wrote:
On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote:
Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author
If I were implementing the server, in this scenario I'd reject the post
with an error
13 matches
Mail list logo
