We went round and round arguing this a while back and
I have no interest in repeating it again, please
check that archives for the whole discussion.
Thanks,
-joe
On 7/5/06, Henry Story <[EMAIL PROTECTED]> wrote:
Can someone remind me why we have to liter the web with one more xml
format and mime type? The more of these there are the more likely
tools are going to break on the sophisticated differences between
formats and their interrelations? Is this something that is really
needed? Is there something in the Service document that is sooooo
amazingly new and different that it needs its own format?
So what does the Service document bring to the table? Let us look and
see if we have something really different...
1. Collections are just types of feeds. When you get a Collection
document [1], (the href thing) you receive a feed. Feeds are linked
lists because of the next and previous links, so they are collections
too. They are feeds with an extra property: an optional accept mime
type restriction. This information
could easily be placed on the <feed> document themselves.
2. All the rest of the stuff <service> documents with workspaces, and
collections seems arbitrary to
me and out of scope of the specification. Why do we need to group
this information together like this. What is the point? The service
idea seems like a throwback to some xmlrpc idea, where you need to have
a service at an end point.
So let me guess. From the example there is a main information and a
sidebar. This seems to be very much related to one use case, which is
writing about a web log. Why could that information not just appear
in the html? One just needs a notation to specify that the feed
location for the sidebar is at
some place and that the feed location for the entries are at some
other place. When those feeds get downloaded they just specify how
they can be edited.
Again the whole point of the Service document escapes me somewhat.
Henry
[1] http://groups.google.com/group/atom-owl/browse_frm/thread/
b0bc3bf2ad7edaae/ed75c368d3dc1202?q=APP&rnum=4#ed75c368d3dc1202
--
Joe Gregorio http://bitworking.org
