On 6/14/06, Kyle Marvin <[EMAIL PROTECTED]> wrote:
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'm worried about interop. Shortly after APP is released I expect to
see a plethora of extensions, most using namespaced elements in the
atom entry. It'll be another 'let a 1000 flowers bloom' period like
we saw for RSS 2.0.
But here comes the rub, client writers have no idea which APP endpoints
support which extensions. Yeah, sure, that in itself will show up as a
namespaced
extension element in the introspection document when the pain becomes
intolerable, but for now we've provided no guidance for
a client to figure out which extensions a server supports and they really
are now in a bind because:
1. Some servers, like GData, will reject new fangled namespaced elements.
2. Others will accept and store them.
3. Still others will accept and drop them.
4. The poor client writer is totally borked, the client can't ask
the server, the server can't tell the client, and the
client can't even guess and go by trial and error since
we haven't standardized on an error reporting format.
Please realize we have the same problem in the other direction too,
what if a server adds support for a newfangled namespaced element
and the client silently drops it while doing a GET/PUT editing cycle?
Or does the client just pop up an error and refuse to edit an entry
when it encounters foreign markup?
In general we have two classes of data - atom elements and foreign
markup - and we need to determine both client and server expectations
for handling them during editing.
Scenario 1:
======
Client does a GET, edits the entry, then PUTs it back.
We need to answer the following questions:
SHOULD/MAY/MUST the client preserve atom:id, atom:updated, etc? Each one
of these needs to be answered one by one.
SHOULD/MAY/MUST the client preserve foreign markup?
Scenario 2:
======
Client does a PUT then a GET on the entry just updated.
We need to answer the following questions:
SHOULD/MAY/MUST the server preserve atom:id, atom:updated, etc? Again
we need an answer for each element.
SHOULD/MAY/MUST the server preserve foreign markup, etc?
Of course, the other option is to give up on trying to set client
and server expectations and provide no guidance on the
preservation/editability of elements in an entry, but even then
we need to add text to spec that states we are explicitly providing
no guidance.
Sorry that answer was long-winded and tedious and in the
end provided no guidance on a solution, but I want to make
sure we are on the same page and agree that we have a problem.
Thanks,
-joe
--
Joe Gregorio http://bitworking.org
