On 6/14/06, Joe Gregorio <[EMAIL PROTECTED]> wrote:
On 6/14/06, James M Snell <[EMAIL PROTECTED]> wrote: > > So as an implementor who is mapping APP and Atom onto a pre-existing > relational data model, I would have to scan every entry in every request > for any elements and attributes my implementation is incapable of > storing rather than just looking for the bits and pieces I do understand > and am capable of handling, effectively rendering Atom's Must-Ignore > extension semantics absolutely useless to me as a server developer and > consuming additional server resources for what reason again? Exactly, this is what I meant when I said that this made APP a must-understand protocol.
Must-store and must-understand are different things, at least to me. I can store XML content w/out understanding it's semantic significance to the client. An APP store might support and store client-namespaced data w/out understanding its meaning... but if it doesn't do that (store), I feel obligated to let the client know that. There's a difference between a very permissive APP service (ex, a generic Atom aggregator) and a more narrowly constrained one (ex. a Calendar service that expects entries w/ specific content constraints), but in both cases, when they accept an entry its accepted intact. I don't understand James relational DB-exposed-as-Atom example. If I try to set a column that a DB can't match to the underlying schema using SQL, I get an error. Why woudn't I expect the same if I did so via an Atom mapping over SQL relational data? Wouldn't you parse the input data for the bits you do persist (to store them) and isn't it possible to recognize that there are exceptions? Is there really extra work there? Honestly, I'm not religious about this issue, but I'd feel better if someone gave me one real world use case that I could get my arms around. -- Kyle
