Yes, absolutely, a way to distinguish extensions-to-the-entry from
extensions-for-the-feed would be great, even if there's a possibility
that the server would reject one or both. I hadn't even considered
that, must have missed that discussion. Client-to-client extensions
(metadata or markup that the server can safely ignore and pass
through from author to feed consumer) seem very likely and useful in
Atom, even more so than in other applications I've compared to
(calendaring, file sharing, email).
I guess I can turn the flexibility argument around: imagine if Web
servers in 1995 rejected, just refused to store, anything that wasn't
defined in HTML 3.0; the Web never would have been as flexible as it
is today. Of course we can't require Web servers or Atom servers to
absolutely accept all content, but we can make it clear what the
expectation is and perhaps even offer safe ways of violating the
expectation.
Lisa
On Oct 17, 2006, at 4:31 PM, Eric Scheid wrote:
On 18/10/06 8:07 AM, "Lisa Dusseault" <[EMAIL PROTECTED]> wrote:
Extensions
When the client puts extension elements in a MER, MUST the server
store those
unrecognized extension elements? I think the answer to this is
actually that
servers often do not and should not be required to do so. That
makes it hard
for clients to extend AtomPub's syntax in ways that other clients
will
understand but servers don't care about. Consider the
consequences: when some
enterprising client developer decides to do something cool and
useful and
encounters servers that don't store their metadata in the obvious
place, the
client developer is going to quickly work around that by storing
in some
unobvious place. For example in HTML comments in the atom entry
content, or
microformats, etc. Is that all cool?
This issue also has implications on what extensions are passed
through to
the published feed ... a client might insert some extension
metadata they
want published (eg. geo-coordinates), and a client might insert some
extension metadata they only want visible within the collection
feed (eg.
editor workflow comments) ... with the understanding also that if
the server
actually understands a particular extension it might result in
extensions
being added/modified outside of the bucket (eg. <ext:include
trackbacks="yes" /> resulting in lots of <link/> elements being added)
We did at one time discuss providing a bucket container
specifically for the
latter, with the assumption that extensions outside the bucket are
data
elements meant for publication. Having a bucket container would
make life
simpler for server implementations -- just store everything as an
xml blob,
the same as they do for atom:[EMAIL PROTECTED]
Lisa, would that help?
e.
