Bob Wyman wrote:
2. I've been thinking that I might include an atom:summary element that
contained a textual version of the XML data carried in the content field.
However, it appears that most aggregators today display either the summary
or the content but don't display both...
The same is true of <content:encoded> and <xhtml:body> in the various RSS versions. I would include the summary.
One might reasonably expect they would show the summary if they don't support the content.
5. What should a client do when presented with this data? Clearly, there
are all sorts of interesting things that one can do if you know the format
and build a custom app. However, it would be nice to allow "dumb" clients to
do something useful without having to force the format to
lowest-common-denominator (i.e. HTML or XHTML). I think what I'd like to do
is provide a pointer to an XSL-template in some standard manner. Then, a
client could fetch the style sheet and generate something for display. Is
this reasonable? If so, where would I identify the style sheet?
This has been brought up before, people felt it was a security risk equal to object tags and javascript.
6. This kind of data is really sensitive. I would very much like to be able to use a Digital signature to ensure that we can repudiate any fake messages that might get generated by spammers and other idiots as well as to repudiate mangled versions of the data that might get produced down-stream of us. The subject of signing Atom entries doesn't seem to be getting much attention. Can we wake this one up again? I really do not think that signing should be considered something "outside the core" and subject to individual or proprietary extensions.
DSig and XMLEnc are in core. http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.7
Also, the pubsub namespace declaration should be on <Message>.
Robert Sayre
