RE: Can we make Atom:Author, Atom:Title, Atom:Summary, Atom:updated and Atom:id optional?

[Yaron Goland <yarong@xxxxxxxxxxxxx>]

To Nikunj's comment - I recognize that the changes I'm asking for would require changing the RFC and/or introducing a new content type. The real question I'm trying to get to is - do enough people have problems similar to ours that introducing another content type makes any sense? I don't know.

To Tim's Comment - That sounds like a reasonable trade off. Our concern actually isn't in clients sending placebos to the server since obviously we can deal with that as we want. I'm much more concerned about us sending down bogus/empty data down to the client. I hate having to throw in a bunch of bogus values just to be standards compliant. The fact that I need to throw in bogus values seems to say that something is wrong. Either the data we are pushing out shouldn't be in ATOM or ATOM shouldn't be requiring people pushing out data such as ours to put in bogus values.

My guess however is that ATOM got it right. As an outsider coming to the ATOM party the thing that really struck me about ATOM is that it's a really neat way to address the problem of letting people interact with loosely structured data whose semantics their ATOM reader/editor may not understand. Suddenly people can browse heterogeneous data sources and have a good shot at being able to understand what they are seeing and in many cases even have a good shot at being able to edit the data even though their ATOM reader/editor has no clue what the actual semantics of the data is. In that context the mandatory ATOM properties make sense because they provide common information points that can help a user figure out what is happening.

But it still leaves us in an odd place because our scenarios don't really fit the previous.

                Yaron

> -----Original Message-----
> From: Tim.Bray@xxxxxxx [mailto:Tim.Bray@xxxxxxx]
> Sent: Wednesday, June 20, 2007 8:51 PM
> To: Yaron Goland
> Cc: atom-protocol@xxxxxxx
> Subject: Re: Can we make Atom:Author, Atom:Title, Atom:Summary,
> Atom:updated and Atom:id optional?
>
>
> On Jun 20, 2007, at 4:54 PM, Yaron Goland wrote:
>
> >
> > Below I walk through a number of mandatory ATOM elements and
> > explain that in many cases we either have no useful value for these
> > elements
>
> The WG took up this problem at some length, because lots of people
> have this issue.  It is obvious that in many cases, servers will
> ignore the client's opinion about the value of <author>, <id>,
> <updated>, and so on. In which case, why require the client to
> provide them?  Largely, because the cost of generating "placebo"
> values is low and the costs of defining a whole new data format,
> RFC4287++, with some elements made optional, is substantial.  Right
> now the spec can say "Post an Entry (see [RFC4287])" and the
> implementor only has to go look in one place.  In practical terms, I
> suspect that few server implementations will reject an entry because
> it's missing an ID field, but in practice careful client implementors
> will provide placebo values.  -Tim
>
>