* Aleksander Slominski <[EMAIL PROTECTED]> [2005-10-08 04:00]: > it is interesting that atom reader (in this case it seems to > SharpReader) is actually rendering text content of […] are atom > readers supposed to do that?
They’re certainly free to. Atom does not dictate what you do with the bits once you have them, it just tells you what they mean. > would it not be better to have a proper XHTML as content and > store EndpointReference directly as a child inside atom:entry? > after all EndpointReference is used by services and not Atom > GUI apps? No. Atom is not a weblog aggregation format. It can be used in that capacity, and certainly is the finest choice for that, but that is only one possible use case, and applications using Atom should not be bent around it. Putting the EndpointReference in the content is the right thing to do. Intermediaries and generic Atom stores can trivially pass it around and/or extract it and delegate it to attached format-specific processors correctly. If you put it directly in atom:entry, it becomes a structured extension element, and then suddenly you have much higher requirements of your entire infrastructure chain in order to get the same things done. > second comment is very difficult (or impossible) to know that > feed is actually representing "WS introspection" The namespace of the entries’ contents would be a bit of hint, no? > should there not be there a some (optional) element inside > atom:feed to indicate that feed contains (only) list of > EndpointReferences? An extension that allows one to define something like that sounds like a useful thing to have. (James?) The right term for this would probably be “role”. Or maybe “profile”, in the sense that it’s a constrained use of a more generic format. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
