2006/6/15, Joe Gregorio <[EMAIL PROTECTED]>:
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.
I'd rather say we have *three* classes of data:
- markup from the Atom Vocabulary defined in RFC4287
- markup from the Atom Vocabulary, which are not defined in RFC4287
- markup from other vocabularies
Using your 2 classes, it wasn't clear whether "unrecognized Atom
markup" is in the "atom elements" or "foreign markup" class.
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.
Let's start by answering the first ones:
- atom:id: MUST, and servers MUST reject entries with a different
atom:id on PUT.
- atom:updated: "might": atom:updated indicates "the most recent
instant in time when an entry or feed was modified in a way the
publisher considers significant", the key word here is "publisher",
which APP should not constraint to the "publishing server".
Authors/editors should be able to change this value to tell future
readers that the entry has changed in a way he considers significant.
(note that I'm not forbidding some server implementations to manage
this field by themselves).
SHOULD/MAY/MUST the client preserve foreign markup?
MUST
(foreign markup here being any unrecognized markup, whether it's from
the Atom Vocabulary or not)
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.
Again, for the mentionned ones:
- atom:id: N/A: see above, clients MUST preserve it, servers MUST
reject any attempt to change it
- atom:updated: "might": see above. The implementation behavior,
however, should be clearly documented.
SHOULD/MAY/MUST the server preserve foreign markup, etc?
SHOULD (same as entity-headers at the HTTP level)
mapping from Atom to another schema can be a valid reason not to store
foreign markup.
The answer might be different for unrecognized markup from the Atom
Vocabulary and other foreign markup. I'm wondering if unrecognized
markup from the Atom Vocabulary shouldn't result in an error… but that
could hurt interop because a client sending Atom 1.1 or Atom 2.0 won't
be able to communicate with a server knowing no more than Atom 1.0…
--
Thomas Broyer
