On 1/27/06, James M Snell <[EMAIL PROTECTED]> wrote: > > > > 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.
I think that is fine, another constaint I would add to the one I already proposed is that every client should be able to handle every type of Text Construct. > 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. Agreed. I believe the server is allowed to modify the entry to fit the local requirements (unless it can advertise ahead of time it will reject such content). > 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. I am not suggesting that. I am suggesting a restriction on what the server can reject an entry for (assuming we don't add a way for the server to announce it's capabilities). > >>> "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. Yes. Accept/Role/etc. I don't care about names, but the server needs to communicate to the client what it will accept via POST. This is not a radical idea. On the HTTP level we have Accept-* headers that both the client and the server send. At the HTML level we have forms which include the 'enctype' attribute: http://www.w3.org/TR/REC-html40/interact/forms.html That example is particularly telling: A bit of hypertext served up by the server that tells the client what types of content it is willing to accept in a POST. This is exactly what I have proposed in the past for the introspection document. > 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? This is not a slippery slope. We have an interop problem and the stop criteria is very simple; we stop adding constraints when the interop problem goes away to the WG's satisfaction. We can either add constraints to all clients and servers or we can let a server announce what types of content it can handle. Either of those would solve the interop problem. If you have other suggestions; besides ignoring the problem which I don't believe is a legitimate option, I would very much like to hear them. -joe -- Joe Gregorio http://bitworking.org
