Joe Gregorio wrote:
On 1/27/06, James M Snell <[EMAIL PROTECTED]> wrote:
Joe Gregorio wrote:
How is a client supposed to detect that a server
rejects any entry with a title/@type="xhtml"?
I know that's probably going to be rare, but iti is currently
allowed since there is currently no spec text which states:
May not be as rare as you think. The APP implementation I'm currently
working on is being grafted over an existing data model in which titles
are, you guessed it, text only. Markup in titles is not allowed. If
you pass in markup, it would come out as escaped text. Rather than lose
data by dropping the tags and changing the type to text, we're rejecting
the posts with a 403 Forbidden (possibly changing to a 422).
Hmm, besides being a clear violation of Postel's law,
how is my client supposed to detect/recover from this?
Better question: how would your client deal with things if I strip
markup and change the type to "text"... e.g. you pass in <title
type="xhtml"><div><a href="http://foo";>bar</a></div></title> and all you
get back is <title type="text">bar</title>? Because that is exactly what
would happen if we didn't reject the post.
There are two ways of viewing the APP server implementation. a) as a
generalized content database that should just store all of the data it's
asked to store (e.g. like a web server serving up Web pages) or b) as
an integration layer on top of an existing application layer. If I'm
implementing my APP server as nothing but a content store, the
expectation that the server will accept whatever the client sends is
appropriate. If I'm implementation my APP server as an integration API,
there must be an expectation that the server may need to restrict input
to match up with the capabilities and configuration of the underlying
applications data model.
For instance, suppose I want to implement an APP-to-email bridge that
maps the title of entries to the subject line of an email. When I POST
an entry, the email is generated and sent. Should I accept title
elements that contain markup? Is the server required to maintain the
content of the title exactly as the user provided?
The protocol should place no constraints on what the server MUST do with
regards to entry content.
"A server MUST NOT reject a POSTed entry because of the
choice of @type for any of it's Text Constructs."
This would be a mistake. Implementations should have the sole
discretion as to what kinds of inputs they will allow; the protocol
should not be dictating content requirements.
The server can reject based on other criteria, such foul language,
text length restrictions, etc, but unless
the server is able to announce the kinds of Text Constructs
it is willing to accept I think this is a reasonable constaint
that will aid interop, otherwise clients will quickly converge
to the least common denominator (text) and we won't have
gained anything by using Atom as a base.
Ok, then we've come back, more or less, to the idea of an accept
attribute in the introspection doc. Unfortunately, this is a bit of a
slippery slope. What kind of content can be in title elements? summary
elements? rights elements? Will the server even preserve summary and
rights? (ours won't given that the underlying data model doesn't) What
kind of content can be in the content element? Is referenced content
allowed? And why stop at just content, will the server preserve
published dates? updated dates? Does it persist all of the links? Does
it persist categories? And if so, does it also persist the scheme and
label attributes? How about author and contributor elements?
We can make reasonable assumptions for each of these about APP
implementations written from the ground up to operate as Atom content
stores. It gets a whole lot more difficult when we're talking about APP
implementations written as an integration layer on top of existing data
models that may simply not have any means of dealing with specific types
of inputs.
- James
