Bill de hÓra wrote:
James M Snell wrote:
http://www.intertwingly.net/wiki/pie/PaceReworkProtocolModel
-1. Section 5 could do with some qualifying text, but not all this. I
understand the current model well enough from pretty graphics btw, and
nothing lept out at me from this text other than it appears to be a
different model.
The only differences in the model at this level are:
a. Get on Collection URI returns an Atom Feed
b. Drop workspace introspection
Either can be achieved without the specific text in this pace.
In the current model, GET on the collection URI is left undefined which,
in my opinion, is a big hole.
Specification text does not belong in a model section (imo).
Fair enough
http://www.intertwingly.net/wiki/pie/PaceReworkCollectionMembership
-1. There's a claim that it "significantly simplifies the collection
model in the core protocol" but I don't see it myself. I do see an
assumption that a collection is a feed, which we need to discuss (and is
the main reason for -1).
Collection != Feed. A GET on the collection URI returns a feed. One is
the resource, the other is the representation.
This assumes that all collections are media collections unless otherwise
specified.
http://www.intertwingly.net/wiki/pie/PaceReworkCollectionListing
0. Possibly tag abuse tho'. I don't know what it means to subscribe to a
collection document and it isn't explained. Almost certainly overlaps
with next/prev stuff that has been going on over in atom syntax.
I'm not sure that anyone has suggested "subscribing to collection
documents". What has been suggested is using feeds to list collection
members. The only difference between this Pace and -06 is that
list-template is found in the collection feed rather than the
introspection doc and a feed is returned by GET on the collection URI.
Do you really think a collection is a feed?
Never suggested such a thing :-)
- James
